前言¶
在 DSH（DeepSeek Harness）里用智能体做功能开发，常见问题是：进度散落在聊天记录里，换会话就丢上下文；规格写得很满，却缺少硬门禁，实现阶段照样跑偏；多角色并行时，测试、实现、验收边界模糊，质量靠模型自觉。生态里已有大量规格驱动或角色编排类插件，有的靠 LLM 自查「写完了没」，有的用代码矩阵拦写入，有的用机器 verdict 直接放行。
下面介绍维护者 SHADOW-LI0327 的工作流插件 dsh-process-kit：把需求包状态、门禁签署、流程与 bug 记录写进目标仓库的 docs/process/**，插件只做确定性读取、渲染、安全追加与脚手架落地，不在插件侧另存状态。阶段推进在 Gate0/1/2/4 等人手确认；机器门禁只判客观可验证项，主观裁量留给人。
这是什么¶
dsh-process-kit 是面向任意仓库的开发流程增强插件，分类为工作流（workflow）。它为 DSH 增加一套文件驱动的工程化流程：内置多角色 Subagent 技能（当前仓库版本为 9 个角色；npm 已发布 0.5.0 为 8 个角色，0.6.0 含 architect 尚未发布），配合 scripts/process/ 门禁脚本与 process_init 初始化工具。许可证 MIT；GitHub 仓库 SHADOW-LI0327/dsh-process-kit，社区目录页 SkillHub 条目。
与「规格驱动、不做硬门禁」或「机器直接阻断」的做法不同，这里强调三条：状态入仓（docs/process/** 为唯一真源，CI 不装插件也可消费契约）、防篡改 journal（链式指纹，读取侧重算并如实报红）、两段式 Gate 摘要（✅ 完成了什么 / ❓ 还需要裁定什么）。0.4.0 起流程看板改为纯服务端 bundle，不再依赖独立 GUI 状态看板。
核心功能¶
文件状态机与工具¶
进度写在 docs/process/** 各文档的 frontmatter 里。每轮唤醒可调用 process_status 扫描目录，恢复每个包的状态、Gate 四灯、journal 尾部、未关闭 bug 与建议下一步，不依赖聊天历史。
| 工具 | 作用 |
|---|---|
process_status |
扫描 docs/process，汇总包状态与下一步 |
gate_summary |
为指定包生成 Gate 两段式摘要骨架（✅ / ❓ 待填） |
process_journal |
安全追加 journal：锁、指纹校验、原子替换 |
process_init |
将流程骨架与脚本落到当前仓库；默认只创建不覆盖 |
process_init 会生成（或升级时按规则处理）：
docs/process/：流程总纲、orchestrator.md、PROJECT.md、PRD 与核对件模板等scripts/process/：journal-append.mjs、check-artifact-paths.mjs、check-rules.mjs、check-ui-geometry.mjs、sync-prd-version.mjsAGENTS.md：仅当不存在时创建；已存在则不改写，只输出待合并段落（可用agents: false跳过）
Gate 与角色分工¶
Gate 在 Gate0/1/2/4（需求核对、设计、开发、验收）停下做人签；每次输出两段式摘要。角色在提示词层面分工，交付质量由 Gate 人裁承担；项目内 .dsh/skills/** 同名技能可覆盖插件自带技能。环境变量 PROCESS_KIT_SKILLS=off 可关闭插件技能注册。
9 个角色（版本演进见 README）：product-manager、architect（0.6.0）、test-agent、dev-agent、uat-agent、code-review-agent、security-review-agent、logic-review-agent、ui-designer。写实现的不写测试，写测试的不做验收；三个评审角色默认只在「发布前整体回归」由人显式发起时派出，未发起则不会自动跑。
Gate0 前可按需并行 product-manager 与 architect 做公开文档/GitHub 借鉴调研，候选进核对件、不直接进 AC；ui-designer 由核对件 uiDesign: required / not-needed 决定是否参与。
配置与门禁¶
流程文档不硬编码项目路径与命令，统一引用 docs/process/PROJECT.md。插件升级永不覆盖该文件及 ui/tokens.md、ui/recipe.md 等项目可定制文件。§3 产物属主表为硬门槛，未填会导致落点门禁 exit 1。最小可用需填 §1、§2（至少「快速验证」与「journal 追加」）、§3。
安装与启用¶
插件以 DSH 进程权限运行，安装前建议阅读仓库源码与 MIT 许可证。Node 要求 ^22.19.0 || >=24.0.0；peer 依赖 @deepseek-ai/dsh >=0.1.7-rc.2 <0.3.0。
README 给出的安装 target 如下（在 DSH 插件安装流程中使用对应 target；装完后一般无需重启客户端）：
| 方式 | target |
|---|---|
| npm（推荐） | dsh-process-kit |
| GitHub | github:SHADOW-LI0327/dsh-process-kit（锁版本可用 #<tag> 或 #<commit>） |
| 本地目录 | 插件源码的绝对路径 |
npm 上最新为 0.5.0；仓库 0.6.0 未提交/未发布。若使用 pnpm 11/12 且新版本发布未满 24 小时，可能因 minimumReleaseAge 解析不到最新版，可等待、钉死版本如 dsh-process-kit@0.4.0，或在 pnpm-workspace.yaml 的 minimumReleaseAgeExclude 中排除该包。
典型用法¶
快速开始步骤（摘自 README）：
1. 安装插件（安装即生效，无需重启）。
2. 告诉 AI 想做什么，比如想做一个网站、做一个 app 等。
3. AI 自动初始化当前环境：调用 process_init。
4. 按流程进行开发。
5. 第一个包建议走快速路径：需求核对件写 flow: fast，人签 Gate0 后直接派 dev + 存量回归；顺手后再上全流程。
已有仓库升级前先预览再落地：
process_init({ upgrade: true, dryRun: true }) // 先看会动哪些文件
process_init({ upgrade: true }) // 再落地
端到端示例在独立仓库 dsh-process-kit-example；验收与开跑步骤见主仓 docs/ACCEPTANCE.md。
适用场景与注意¶
适合希望在任意 Git 仓库里用「仓内 Markdown + 脚本」固定 AI 协作节奏、又希望 Gate 与 journal 可审计、可被 CI 消费的单人或小团队。不适合期望插件在运行时实时拦截每个文件写入、或完全无人参与的全自动发布流水线。
注意：process_init 默认只创建不覆盖；数据目录 input/**、prd/**、bugs/** 等升级时不触碰。三个评审 Subagent 不会出现在单包主路径里，除非人发起发布回归或在 Gate 上点名。若需 architect 或完整 9 角色，需从 GitHub main 安装或等待 0.6.0 发布。
DSH 生态理念是「一切皆插件」；SkillHub 为社区目录，与 DeepSeek / 幻方无官方从属关系。
结尾¶
dsh-process-kit 把开发流程落成仓库内的文件状态机与人签 Gate，用门禁脚本约束客观项、用角色技能分工提效，状态与证据留在 docs/process/** 便于复算与协作。目录页：https://www.skillhub.cn/plugins/SHADOW-LI0327/dsh-process-kit；源码与文档：https://github.com/SHADOW-LI0327/dsh-process-kit。
