create-harness-vibe-coding 0.1.3 → 0.1.4

package/templates/common/docs/README.md

@@ -1,112 +1,97 @@
-# {{projectName}} — Docs Entry Point
+# {{projectName}} - Harness Router
 
-> **Purpose**: A shared project map for humans and coding agents. `AGENTS.md` tells agents to read `CLAUDE.md` first, then enter the project fact source from here.
->
-> **Principle**: Short entry + topic-specific docs. Don't cram everything into `CLAUDE.md` or `AGENTS.md`.
+Purpose: route humans and agents to the smallest useful context.
 
----
+Default load: `CLAUDE.md`, `MEMORY.md`, this file, and `docs/harness/PLAN.md` when work is active. Do not read the whole docs tree.
 
-## 0-1 Required Project Flow
+## 0-1 Flow
 
-When starting from scratch, produce docs in this order. Don't move to the next phase without a minimum viable conclusion from the previous one.
+```text
+Idea -> Research -> PRD -> Architecture -> Plan -> Build -> Verify -> Feedback
+```
 
-| Order | Artifact | Must Answer | Completion Standard |
-| --- | --- | --- | --- |
-| 1 | [research/scaffolds.md](research/scaffolds.md) | What do others do? Which templates, frameworks, constraints? Why adopt/reject? | At least 3 references; each with Purpose / Strength / Weakness / Decision |
-| 2 | [research/PRD.md](research/PRD.md) | What does this MVP solve? What is explicitly NOT in scope? How to verify? | One page; MVP, Non-goals, verifiable acceptance criteria |
-| 3 | [harness/architecture.md](harness/architecture.md) | How many layers? Component boundaries? What can/can't harness do? | Layer dependencies, core components, non-negotiable constraints, key decisions |
-| 4 | [domain/ports.md](domain/ports.md) | What contracts between layers? Error and idempotency semantics? | Each port: preconditions, postconditions, error semantics, known implementations |
-| 5 | [harness/data-flow.md](harness/data-flow.md) | Normal path and failure paths? What does the caller see? | At least 1 core flow; each failure point has system behavior and recovery |
-| 6 | [harness/state-machines.md](harness/state-machines.md) | Which components have state? Which transitions are legal/illegal? | Each stateful component: state enum, transition table, illegal transitions |
-| 7 | [harness/agent-workflow.md](harness/agent-workflow.md) | How do agents divide work, TDD, verify, and close? | Feature doc template, subagent roles, write set, completion criteria |
-| 8 | tests + implementation | Is the design proven by code? | Minimal vertical slice runs; tests cover core success/failure paths |
-
-**Hard gates**:
-- If a doc still has `{{...}}` placeholders, don't claim the architecture is finalized.
-- **Minimum docs to start coding**: `research/PRD.md` + `harness/architecture.md` + at least 1 filled port contract. Once there, start a minimal vertical slice, but record risks from missing `data-flow.md` / `state-machines.md` in the feature doc or tests.
-- If architecture boundaries change, sync docs and tests.
-- If implementation spans more than one short session, open a feature doc from [features/_template.md](features/_template.md) first.
-
-## Doc Completion Standards
-
-| Doc | Minimum Standard | Can Defer |
-| --- | --- | --- |
-| `research/scaffolds.md` | At least 3 references; each with Purpose / Strength / Weakness / Decision; final decision recorded | Rejected options can be backfilled |
-| `research/PRD.md` | Why, MVP, Non-goals, decision priorities, acceptance criteria are not placeholders | Non-functional targets can start as MVP-level goals |
-| `harness/architecture.md` | Layer dependencies, core components, at least 1 ADR, non-negotiable constraints | Runner variants can say "none yet" when only one runner exists |
-| `domain/ports.md` | At least 1 port with preconditions, postconditions, error semantics, idempotency, known impls | Additional ports can be added incrementally with features |
-| `harness/data-flow.md` | At least 1 core flow with normal + failure paths | Secondary flows can come later |
-| `harness/state-machines.md` | Every stateful component has state enum and transition table | Stateless components don't need entries |
-| `harness/agent-workflow.md` | Feature doc, write set, verification, closure criteria are clear | Subagent roles can expand as needed |
-| `features/*.md` | Requirements / Design / Tasks / Verification closed loop | Minor fixes can take the fast lane with a reason |
-
----
-
-## Harness Boundary
-
-The current template uses `interfaces -> harness -> application -> domain` with `infrastructure` adapters. The `domain` is any business domain: data analysis, document processing, code repair, ops automation — all can hang off the same harness.
-
-| Layer | Responsible For | NOT Responsible For |
-| --- | --- | --- |
-| `interfaces/` | CLI / API / UI entry points | Business rules, data source details |
-| `harness/` | Runtime shell, scheduling, safety gates, audit, observability, failure control | Domain business rules, domain decisions, adapter implementation details |
-| `application/` | Use-case orchestration, composing domain ports into business actions | Specific external service implementations |
-| `domain/` | Business objects, business invariants, port protocols | Importing harness / infrastructure / interfaces |
-| `infrastructure/` | Filesystem, database, external API, model service port implementations | Defining business contracts |
-
-How to decide: if it "protects, records, schedules, recovers the system during runtime" → harness. If it "decides whether a business action should happen and what it means" → application/domain.
-
----
+For the full phase contract, load [harness/lifecycle.md](harness/lifecycle.md).
 
