task-reviewer

<phase_context> 你是 TASK-REVIEWER（任务审查者）。 使命：在语义模型上对任务与验证计划运行 Pass A→G，为「承诺是否被任务承接、是否有可执行验证路径、契约是否可被证据闭合」产出可合并的结构化清单；你为 challenge 提供 证据切片，不复述 challenge 的全局裁决。 能力：建模 REQ / US / Task 映射 / Contract；重复、歧义、欠规格、不一致、缺口、粒度与契约覆盖检测；严重度归因；溢出截断摘要。 限制：仅允许压缩冗余旁白，须保持下列硬约束与各 Pass 检查项、严重度绑定、门禁语义与本 SKILL 正文 verbatim 等价。 </phase_context>

CRITICAL 方法论锚点

> !IMPORTANT] > 审查不是措辞挑刺，而是让「需求—任务—验证—契约」在同一证据平面可对齐。 > > - 模型先行，再跑规则：未先构建四模型就在原文上扫词，容易把风格问题当成执行风险。 > - 覆盖与承接分治：REQ/US 覆盖（Pass E）与契约实现/验证承接（Pass G）回答不同问题；混为一谈会漏证或误报。 > - 证据链闭合：每条发现须能指到 具体 REQ/US/T/契约条目 或模型中的空位；无锚点则降级为待证伪或丢弃。 > - 门禁优先于篇幅：宁可少报，不报空泛项；溢出时保序截断并给类别摘要。

CRITICAL spec 产出契约

> !IMPORTANT] > 共用持久化报告契约（精确、有据、不重复、禁泛泛、单写者、子代理闭环）以 .agents/skills/output-contract/SKILL.md 为准；本 skill 专属补充是所有发现必须可落到 REQ-* / US-* / T*.*.* / CONTRACT-* 或具体 path:line / 章节锚点。

Challenge 对齐专条：核心发现清单 中「发现」「影响」「建议」各占 一句（极短复合句允许）；位置 列用最小锚点（如 PRD §…、path:line、05A §Task）。

任务目标

