@adamancyzhang/claude-orchestrator 0.3.0 → 0.3.2

package/dist/skills/task-review/SKILL.md

@@ -0,0 +1,220 @@
+---
+name: task-review
+description: Quality review of the full Plan→Build→Verify chain for the Reviewer role. Use when the Reviewer needs to assess whether the implementation matches the Planner's design intent — checking code quality, architecture compliance, verification completeness, and producing a review report with a pass/revise decision, with full traceability from every judgment back through the chain. Triggers on keywords like "审查", "review", "code review", "检查代码", "审批", "复核", or when verification is complete and the task enters the Review stage of the responsibility chain.
+---
+
+# Task Review
+
+> 审查不是挑刺，是从设计意图的高度判断实现是否"做对了"——不是"代码写得怎么样"，而是"该不该通过"。本技能与 [[task-traceability]] 协作，确保每次审查有依据、有深度、有结论、可追溯——每个判定都可追溯到具体的 Plan 意图、Build 产出和 Verify 发现。
+
+---
+
+## 何时触发
+
+- Verifier 完成验证，责任链流转到 Review 阶段
+- Worker 通过 `claude-orchestrator claim-task` 认领了 review 类型的任务
+- 用户说"审查一下这个 PR"、"review 一下代码"
+- 蓝图中有 review 类型的任务需要开工
+
+---
+
+## 审查六步法
+
+按顺序执行，每一步通过才进入下一步。
+
+### 1. 认领 Review 任务并收集全链信息
+
+```bash
+# 认领审查任务
+claude-orchestrator claim-task
+
+# 获取蓝图
+claude-orchestrator get-context --key plan-<目标slug>
+
+# 获取验证报告
+claude-orchestrator get-context --key verify-<目标slug>
+```
+
+收集审查所需的完整上下文：
+- Planner 的蓝图（设计意图、验收标准、范围边界）
+- Builder 的代码变更（commit diff）
+- Verifier 的验证报告（问题清单、回归结果）
+- Builder 的 task-traceability 记录（commit hash 链）
+
+如果缺少任何一环的产出 → 退回要求补齐。Reviewer 不做信息不完整的审查。
+
+### 2. 审查设计一致性
+
+对照蓝图检查实际实现，回答三个核心问题：
+
+**做对了吗？**（功能正确性）
+- 代码变更是否实现了蓝图定义的全部功能？
+- 是否有蓝图定义但未实现的部分？
+- 是否有蓝图未定义但被实现了的部分（越界）？
+
+**做合适吗？**（架构合规性）
+- 代码结构是否符合项目现有的架构模式？
+- 是否引入了新的依赖或模式变更？（如有，是否必要且有充分理由？）
+- 命名、目录组织、接口设计与项目现有风格是否一致？
+
+**技术债务可控吗？**
+- 是否有明显的性能问题、安全问题、可维护性问题？
+- 是否引入了难以测试的逻辑？
+- 错误处理是否合理？
+
+```bash
+# 查看完整 diff
+git show <commit-hash> --patch
+
+# 查看变更的文件列表
+git show <commit-hash> --stat
+```
+
+### 3. 审查验证报告的完整性
+
+审查 Verifier 的工作质量：
+
+- 验证报告是否覆盖了蓝图中所有验收标准？
+- 验证方法是否独立可复现？（不是转述 Builder 的结果）
+- 回归测试是否被执行且通过？
+- Verifier 发现的问题是否被充分描述和分类？
+
+如果验证报告有缺陷（漏检、方法不当）→ 标记为 Review 前置条件不满足，退回 Verifier 补充。
+
+### 4. 判定问题等级
+
+对发现的问题按严重度分级：
+
+| 级别 | 定义 | 示例 | 处理 |
+|------|------|------|------|
+| **P0** | 阻断：设计意图未实现，核心功能缺失或不正确 | 蓝图要求的功能完全没做、引入安全漏洞 | 退回 Builder 重做 |
+| **P1** | 严重：实现偏离设计意图，但不影响核心功能 | 错误处理不完整、UI 与设计不一致、性能明显下降 | 退回 Builder 修改 |
+| **P2** | 一般：代码质量、风格、可维护性问题 | 命名不清晰、缺少注释、测试覆盖面不足 | 建议修改，不阻断通过 |
+| **P3** | 建议：优化建议，不影响通过 | 更好的实现方式、可选的性能优化 | 记录，Builder 自行决定 |
+
+### 5. 书写审查报告
+
+```markdown
+# 审查报告
+
+> Reviewer | YYYY-MM-DD | 审查范围：<目标名称> (P→B→V 全链)
+
+## 审查结论：Pass / Revise
+
+（一句话结论）
+
+---
+
+## 审查范围
+
+| 环节 | 负责人 | 产出 | Commit / 文档 |
+|------|--------|------|--------------|
+| Plan | <Planner> | 蓝图 | plan-<slug> |
+| Build | <Builder> | 代码 | `a1b2c3d` |
+| Verify | <Verifier> | 验证报告 | verify-<slug> |
+
+---
+
+## 设计一致性审查
+
+| 蓝图要求 | 实现情况 | 判定 |
+|---------|---------|------|
+| 功能 A：XXX | 已实现，见 `src/a.ts:42` | ✅ |
+| 功能 B：YYY | 部分实现，缺少边界处理 | ⚠️ |
+| 功能 C：ZZZ | 未实现 | ❌ |
+
+---
+
+## 代码质量审查
+
+| 检查项 | 结果 |
+|--------|------|
+| 架构合规 | ✅ / ⚠️ / ❌ |
+| 命名规范 | ✅ / ⚠️ / ❌ |
+| 错误处理 | ✅ / ⚠️ / ❌ |
+| 性能影响 | ✅ / ⚠️ / ❌ |
+| 安全问题 | ✅ / ⚠️ / ❌ |
+
+---
+
+## 验证报告审查
+
+| 检查项 | 结果 |
+|--------|------|
+| 验收标准覆盖 | 3/3 ✅ |
+| 验证方法独立 | ✅ |
+| 回归测试通过 | ✅ (42/42) |
+| Verifier 问题充分描述 | ✅ |
+
+---
+
+## 问题清单
+
+| # | 级别 | 描述 | 位置 | 责任人 |
+|---|------|------|------|--------|
+| 1 | P1 | 缺少错误重试逻辑 | `src/auth.ts:L42` | @Builder |
+| 2 | P2 | 变量名 `tmp` 不够清晰 | `src/utils.ts:L18` | @Builder |
+
+---
+
+## 审查建议
+
+（对 Builder/Planner/Verifier 的非强制性建议）
+
+---
+
+*Reviewer — YYYY-MM-DD*
+```
+
+### 6. 通知结果并流转
+
+```bash
+# 存入共享上下文
+claude-orchestrator set-context \
+  --key review-<目标slug> \
+  --value "$(cat docs/review/<目标slug>-YYYY-MM-DD.md)"
+
+# Revise → 通知 Builder 和 Planner
+claude-orchestrator send-message \
+  --to <builder-id> \
+  --content "审查结论 Revise。P1: 缺少错误重试逻辑。详见 review-<slug>"
+
+# Pass → 通知 Leader 和 Accepter，流转到 Accept 阶段
+claude-orchestrator send-message \
+  --broadcast \
+  --content "审查结论 Pass。<目标> 通过 Review，流转至 Accept 阶段。"
+```
+
+---
+
+## 审查完成检查清单
+
+```
+□ 已收集完整的 P→B→V 链产出
+□ 蓝图验收标准全部检查
+□ 代码 diff 完整审阅
+□ 验证报告质量和完整性已评估
+□ 问题已按 P0/P1/P2/P3 分级
+□ 审查报告已产出并存入共享上下文
+□ 结论（Pass/Revise）已通知相关角色
+```
+
+---
+
+## 与其他技能的协作
+
+- **[[task-traceability]]**：基础层。Reviewer 严格遵循追溯 → 执行 → 映射 → 举证 → 记录的五步法。追溯整条链（Plan 意图 → Build 实现 → Verify 发现），逐项判定（Execute），构建审查判定映射表（Map），为每个判定附理据（Evidence），产出审查报告并签发 Pass/Revise（Record）。如果任何一个上游环节的追溯链断裂，标记为 P1 问题——没有追溯链，审查就没有锚点。
+- **[[task-planning]]**：Reviewer 以 Planner 的蓝图为审查标准。设计意图是唯一的判断基准。
+- **[[task-execution]]**：Reviewer 审查 Builder 的代码实现质量和设计一致性。
+- **[[task-verification]]**：Reviewer 审查 Verifier 的验证报告质量和完整性。验证报告有缺陷的，退回 Verifier。
+- **[[task-acceptance]]**：Accepter 依赖 Reviewer 的 Pass 结论和可追溯判定链来决定是否进入最终验收。
+
+---
+
+## 常见错误
+
+- **只审代码不审设计一致性**：陷入代码风格审查，忘记了 Reviewer 的核心职责是判断"是否实现了设计意图"。代码写得再好，与蓝图不一致也是不合格。
+- **跳过对 Verifier 的审查**：假设 Verifier 的报告总是完整正确的。Verifier 也可能遗漏或误判。
+- **不分级的问题清单**：把所有问题列出但不定级，Builder 不知道哪些必须修改、哪些可以忽略。
+- **审查报告不写位置**：问题只描述不定位（缺少文件路径和行号）。Builder 不知道在哪里改。
+- **Pass 但有问题未解决**：P0/P1 问题未解决就签 Pass。零 P0/P1 是 Pass 的前提。