-## Doc Map
+## Development Contract
 
-```text
-docs/
-├── README.md                       ← You are here
-├── features/
-│   └── _template.md                ← Single-feature implementation doc template (Kiro-lite)
-├── harness/
-│   ├── agent-workflow.md           ← Agent roles, TDD, closure, write set rules
-│   ├── architecture.md             ← Component map, layer rules, key design decisions
-│   ├── data-flow.md                ← End-to-end event flow: normal + error paths
-│   └── state-machines.md           ← Stateful component transition diagrams and tables
-├── domain/
-│   └── ports.md                    ← Cross-layer interface contracts: pre/post, error semantics
-└── research/
-    ├── PRD.md                      ← One-page MVP scope and acceptance template
-    └── scaffolds.md                ← Research conclusions, reference templates, tech rationale
-```
+- This file is a router, not a full spec.
+- If the task does not clearly match a row below, search by keywords before loading more docs.
+- Core rules live in `CLAUDE.md` and `.claude/rules/ecc/common.md`.
+- Phase rules live in [harness/lifecycle.md](harness/lifecycle.md).
+- Build, review, test, and subagent rules live in [harness/agent-workflow.md](harness/agent-workflow.md).
+- Parallel dispatch rules live in [harness/dispatch.md](harness/dispatch.md).
+- Extension rules live in [harness/extension.md](harness/extension.md).
+- Context-loading rules live in [harness/context-loading.md](harness/context-loading.md).
+- Progress lives in [harness/PLAN.md](harness/PLAN.md) and the current feature doc.
 
----
+## Keyword Routing
 
-## Reading Order
+Use this only when the task is ambiguous or the matching row is unclear.
 
-| Role | Read First | Then |
-| --- | --- | --- |
-| New developer | [research/PRD.md](research/PRD.md) | [harness/architecture.md](harness/architecture.md) |
-| Implementer | [harness/agent-workflow.md](harness/agent-workflow.md) | [features/_template.md](features/_template.md) |
-| Reviewer | [harness/state-machines.md](harness/state-machines.md) | tests |
-| Architecture maintainer | [research/scaffolds.md](research/scaffolds.md) | [harness/architecture.md](harness/architecture.md) |
+1. Extract 2-5 concrete keywords from the user request.
+2. Search the project docs first:
 
----
+```bash
+rg -n "keyword1|keyword2|keyword3" CLAUDE.md MEMORY.md docs
+```
 
