SPARV 五阶段开发工作流
用 Specify→Plan→Act→Review→Vault 五个阶段和外部记忆文件，把模糊需求一次性推进到可验证交付，避免凭假设写代码。
加分项：EHRB 高风险检测要求显式用户确认，PreToolUse 钩子用 --dry-run 只提示不写状态，脚本仅操作项目内 .sparv/ 目录，无网络外发、无凭据读取、权限范围最小。扣分项：PostToolUse 钩子在每次 Edit/Write/Bash 等工具调用后静默执行 save-progress.sh，用户确认粒度粗；init-session.sh 使用 --force 但文档未解释覆盖后果；未提供回滚/卸载 .sparv/ 状态的说明；发布者身份未经核实，来源归属仅到个人邮箱。
加分项：已展示的脚本（check-ehrb.sh、failure-tracker.sh、changelog-update.sh、archive-session.sh）参数校验、错误输出和退出码设计良好，失败会给出可诊断信息而非静默失败。扣分项：静态读无法执行验证；SKILL.md 声称状态在 .sparv/state.yaml 根路径，而 archive-session.sh 在 .sparv/plan/<session_id>/ 下查找会话，两处约定不一致；init-session.sh、save-progress.sh、reboot-test.sh 及 lib/state-lock.sh 未在证据中提供，关键路径无法复核；仓库 CI 只覆盖 codeagent-wrapper，不含 sparv。
加分项：场景（单项目需求→交付流程）、触发命令 /sparv、Quick/Full 路由条件、固定阶段名均明确声明，脚本含中文关键词（身份证/银行卡/权限）风险检测。扣分项：未声明不适用边界（如非软件任务、无 TDD 环境的项目）；10 分 spec 门槛的主观评分可能导致误触发或卡死在 Specify 阶段；无中文文档说明。
加分项：SKILL.md 与 README 层次清晰、含安装/卸载命令、版本号 1.1.0 与 plugin. 一致、脚本有 usage 与示例、仓库有 AGPL-3.0 LICENSE。扣分项：skill 自身无 CHANGELOG 或版本历史记录（仅有写入 CHANGELOG 的工具）；维护责任与更新路径依赖未验证的仓库整体；部分行为（钩子静默吞错 || true）属隐藏假设。
加分项：外部记忆（journal/state）+ 失败升级 + 风险确认的组合在静态层面看能减少盲目迭代，价值主张清晰。扣分项：静态审阅无法验证实际产出可直接使用；价值依赖 LLM 自评 spec 分数，主观数字门（>=9）与实际交付质量的相关性未证实；相比直接让 agent 执行的边际收益仅有文档层面的论证。
加分项：方法论在 SKILL.md/README/methodology.md 三处交叉一致，脚本源码可审计。扣分项：无 sparv 专属测试套件或执行记录；仓库 CI（静态可见）仅测试 codeagent-wrapper，不能佐证本 skill 关键路径；无第三方执行证据，静态上限内只能给低分。
- SKILL.md 与 archive-session.sh 的会话目录约定不一致（.sparv/state.yaml vs .sparv/plan/<id>/），使用前请核实实际初始化结构。
- 钩子在每次工具调用后静默运行（|| true 吞错），且 --force 初始化可能覆盖已有 .sparv/ 状态，建议先 --dry-run 或备份。
- spec 10 分门槛由 LLM 主观评分，可能在模糊需求上反复提问或卡死；发布者未经注册表核实。
- 仓库 CI 不覆盖 sparv 脚本，本评估为纯静态审阅，未做任何执行验证。
这个 Skill 能做什么，适合哪些场景？
SPARV 是 stellarlinkco/myclaude 仓库中的一个技能，位于 skills/sparv/。它把开发任务组织为五个固定阶段：明确需求、计划、执行、评审、归档，并用 10 分制规格门禁（≥9 分才进入计划）强制先把需求问清楚。执行过程中通过 .sparv/ 目录下的 state.yaml 和 journal.md 两个文件维护外部记忆，每 2 次工具调用自动保存进度，连续失败 3 次或检测到高风险操作（生产环境、敏感数据、计费 API 等）时强制升级给用户确认。v1.1 还加入不确定性声明、Quick/Full 双路由和知识库维护。
在项目根目录运行 init-session.sh 初始化 .sparv/state.yaml（状态机）和 journal.md（统一日志）；按 5 个维度（价值、范围、验收、边界、风险）给需求打 0-10 分，低于 9 分继续提问不进入计划；计划阶段拆解为 2-5 分钟粒度的原子任务写入日志；执行阶段执行 TDD 规则（无失败测试不写生产代码），由 PostToolUse 钩子每 2 次操作调用 save-progress.sh 追加日志，PreToolUse 钩子运行 check-ehrb.sh 扫描 diff 检测高风险操作，failure-tracker.sh 记录连续失败并在第 3 次以退出码 3 触发升级；评审阶段做规格符合性与代码质量两段检查（最多 3 轮修复），会话结束前运行 reboot-test.sh 三问自检；归档阶段用 archive-session.sh 把日志和状态存入 .sparv/history/，并可在 Vault 阶段更新 .sparv/kb.md 知识库和用 changelog-update.sh 更新 CHANGELOG。
- 独立开发者接到一个描述模糊的功能需求，想在动手前把验收标准和边界问清楚
- 团队希望 AI 编码会话留下可审计的决策记录，而不是散落在聊天记录里
- 在涉及生产环境、敏感数据或计费 API 的改动前，需要强制的人工确认关卡
- 使用 TDD 的开发者想让模型遵守'先有失败测试再写实现'的纪律
- 长会话中断后想快速恢复上下文，靠 journal.md 和 reboot-test 三问自检重建状态
这个 Skill 有哪些优点和局限？
- 10 分规格门禁和 uncertainty 声明机制能显著减少模型基于错误假设开工的情况
- journal.md + state.yaml 提供结构化外部记忆，跨会话可追溯
- EHRB 高风险检测和 3 次失败升级协议内置了安全护栏
- 配套 6 个 shell 脚本，规则不是纯文字而是有脚本强制执行
- Quick/Full 双路由让小任务不必走完整五阶段流程
- 自动钩子（2-action 保存、EHRB diff 扫描、Stop 自检）依赖 Claude Code 的 hooks 机制，迁移到其他客户端需手动改造
- 所有脚本路径硬编码为 ~/.claude/skills/sparv/scripts/，安装目录不同会失效
- README 未提供 sparv 技能的测试套件或独立使用统计，长期效果缺乏佐证
- 门禁流程对小任务偏重，Quick 模式虽然跳过 Plan 但仍要求日志与评审
- 仓库整体 AGPL-3.0，闭源商业使用需联系作者购买商业许可
如何安装这个 Skill？
通过仓库安装整套集合：运行 npx github:stellarlinkco/myclaude（交互式安装器），或 npx github:stellarlinkco/myclaude --list 查看可安装项。安装后技能位于 ~/.claude/skills/sparv/。也可在 config. 的 modules 中通过 "sparv": {"enabled": true} 控制是否启用。单个 sparv 技能是否能独立安装，README 未说明（它打包在 sparv 模块内，不在独立技能列表中）。
如何使用这个 Skill？
安装后在 Claude Code 中用 /sparv 命令触发。首先在项目根目录运行 ~/.claude/skills/sparv/scripts/init-session.sh --force 初始化 .sparv/ 目录；随后按提示经历 Specify（回答打分问题，得分 ≥9 并写下 completion_promise）、Plan、Act、Review、Vault。2-action 保存、EHRB 扫描和 reboot-test 由 hooks/hooks. 中定义的钩子自动执行，前提是钩子已配置到 Claude Code 的 settings.。
这个 Skill 与同类方案有什么区别？
同仓库的 do 技能被 README 标为推荐默认（带 codeagent 多后端编排的 5 阶段功能开发）；omo 侧重多智能体路由。如果你只想要规范化规格流程而不需要多后端执行，sparv 更轻；如果主要做功能开发且用多个 AI 后端，do 更合适。