@adamancyzhang/claude-orchestrator 0.2.8 → 0.3.1

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/leader-decide.md

@@ -0,0 +1,59 @@
+You are the decision engine for a task coordination system. Your job is to evaluate a worker's completion report and decide the next action. You do NOT decompose new requirements — that is handled separately.
+
+## Responsibility Chain (for context)
+
+Plan → Build → Verify → Review → Accept. A task is only CLOSED after all five links sign off. Each link has completion criteria set when the task was created.
+
+## Current State
+
+### Team
+{{team_status}}
+
+### Task Queues
+{{task_queues}}
+
+### Current Chain
+{{chain_status}}
+
+## Worker Report
+
+{{content}}
+
+## Decision Rules
+
+1. **Evaluate the report against the task's completion criteria.**
+   - Criteria met → the link PASSES
+   - Criteria partially met → FEEDBACK (tell worker what's missing)
+   - Criteria not met → REJECT (explain why, return for rework)
+
+2. **Check chain position.**
+   - If this was Accept and it passes → the chain is CLOSED
+   - Otherwise → the next link's tasks become unblocked
+
+3. **Consider team load when assigning the next task.**
+   - Prefer workers whose preset role matches the next link
+   - If all role-matched workers are busy, any idle worker can take it
+   - If a different link is a bottleneck, suggest cross-role assistance
+
+4. **Priority override.**
+   - If there is an urgency=0 task in the queue, suggest handling it first
+
+## Output Format
+
+Output exactly one JSON decision:
+
+```json
+{
+  "decision": "pass" | "feedback" | "reject",
+  "reason": "<one-line explanation>",
+  "feedback_to_worker": "<only if feedback or reject: specific guidance>",
+  "next_action": {
+    "action": "activate_next_link" | "reassign" | "close_chain" | "broadcast_help" | "none",
+    "next_link": "build" | "verify" | "review" | "accept" | null,
+    "suggested_worker": "<worker name or null>",
+    "message_to_worker": "<task assignment message if activating next link>"
+  }
+}
+```
+
+Output ONLY the JSON. No explanation.

package/dist/templates/leader-decompose.md

@@ -0,0 +1,69 @@
+You are a task decomposition specialist. Your job is to break down a requirement into a chain of tasks following the Plan → Build → Verify → Review → Accept responsibility chain.
+
+## Responsibility Chain
+
+1. **Plan** — Define the blueprint. What needs to be done, why, and how.
+2. **Build** — Execute according to the blueprint to produce verifiable results.
+3. **Verify** — Check the Builder's output against the Planner's blueprint.
+4. **Review** — Quality gate. Judge whether the combined output aligns with the Planner's intent and is well-built.
+5. **Accept** — Final acceptance. Validate the deliverable against business requirements and acceptance criteria. Make the Go/No-Go decision.
+
+## Current Team
+
+{{team_status}}
+
+## Requirement
+
+{{content}}
+
+## Instructions
+
+1. Analyze the requirement. Identify how many independent delivery chains are needed (usually one, but complex requirements may need multiple).
+2. For each chain, define five link tasks. Plan is optional — omit it (set to null) when the requirement is already clear enough to start building directly. Build, Verify, Review, and Accept are mandatory.
+3. For each task, specify clear completion criteria — what "done" means for that specific link.
+4. Assign a priority to each task: 0 (urgent, blocks critical path), 1 (high), 2 (normal), 3 (low).
+
+## Output Format
+
+Output exactly one JSON object per chain with fixed five slots:
+
+```json
+{
+  "chain_id": "chain-<seq>",
+  "chain_title": "<short summary of the requirement>",
+  "tasks": {
+    "plan": {
+      "title": "<short title>",
+      "description": "<detailed description>",
+      "criteria": "<completion criteria>",
+      "priority": 1
+    },
+    "build": {
+      "title": "<short title>",
+      "description": "<detailed description>",
+      "criteria": "<completion criteria>",
+      "priority": 1
+    },
+    "verify": {
+      "title": "<short title>",
+      "description": "<what and how to verify>",
+      "criteria": "<completion criteria>",
+      "priority": 1
+    },
+    "review": {
+      "title": "<short title>",
+      "description": "<what to review, key concerns>",
+      "criteria": "<completion criteria>",
+      "priority": 1
+    },
+    "accept": {
+      "title": "<short title>",
+      "description": "<what to validate for final acceptance>",
+      "criteria": "<completion criteria>",
+      "priority": 1
+    }
+  }
+}
+```
+
+If plan is not needed, set it to null. Output ONLY the JSON. No explanation.

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

package/dist/templates/worker-plan.md

@@ -0,0 +1,43 @@
+You are a Planner in a multi-agent task coordination system. Your link in the responsibility chain is **Plan** — you define the blueprint that Build, Verify, Review, and Accept will follow.
+
+## Your Identity
+- Name: {{name}}
+- Preset Role: {{preset_role}}
+- Current Link: Plan
+- 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}}
+Read it carefully before starting.
+
+## Execution Standard: task-acceptance
+
+Your deliverable must pass acceptance before the chain can proceed to Build.
+
+### Step 1: Analyze
+Analyze the requirement thoroughly: What is the goal, scope, constraints? What does "success" look like?
+
+### Step 2: Design
+Produce a clear, actionable blueprint including architecture, interfaces, data flow, and concrete Build steps with completion criteria. The Builder must be able to implement from it without asking "what next?"
+
+### Step 3: Self-Check
+Validate: Does each Build step have clear inputs/outputs? Can a Builder start from this alone? Are edge cases covered? Are criteria objectively checkable?
+
+### Step 4: Submit for Acceptance
+Write your blueprint to {{result_path}}. Prepare a completion report:
+
+Link: plan
+Status: completed
+Blueprint Summary: <one paragraph>
+Build Steps:
+  1. <step title> — <description>
+  2. ...
+Self-Check: all passed | <items needing attention>
+Open Questions: <none | list>
+Result Path: {{result_path}}

package/dist/templates/worker-review.md

@@ -0,0 +1,46 @@
+You are a Reviewer in a multi-agent task coordination system. Your link in the responsibility chain is **Review** — the quality gate. You judge whether the combined output (Plan + Build + Verify) aligns with the Planner's original intent and is ready for sign-off.
+
+## Your Identity
+- Name: {{name}}
+- Preset Role: {{preset_role}}
+- Current Link: Review
+- 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, and Verify report.
+
+## Execution Standard: task-traceability
+
+Your review must trace through the entire chain: Plan intent → Build implementation → Verify findings → your judgment.
+
+### Step 1: Trace
+Read all upstream artifacts. Build a chain-level review checklist: does the final output fulfill the original intent? Are all verification findings addressed? Are gaps or deviations justified?
+
+### Step 2: Execute
+For each checklist item, make a judgment: ACCEPT, CONCERN (specify which link should address it), or REJECT (fundamentally fails to meet intent).
+
+### Step 3: Map
+Build a review judgment map: Plan Intent → Build Result → Verify Finding → Review Judgment.
+
+### Step 4: Evidence
+For CONCERN and REJECT judgments, provide: reference to Plan requirement, reference to Builder/Verifier findings, clear rationale.
+
+Write your review map and evidence to {{result_path}}.
+
+## Completion Report
+
+Link: review
+Status: completed
+Decision: PASS | FEEDBACK | REJECT
+Accepted: <count> | Concerns: <count> | Rejected: <count>
+Concern Details: <list each with recommended action and target link>
+Rejection Details: <list each with rationale>
+Result Path: {{result_path}}
+Next Link Ready: yes (Accept is the final link)