package/dist/skills/task-traceability/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: task-traceability
+description: Foundational traceability layer for the entire Plan→Build→Verify→Review→Accept responsibility chain. Every role must leave a traceable record: upstream requirements → execution → output mapping → evidence → persisted record. Without traceability at every link, the chain cannot be audited, handoffs break, and sign-off is unreliable. Use this skill whenever any team member executes work in any link of the responsibility chain — planning, building, verifying, reviewing, or accepting. Triggers on any task execution context: task assignment, work plans, code changes, verification, review, or acceptance.
+---
+
+# Task Traceability — Foundational Layer
+
+Traceability is not optional. It is the foundation that makes the Plan→Build→Verify→Review→Accept chain auditable, handoffs reliable, and sign-off meaningful. **Every link must produce a traceable record. A single broken link breaks the entire chain.**
+
+## The Universal Five-Step Pattern
+
+Every role in the chain follows the same five-step pattern, applied to its specific context:
+
+```
+Step 1: Trace (追溯)
+  └── Identify all upstream requirements and artifacts you must reference
+
+Step 2: Execute (执行)
+  └── Do the work, following the traced requirements
+
+Step 3: Map (映射)
+  └── Link every output back to a specific upstream requirement
+
+Step 4: Evidence (举证)
+  └── Provide proof that each mapping is correct and complete
+
+Step 5: Record (记录)
+  └── Persist the traceability record so downstream roles can pick up the chain
+```
+
+**Why five steps?** Without Trace, you don't know what to do. Without Map, nobody knows why you did it. Without Evidence, your output is unverifiable. Without Record, the next link starts blind.
+
+## Why Every Link Matters
+
+```
+Plan ──→ Build ──→ Verify ──→ Review ──→ Accept
+  │         │         │          │           │
+  │         │         │          │           └── Break here → sign-off is unverifiable
+  │         │         │          └── Break here → audit trail is incomplete
+  │         │         └── Break here → verification is untrustworthy
+  │         └── Break here → implementation is untraceable
+  └── Break here → entire chain starts without a foundation
+```
+
+A chain is only as strong as its weakest link. Traceability must be enforced at **every** link.
+
+## Role-Specific Application
+
+### Plan — Blueprint Traceability
+
+Plan is the chain's foundation. If blueprint traceability is broken, every downstream link is working from ambiguity.
+
+| Step | Action |
+|------|--------|
+| **Trace** | Read the original requirement. Extract business goals, constraints, scope boundaries, and success criteria. |
+| **Execute** | Design the blueprint: architecture, interfaces, data flow. Break into ordered Build steps, each with completion criteria. |
+| **Map** | Every Build step must trace back to a specific requirement. Every completion criterion must be objectively verifiable. |
+| **Evidence** | Self-check: can a Builder start from this blueprint alone? Are edge cases covered? Are interfaces unambiguous? |
+| **Record** | Write the blueprint document. Push tasks to the orchestrator queue. Store the blueprint in shared context (`set-context`). Notify Leader. |
+
+**Plan traceability record**: `requirement → blueprint → task list → shared context key`
+
+### Build — Implementation Traceability
+
+Build produces the concrete artifacts. Every code change must be traceable to a specific Plan requirement.
+
+| Step | Action |
+|------|--------|
+| **Trace** | Read the Planner's blueprint. Extract every implementable requirement as a checklist. |
+| **Execute** | Implement each requirement. Follow the Plan's architecture and interfaces. Document any deviations. |
+| **Map** | Build a traceability map: `Plan Requirement → Implementation → Status (done/deviated/blocked)`. |
+| **Evidence** | Provide proof: tests passing, manual verification results, key implementation decisions and rationale. |
+| **Record** | Commit code signed with your own name. Record the commit hash next to each completed item in the task document. Commit the document update. |
+
+**Build traceability record**: `blueprint requirement → code change → commit hash → document update → document commit`
+
+### Verify — Verification Traceability
+
+Verify independently checks Builder output. Every verification finding must be traceable to a Plan acceptance criterion and a Builder output.
+
+| Step | Action |
+|------|--------|
+| **Trace** | Read the Plan blueprint (acceptance criteria) and Builder output (commits, artifacts). Build a verification checklist by cross-referencing. |
+| **Execute** | For each checklist item, independently verify. Run tests. Inspect code. Check edge cases and regressions. |
+| **Map** | Build a verification map: `Plan Criterion → Builder Output → Verified Result → Status (pass/gap/fail)`. |
+| **Evidence** | For each finding, record: what was checked, how, actual command output, and references to Plan and Builder artifacts. |
+| **Record** | Write the verification report. Store in shared context. Flag gaps and failures to Builder and Reviewer. |
+
+**Verify traceability record**: `acceptance criterion → verification method → actual result → verdict → report path`
+
+### Review — Judgment Traceability
+
+Review judges the full chain. Every judgment must be traceable to Plan intent, Builder output, and Verify findings.
+
+| Step | Action |
+|------|--------|
+| **Trace** | Read all upstream artifacts: Plan blueprint, Builder traceability map, Verify report. Build a chain-level review checklist. |
+| **Execute** | For each item, make a judgment: ACCEPT / CONCERN / REJECT. Classify issues as P0 (blocking) / P1 (severe) / P2 (minor) / P3 (suggestion). |
+| **Map** | Build a review map: `Plan Intent → Build Result → Verify Finding → Review Judgment`. |
+| **Evidence** | For each CONCERN and REJECT: reference the specific Plan requirement, Builder output, Verify finding, and clear rationale. |
+| **Record** | Write the review report. Store in shared context. Issue Pass/Revise decision. Notify responsible roles. |
+
+**Review traceability record**: `plan intent → build result → verify finding → review judgment → report path → decision`
+
+### Accept — Sign-Off Traceability
+
+Accept is the final gate. The Go/No-Go decision must be traceable to specific business acceptance criteria and verified deliverables.
+
+| Step | Action |
+|------|--------|
+| **Trace** | Read the full chain: Plan blueprint, Builder output, Verify report, Review judgment. Extract business acceptance criteria. |
+| **Execute** | For each acceptance criterion, verify: is there a corresponding deliverable? Does it actually exist? Are upstream issues resolved? |
+| **Map** | Build an acceptance map: `Acceptance Criterion → Deliverable → Verification Result → Review Judgment → Status`. |
+| **Evidence** | For each criterion: verify code exists (grep), verify commits exist (git log), verify tests pass (run them), verify reports are self-consistent. |
+| **Record** | Write the acceptance report. Sign Go/No-Go. Zero issues for Go — no conditional passes. Store in shared context. |
+
+**Accept traceability record**: `acceptance criterion → deliverable → verification → review → Go/No-Go → report path`
+
+## The Traceability Record Chain
+
+When every link records its traceability, the full chain is auditable from end to end:
+
+```
+Business Requirement
+  └── Plan: blueprint → task-001(task-0000000001), task-002(task-0000000002)
+        └── Build: task-001 → commit a1b2c3d → doc update commit e4f5g6h
+              └── Verify: criterion A → test X passed, criterion B → gap found
+                    └── Review: gap B → CONCERN P1 → Revise decision
+                          └── Re-Build: fix gap B → commit i7j8k9l
+                                └── Re-Verify: criterion B → test Y passed
+                                      └── Re-Review: all clear → Pass
+                                            └── Accept: all criteria met → GO
+```
+
+Anyone can enter the chain at any point and traverse forward or backward. A reviewer can ask "what requirement led to this commit?" and get the answer in one step. An auditor can ask "was this acceptance criterion verified?" and find the verification report, the test output, and the reviewer's judgment.
+
+## Task Completion Checklist (All Roles)
+
+```
+□ Step 1 — Trace: Identified all upstream requirements and artifacts
+□ Step 2 — Execute: Completed work following traced requirements
+□ Step 3 — Map: Every output linked to a specific upstream requirement
+□ Step 4 — Evidence: Proof provided for each mapping
+□ Step 5 — Record: Traceability record persisted (commit, context store, or report)
+```
+
+## Common Mistakes (All Roles)
+
+- **Skipping Trace (Step 1)**: Starting work without reading upstream artifacts. Produces output that may not align with requirements.
+- **Skipping Map (Step 3)**: Producing output without linking it back to requirements. Downstream roles can't tell what was done for what.
+- **Map without Evidence (Step 4)**: Claiming "done" without proof. Unverifiable claims are invisible to auditors.
+- **Skipping Record (Step 5)**: Doing the work but not persisting the traceability record. The next link starts blind — the chain is broken.
+- **Weak evidence**: "Looks good" is not evidence. Specific commands run, specific outputs observed, specific file paths checked — these are evidence.
+- **Signing with someone else's name**: Traceability depends on knowing who did what. Every commit and report must identify its author.

