DeepSeek harness dsh system prompt

DeepSeek harness (dsh) system prompt

One-liner

There is no single authored system-prompt file. In deepseek-ai/deepseek-harness (dsh), the model-facing system text is assembled per agent step by @deepseek-ai/dsh-system-prompt from ordered plugin sections + tool schemas + variables, then delivered as a durable system/message surface node — not as a chat-API system request field.

Related vault note (prompt-collector landscape, different product): 2026-09-28 Grok Bot system prompts collectors

---

What “dsh” is

Product	DeepSeek Harness — open-source agent runner (“everything is a plugin”), Cordis-based
Repo	deepseek-ai/deepseek-harness (MIT; topics dsh, dsh-plugin, ai-agents, cordis)
CLI / npm	npx @deepseek-ai/dsh web · package @deepseek-ai/dsh
Docs	Official reference · product home deepseek.com/harness · plugin index dsh.pub
Status	Developer preview; breaking changes expected (README, SAFETY.md)
Snapshot	master tip 4878cdab (2026-09-28 19:48 CST / 11:48Z) — release note 0.2.0-rc.1; @deepseek-ai/dsh-system-prompt 0.2.0-rc.1

Not a DeepSeek Chat website system prompt, and not a model-weights RLHF template. It is the harness’s runtime prompt pipeline for coding/agent sessions (tools, sandbox, plan mode, workspace AGENTS.md, presets).

Alternatives briefly: community explainers such as dsh-in-depth.com/core/system-prompt mirror the architecture but lag the API (still mention older persona / order -100 in places). Prefer the repo files below. Unrelated “dsh” hits (other products/acronyms) are out of scope.

---

Where the “system prompt” lives

Primary implementation:

• packages/core/system-prompt/src/index.ts — SystemPrompt service (ctx.systemPrompt), assemble(), renderPrompt(), section/context order tables
• Package docs: packages/core/system-prompt/README.md
• Cross-package types: docs/subsystems/system-prompt.md
• Loop wiring: docs/architecture.md (turn/step flow: assemble at agent/pre-step, once per step — not every retry)

Ownership principle (Agent Note): prompt variables & tool-guidance ownership — each fact has one owner (identity vs persona vs per-tool section vs schema description).

Fixed harness opener (only hard-coded identity line)

Registered as section harness:identity at named order HARNESS_IDENTITY (−1000), when includeHarnessIdentity: true (default):

You are an AI agent powered by DeepSeek Harness.

Source: constructor in index.ts. Disable only for compatibility deployments that own a complete: true prompt.

Deployment persona slots

Config on @deepseek-ai/dsh-system-prompt (current master):

Field	Section name	Order	Default in dsh-base
personaPrefix	deployment:persona-prefix	0	'' (packages/bundle/base/cordis.patch.yml)
personaSuffix	deployment:persona-suffix	10200	''
includeRuntimeContext	—	—	true
toolOrder	—	—	omitted ⇒ lexicographic tool names; if set must include rest marker <unlisted-tools>

Per-agent override: mount @deepseek-ai/dsh-persona inside an agent preset to shadow the same section names (prefix / optional suffix / complete / includeRuntimeContext). Global mount collides with the registry’s own persona registration.

Templates support strict {{variable}} interpolation at render time ([a-z][a-z0-9_]*). Unknown / undefined / malformed refs throw (fail assembly rather than ship a bad prompt). Loop-supplied variables include model and cwd (plus others plugins register).

---

Assembly model (not a static blob)

Four contribution kinds on ctx.systemPrompt:

1. section() — system-role prose (ordered, join with blank lines after interpolate)
2. context() — dynamic facts → user-role runtime-context snapshots (separate from system text)
3. tools(provider) — ToolSchema[] for the model-visible tool catalog (also part of PromptAssembly)
4. variable(name, provider) — values for {{…}}

Pipeline (assemble → optional system-prompt/assemble waterfall → restore complete section if any → renderPrompt):

1. Merge global + agent-scope layers (scoped same-name sections/variables shadow globals)
2. Collect tool schemas; detach/clone parameters; apply toolOrder
3. Sort sections by ascending order, then code-unit name
4. Run scope-filtered waterfall (listeners may rewrite assembly)
5. If one section has complete: true, it becomes the sole system section after waterfall (tools/contexts/variables still from waterfall); multiple completes ⇒ hard fail
6. renderPrompt: interpolate, drop empty sections, join with \n\n

Delivery to the model (critical difference vs chat): agent-loop commits rendered text as a system/message surface node in the session log / derived history (node 0, or in-history append when systemPromptUpdate: 'in-history'). The HTTP request does not carry a separate system field — the prompt is reconstructable from the session log’s request/header + surface nodes.

Runtime-context snapshot opener (when contexts present):

Current runtime context. This snapshot supersedes earlier runtime-context snapshots.

Contexts are suppressed by includeRuntimeContext: false or suppressRuntimeContext() without disabling the services that own sandbox/approval state.

---

Canonical section order bands

Named allocation in SECTION_ORDERS (index.ts) — contributors must use getSectionOrder() / getContextOrder():

Order name	≈	Typical content
HARNESS_IDENTITY	−1000	Fixed “powered by DeepSeek Harness”
DEPLOYMENT_PERSONA_PREFIX	0	Deployment / preset persona
PLAN_POLICY	500	Plan-mode soft guidance (plan:policy)
TEAM_POLICY	600	Agent-team policy (experimental)
PTC_ONLY	800	Programmatic tool-calling guidance
FILE_REFERENCE	900	File-reference UX
TOOL_BASH … TOOL_COMPUTER_USE	1000–3000	Per-tool cross-call habits
MCP_SERVERS	3100	MCP server context
TOOLS_SDK	5000	Generated tools SDK prose
DELIVERABLE_FILE_REFERENCES	9000	Deliverables
STRUCTURED_OUTPUT	9900	Structured output
HARNESS_SOURCE	10000	Local harness source path hints
WEB_SURFACE	10100	Web GUI surface contract
DEPLOYMENT_PERSONA_SUFFIX	10200	Late persona suffix

