DeepSeek Harness system prompt sections in a DSH plugin

A DSH plugin adds to the system prompt not by concatenating a string field but by registering contributors through ctx.systemPrompt, which one assembly call resolves, orders, and renders into a surface node (source). This article covers the four contribution kinds and their ordering, why the prompt is "surface node 0" rather than a request field, and the authority and ceiling of the assemble waterfall; where the prompt comes from and why it grows is explained in the system prompt explained, while this article covers the contract a developer must implement.

The four kinds of contribution and their ordering in a DSH plugin system prompt

The system prompt assembly package manages the data exchanged between prompt contributors and one assembly call, across four contribution kinds: section, context, tools, and variable (source).

1. section — the prompt text itself. A PromptSection has a unique name (duplicate registration throws), an order (concatenated ascending, with equal orders using code-unit name order), text (a static string or a provider evaluated at each assembly, referencing {{variable}}s interpolated later by renderPrompt), and an optional complete.
2. context — the cache-safe counterpart of a section, materialized as a durable user-role snapshot; a PromptContext is likewise unique by name, joined in ascending order, and empty text contributes nothing.
3. tools — a tool schema provider returning a ToolProviderResult: schemas is the schema set visible to the model in this assembly, and knownNames is the pre-restriction name universe used to tell a typo in configuration from a known tool deliberately hidden in this scope.
4. variable — a prompt variable whose name matches [a-z][a-z0-9_]*; the provider may return undefined, but rendering a section that references that value then fails.

Ordering is two-stage: sections first sort by ascending order, then by code-unit name order. Repository contributors resolve their centrally owned placement via getSectionOrder() (such as DEPLOYMENT_PERSONA_PREFIX / DEPLOYMENT_PERSONA_SUFFIX), and runtime-context contributors resolve a separate allocation via getContextOrder(). By scope, scoped sections and variables shadow same-named globals, and duplicates within one layer and non-finite orders both throw.

A DSH plugin system prompt is surface node 0, not a request field

After cooperative assembly, one effective complete section becomes the sole prompt section; the agent loop renders the sections with renderPrompt and submits the text as the system/message surface node (source). There are three ways it is submitted:

1. First step — appended as surface node 0.
2. When the rendered text changes — the node is replaced in place.
3. Sequence continuation where the prepared call declares systemPromptUpdate: 'in-history' — the non-empty update is appended after the cached history.

The key takeaway: the system prompt reaches the model as a message in the derived history rather than a request field. Changing the prompt therefore means replacing or appending a surface node, not editing a request header — which is why prompt changes flow through the log and replay uniformly.

The context path is more restrained: assembly resolves and orders those contributions, but the agent loop records it after the retained model history only when the full current snapshot changes or compaction removes it.

The authority and ceiling of the DSH plugin assemble waterfall

system-prompt/assemble is an expert waterfall over the assembled sections, contexts, tools, and variables with scope-filtered dispatch, so scoped listeners receive only that scope's assemblies and the returned value is authoritative (source). Three boundaries cannot be crossed:

1. A complete section is restored after the waterfall — if an effective complete section is registered, assembly restores it as the sole prompt section after the waterfall, so listeners cannot add to or replace that scope's system prompt. More than one effective complete section makes assembly fail.
2. The signal belongs to this assembly only — the signal the waterfall receives controls only this explicit assembly request and must not be retained to control later turns.
3. Reserved names and suppression — a tools() provider returning the reserved TOOL_ORDER_REST name makes assembly fail; suppressRuntimeContext() can suppress every dynamic runtime-context contribution in the calling context's scope without changing the services that own or enforce those facts, and multiple suppressors remain independently disposable.

Also: system-prompt/change is an unfiltered registry notification (a global change affects every scope); ctx.systemPrompt.assemble(context) assembles global and scoped providers, detaches tool parameters, applies canonical ordering, runs the waterfall, then enforces any complete section.

Three self-checks when done: is name unique and order finite; when replacing the whole prompt, did you use complete instead of mutating the waterfall result; and did you avoid caching signal to control later turns. To find community implementations of prompt plugins, search the DSH Plugin Hub; for extension-point ownership see the feature-to-mechanism map.