package/dist/skills/task-verification/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: task-verification
+description: Independent verification of Builder output for the Verifier role. Use when the Verifier needs to verify that a Builder's output matches the Planner's blueprint — running tests, checking deliverables, identifying deviations, and producing a verification report with full traceability from every finding back to acceptance criteria. Triggers on keywords like "验证任务", "verify", "check", "测试验证", "排查问题", "验证产出", or when a Builder reports completion and the task enters the Verify stage of the responsibility chain.
+---
+
+# Task Verification
+
+> 验证不是跑一遍测试就完了，是对照蓝图逐项核实 Builder 的产出与计划的一致性。本技能与 [[task-traceability]] 协作，确保每次验证独立、客观、可复现、可追溯——每个验证结果都可追溯到具体的验收标准。
+
+---
+
+## 何时触发
+
+- Builder 标记任务完成，责任链流转到 Verify 阶段
+- Worker 通过 `claude-orchestrator claim-task` 认领了 verify 类型的任务
+- 用户说"验证一下 XXX 的产出"、"检查一下有没有问题"
+- 蓝图中有 verify 类型的任务需要开工
+
+---
+
+## 验证六步法
+
+按顺序执行，每一步通过才进入下一步。任一步发现偏离 → 记录问题，最终报告中体现。
+
+### 1. 认领 Verify 任务并读取蓝图
+
+```bash
+# 认领验证任务
+claude-orchestrator claim-task
+
+# 读取蓝图
+claude-orchestrator get-context --key plan-<目标slug>
+```
+
+从蓝图中提取：
+- 被验证的 Build 任务的验收标准
+- 预期的产出物类型和路径
+- 上下游依赖（谁依赖这个验证结果）
+
+明确验证范围：只验证蓝图定义的范围内内容。不验证蓝图未定义的东西。
+
+### 2. 收集 Builder 的产出物
+
+定位 Builder 在 `complete_task` 中声明的产出物：
+
+```bash
+# 通过 orchestrator 或任务文档找到 Builder 的 commit hash
+claude-orchestrator list-tasks --status completed | grep <task-id>
+
+# 查看 Builder 的代码变更
+git show <commit-hash> --stat
+git diff <commit-hash>^..<commit-hash>
+```
+
+确认产出物是否存在且可访问：
+- 代码 commit 是否存在且可检出？
+- 测试报告/截图文件是否存在？
+- Builder 声明的产出物是否都可以独立检查？
+
+如果产出物不存在或不可访问 → 立即记录为 P1 问题，退还给 Builder。
+
+### 3. 逐项对照验证
+
+按照蓝图中的验收标准，逐项独立验证（不依赖 Builder 的自测报告）：
+
+```bash
+# 运行蓝图指定的测试命令
+npm test -- <test-pattern> 2>&1
+
+# 检查蓝图要求的文件产出
+ls -la <expected-output-path>
+
+# 验证代码变更是否匹配任务描述
+git show <commit-hash> --name-only
+```
+
+对每一项验收标准记录：
+- 验收标准原文
+- 验证方法和命令
+- 实际结果
+- 判定（通过 / 偏离 / 未覆盖）
+
+如果某项验收标准无法独立复现（如依赖 Builder 的本地环境），标记为 ⏸ 无法验证，记录原因。
+
+### 4. 检查边缘情况
+
+蓝图定义了 happy path，Verifier 检查边缘情况：
+
+- 异常输入的处理是否正确？
+- 边界值是否行为正确？
+- 空状态、加载中状态是否处理？
+- 与现有功能的兼容性是否被破坏？（回归测试）
+- 错误信息是否有意义？
+
+```bash
+# 运行全量测试确认无回归
+npm test 2>&1 | tail -30
+```
+
+### 5. 判断偏离类型
+
+对每个发现的问题进行分类：
+
+| 类型 | 定义 | 处理 |
+|------|------|------|
+| **偏离** | 产出与蓝图不一致（少做了、做错了、多做了） | 退回 Builder 修复 |
+| **遗漏** | 蓝图的验收标准未满足 | 退回 Builder 补齐 |
+| **越界** | 做了蓝图范围外的事 | 标记给 Reviewer 判断是否需要回退 |
+| **隐患** | 表面上满足验收标准但存在隐蔽问题 | 写入验证报告，提醒 Reviewer 关注 |
+
+### 6. 产出验证报告
+
+写入验证报告文件（如 `docs/verify/<目标slug>-YYYY-MM-DD.md`）：
+
+```markdown
+# 验证报告
+
+> Verifier | YYYY-MM-DD | 验证范围：Builder <name> 对 <task> 的产出
+
+## 验证结论
+
+（一句话：通过 / 不通过）
+
+## 验证范围
+
+| Build 任务 | Builder | Commit | 产出物 |
+|------------|---------|--------|--------|
+| <任务名> | <name> | `hash` | <path> |
+
+## 逐项验证
+
+| # | 验收标准 | 验证方法 | 实际结果 | 判定 |
+|---|---------|---------|---------|------|
+| 1 | `npm test -- auth` 通过 | 执行 `npm test -- auth` | 5/5 passed | ✅ |
+| 2 | 截图 `login-flow.png` 存在 | `ls -la screenshots/` | 文件存在，尺寸 1200x800 | ✅ |
+| ... | ... | ... | ... | ... |
+
+## 问题清单
+
+| # | 类型 | 描述 | 影响 |
+|---|------|------|------|
+| 1 | 遗漏 | 未实现错误重试逻辑（蓝图要求 3 次重试） | 生产环境可能因瞬时故障失败 |
+
+## 回归检查
+
+| 检查项 | 结果 |
+|--------|------|
+| 全量测试 | 42/42 passed |
+| lint | 0 errors, 0 warnings |
+
+---
+
+*Verifier — YYYY-MM-DD*
+```
+
+验证报告写入后记录到共享上下文：
+
+```bash
+claude-orchestrator set-context \
+  --key verify-<目标slug> \
+  --value "$(cat docs/verify/<目标slug>-YYYY-MM-DD.md)"
+```
+
+---
+
+## 验证完成检查清单
+
+```
+□ 已从蓝图获取验收标准
+□ Builder 的产出物全部可独立访问
+□ 逐项验证了每条验收标准
+□ 检查了边缘情况和回归测试
+□ 每个问题已分类（偏离/遗漏/越界/隐患）
+□ 验证报告已产出并存入共享上下文
+□ 如有不通过项，已通过消息通知 Builder 和 Reviewer
+```
+
+---
+
+## 与其他技能的协作
+
+- **[[task-traceability]]**：基础层。Verifier 严格遵循追溯 → 执行 → 映射 → 举证 → 记录的五步法。每个验证结果必须追溯到蓝图的验收标准（Trace），逐项独立验证（Execute），映射验证结果到标准（Map），记录命令输出作为证据（Evidence），产出验证报告并存入共享上下文（Record）。
+- **[[task-planning]]**：Verifier 以 Planner 的蓝图为标准。蓝图中的验收标准是唯一的判断依据。
+- **[[task-execution]]**：Verifier 验证 Builder 的产出。Builder 的自测报告仅供参考，Verifier 独立验证。
+- **[[task-review]]**：Reviewer 读取 Verifier 的验证报告来判断是否进入下一环节。Verifier 发现的问题直接进入 Reviewer 的审查视野。
+
+---
+
+## 常见错误
+
+- **只跑 Builder 的测试命令**：Builder 的测试可能在 Builder 的本地环境通过，但 Verifier 的环境不同导致失败。环境差异本身就是有价值的发现。
+- **信任 Builder 的自测报告**：Verifier 不独立验证，只是转述 Builder 的报告。这丧失了验证的意义——如果 Builder 的报告可作为真相，就不需要 Verifier。
+- **不检查越界修改**：Builder 顺手重构了无关代码，Verifier 没发现。越界修改可能引入未被验收标准覆盖的 bug。
+- **验证报告太抽象**：只写"通过了"没有附上实际命令输出。Reviewer 无法判断验证的可信度。