Runtime context orders: SANDBOX_POLICY 110, APPROVAL_POLICY 115, SUBAGENT_DELEGATION 120.

---

Key behaviors the assembled prompt encodes

Identity / style

• Minimal first-party identity (one sentence). Behavioral “personality” is deployment/preset persona, not the harness opener.
• Shipped dsh-base leaves personaPrefix empty — a live Web/CLI session’s chatty persona comes from presets / overlays, not from a baked novel in dsh-system-prompt.

Tools & schemas

• Each tool plugin registers (a) a schema via the tools registry / ToolRuntime auto-provider and (b) often a short cross-call system section.
• Example — bash (packages/shell/tool-bash):

Check the [exit code: N] marker on every bash result; investigate failures before moving on.

• Example — fs tools (packages/fs/tool-fs README Model Experience): prefer read over cat; read-before-write/edit under observation policy.
• Tool guidance sections often gate on visibility (ctx.tools.get(name, scope)) so restricted agents drop prose that doesn’t match their schema set.
• Schema description owns one-call semantics; prompt sections own habits a single description can’t carry.

Plan mode (richest shipped deployment prose in base)

dsh-plan-mode contributes plan:policy at order 500 only while active. Base bundle ships a long soft-guidance section (explore/design, no mutating implementation, use exit_plan_mode as sole final tool call, etc.) in cordis.patch.yml. Explicitly not enforcement — sandbox + approval stay independent.

Workspace instructions (user-role, not system sections)

@deepseek-ai/dsh-agent-instructions injects $DSH_HOME/AGENTS.md + project AGENTS.md/CLAUDE.md (+ local overlays) as durable <system-reminder> user messages (budget maxBytes: 65536 in base). Lower authority than system/developer/direct user instructions.

Web surface (when Web profile mounts)

Web app registers app:web-surface (~order 10100): model is told it is interacting via the DeepSeek Harness Web GUI at a local URL, with no implicit DOM/route/screenshot context (packages/bundle/web-app/src/index.ts).

Safety / host policy vs model prose

• SAFETY.md is a human/operator warning (experimental code execution, sandbox limits, no warranty) — not a long model refuse/allowlist block in harness:identity.
• Model-visible policy arrives mainly as runtime-context snapshots (sandbox mode, approval policy) plus tool result markers ([sandbox: file access denied under mode], escalation via sandbox_permissions + justification).
• Default permission posture in base: workspace-write + approval ask (env-overridable).

---

How this differs from plain DeepSeek chat prompts

	DeepSeek Chat / API chat	dsh harness
Shape	One optional system string (or product-owned chat template)	Composable registry of ordered sections + tools + variables
Tools	Optional function-calling fields on the request	First-class PromptAssembly.tools; loop executes via ctx.tools
History	Client-managed messages	Append-only session log; system prompt is a surface message
Identity	Product chat persona	Fixed one-line harness identity + empty/default persona + plugins
Workspace	Usually none	AGENTS.md chain as sourced user reminders
Extensibility	Prompt string edit	Mount Cordis plugins / presets / system-prompt/assemble waterfall
Reconstructability	Opaque unless logged	Exact past prompt reconstructable from session request/header + nodes

Using DeepSeek models inside dsh still goes through adapters (dsh-llm-deepseek-*); the harness prompt is orthogonal to whatever system string chat.deepseek.com uses.

---

Harness loop (related config)

From architecture turn flow: claim inbox → assemble prompt + tool schemas → agent/pre-step → prepare call → reconcile system/message → append users → derive history → stream LLM → tool pipeline → next step. Retries inside a step do not re-run assembly. Profiles (web, headless, sdk, sdk-minimal, acp) compose bundles; dsh --profile web --dump-config dumps the live Cordis tree.

---

Sources

• deepseek-ai/deepseek-harness README
• packages/core/system-prompt/src/index.ts · README
• docs/subsystems/system-prompt.md · docs/architecture.md
• packages/bundle/base/cordis.patch.yml (plan-mode section, empty personaPrefix, tool mounts)
• packages/preset/persona · packages/shell/tool-bash · packages/plan/plan-mode · packages/context/agent-instructions
• SAFETY.md · dsh.pub system-prompt plugin · commit 4878cdab
• Secondary (slightly stale API details): dsh-in-depth system-prompt

Gaps / uncertainties

• No single canonical “full prompt dump” in-repo — by design the rendered text is composition-dependent (profile, presets, plan on/off, tool restrictions, persona overlays). Capturing one live assembly requires running dsh and reading session log / request/header.
• Default Web/CLI agent persona prefix for the stock “standard” preset was not fully enumerated here (base ships empty; presets live under agent-preset composition and may change rapidly in preview).
• GitHub code-search / third-party mirrors still surface older APIs (persona vs personaPrefix/personaSuffix, identity order -100 vs −1000, deployment:persona vs deployment:persona-prefix). Prefer raw master files; note dated Agent Notes may lag.
• Chat.deepseek.com / API product system prompts are out of scope and not published in this harness repo.
• Secondary sites (dsh-in-depth, mirrored “docs” domains) should not be treated as version-pinned primary sources.