dsh-custom-instructions
Verifieddsh-custom-instructions · v0.1.0 · MIT · Web UI
One system prompt for every workspace: a Custom instructions page in DSH's Settings panel that adds your standing instructions to every session.
Install
dsh plugin add dsh-custom-instructions Confirm the layer applied with dsh --profile default --dump-config — see the install guide.
Source
Tags
Readme
English | 中文
dsh-custom-instructions(自定义指令)
给 Agent 的长期指令,对所有工作区生效:在 DeepSeek Harness 自己的设置面板里新增一个 「自定义指令」页面,页面里的文本会加入该 profile 下每个会话的系统提示词。
它就是 DSH 版的 Codex 自定义指令 —— 一处写下「始终用中文回答」「优先用 pnpm」 「未经说明不要改写我的文件」;区别在于文本进入的是每次组装出来的系统提示词,而不是某个 项目里的文件,所以它对所有工作区、所有新会话、以及子代理都生效,不需要逐个项目配置。
安装
dsh plugin add dsh-custom-instructions
然后刷新 Web 界面,进入 设置 → 自定义指令。
通过插件管理器安装(设置 → 插件,或插件市场)是热生效的,不用重启宿主,只需刷新浏览器
即可看到新页面。如果是手工把包写进 profile 的 dsh.profile.bundles,则必须先完全退出 DSH,
因为 bundle 与 patch 层只在启动时合成。
使用
| 控件 | 作用 |
|---|---|
| 启用自定义指令 | 总开关。关闭后仍保留文本,只是不再注入。 |
| 用标题引出这段文本 | 默认开启。标题(User custom instructions)让模型知道这段要求来自你;如果文本本身就是完整的提示词片段,可以关闭。 |
| 指令内容 | 文本本身。留空则不注入,所以「全选删除再保存」也是一种真正的关闭方式。 |
保存后,Agent 下一次组装请求时即生效;正在进行的会话会在下一轮拿到新内容。
页面显示的是实际状态,而不只是开关:会注入时显示「已生效」,开关关闭显示「已停用」, 文本框为空显示「未生效」。
值存在哪里
这三个字段是 volatile 配置字段,因此写入会走 DSH 的设置文档,持久化在该 profile 的 patch 文件里(位于 DSH 主目录下)—— 一份文档被该 profile 的所有工作区共用。 不会向任何项目目录写入内容,也不会创建或修改项目级文件。
它如何进入模型
插件只注册一个 systemPrompt 段落:
| 属性 | 取值 | 原因 |
|---|---|---|
name |
custom-instructions |
全局只注册一次,不会被任何 scope 遮蔽。 |
order |
100 |
紧跟部署人设前缀(0),位于所有策略与工具段落(500 起)之前:长期指令属于「Agent 是谁」,而不是工具说明旁边的补充。 |
interpolate |
false |
提示词是普通散文,完全可能包含 {{ 和 }};否则assembler 的严格变量语法会替换它或直接报错。文本按字面处理。 |
text |
每次组装时解析 | 设置写入后,下一次组装的提示词即可见,无需重启。 |
assembler 会丢弃空段落,这正是「关掉开关」和「清空文本框」能让内容从请求中消失、 而不是留下一个孤立标题的原因。
配置
可以在上面的页面里编辑;也可以直接写在 profile 的 patch 文件里
(~/.dsh/profiles/<profile>/cordis.patch.yml):
- id: dsh-custom-instructions
name: dsh-custom-instructions
config:
enabled: true
wrapHeading: true
instructions: |-
始终用中文回答。
优先使用 pnpm 而不是 npm。
| 字段 | 类型 | 默认值 | 含义 |
|---|---|---|---|
enabled |
boolean | true |
是否注入任何内容。 |
wrapHeading |
boolean | true |
是否用标题引出文本。 |
instructions |
string | "" |
指令内容,纯空白等同于空。 |
环境要求
- DSH
>=0.1.0-rc.7 <0.3.0-0(设置表单、settings.section页面插槽、提示词段落注册表)。 上界是刻意的:后续小版本可能改动本插件所依赖的规则,安装被明确拒绝比运行中出问题更容易理解。 - Web 界面:该页面是浏览器端插件。宿主部分在没有设置界面的组合里同样会注册段落, 所以文本照常生效,只是没有地方编辑它。
开发
npm run link:peers # 把受限的 peer 指向正在运行的 profile 中的副本
npm test # 决定「什么内容会到达模型」的规则
npm run check # 两侧语法检查 + 测试
npm run release:check # 市场收录前的机械自检(含 YAML 与 BOM 两类静默陷阱)
lib/config.js 保存了关于注入文本的全部规则,并被直接测试;lib/index.js 是 schema
加一次注册;client/client.js 是预构建的浏览器 bundle(相对平台模块表写的纯 JavaScript,
无需构建步骤)。
有两个检查之所以存在,是因为它们对应的是静默失败而不是报错:scripts/release-check.mjs
会拒绝一份 YAML 解析器会一声不响丢掉的 bundle patch(多了一个 tab,或 config: 的子键写成了
同级键);scripts/verify-bundle-resolves.mjs 则证明列表里的包在 profile 下确实能解析并
import——「名字在列表里」和「包能加载」是两件事,而栽在后者上的启动失败看起来就是什么都没发生。
test/plugin.test.js 交给插件的是一份 Cordis 风格的 Context:读任何未声明的属性都会抛错。
这不是花架子:把实时配置读成 ctx.config 会在插件加载期抛错,而 DSH 的启动是 all-or-nothing,
所以插件只能读自己的配置参数,别的都不能碰。
许可证
MIT