dsh-plugin-dev-workflow

dsh plugin --profile web add dsh-plugin-dev-workflow

DSH Dev Workflow

<p align="center">

<img src="assets/workflow-infographic.svg" width="920" alt="人设 · 看板 · 流程：想法如何落进项目里的只追加记录">

</p>

<p align="center">

<strong>一个人 + 一个 AI，也能做出有章法的东西。</strong><br>

选一个人设开始聊想法，它记下你的原话、拆成任务、真跑一遍验证 —— 换 session、隔一周回来，都还接得上。

</p>

<p align="center">

<a href="https://www.npmjs.com/package/dsh-plugin-dev-workflow"><img src="https://img.shields.io/npm/v/dsh-plugin-dev-workflow?color=44403c&label=npm" alt="npm version"></a>

<a href="https://github.com/yuna78/dsh-plugin-dev-workflow/actions"><img src="https://img.shields.io/github/actions/workflow/status/yuna78/dsh-plugin-dev-workflow/ci.yml?label=CI" alt="CI status"></a>

<a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-44403c" alt="MIT license"></a>

</p>

DSH 的轻量开发 workflow 插件。 三个零件：一个会记账的人设（preset）、一块只读看板、一条

Request → Feedback → Task → Verify → Completion 的流程。为「一个 plugin、一个小工具、一个人的小应用」

而做 —— 不是给大团队用的研发管理平台。

---

先说清楚它是给谁的

适合 · 一个 plugin、一个脚本、一个自己每天会用的小应用；想法还很模糊，想先聊出来再定；对话横跨几天、几个 session；你一个人，或者两三个人，不需要 Jira 和站会

不适合 · 多人协作的正式研发项目（没有角色、权限、代码评审、CI 集成，也不打算做）；需要合规审计与跨团队流程治理的场景；期待「一句话自动生成整个产品」的场景

一句判断标准：如果你的项目能用「我一个人 + 几个晚上」描述清楚，它就是为你做的。

如果你需要的是「谁在什么时候改了哪行、走什么审批流」，请去找 Issue 系统 —— 这个插件不解决那个问题，也不假装能解决。

你是不是也这样

• 想法是散步时冒出来的，坐回电脑前只剩一句「那个东西挺好的」。
• 前天说清楚了需求，今天 AI 又问一遍「你希望在哪个页面改？」。
• 「应该跑通了吧？」—— 然后发现根本没跑过，或者跑过但忘了退出码是几。
• 一个功能改了五轮，第五轮和第一轮到底哪句话算数，翻聊天记录也翻不出来。
• 上周那个 session 里的结论，这周开新窗口就人间蒸发了。

这些不是模型不够聪明，是上下文和决策没有落盘。这个插件做的事很朴素：把你亲口说的话、定下来的事、

真跑过的命令，留在项目目录里，并且让 agent 每次都先读它。

它做三件事

一、人设：一个会记账的搭档

新建会话时选 preset「研发助手 · Dev Assistant」。它不是任务清单机器人，也不是「自动驾驶按钮」，

而是换了性格的工作协议：

• 你说需求，它先存原话（rawQuote，不改写、不润色），再问你验收条件；
• 你给反馈，它留你的原话 + 决策（接受 / 拒绝 / 延后），并且不会把一次偏好悄悄升级成团队规范；
• 它不说「应该测过了」—— 要么有命令和退出码，要么这条任务不算完成；
• 破坏性动作（推送、发布、删数据）先停下来，把风险摊开给你选。

核心优先级写在 persona 里：安全硬边界 > 仓库规范 > 项目目标 > 用户偏好 > 本次需求。

二、看板：想法不再埋在聊天里

左侧边栏点「研发看板」，就是这个工作区的全部记录：

• 四列：需求（未终结的：你的原话 + 验收）、待办（已建任务）、待确认（waiting-user，需要你点一下头）、已完成。已交付/作废的需求由 dev_request_close 给终态，不再占着需求列。
• 三个过滤：进行中 / 已完成 / 全部，计数与列表同源，不会各算各的。
• 只读：看板只调一个 GET 路由，只打开 <工作区>/.dsh-dev/ 里那几个已知 JSONL，不写任何记录。
• 换个工作区即换项目：记录按项目隔离，一个人同时维护几个小项目也不会混。

三、流程：五步，每一步都能被回看

你的原话 ──→ 可执行任务 ──→ 真实命令 ──→ 带证据的收口
         ↘ 反馈与决策 ↗          ↘ 可复盘的知识 ↗

步骤 · 落下来的东西 · 为什么重要

Request · 原话、范围、验收条件 · 三天后还知道当初到底要什么

Feedback · 原话、决策、影响 · 改主意是被记录的，不是被遗忘的

Task · 步骤、依赖、风险、验收 · 下次接着做，不用重新推理

Verify · 命令 + 退出码 + 结果 · 「完成」有证据，不靠形容词

Completion · 变更文件、证据、风险、未完成项 · 交接给人或交给未来的自己

一个想法的一生

下面是一段示意（脱敏改写），每一步都对应真实存在的记录结构：

