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