package/dist/templates/worker-accept.md

@@ -0,0 +1,46 @@
+You are an Accepter in a multi-agent task coordination system. Your link in the responsibility chain is **Accept** — the final gate. You validate the complete deliverable against business acceptance criteria and make the Go/No-Go decision.
+
+## Your Identity
+- Name: {{name}}
+- Preset Role: {{preset_role}}
+- Current Link: Accept
+- Work Directory: {{work_dir}}
+- Time: {{time}}
+
+## Your Task
+
+**Title**: {{task_title}}
+**Description**: {{task_description}}
+**Completion Criteria**: {{task_criteria}}
+
+The full task specification is at: {{task_doc_path}}
+This includes the entire chain: Plan blueprint, Build output, Verify report, and Review judgment.
+
+## Execution Standard: task-acceptance
+
+Your job is NOT to re-verify or re-review. Your job is to validate the deliverable against business acceptance criteria and sign off.
+
+### Step 1: Read Full Chain Output
+Read all upstream artifacts: Planner blueprint, Builder traceability map, Verifier verification map, Reviewer review judgment.
+
+### Step 2: Verify Against Acceptance Criteria
+For each acceptance criterion: is there a corresponding deliverable? Does it actually exist? Are upstream issues resolved? Is evidence sufficient?
+
+### Step 3: Make Go/No-Go Decision
+- **Go**: All acceptance criteria met. Deliverable ready to ship.
+- **No-Go**: One or more criteria not met. Specific issues must be addressed before re-acceptance.
+
+There is no "conditional pass". Zero issues for Go.
+
+### Step 4: Sign Acceptance Report
+Write your acceptance report to {{result_path}}. Include per-criteria results and Go/No-Go decision with rationale.
+
+## Completion Report
+
+Link: accept
+Status: completed
+Decision: GO | NO-GO
+Criteria Checked: <count> | Passed: <count> | Failed: <count>
+Failed Criteria: <list each with responsible link and required fix>
+Result Path: {{result_path}}
+Next Link Ready: N/A (Accept is the final link — chain closed if GO)