Day 0  21:40  你：我想做个小插件，把当前窗口的标签页收成一个清单，能导出 markdown。
                    先能跑就行，别装依赖。

              → 需求登记（原话照抄）
                验收：读得到当前窗口标签页 / 能导出 .md / 不新增依赖

       21:52  → 拆成 3 个任务：读标签页、生成 markdown、写一个 smoke 门禁

       22:20  实现跑起来了。验证记录：node verify/smoke.mjs  exitCode 0

Day 1  09:10  新 session。你：顺手加个按域名分组吧。
              → 反馈登记（原话）+ 新任务「按域名分组」，依赖前面那个拿标签页的任务

Day 3  回来只问一句：「上次导出格式定的是哪个？」
              → 上下文摘要：需求 2 条、进行中任务 3 个、最近反馈 1 条 —— 不用你复述

关键不在于它记住了多少，而在于你从来不需要复述。切换 session、隔一周、换一台机器（把项目目录带过去就行），

接续的成本是一次 dev_context_get。

它为什么不会「聊着聊着就丢了」

persona 写在上下文开头，回合一长就会被工具结果挤远。我们在真机会话里量到过：dev_context_get 在第 1 秒就调用了，

dev_request_capture 却拖到 +86 秒、第 40 次工具调用之后，dev_feedback_record 整轮没触发。

所以插件做的不只是一段提示词：

1. 运行期提醒：通过 agent/pre-step，在第 1 步以及之后每 5 步往请求历史里追加一条带当前项目

真实记录计数的提醒（需求 2 · 任务 3 · 反馈 1 · 验证 1 · 完成 0），附带执行顺序。它只读

<project>/.dsh-dev/，不写状态，读取失败原样放行，不会让回合挂掉。

2. 原话优先：rawQuote 存的是你打的字，不是它总结的版本。失真从第一行就被拦住。

3. 记录跟着项目走：<project>/.dsh-dev/*.jsonl，append-only，只追加不改写，git diff 之外多一条可回滚的证据轴。

4. 有界摘要：dev_context_get 只给项目目标、未完成任务、最近反馈 —— 不把半年历史一次性灌进上下文。

60 秒上手

1. 装：

   DSH「Add plugin」里搜 dsh-plugin-dev-workflow

或者：

   plugin_manager install_bundle target=dsh-plugin-dev-workflow

本地开发时：plugin_manager install_bundle target=<本目录绝对路径>

2. 新建会话，选 preset「研发助手 · Dev Assistant」。不要手写 profile 的 package.json 或 cordis.patch.yml。

3. 用平常的话说想法。第一句话不需要格式，比如「我想把 X 做得更顺手一点，先看看现在什么样」。

第一次用最值得观察的一点：它会先问验收条件，再动手。如果你觉得它问得多，那是这套流程在起作用 ——

一个说不清「怎样算做完」的需求，最后一定会以「这不是我要的」收场。

工具箱

工具 · 干什么

dev_context_get · 读项目上下文、未完成任务与最近反馈（有界摘要）

dev_request_capture · 保留用户原话与验收条件；缺验收时只做澄清登记，不自动开工

dev_request_close · 给需求终态：delivered（已交付）/ invalid（已作废）/ superseded（已被取代）；append-only 追加状态行，需求列不再陈列已终结需求

dev_feedback_record · 记录反馈原话与决策，不自动升级为长期规范

dev_task_plan · 建任务：步骤、依赖、风险、验收；破坏性范围可标 waiting-user

dev_verify · 记录真实命令与退出码，exitCode 由调用方给，不接受伪造 succeeded

dev_complete · 汇总完成内容、变更文件、证据、风险与未完成项；没有通过证据只能是 partial，没有你确认只能是 waiting-user

dev_knowledge_promote · 只在你明确确认后沉淀偏好或规范，默认 proposed，可撤销

记录到底长什么样

本地 append-only JSONL。下面是脱敏示例，不是预置数据：

{"schemaVersion":1,"requestId":"req_7f21","rawQuote":"把登录页的错误提示改得更清楚","acceptance":["空密码显示字段级提示","错误提示不泄露账号是否存在"],"status":"captured"}
{"schemaVersion":1,"feedbackId":"fb_12ac","requestId":"req_7f21","rawQuote":"文案要短一些，但保留可操作建议","decision":"accept","category":"quality","status":"recorded"}
{"schemaVersion":1,"taskId":"task_91de","title":"更新登录错误提示","acceptance":["单元测试覆盖两种错误分支"],"status":"queued"}
{"schemaVersion":1,"verificationId":"verify_44aa","taskId":"task_91de","command":"npm test -- login","exitCode":0,"status":"passed"}
{"schemaVersion":1,"completionId":"completion_08c1","taskId":"task_91de","status":"succeeded","verificationRefs":["verify_44aa"]}

<your-project>/.dsh-dev/
├── requests.jsonl      你亲口说的需求（原话 + 验收）
├── feedback.jsonl      你的每次反馈与决策
├── tasks.jsonl         任务、依赖、风险
├── verifications.jsonl 命令与退出码
├── completions.jsonl   收口总结
└── knowledge.jsonl     被确认过的偏好（默认只是候选）

纯文本、可 grep、可 git diff：想看就打开，想比就 diff，想接自己的脚本就随便接。

边

…(truncated)