dsh-custom-instructions
English | 中文
Standing instructions for the agent, in every workspace: a Custom instructions page inside
DeepSeek Harness's own Settings panel, whose text is added to the system prompt of every session
in the profile.
It is the DSH equivalent of Codex's custom instructions — one place to say "always answer in
Chinese", "prefer pnpm", "never rewrite a file without telling me first" — except the text lands in
the assembled system prompt rather than in a per-project file, so it applies to every workspace,
every new session, and every subagent, with nothing to configure per project.
Install
dsh plugin add dsh-custom-instructions
Then reload the Web GUI and go to Settings → Custom instructions.
Installing through the plugin manager (Settings → Plugins, or the market) takes effect without
restarting the host; only the browser needs a reload to pick up the new page. Hand-editing a
profile's dsh.profile.bundles instead requires quitting DSH completely first — bundle and patch
layers are composed at startup.
Use
| Control | What it does |
|---|
| Enable custom instructions | Master switch. Off keeps the text but injects nothing. |
| Introduce the text with a heading | On by default. A heading (User custom instructions) lets the model attribute the block to you; turn it off when the text is itself a complete prompt fragment. |
| Instructions | The text itself. Empty injects nothing, so deleting everything is a real way to switch the feature off. |
A save takes effect on the next request the agent assembles. Sessions that are already running pick
it up on their next turn.
The page shows the effective state, not just the switch: Active when something will be
injected, Disabled when the switch is off, Inactive when the box is empty.
Where the value lives
The three fields are volatile configuration fields, so a write goes through DSH's settings
document and persists in the active profile's patch file under the harness home — one document
shared by every workspace of that profile. Nothing is written into a project directory, and no
project-level file is created or edited.
How it reaches the model
The plugin registers one systemPrompt section:
| Property | Value | Why |
|---|
name | custom-instructions | One global registration, so nothing shadows it per scope. |
order | 100 | Immediately after the deployment persona prefix (0) and before every policy and tool section (500+): standing instructions are part of who the agent is, not an afterthought beside tool documentation. |
interpolate | false | A prompt is prose that may legitimately contain {{ and }}; the assembler's strict variable grammar would otherwise substitute or reject it. The text is literal. |
text | resolved per assembly | A settings write is visible to the next assembled prompt without restarting anything. |
The assembler drops empty sections, which is how the off-switch and the empty box remove the text
from requests instead of leaving a stray heading behind.
Configuration
Editable in the page above; the same fields can be set by hand in the profile patch
(~/.dsh/profiles/<profile>/cordis.patch.yml):
- id: dsh-custom-instructions
name: dsh-custom-instructions
config:
enabled: true
wrapHeading: true
instructions: |-
Always answer in Chinese.
Prefer pnpm over npm.
| Field | Type | Default | Meaning |
|---|
enabled | boolean | true | Whether anything is injected at all. |
wrapHeading | boolean | true | Whether the text is introduced by a heading. |
instructions | string | "" | The instructions. Whitespace-only counts as empty. |
Requirements
- DSH
>=0.1.0-rc.7 <0.3.0-0 (the settings form, the settings.section page slot, and the prompt
section registry). The upper bound is deliberate: a later minor release may change rules this
plugin was written against, and a refused install is easier to understand than a broken one.
- The Web GUI: the page is a browser-side plugin. The Host half alone still injects the section in
every other composition, so the text applies even where there is no settings UI to edit it.
Develop
npm run link:peers # point the restricted peer at the running profile's copy
npm test # the rules that decide what reaches the model
npm run check # syntax of both halves, then the tests
npm run release:check # what the plugin market's gate checks, including YAML and BOM traps
lib/config.js holds every rule about the injected text and is tested directly; lib/index.js is
the schema plus one registration; client/client.js is a prebuilt browser bundle (plain JavaScript
against the platform module table, no build step).
Two checks exist because their failures are silent rather than loud: scripts/release-check.mjs
rejects a bundle patch a YAML parser would drop without a word (a tab, or a config: whose keys are
siblings), and scripts/verify-bundle-resolves.mjs proves a listed bundle actually resolves and
imports from the profile — because "the row is in the list" and "the package loads" are different
facts, and a boot that dies on the second one looks like nothing happened at all.
test/plugin.test.js hands the plugin a Cordis-shaped context that throws on any undeclared
property. That is not decoration: reading the live configuration as ctx.config throws during
plugin load, and DSH's boot is all-or-nothing, so the plugin must read its configuration argument
and nothing else.
License
MIT