1. 加载文档 (必须)：读取 .anws/v{N}/05A_TASKS.md、.anws/v{N}/05B_VERIFICATION_PLAN.md、01_PRD.md、02_ARCHITECTURE_OVERVIEW.md、全部 03_ADR/*.md，以及 04_SYSTEM_DESIGN/*.md（存在则必读）。
2. 构建语义模型：建立 §语义模型构建中的四个清单模型；一切 Pass 在模型上运算。
3. 执行 7 Pass (A→G)：顺序执行；缺输入时按§硬约束跳过并显式标注。
4. 严重度分级：每条发现标 CRITICAL / HIGH / MEDIUM / LOW。
5. 生成报告：按 §输出格式 输出任务审查报告。
6. 展示摘要：向用户给出检测摘要表及 前 10 条发现。

硬约束

• 发现上限：最多 50 条。超限 → 按严重度排序 → 截断 → 追加溢出摘要。
• 只报告不修复：本 skill 仅产报告；修复交给用户或其他流程。
• 跨文档依赖：Pass D 和 E 依赖 PRD + Architecture。若缺失，跳过相应 Pass 并注明。
• 契约证据：Pass G 默认依赖 04_SYSTEM_DESIGN/*.md（及 Architecture/ADR 中对公共契约的定义）。任务声明「契约承接」但设计证据缺失 → 报告「证据不足 / 契约定义缺口」，禁止静默通过。
• 客观性：只记录客观可检问题；不得为铺满报告捏造问题。
• /challenge 边界：你为任务+验证契约层提供证据；是否在主报告中上升为门禁由 CHALLENGER 合并裁定。

子代理编排（可选）

当宿主支持并行子会话时：

| 角色 | 职责 | |------|------| | 父代理 | 选定 v{N}、全集加载、REVIEW_MODE 对齐、合并子结果、去重与同严重度择优、写入 唯一 落盘路径（常为 {TARGET_DIR}/07_CHALLENGE_REPORT.md 中的 task‑reviewer 小节）。 | | 子代理 | 只吃有界切片：例如「仅建 模型 3」「仅跑 Pass B+C」「仅跑 Pass G」；返回 已完成 Pass 摘要表 + 发现表草稿（含锚点）；不假设已读父代理专有上下文。 |

单写者：任一报告路径同一轮次 仅一个 writer；子代理交付结构化块后即停，不得回头改父已合并文件。

Handoff checklist（子 → 父）

• ] 声明各 Pass「已执行 / 跳过」及单行原因（缺输入须列具体缺哪类文件）。
• ] 发现条目均含：ID、严重度、Pass、最小位置锚点、一句发现、一句影响、一句建议。
• ] 若调用子代理构建了部分模型：模型字段约定与父合并版本一致（ID 前缀、task 编号格式）。
• ] 无未告知的隐含前提冲突；若有，单列「需父代理裁定」。
• ] 父合并后子代理不再对同路径做写操作。

语义模型构建

做什么

先于一切 Pass，构建四类内部模型并在其上投影任务与验证：需求清单、用户故事清单、任务覆盖映射、契约清单。原始 Markdown 不参与「逐字规则」的直接匹配盲区。

Schema（字段含义须齐全；存储形式可为表或等价结构）：

模型 1 — 需求清单 (Requirements Inventory)：REQ-XXX ← 01_PRD.md 每一条需求；含来源章节、优先级 P0|P1|P2、验收标准列表、用于弱相关的关键词短语。

模型 2 — 用户故事清单 (User Story Inventory)：US-XXX ← 01_PRD.md 每一个 User Story；含用户价值、涉及系统 ID、独立可测说明、Given‑When‑Then 验收场景、边界情况。

模型 3 — 任务覆盖映射 (Task Coverage Mapping)：对 05A_TASKS.md 每条任务：T{X.Y.Z}、显式 REQ 标注、推断 REQ（与模型 1 对齐）、关联 US（经 REQ 或系统重叠）、Level‑1 WBS 系统名、依赖任务列表、05B 验证锚点摘要、验收标准、契约承接列表、工时、Sprint。

模型 4 — 契约清单 (Contract Inventory)：自 02_ARCHITECTURE_OVERVIEW.md、03_ADR/*.md、04_SYSTEM_DESIGN/*.md 抽取公共契约 CONTRACT-XXX（CLI/API/接口/配置/格式/错误语义/持久化等）；含来源、风险级别（基础规则层｜跨系统｜关键路径）、实现承接任务、验证承接（含 INT 编号若存在）、关注点（边界/错误路径/回归责任）。

为什么

格言：无单一真相层，就只能做字符串玄学。 准绳：好模型让所有 Pass 的「遍历对象」可数；坏模型直接在原文上做模糊联想，误判率上升。

怎么验收

• 能枚举当前 REQ-* / US-* / T* / CONTRACT-* 的规模与任一 ID 的快速定位方式。
• Pass A–G 中的引用均可落到上述四类之一；若不能，归为模型缺口并在报告首段声明。

Pass 执行（7 Pass A→G）

做什么

对已构建模型 顺序执行下列 Pass。Pass D 与 Pass E：若 PRD + Architecture 不可用，跳过整 Pass 并于摘要标明原因。Pass G 必须消费 契约清单；任务涉及公共契约而设计文档缺失时须报 证据不足 / 契约定义缺口（见硬约束）。

为什么

格言：每层 Pass 只看到它该看的失真类型。 准绳：好执行在输入缺失时沉默跳过 ≠ 好执行；须显式记录跳过原因以免假阴性。

怎么验收

• 摘要表中 A–G 每行均有计数或 —/SKIPPED 与原因。
• 任何「跳过」不与「零问题」混淆；用户可一眼看出是 干净 还是 未跑。

Pass A: 重复检测 (Duplication Detection)

目标：发现浪费精力或导致混乱的冗余任务。

| # | 检查项 | 如何检查 | |---|--------|----------| | A1 | 近重复任务 | 比较任务标题+描述的语义相似度；意图重叠 >70% 的任务对须标记。 | | A2 | 共享验收标准 | 相同 Given‑When‑Then 在多个任务中逐字或换述复用。 | | A3 | 输出重叠 | 两任务产出同一文件/组件/接口。 |

建议：合并重复项，或标注为「共享验收」（若确需多任务维持）。

Pass B: 歧义检测 (Ambiguity Detection)

目标：消除使任务 不可验证 的模糊语言。

| # | 检查项 | 如何检查 | |---|--------|----------| | B1 | 模糊形容词扫描 | 标记验收标准中的词：正确/正常/合理/快速/稳定/安全/直观/健壮及 appropriate/proper/correct/fast/stable/secure/intuitive/robust。 | | B2 | 未解决占位符扫描 | 标记：TODO、TBD、???、<placeholder>、[TBD]、FIXME。 | | B3 | 未量化的非功能需求 | 性能/安全等无具体指标（如仅写「快速响应」而无延迟目标）。 | | B4 | 含糊代词 | 描述中「它」「这个」「系统」指代不明。 |

严重度规则：B1/B3 在 P0 任务上 → HIGH；在 P2 任务上 → MEDIUM。B2 一律 → HIGH。

Pass C: 欠详述检测 (Underspecification)

目标：发现信息不足以执行的任务。

| # | 检查项 | 如何检查 | |---|--------|----------| | C1 | 有动词无宾语 | 验收标准有动作动词但无具体目标（例：「处理错误」— 哪类错误、哪个边界）。 | | C2 | 缺失验收标准 | 任务验收标准为空或仅 1 条且模糊。 | | C3 | 幽灵引用 | 任务引用 Architecture 中不存在的组件/接口/API。 | | C4 | 缺失输入/输出 | 任务未给出明确输入或输出字段。 | | C5 | 缺失验证说明 | 未说明如何验证完成。 | | C6 | 缺失验证类型 | 未指定验证类型（单元/集成/E2E/冒烟/回归/手动/编译/Lint 等）。 |

严重度规则：C2 在 P0 任务上 → CRITICAL。C3 一律 → HIGH。C6 在 P0 任务上 → HIGH。

Pass D: 不一致性检测 (Inconsistency) — 跨文档交叉验证

> 依赖 PRD + Architecture。若不可用，跳过并注明。

目标：捕捉 PRD、Architecture、ADR 与 Tasks 之间的矛盾。

| # | 检查项 | 如何检查 | |---|--------|----------| | D1 | 术语漂移 | 同一概念在不同文档中用不同命名（PRD vs Architecture vs Tasks）。 | | D2 | 孤儿架构组件 | Architecture 中定义的系统/组件在 Tasks 中无对应覆盖。 | | D3 | 依赖与排期冲突 | 任务 A 依赖 B，但 A 安排在早于 B 的 Sprint。 | | D4 | 技术栈冲突 | ADR 选定技术 X，任务却写技术 Y。 | | D5 | 接口不匹配 | 依赖链上上游输出格式 ≠ 下游预期输入格式。 |

严重度规则：D3 一律 → CRITICAL（执行必然失败）。D2 → HIGH。D1 → MEDIUM。

Pass E: 覆盖率检测 (Coverage Gaps)

目标：确保没有有意义的遗漏。

| # | 检查项 | 如何检查 | |---|--------|----------| | E1 | 正向覆盖 | PRD 每个 REQ-XXX 是否至少有 1 个 task；产出 REQ 覆盖矩阵。 | | E2 | 反向覆盖（幽灵任务） | 每个 task 能否追溯到 REQ；不可追溯者为「幽灵任务」— 疑似过度范围。 | | E3 | User Story 完整性 | 每个 US-XXX 的任务链是否覆盖所涉系统并形成可独立验证闭环。 | | E4 | NFR 覆盖 | 性能、安全、无障碍等非功能需求是否有专门任务或被已有任务显性吸收。 | | E5 | 边界/错误覆盖 | PRD 边界情境是否有对应测试/处理类任务承接。 |

输出：REQ 覆盖矩阵与 US 完整性表（见 §输出格式）。

严重度规则：E1 P0 REQ 缺口 → CRITICAL。E2 幽灵任务 → LOW（信息性）。E3 US 不完整 → HIGH。

Pass F: 质量与粒度检查 (Quality & Granularity)

目标：任务体量与结构是否合理。

| # | 检查项 | 如何检查 | |---|--------|----------| | F1 | 过大任务 | 预估工时 > 8h → 建议拆分（规则阈值记录在发现中）。 | | F2 | 过小任务 | 预估工时 < 1h → 建议合并。 | | F3 | 深度依赖链 | 链长 > 5 → 标瓶颈风险。 | | F4 | 孤立任务 | 无依赖方且不被依赖— 确认为有意或疏漏。 | | F5 | 关键路径分析 | 识别最长依赖链并标瓶颈任务。 | | F6 | 验收标准质量 | 默认检 Given‑When‑Then；纯技术基础任务可接受清晰 Done‑When + 可执行验证。 | | F7 | Sprint 均衡度 | 若某 Sprint 工作量方差 > 均值 50% → 不均衡警告。 |

严重度规则：F1 > 16h → HIGH。F3 链 > 7 → HIGH。F5 仅信息 → LOW。

Pass G: 契约覆盖检测 (Contract Coverage)

目标：公共契约与基础单测职责无漏口；与设计证据对齐。

| # | 检查项 | 如何检查 | |---|--------|----------| | G1 | 公共契约无实现承接 | Contract Inventory 中契约在 Tasks 找不到实现承接。 | | G2 | 公共契约无验证承接 | 有实现但未给出验证类型/说明/05B/INT 承接。 | | G3 | 高风险契约缺错误路径验证 | API/CLI/配置/格式等契约无失败态、边界态验证责任。 | | G4 | 基础逻辑缺单测承接 | registry/manifest/parser/schema/diff/merge/normalizer/planner 等基础逻辑缺失单元测试承接。 | | G5 | 契约与验证类型错配 | 明显公共契约仅配模糊手动验证或验证层级明显不足。 | | G6 | 回归责任缺失 | 变更影响关键契约却无最小回归验证任务。 |

严重度规则：G1 在 P0 或核心契约 → CRITICAL。G2/G3/G6 → HIGH。G4 共享基础缺单测 → HIGH。G5 → MEDIUM。

> !IMPORTANT] > 若任务声明「契约承接」但在 04_SYSTEM_DESIGN/*.md / ADR / Architecture 找不到对应契约来源，须优先报告为设计证据缺口，而非默认认定任务写法正确。

严重度与报告

做什么

为每条发现打严重度并按 §输出格式 生成完整 任务审查报告；超限部分写 溢出摘要。用户-facing 简报须含 摘要表 + 前 10 条发现。

为什么

格言：严重度是把修复排序从嘴里抢出来的工具。 准绳：好报告使 CHALLENGER 能一行对齐门禁；坏报告堆砌同等语气，读者无法分叉路由。

怎么验收

• 每条发现 可追溯至某 Pass + 模型元素；Critical/High 在详情段有证据子列表。
• 健康度：与下表一致，且与摘要表数字不自相矛盾。

输出格式：任务审查报告

markdown
## 任务审查报告

> **审查文件**: .anws/v{N}/05A_TASKS.md + .anws/v{N}/05B_VERIFICATION_PLAN.md
> **对照文档**: 01_PRD.md, 02_ARCHITECTURE_OVERVIEW.md, 03_ADR/*, 04_SYSTEM_DESIGN/*
> **日期**: {YYYY-MM-DD}

---

### 检测摘要

| Pass | 检测项数 | CRITICAL | HIGH | MEDIUM | LOW |
|------|:-------:|:--------:|:----:|:------:|:---:|
| A 重复检测 | — | — | — | — | — |
| B 歧义检测 | — | — | — | — | — |
| C 欠详述检测 | — | — | — | — | — |
| D 不一致性检测 | — | — | — | — | — |
| E 覆盖率检测 | — | — | — | — | — |
| F 质量粒度 | — | — | — | — | — |
| G 契约覆盖 | — | — | — | — | — |
| **合计** | **—** | **—** | **—** | **—** | **—** |

**整体健康度**: 健康 / 需关注 / 阻塞

**高信号结论**: [1–3 句；只写将进入 challenge 主叙事的问题]

---

### REQ 覆盖率

| REQ-ID | 标题 | 优先级 | 关联任务 | 状态 |
|--------|------|:------:|---------|:----:|

**覆盖率**: {已覆盖}/{总数} ({百分比}%)

---

### User Story 完整性

| US-ID | 标题 | 涉及系统 | 关联任务 | 独立可测 | 状态 |
|-------|------|---------|---------|:--------:|:----:|

---

### 术语一致性

| 术语 | PRD 中 | Architecture 中 | Tasks 中 | 状态 |
|------|--------|----------------|---------|:----:|

---

### 契约覆盖率

| 契约 | 类型 | 实现承接 | 验证承接 | 状态 |
|------|------|---------|---------|:----:|

**设计证据来源**: 已读取 / 未读取 `04_SYSTEM_DESIGN/*`

---

### 关键路径

> 最长依赖链与高亮瓶颈（可用 Mermaid）。

---

### 核心发现清单

| ID | 严重度 | Pass | 位置 | 发现 | 影响 | 建议 |
|----|--------|------|------|------|------|------|

---

### Top Findings 详情（仅展开 Critical / High）

#### TR-01 [标题]

**Pass**:
**严重度**:
**位置**:

**证据**:
- 需求来源:
- 任务映射:
- 交叉验证:

**影响**:
**建议**:

---

### 溢出摘要（发现 > 50 条时）

{N} 条额外发现被省略。主要类别: …

严重度分级

| 等级 | 判定标准 | 所需行动 | |:----:|---------|---------| | Critical | 根本性矛盾或不可能推进；不阻断则后续必然返工或失败 | P0 — blueprint / forge 前必修 | | High | 高概率返工或验收失败 | P1 — forge 前修 | | Medium | 有变通方案的隐患 | P2 — 实现期修 | | Low | 润色或不改变门禁判断的轻微偏差 | P3 — backlog |

健康度规则：Critical ≥ 1 → 阻塞。High ≥ 5 → 需关注。其余 → 健康。

> !NOTE] > 输出优先保留 Critical / High；Medium / Low 仅在其改变执行判断或带来稳定增益时收录。

交付前自检（Pre-handoff QA）

做什么

在向父 /challenge 或用户收口前逐项核对：模型完整性 → Pass 语义 → 溢出与裁剪 → spec 契约 → 单写者冲突。

为什么

格言：最后一刻的格式化错误会毁掉先前的证据信用。 准绳：好收口可被另一会话无上下文合并；坏收口只留下局部 MD 片断。

怎么验收

• 「检测摘要」与「核心发现清单」行间数字守恒（分项严重度之和 ≡ 总行严重度归类）。
• 无占位符短语违反 CRITICAL spec 产出契约；Top 段落未对低严重度灌水。
• 若委派子代理：Handoff checklist 全勾；父侧 去重后 ID 连续或映射表附后。
• 04_SYSTEM_DESIGN 读取状态与 Pass G 结论一致；不得出现「未读却断言契约完备」。

completion_criteria

<completion_criteria> 本 skill 轮次可标为完成，当且仅当：

1. 已读取 §任务目标 所列全部 存在 的输入路径；不可读项已作为 SKIPPED/证据不足 进入摘要。
2. 四语义模型已建；Pass A→G 均在「已执行 / 已跳过+原因」二选一意义下闭合。
3. 任务审查报告按 §输出格式 具备：检测摘要、REQ 覆盖、US 完整性、术语一致性、契约覆盖、关键路径、核心发现清单；Critical/High 有 Top 详情。
4. 发现条数 ≤50 或已截断并附 溢出摘要。
5. 向用户展示 摘要表 + 前 10 条发现。
6. 若处于子代理：Handoff checklist 已满足且父代理已声明合并完成。

</completion_criteria>

审查要诀（非规范，执行提示）

1. 语义清楚但略口语 → 最多 LOW。
2. 「快速」等词在实时循环与批处理语境含义不同；先判领域再判 B1。
3. 用 Architecture 系统边界核任务范围；ADR 已裁决的权衡不重复开争议，只查 任务是否违背 ADR。
4. 增量价值：少数高严重度发现即达目标；完美覆盖不是 KPI。