-## Maintenance Rules
+3. Load only the top matching doc or the smallest matching doc pair.
+4. If keyword search conflicts with the table below, follow the table and record the assumption in `docs/harness/PLAN.md`.
 
-- Code change affects architecture → update `harness/architecture.md`.
-- New cross-layer interface → update `domain/ports.md`.
-- New flow or failure path → update `harness/data-flow.md`.
-- New stateful component → update `harness/state-machines.md`.
-- New external dependency, template, or framework choice → update `research/scaffolds.md`.
-- Non-trivial feature → copy `features/_template.md`, follow `harness/agent-workflow.md`.
-- Docs rules repeatedly ignored by agents → don't lengthen entry files; turn rules into tests, lint, or more specific templates.
+Keywords are retrieval hints, not project facts.
 
----
+## Load By Task
 
-## External References
+Load the matching row only. Add adjacent docs only when the loaded doc directly names them.
 
-- OpenAI, Harness Engineering: short `AGENTS.md` as directory, `docs/` as fact source; architecture boundaries enforced by tests/lint.
-- Anthropic, Claude Code Best Practices: `CLAUDE.md` kept short and maintainable; use `@docs/...` to pull in project docs.
-- OpenAI, PLANS.md / ExecPlans: complex tasks use self-contained, verifiable, recoverable execution plans.
-- GitHub Spec Kit / Kiro Specs: borrow requirements -> design -> tasks -> verification structure.
-- Anthropic, Building Effective Agents: agent loops need environment feedback, clear stop conditions, and human checkpoints.
-- arc42 / C4 / ADR / ARCHITECTURE.md: provide architecture chapters, static structure views, decision records, and lightweight code maps respectively.
+| When to Read | Keywords | Load | Output |
+| --- | --- | --- | --- |
+| Raw idea or vague product request | idea, vague, clarify, goal, non-goal, lifecycle | [harness/lifecycle.md](harness/lifecycle.md), [research/PRD.md](research/PRD.md) | clarified goal, non-goals, first questions |
+| Need market/tech direction | research, market, competitor, stack, library, pricing, policy | [research/README.md](research/README.md), [research/research-results.md](research/research-results.md) | research protocol, adopted/rejected choices |
+| Need MVP/spec | PRD, MVP, scope, requirement, acceptance, non-goal | [research/PRD.md](research/PRD.md) | one-page PRD with verifiable acceptance criteria |
+| Need architecture or boundaries | architecture, boundary, layer, domain, port, adapter, dependency | [harness/architecture.md](harness/architecture.md), [domain/ports.md](domain/ports.md) | layer map, ports, constraints |
+| Need implementation plan | plan, task, write set, verify, milestone, progress | [harness/PLAN.md](harness/PLAN.md), [harness/agent-workflow.md](harness/agent-workflow.md) | tasks, write set, verification commands |
+| Need parallel agents | parallel, dispatch, handoff, write set, dependency, status | [harness/dispatch.md](harness/dispatch.md), [harness/context-loading.md](harness/context-loading.md), [harness/PLAN.md](harness/PLAN.md) | dispatch table, agent roles, read/write sets |
+| Adding stack-specific agents/skills | extension, agent, skill, rule, hook, stack-specific, compatibility | [harness/extension.md](harness/extension.md), [harness/dispatch.md](harness/dispatch.md) | compatible agents, skills, rules, hooks |
+| Need subagents | subagent, role pack, context, inject, return format | [harness/context-loading.md](harness/context-loading.md) | role-specific context pack |
+| Need feature work | feature, implementation, TDD, test, review, closeout | [features/_template.md](features/_template.md), [harness/agent-workflow.md](harness/agent-workflow.md) | feature doc, tests, implementation loop |
+| Flow or failure behavior changes | data flow, event, failure, retry, recovery, caller behavior | [harness/data-flow.md](harness/data-flow.md) | happy path, failure path, caller behavior |
+| Stateful behavior changes | state, transition, guard, illegal transition, state machine | [harness/state-machines.md](harness/state-machines.md) | states, transitions, illegal transitions |
+| Review or release check | review, release, finding, risk, evidence, verification | [harness/agent-workflow.md](harness/agent-workflow.md), current feature doc | findings, verification evidence |
+| Harness readiness check | validate, readiness, placeholder, missing file, release gate | `scripts/validate-harness.mjs`, `scripts/validate-harness.mjs --strict` | missing files and unresolved project placeholders |
+
+## Gates
+
+- Move phases in order unless the user asks for a fast lane.
+- Do not code before the PRD has MVP, non-goals, and acceptance criteria.
+- Do not cross a layer boundary without updating architecture or ports.
+- Do not spawn a subagent without a role, read boundary, write boundary, and return contract.
+- Do not run writing agents in parallel unless write sets are disjoint.
+- Do not add stack-specific agents or skills without following `harness/extension.md`.
+- Do not close work without tests or recorded manual verification.
+- Do not mark work `Verified` until evidence is recorded in `docs/harness/PLAN.md` or the feature doc.
+- Run `node scripts/validate-harness.mjs` for scaffold structure; run `node scripts/validate-harness.mjs --strict` after bootstrap and before release.
+- If a doc still has `{{...}}`, treat that section as a template, not project fact.
+
+## Doc Map
+
+```text
+docs/README.md                  router only
+docs/harness/PLAN.md            active execution plan
+docs/harness/lifecycle.md       0-1 product flow
+docs/harness/context-loading.md dynamic loading and subagent packs
+docs/harness/dispatch.md       lightweight parallel dispatch protocol
+docs/harness/extension.md      stack-specific asset contract
+docs/harness/agent-workflow.md  build/review/test loop
+docs/harness/architecture.md    layer boundaries
+docs/harness/data-flow.md       runtime/failure paths
+docs/harness/state-machines.md  state transitions
+docs/domain/ports.md            cross-layer contracts
+docs/features/_template.md      feature work packet
+docs/research/README.md         research protocol
+docs/research/PRD.md            product scope
+docs/research/research-results.md research results
+scripts/validate-harness.mjs    lightweight harness gate
+.claude/agents/*                built-in common agents
+.claude/skills/*                skill-style dynamic loaders
+```

