← 返回列表
✓ 可直接安装
SpecWorkflow 是一套可分享的 workflow skill pack,面向 DeepSeek…
自动检查通过:npm 包已发布且 engines 声明满足基线;该结论来自程序自动检查,未经人工实机验证。 · 最近上游提交 2026/8/16 · 已提供中文文档
DSH 工作流技能包:需求、规格、实现、评审、修复、缺陷与研究
综合分
32.9
GitHub 分
32.9
用户评分
—
★ Stars
4
周下载量
—
安装插件(需先安装 dsh CLI 引擎:npm install -g @deepseek-ai/dsh)
dsh plugin --profile web add specworkflownpm 包 specworkflow 已校验归属本仓库,走 npm 安装最省事
数据截至 2026/9/19(元数据每日更新 · 实装验证按队列轮转,单条结论的验证时间见上方)
安装兼容性检查✓ 自动检查通过
以下结论由程序自动检查 npm 包、engines 声明与入口文件得出,未做人工实机验证——能装不等于用着没问题。
✓npm 包specworkflow @ 0.1.0
✓Node 引擎未声明 engines.node
✓dsh CLI 依赖未声明 dsh 版本约束
✓入口文件main/exports/bin 已声明
验证方式:npm registry 存在性 + package.json 静态校验 · 最后验证 2026/9/19 01:12:23
依赖的 DSH / Cordis 模块
@deepseek-ai/dsh-skill-filesystem用户评分
还没有人投票,来当第一个
订阅周报,不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动
README
SpecWorkflow SpecWorkflow 是一套可分享的 workflow skill pack,面向 DeepSeek Harness 和其它兼容 Agent Skills 的工具。它给 Agent 一条清晰路径:从粗糙需求开始,推进到需求澄清、实施规格、代码执行、交付检查、修复规划、bug 诊断和带来源的调研。 它不会把每个请求都拖进重流程。简单明确的修改可以直接处理;需求模糊、跨模块、影响产品体验、数据、权限、接口或发布风险的工作,才进入完整 workflow。 SpecWorkflow Architecture 功能 | 阶段 | Skill | 处理内容 | | --- | --- | --- | | 调研 | deep-research | 基于官方文档、API、标准、源码等一手来源做调研。 | | 1 | to-grill | 需求质询、消除歧义、风险审查,并判断直接实施还是进入完整流程。 | | 2 | to-spec | 编写可实施 spec、修订说明、验收标准、验证计划和可选 tickets。 | | 3 | spec-do | 根据已批准的 spec、issue、修订或修复计划进行实施。 | | 4 | do-review | 对照需求、spec、代码和证据做最终交付检查。 | | 5 | fix-review | 把 must-fix review findings 转成修复 spec 和修复 tickets。 | | 调试 | bugs-fix | 针对 bug、回归和性能问题做复现、根因定位、修复和证据留存。 | 安装 DSH dsh plugin --profile web add specworkflow dsh web 其它 Agent npx specworkflow install codex 使用 -g 安装到全局目录: npx specworkflow install -g codex 需要时把 codex 换成其它预设: | 输入 | 项目安装位置 | -g 全局安装位置 | | --- | --- | --- | | codex, openai, agents, agent, agent-skills, agents-md, goose, zed, amp, sourcegraph-amp | .agents/skills | ~/.agents/skills | | gemini, gemini-cli, antigravity, google-antigravity | .agents/skills | ~/.gemini/antigravity/skills | | claude, claude-code, claudecode | .claude/skills | ~/.claude/skills | | cursor, cursor-agent, cursor-native | .cursor/skills | ~/.cursor/skills | | copilot, github-copilot, vscode, vs-code | .github/skills | ~/.github/skills | | dsh, deepseek, deepseek-harness | .dsh/skills | ~/.dsh/skills | | opencode, open-code | .opencode/skills | ~/.opencode/skills | | windsurf, cascade | .windsurf/skills | ~/.windsurf/skills | | cline, claudine | .cline/skills | ~/.cline/skills | | roo, roo-code, roocode | .roo/skills | ~/.roo/skills | | qwen, qwen-code, qwencode | .qwen/skills | ~/.qwen/skills | | kiro | .kiro/skills | ~/.kiro/skills | | kilo, kilo-code, kilocode | .kilo/skills | ~/.kilo/skills | | augment, augment-code, augmentcode, auggie | .augment/skills | ~/.augment/skills | | openclaw, claw | skills | ~/.openclaw/skills | 未识别的纯名称会直接报错,避免因为拼错而创建错误目录。如果当前工具不在预设里,请传入明确的项目级 skills 路径: npx specworkflow install .my-agent/skills 带 -g 时,相对显式路径会从用户 home 目录解析。 快速开始 典型功能开发: 使用 to-grill 澄清这个需求,需求收口后再进入 to-spec。 简单修改保持简单: 把表格字体调大一点。 这类请求应该直接实施,不应该强行进入五阶段流程。 工作流 SpecWorkflow 的第一步不是写 spec,而是判断这件事值不值得进入 spec。很多请求本来就很小,比如改一段文案、调一个样式、补一个明显遗漏的判断;这类工作应该直接完成。 只有当需求开始牵涉产品含义、数据语义、权限边界、跨模块影响、发布风险,或者“做错了会很难收拾”时,才进入完整流程。同一件事产生的材料都放在同一个 .spec-workflow// 目录下,后续每一轮都能接得上。 to-grill -> to-spec -> spec-do -> do-review -> fix-review -> spec-do repair -> do-review to-grill 负责把模糊需求压实。它不是机械提问,也不是把仓库里能查到的事实甩给用户确认;它会先自己读上下文、找现有实现、识别真正需要用户拍板的地方。到这一阶段结束时,应该已经知道这件事是直接改、暂缓、还是进入 spec,并留下可以交给下一步使用的需求结论。 to-spec 把结论变成实施契约。好的 spec 不只是“要做什么”,还要写清楚不做什么、哪些模块会受影响、数据和权限怎么处理、用户最终会看到什么、验收时看哪些证据。如果是在已有 spec 上做调整,它会记录修订和影响范围,而不是把历史上下文抹掉重写一份。 到 spec-do 才真正动代码。实施前先处理 git 分支、脏工作区和是否允许自动提交;实施时按已批准的 spec、tickets、修订或修复计划推进。临时证据、调试脚本、截图和运行记录可以放进 .spec-workflow,但长期存在的测试必须回到项目自己的测试目录。这里有一条硬规则:业务逻辑要真实接上,不能为了让验证变绿而 mock 掉系统本身。 实现完成后,do-review 接手判断能不能交付。它会把原始需求、spec、代码 diff、测试和证据放在一起看,找遗漏、回归、边界和验收缺口。review 不是顺手修代码的阶段,也不应该暗中扩大范围;它只负责给出清楚的 ship / no-ship 判断。 如果 review 发现必须修的问题,fix-review 会把这些 finding 收束成修复计划。它关心根因、优先级、验证方式和是否需要拆 ticket,然后把修复计划交回 spec-do。修完以后再回到 do-review,形成一个很短的闭环;直到结果可以交付,或者下一步确实需要用户做决定。 deep-research 和 bugs-fix 不属于主链上的固定阶段,更像两条随时可以插入的支线。遇到外部事实、官方文档、API 行为、标准差异时,先用 deep-research 把依据找齐;如果起点不是新需求,而是失败、回归、异常或性能问题,就直接走 bugs-fix,先复现和定位根因。 Goal Mode 是给单个 spec 用的连续执行开关。用户明确启用后,Agent 可以从实施一路跑到 review、修复规划、修复实施和再次 review,不必每个交接点都停下来等确认。但它不是无限授权;遇到产品选择、安全风险、git 决策、验证缺口、环境问题或 scope 变化时,仍然要停下来。 目录产出 SpecWorkflow 把 workflow 文件放在 .spec-workflow 下,避免把项目代码和 Agent 证据混在一起。 .spec-workflow// requirements.md spec.md issues/ amendments/ implementation/ review/ repair-spec.md repair-issues/ verification/ debug/ bugs/ research/ 项目长期测试仍然放在项目原本的测试目录,不放进 .spec-workflow。 验证 安装到 DSH 后运行: dsh --profile web --dump-config 组合配置里应该出现: == specworkflow - id: specworkflow name: specworkflow 也可以直接询问 Agent 当前有哪些 SpecWorkflow skills,以及什么时候使用 to-grill。 卸载 dsh plugin --profile web remove specworkflow 把 web 换成你实际安装的 profile。 许可证 MIT. See LICENSE.
扫码进群