From harness-flow
Reviews completed design drafts for architecture, modules, API contracts, data models, and backend NFRs. Delivers verdict for approval when draft is stable and traceable to specs.
npx claudepluginhub hujianbest/harness-flow --plugin harness-flowThis skill uses the workspace's default tool permissions.
评审设计文档,判断它是否可以提交给 approval step。核心职责是防止过早拆解任务——确保设计真正锚定规格、决策站得住、接口边界清楚到足以进入任务规划。
Reviews completed UI design drafts for usability (Nielsen heuristics), accessibility (WCAG AA), spec traceability, design tokens, and peer alignment with hf-design-review. For formal verdict before joint approval or task planning.
Reviews design docs with 8-point checklist for problem clarity, success criteria, architecture fit, alternatives, scope, and handoff quality before draft-plan. Auto-dispatched post-design.
Spawns parallel PM, Architect, Designer, Security, and CTO agents to review design docs after brainstorming or commit, iterating until all approve before implementation.
Share bugs, ideas, or general feedback.
评审设计文档,判断它是否可以提交给 approval step。核心职责是防止过早拆解任务——确保设计真正锚定规格、决策站得住、接口边界清楚到足以进入任务规划。
职责边界:本 skill 只评审 架构 / 模块 / API 契约 / 数据模型 / 后端 NFR。若规格声明 UI surface 且 hf-ui-design 被激活,hf-ui-review 会作为 design stage 的并行 review peer 独立评审 IA / 交互 / 视觉 / 前端 a11y 等 UI 维度。两条 review 均通过后,父会话才发起联合 设计真人确认;任一未过,对应起草 skill 回修,另一条可继续其稳定部分。不得跨权评审 hf-ui-design 的职责范围;发现 peer 交接块不一致时,只在 findings 中标注,不代位评审。
本 skill 融合以下已验证方法:
使用:
hf-design 已完成设计草稿,需要正式 review verdict不使用:
hf-designhf-workflow-router直接调用信号:"review 这份设计"、"设计评审"、"帮我看一下这个设计"。
前提条件:存在当前设计草稿、已批准规格、项目相关约定(若项目已声明)。缺设计草稿 → hf-design;缺已批准规格或阶段不清 → hf-workflow-router。
读取:已批准规格(默认 features/<active>/spec.md)、被评审设计文档(默认 features/<active>/design.md)、项目级评审约定(若项目已声明)、feature progress.md(默认 features/<active>/progress.md)当前状态、最少必要技术上下文。
产出:review 记录正文 + 结构化 reviewer 返回摘要。
评审记录落盘由 reviewer 负责;approval step 和主链推进由父会话负责。
hf-tasks读取并固定证据来源:已批准规格(默认 features/<active>/spec.md)、当前设计文档(默认 features/<active>/design.md)、项目约定、feature progress.md(默认 features/<active>/progress.md)状态、必要技术上下文。
不要只根据会话记忆或零散聊天内容判断"已批准"或"设计已经讲清楚"。
检查:是否存在稳定可定位的设计草稿、已批准规格是否可回读、route/stage/profile 与 approval evidence 是否一致。
reroute_via_router=truehf-design对 6 个维度做内部评分(0-10):需求覆盖与追溯、架构一致性、决策质量、约束与 NFR 适配、接口与任务规划准备度、测试准备度与隐藏假设。
评分辅助区分:轻微缺口 vs 需修改 vs 阻塞。按 references/review-checklist.md 逐项审查。
每条 finding 必须带:
severity(critical / important / minor)classification(USER-INPUT / LLM-FIXABLE)rule_id(如 D3、D5、A2)默认分类:
USER-INPUT:缺失外部阈值、未确认业务裁决、规格未批准却引入关键新增能力、核心 trade-off 仍需真人拍板LLM-FIXABLE:缺少方案对比、接口边界说明不足、任务规划准备度表达不清、测试策略未显式写出、隐藏假设未整理成文判定规则(详见 references/review-record-template.md):
severity:critical(阻塞任务规划)> important(应修复)> minor(建议改进)。
按 references/review-record-template.md 写评审记录,并返回结构化 JSON 给父会话。
下一步映射:
通过 → 设计真人确认(needs_human_confirmation=true)需修改 → hf-design阻塞(设计内容) → hf-design阻塞(需求漂移/规格冲突) → hf-workflow-router(reroute_via_router=true)按需加载详细参考内容:
| 主题 | Reference | 加载时机 |
|---|---|---|
| 评审检查清单 | references/review-checklist.md | 执行 Step 2 多维审查时 |
| 评审记录模板 | references/review-record-template.md | 执行 Step 4 写评审记录时 |
| 易混淆 skill | 区别 |
|---|---|
hf-design | design 负责起草设计;本 skill 负责评审设计。起草者不能自审。 |
hf-ui-review | 本 skill 评审架构/模块/API/数据模型/后端 NFR;hf-ui-review 评审 IA/交互/视觉/前端 a11y。两者 peer 并行,不得跨权。联合通过后才进入 设计真人确认。 |
hf-tasks | 本 skill 是评审 gate,输出 verdict + findings;tasks 是拆解实现步骤。评审未通过前不进 tasks。 |
hf-workflow-router | router 负责阶段路由判断(含 UI surface 激活条件);本 skill 假设已处于设计评审阶段。发现需求漂移/证据冲突/激活条件判定错时才 reroute 到 router。 |
hf-spec-review | spec-review 评审需求规格(做什么);本 skill 评审实现设计(如何做)。 |
hf-tasks(跳过 approval step)完成条件:
next_action_or_recommended_skill通过,已明确要求进入 设计真人确认