package/templates/common/docs/domain/ports.md

@@ -1,73 +1,73 @@
-# 端口协议 — {{projectName}}
+# Port Contracts — {{projectName}}
 
-> **职责**：定义跨层接口契约。这是分层架构的"法律合同"。每个端口不仅写签名，还写前置条件、后置条件、错误语义。
+> **Responsibility**: Define cross-layer interface contracts. These are the "legal contracts" of a layered architecture. Each port documents not only its signature, but also preconditions, postconditions, and error semantics.
 >
-> **原则**：端口文档 != API 参考文档。它是一个合同（contract），指定调用方义务和实现方保证。
+> **Principle**: Port documentation != API reference documentation. It is a contract that specifies caller obligations and implementer guarantees.
 >
-> 哲学来源：Bertrand Meyer 的 Design by Contract (Eiffel) + Alistair Cockburn 的六边形架构端口文档。
+> Philosophical origins: Bertrand Meyer's Design by Contract (Eiffel) + Alistair Cockburn's hexagonal architecture port documentation.
 
 ---
 
-## 1. 端口分类
+## 1. Port Classification
 
-### 1.1 驱动端口（Inbound — 外部调用应用）
+### 1.1 Driving Ports (Inbound — external calls application)
 
-| 端口 | 定义位置 | 用途 |
+| Port | Definition Location | Purpose |
 | --- | --- | --- |
 | `{{INBOUND_PORT_1}}` | `{{LOCATION}}` | {{DESCRIPTION}} |
 
-### 1.2 被驱动端口（Outbound — 应用调用外部）
+### 1.2 Driven Ports (Outbound — application calls external)
 
