dsh-custom-instructions
每个工作区使用一个系统提示：DSH 设置面板中的“自定义指令”页面，可将你的长期指令添加到每个会话中。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:ztl0001/dsh-custom-instructions#214f4a184f8f3c66882b2c0788fe15f7e0f3089bCustom Instructions 以 dsh-custom-instructions 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
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.
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.
| 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.
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.
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.
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. |
>=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.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.
MIT