From harness-flow
Reviews completed feature spec drafts with rubrics scoring quality attributes, anti-patterns, completeness, granularity, and scope-fit to verdict approval readiness before design.
npx claudepluginhub hujianbest/harness-flow --plugin harness-flowThis skill uses the workspace's default tool permissions.
评审需求规格,判断范围清晰度、需求可测性、验收标准、success criteria、assumptions 与开放问题闭合度,以及进入 approval step 的准备度。本 skill 是需求规格冻结门禁,目标是把规格准备到可交给 approval step 作为 `hf-design` 候选已批准输入的状态。不替代 `hf-specify`(写规格)或 `hf-design`(做设计)。
evals/README.mdevals/evals.jsonevals/fixtures/precheck-router-conflict/spec-notes.mdevals/fixtures/precheck-router-conflict/task-progress.mdevals/fixtures/precheck-router-conflict/workflow-note.mdevals/fixtures/precheck-stable-draft-stage-conflict/design-draft.mdevals/fixtures/precheck-stable-draft-stage-conflict/evidence-note.mdevals/fixtures/precheck-stable-draft-stage-conflict/spec-draft.mdevals/fixtures/precheck-stable-draft-stage-conflict/task-progress.mdreferences/review-record-template.mdreferences/spec-review-rubric.mdtest-prompts.jsonReviews spec.md files for completeness, clarity, implementability, testability, and structure. Identifies ambiguities, gaps, and missing sections before implementation.
Dispatches read-only subagent to review .planning/SPEC.md for completeness, coverage, clarity before exploration. Internal dev-brainstorm Phase 1 gate.
Creates structured requirement specifications using EARS, BDD/Gherkin, MoSCoW, and IEEE/ISO methods for projects without approved specs, drafts, or post-review revisions.
Share bugs, ideas, or general feedback.
评审需求规格,判断范围清晰度、需求可测性、验收标准、success criteria、assumptions 与开放问题闭合度,以及进入 approval step 的准备度。本 skill 是需求规格冻结门禁,目标是把规格准备到可交给 approval step 作为 hf-design 候选已批准输入的状态。不替代 hf-specify(写规格)或 hf-design(做设计)。
本 skill 融合以下已验证方法:
适用:
hf-specify 已完成规格草稿,需正式 review verdict不适用:缺规格草稿或只需继续写 → hf-specify;阶段不清/证据冲突 → hf-workflow-router;已有已批准规格、当前需要设计评审 → hf-design-review。
前提确认:存在稳定规格草稿(默认 features/<active>/spec.md)、能读取 项目约定和 feature progress.md(默认 features/<active>/progress.md)、请求确实是评审。若 route/stage/profile/证据冲突 → 优先回 router。
hf-design读取并固定:当前规格(默认 features/<active>/spec.md)、deferred backlog(若存在,默认 features/<active>/spec-deferred.md)、项目约定、feature progress.md(默认 features/<active>/progress.md)、少量上下文用于确认状态和锚点。不只根据聊天记忆判断。
检查:是否存在稳定可定位的规格草稿、route/stage/profile 是否已明确、上游证据是否一致。
reroute_via_router=truehf-specify先判断项目是否通过 项目声明了骨架/字段/优先级体系,当前规格是否遵循。只要语义可回读,不强迫文档长得和默认模板一模一样。
详细规则:references/spec-review-rubric.md
核心需求可回指来源?模糊词已量化?验收标准可判断?需求无冲突/重复?无缺失 Priority/Source?
模糊词、复合需求、设计泄漏、无主体被动表达、关键需求中待确认/占位值、缺少负路径/边界/权限差异。
核心 FR/NFR 具备 ID/Statement/Acceptance/Priority/Source?当前轮目标与 success criteria 是否具体可判断?范围内外闭合?阻塞性开放问题为空?assumptions 是否显式且失效影响可回读?deferred requirements 已显式处理?
命中 GS1-GS6 的 oversized requirements?当前轮和后续增量混写?findings 足够具体可支持定向回修?
每条 finding 带 severity(critical/important/minor)、classification(USER-INPUT/LLM-FIXABLE)、rule_id(如 Q2、A3、C1、GS1)。
分类:缺业务事实/外部决策/性能阈值/优先级冲突 → USER-INPUT;缺 wording/拆分/章节/重复整理/设计泄漏改写 → LLM-FIXABLE。无法在不新增事实前提下修复的不能标 LLM-FIXABLE。
severity:critical(阻塞设计)→ important(应批准前修复)→ minor(建议改进)。
| 条件 | verdict | 下一步 |
|---|---|---|
| 范围清晰、核心需求可验收、无阻塞 USER-INPUT、足以成为设计稳定输入 | 通过 | 规格真人确认 |
| 有用但不完整,findings 可 1-2 轮定向修订 | 需修改 | hf-specify |
| 过于模糊/核心范围未定/findings 无法定向回修 | 阻塞(内容) | hf-specify |
| route/stage/证据冲突 | 阻塞(workflow) | hf-workflow-router |
按 references/review-record-template.md 的结构写记录并回传父会话。
交互约束:
reroute_via_router=true 时只说明 workflow blocker| Skill | 区别 |
|---|---|
hf-specify | 写/改规格草稿;本 skill 只做评审不改规格 |
hf-design-review | 评审设计文档;本 skill 评审需求规格,不涉及设计 |
hf-workflow-router | 编排/路由/阶段判断;本 skill 只做规格评审 verdict |
hf-design(跳过 approval step)| 文件 | 用途 |
|---|---|
references/spec-review-rubric.md | 正式审查 rubric(Q/A/C/G 四组) |
references/review-record-template.md | 记录结构、JSON 格式、返回规则、状态同步 |
通过 时已明确要求进入 规格真人确认