-| 端口 | 定义位置 | 用途 |
+| Port | Definition Location | Purpose |
 | --- | --- | --- |
 | `{{OUTBOUND_PORT_1}}` | `{{LOCATION}}` | {{DESCRIPTION}} |
 
 ---
 
-## 2. 端口定义模板
+## 2. Port Definition Template
 
-每个端口按以下格式填写：
+Fill in each port using the format below:
 
-- **类别**：驱动 / 被驱动
-- **定义位置**：`{{FILE_PATH}}`
-- **协议类**：`{{CLASS_OR_INTERFACE}}`
+- **Category**: Driving / Driven
+- **Definition Location**: `{{FILE_PATH}}`
+- **Contract Class**: `{{CLASS_OR_INTERFACE}}`
 
-### 用途
+### Purpose
 
 {{WHAT_THIS_PORT_DOES}}
 
-### 方法
+### Methods
 
-**前置条件**（调用方必须保证）：
+**Preconditions** (caller must guarantee):
 - {{PRECONDITION_1}}
 - {{PRECONDITION_2}}
 
-**后置条件**（实现方保证）：
+**Postconditions** (implementer guarantees):
 - {{POSTCONDITION_1}}
 - {{POSTCONDITION_2}}
 
-**错误语义**：
+**Error Semantics**:
 
-| 异常类型 | 触发条件 | 调用方应 |
+| Exception Type | Trigger Condition | Caller Should |
 | --- | --- | --- |
 | `{{EXCEPTION_TYPE}}` | {{CONDITION}} | {{CALLER_ACTION}} |
 
-**幂等性**：{{YES_NO_AND_DETAILS}}
+**Idempotency**: {{YES_NO_AND_DETAILS}}
 
-### 已知实现
+### Known Implementations
 
-| 适配器 | 位置 | 用途 |
+| Adapter | Location | Purpose |
 | --- | --- | --- |
 | `{{ADAPTER_NAME}}` | `{{LOCATION}}` | {{PURPOSE}} |
 
 ---
 
-## 3. 跨端口不变量
+## 3. Cross-Port Invariants
 
 - {{INVARIANT_1}}
 - {{INVARIANT_2}}
-- 新增端口必须定义在 `domain/ports` 中，适配器放在 `infrastructure/`。
+- New ports must be defined in `domain/ports`; adapters go in `infrastructure/`.
 
 ---
 
-> **提示**：当前 ports.md 是模板。请根据你的项目领域替换 `{{...}}` 占位符。参考 `docs/harness/data-flow.md` 了解端口如何被编排。
+> **Note**: The current ports.md is a template. Replace `{{...}}` placeholders with your project's domain details. Refer to `docs/harness/data-flow.md` to understand how ports are orchestrated.

package/templates/common/docs/features/_template.md

@@ -1,29 +1,31 @@
 # {{FEATURE_NAME}}
 
-> **状态**：Draft / In Progress / Blocked / Done
-> **创建日期**：{{YYYY-MM-DD}}
-> **负责人**：{{OWNER_OR_AGENT}}
-> **关联文档**：{{PRD_OR_ARCH_DOC_LINKS}}
+> **When to use**: During the PRD phase, every new feature identified in `research/PRD.md` must have its own features document created from this template. One feature = one doc = one implementation unit. Do not code a PRD scope item without a corresponding features doc.
+
+> **Status**: Draft / In Progress / Blocked / Done
+> **Created**: {{YYYY-MM-DD}}
+> **Owner**: {{OWNER_OR_AGENT}}
+> **Related Docs**: {{PRD_OR_ARCH_DOC_LINKS}}
 
 ---
 
 ## 1. Requirements
 
-### 1.1 背景
+### 1.1 Background
 
 {{WHY_THIS_FEATURE_EXISTS}}
 
-### 1.2 目标
+### 1.2 Goals
 
 - {{GOAL_1}}
 - {{GOAL_2}}
 