package/dist/templates/worker-build.md

@@ -0,0 +1,45 @@
+You are a Builder in a multi-agent task coordination system. Your link in the responsibility chain is **Build** — you produce verifiable results according to the Planner's blueprint.
+
+## Your Identity
+- Name: {{name}}
+- Preset Role: {{preset_role}}
+- Current Link: Build
+- Work Directory: {{work_dir}}
+- Time: {{time}}
+
+## Your Task
+
+**Title**: {{task_title}}
+**Description**: {{task_description}}
+**Completion Criteria**: {{task_criteria}}
+
+The full task specification is at: {{task_doc_path}}
+This includes the Planner's blueprint and any upstream outputs.
+
+## Execution Standard: task-traceability
+
+Every piece of your work must be traceable to a specific requirement in the Plan.
+
+### Step 1: Trace
+Read the Planner's blueprint. Extract every implementable requirement: feature, interface, data, and quality requirements. List them as your implementation checklist.
+
+### Step 2: Execute
+Implement each requirement from your checklist. Follow the Plan's architecture exactly. Document any deviations with reasons. If the Plan is unclear, make a reasonable decision and proceed.
+
+### Step 3: Map
+Build a traceability map: Plan Requirement → Implementation → Status. Mark each as done, deviation (with reason), or not applicable.
+
+### Step 4: Evidence
+For each mapped item, provide evidence: tests written/passing, manual verification results, key decisions and rationale.
+
+Write your traceability map and evidence to {{result_path}}.
+
+## Completion Report
+
+Link: build
+Status: completed
+Implemented: <count> items
+Deviations: <count> items (list each with reason)
+Evidence: see {{result_path}} for full traceability map
+Result Path: {{result_path}}
+Next Link Ready: yes