前言¶
用 DSH 做一个小插件、脚本或自用工具时，常见的问题不是模型不够聪明，而是上下文和决策没有落盘：前天说清的需求，新 session 里 AI 又问一遍；「应该跑通了吧」其实没有命令和退出码；改了几轮需求，聊天记录里找不出哪句话算数。Issue 系统和 Jira 对「一个人 + 几个晚上」的项目又偏重。下面介绍社区插件 dsh-plugin-dev-workflow（维护者 yuna78，分类：工作流）：在 DSH 里提供研发助手 preset、只读看板，以及 Request → Feedback → Task → Verify → Completion 五步流程，把原话、任务和验证证据 append-only 写在 <工作区>/.dsh-dev/ 里，换 session 或隔一周回来仍可接续。
这是什么¶
dsh-plugin-dev-workflow 是 DSH 的轻量开发 workflow 插件。README 用一句话概括：Lightweight dev workflow for DSH: a dev-assistant preset, a read-only kanban, and decisions that stay in the repo（研发助手 preset、只读看板、决策留在仓库侧的项目目录里）。
三个零件：
- 人设：新建会话时选 preset「研发助手 · Dev Assistant」，按协议先存用户原话（
rawQuote）、再问验收条件，破坏性动作先停下来让你选。 - 看板：左侧边栏「研发看板」，只读展示需求 / 待办 / 待确认 / 已完成，数据来自
.dsh-dev/下已知 JSONL，不写记录。 - 流程：五步落盘，agent 通过
dev_*工具写入；另有agent/pre-step在第 1 步及之后每 5 步注入带真实计数的运行期提醒，减轻「聊很久才登记需求」的问题。
记录全部在本地，无账号、无云端、无遥测。插件以当前 DSH 进程权限运行；安装前建议自行查看 GitHub 仓库 源码与 MIT 许可证。社区目录 skillhub.cn 为独立站点，与 DeepSeek / 幻方无官方从属关系。
核心功能¶
人设与优先级¶
preset 不是任务清单机器人，核心行为包括：需求先存原话再澄清验收；反馈留原话与决策（接受 / 拒绝 / 延后），不悄悄把一次偏好升级成团队规范；任务完成要有命令和退出码，否则不算完成；推送、发布、删数据等破坏性动作先摊开风险。persona 里写的优先级为：安全硬边界 > 仓库规范 > 项目目标 > 用户偏好 > 本次需求。
看板¶
四列：需求（未终结的原话 + 验收）、待办、待确认（waiting-user）、已完成。已交付或作废的需求由 dev_request_close 给终态，不再占需求列。过滤：进行中 / 已完成 / 全部。看板只调 GET 路由，只读 <工作区>/.dsh-dev/；换工作区即换项目，记录按项目隔离。
五步流程与工具¶
| 步骤 | 工具（节选） | 落盘内容 |
|---|---|---|
| Request | dev_request_capture |
原话、范围、验收；缺验收时只做澄清登记 |
| Feedback | dev_feedback_record |
原话、决策、影响 |
| Task | dev_task_plan |
步骤、依赖、风险、验收 |
| Verify | dev_verify |
命令、退出码（由调用方提供，不接受伪造 succeeded） |
| Completion | dev_complete |
变更、证据、风险、未完成项 |
另有 dev_context_get（有界摘要：项目目标、未完成任务、最近反馈）、dev_request_close（delivered / invalid / superseded）、dev_knowledge_promote（仅在你明确确认后沉淀偏好，默认 proposed）。
本地目录结构（append-only JSONL）：
<your-project>/.dsh-dev/
├── requests.jsonl
├── feedback.jsonl
├── tasks.jsonl
├── verifications.jsonl
├── completions.jsonl
└── knowledge.jsonl
README 建议不要把 .dsh-dev/ 提交进 Git，也不要写入密钥或客户资料。
明确不做的事¶
不适合多人正式研发（无角色、权限、代码评审、CI 集成）、合规审计、云同步团队看板、自动 git commit / npm publish。若需要「谁在什么时候改了哪行、走什么审批流」，应使用 Issue 系统，本插件不替代该类平台。
安装与启用¶
兼容性（资料原文）
- DSH：
>=0.2.1-rc.2 <0.3.0 - Node.js：
>=22.19.0 - 插件当前版本：
0.2.6
安装
在 DSH「Add plugin」里搜索：
dsh-plugin-dev-workflow
或使用 plugin_manager：
plugin_manager install_bundle target=dsh-plugin-dev-workflow
本地开发插件本身时：
plugin_manager install_bundle target=<本目录绝对路径>
启用
- 新建会话，选 preset「研发助手 · Dev Assistant」。不要手写 profile 的
package.json或cordis.patch.yml。 - 用平常话术想法即可，例如「我想把 X 做得更顺手一点，先看看现在什么样」。第一次使用时通常会先问验收条件再动手。
典型用法¶
接续上下文时，agent 可先调用 dev_context_get，无需你复述上周结论。下面是一段 README 中的示意流程（脱敏改写），对应真实记录结构：
Day 0 你：我想做个小插件，把当前窗口的标签页收成一个清单，能导出 markdown。先能跑就行，别装依赖。
→ 需求登记（原话照抄），验收：读得到标签页 / 能导出 .md / 不新增依赖
→ 拆任务并实现；验证：node verify/smoke.mjs exitCode 0
Day 1 新 session：顺手加个按域名分组
→ 反馈登记 + 新任务，依赖先前任务
Day 3 只问：「上次导出格式定的是哪个？」
→ 上下文摘要给出需求、进行中任务、最近反馈
记录示例（脱敏，非预置数据）：
{"schemaVersion":1,"requestId":"req_7f21","rawQuote":"把登录页的错误提示改得更清楚","acceptance":["空密码显示字段级提示","错误提示不泄露账号是否存在"],"status":"captured"}
{"schemaVersion":1,"verificationId":"verify_44aa","taskId":"task_91de","command":"npm test -- login","exitCode":0,"status":"passed"}
适用场景与注意¶
适合：一个 plugin、一个脚本、自用小应用；想法模糊想先聊再定；对话跨多个 session；一个人或两三个人，不需要 Jira 和站会。判断标准：项目能用「我一个人 + 几个晚上」描述清楚。
不适合：多人协作正式项目、合规与跨团队流程治理、期待一句话自动生成整个产品。
安全与权限：插件与 DSH 同进程，能读写当前工作区；dev_* 工具只追加不改写历史，但不替代你对源码和行为的审查。安装前阅读仓库与许可证是必要步骤。
结尾¶
dsh-plugin-dev-workflow 把「原话、决策、命令证据」放进项目里的 .dsh-dev/，用 preset、运行期提醒和只读看板让 agent 每次先读再干，适合轻量、单人向的 DSH 开发节奏。