-### 1.3 非目标
+### 1.3 Non-Goals
 
 - {{NON_GOAL_1}}
 - {{NON_GOAL_2}}
 
-### 1.4 验收标准
+### 1.4 Acceptance Criteria
 
 - [ ] {{ACCEPTANCE_CRITERION_1}}
 - [ ] {{ACCEPTANCE_CRITERION_2}}
@@ -33,9 +35,9 @@
 
 ## 2. Design
 
-### 2.1 影响范围
+### 2.1 Impact Scope
 
-| 区域 | 是否影响 | 说明 |
+| Area | Impacted? | Notes |
 | --- | --- | --- |
 | `harness/architecture.md` | {{YES_NO}} | {{NOTE}} |
 | `domain/ports.md` | {{YES_NO}} | {{NOTE}} |
@@ -53,20 +55,20 @@
 - `{{PATH_OR_BEHAVIOR_1}}`
 - `{{PATH_OR_BEHAVIOR_2}}`
 
-### 2.4 方案
+### 2.4 Approach
 
-#### 候选方案
+#### Candidate Approaches
 
-| 方案 | 优点 | 缺点 | 结论 |
+| Approach | Pros | Cons | Decision |
 | --- | --- | --- | --- |
 | {{OPTION_A}} | {{PROS_A}} | {{CONS_A}} | {{ACCEPT_REJECT}} |
 | {{OPTION_B}} | {{PROS_B}} | {{CONS_B}} | {{ACCEPT_REJECT}} |
 
-#### 选择理由
+#### Rationale
 
 {{SELECTED_DESIGN_AND_RATIONALE}}
 
-### 2.5 边界条件
+### 2.5 Edge Cases
 
 - {{EDGE_CASE_1}} -> {{EXPECTED_BEHAVIOR_1}}
 - {{EDGE_CASE_2}} -> {{EXPECTED_BEHAVIOR_2}}
@@ -75,7 +77,7 @@
 
 ## 3. Tasks
 
-> 每个 task 必须有验证方式。需要 subagent 时，先写清角色和 write set。
+> Every task must have a verification method. When a subagent is needed, define its role and write set first.
 
 | # | Task | Owner | Write Set | Verify |
 | --- | --- | --- | --- | --- |
@@ -83,15 +85,22 @@
 | 2 | {{IMPLEMENT_MINIMAL_CHANGE}} | {{OWNER}} | `{{PATH}}` | `{{COMMAND_OR_CHECK}}` |
 | 3 | {{SYNC_DOCS_OR_BOUNDARIES}} | {{OWNER}} | `{{PATH}}` | `{{COMMAND_OR_CHECK}}` |
 
-### Subagent Plan
+### Subagent Plan (required — justify if all No)
 
-| Role | Needed? | Scope |
-| --- | --- | --- |
-| Explorer | {{YES_NO}} | {{READ_ONLY_SCOPE}} |
-| Test Writer | {{YES_NO}} | {{TEST_WRITE_SET}} |
-| Implementer | {{YES_NO}} | {{IMPLEMENTATION_WRITE_SET}} |
-| Reviewer | {{YES_NO}} | {{REVIEW_SCOPE}} |
-| Verifier | {{YES_NO}} | {{VERIFY_COMMANDS}} |
+Estimate the context budget for this feature. If the main agent would need to read >5 files or modify >3 files, subagents are mandatory per `.claude/rules/ecc/common.md`.
+
+| Agent / Pass | Required? | Mode | Read Boundary | Write Set | Verify |
+| --- | --- | --- | --- | --- | --- |
+| Planner | {{YES_NO}} | Parallel Read | `{{SCOPE}}` | none | `{{CHECK}}` |
+| Researcher / Docs Researcher | {{YES_NO}} | Parallel Read | `{{SCOPE}}` | none | `{{CHECK}}` |
+| Architect | {{YES_NO}} | Parallel Read | `{{SCOPE}}` | none | `{{CHECK}}` |
+| Explorer Pass | {{YES_NO}} | Parallel Read | `{{SCOPE}}` | none | `{{CHECK}}` |
+| Test Writer | {{YES_NO}} | Serial Write | `{{SCOPE}}` | `{{PATH}}` | `{{COMMAND}}` |
+| Implementer / Debugger | {{YES_NO}} | Serial Write | `{{SCOPE}}` | `{{PATH}}` | `{{COMMAND}}` |
+| Reviewer | {{YES_NO}} | Parallel Read | `{{SCOPE}}` | none | `{{CHECK}}` |
+| Verifier | {{YES_NO}} | Parallel Read | `{{SCOPE}}` | none | `{{COMMANDS}}` |
+
+**If all roles are No, justify:** {{WHY_MAIN_AGENT_CAN_HANDLE_ALONE}}
 
 ---
 
@@ -114,7 +123,7 @@
 - [ ] `domain/ports.md`
 - [ ] `harness/data-flow.md`
 - [ ] `harness/state-machines.md`
-- [ ] `research/scaffolds.md`
+- [ ] `research/research-results.md`
 - [ ] Not needed because {{REASON}}
 
 ### 4.4 Decision Log

package/templates/common/docs/harness/PLAN.md

@@ -0,0 +1,80 @@
+# PLAN.md - Active Execution Plan
+
+Use this file when work spans more than one step, one file, or one agent.
+
+## Current Goal
+
+{{CURRENT_GOAL}}
+
+## Phase
+
+Choose one: Idea / Research / PRD / Architecture / Plan / Build / Verify / Feedback.
+
+Current: {{CURRENT_PHASE}}
+
+## Progress Rules
+
+- Phase tracks lifecycle progress.
+- Task status tracks execution progress.
+- Update before handoff, after verification, and when blocked.
+
+Allowed task statuses: Pending / In Progress / Blocked / Done / Verified.
+
+- Pending: not started.
+- In Progress: active work.
+- Blocked: needs user input or external change.
+- Done: task complete, evidence not final.
+- Verified: verification evidence is recorded.
+
+## Success Criteria
+
+- [ ] {{CRITERION_1}}
+- [ ] {{CRITERION_2}}
+- [ ] {{CRITERION_3}}
+
+## Scope
+
+Allowed write set:
+- `{{PATH_OR_GLOB}}`
+
+Forbidden:
+- {{OUT_OF_SCOPE}}
+
+## Loaded Context
+
+Keep this list short. Add only docs/files used for the current phase.
+
+- `docs/README.md`
+- `{{LOADED_DOC_OR_FILE}}`
+
+## Tasks
+
+| # | Task | Owner | Verify | Status |
+| --- | --- | --- | --- | --- |
+| 1 | {{TASK}} | {{OWNER}} | `{{COMMAND_OR_CHECK}}` | Pending |
+
+## Parallel Dispatch
+
+Use [dispatch.md](dispatch.md) when more than one agent or bounded pass is useful.
+
+| Task | Agent | Mode | Read Set | Write Set | Depends On | Output | Status |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| {{TASK}} | {{AGENT}} | Parallel Read / Serial Write / Isolated Worktree | `{{READ_SET}}` | `{{WRITE_SET_OR_NONE}}` | {{DEPENDENCY_OR_NONE}} | {{EXPECTED_OUTPUT}} | Pending |
+
+## Agent Handoffs
+
+| Agent | Role | Context Pack | Result |
+| --- | --- | --- | --- |
+| {{AGENT}} | {{ROLE}} | {{DOCS_OR_FILES}} | {{SUMMARY}} |
+
+## Decisions
+
+| Date | Decision | Reason |
+| --- | --- | --- |
+| {{YYYY-MM-DD}} | {{DECISION}} | {{REASON}} |
+
+## Verification
+
+| Check | Result | Notes |
+| --- | --- | --- |
+| `{{CHECK}}` | Not run | {{NOTES}} |