agent-method 1.5.3 → 1.5.6

package/templates/starter/CLAUDE.md

@@ -21,6 +21,10 @@
 | **Methodology guidance** | .context/METHODOLOGY.md | -- |
 | **Phase completion** | SUMMARY.md | SUMMARY.md, STATE.md, ROADMAP.md |
 | **Backlog / ideas** | todos/backlog.md | todos/backlog.md |
+| **Management overview** | Management/DIGEST.md, Management/STATUS.md, STATE.md | Management/STATUS.md, Management/DIGEST.md |
+| **Project review** | Reviews/INDEX.md, relevant source files | Reviews/ (affected review file) |
+| **Workflow analysis** | agentWorkflows/INDEX.md, SESSION-LOG.md | agentWorkflows/ (affected analysis file) |
+| **Docs update** | .context/DOCS-MAP.md, relevant docs/ files | docs/ files, .context/DOCS-MAP.md |
 
 <!-- INSTRUCTION: Replace the {your-domain-type} row with project-specific query types.
      Each should pair .context/BASE.md with one specialist. Add as many rows as needed. -->
@@ -39,18 +43,126 @@ When a file changes, check this table and update dependent files in the same res
 | Intelligence layer file exceeds 300 lines | Restructure into index + components subdirectory (keep active content, archive completed sections) |
 | New domain area | .context/BASE.md, consider new .context/ specialist, this file (if new scoping row) |
 | Lifecycle stage change | PROJECT-PROFILE.md (update stage + date), STATE.md (record decision) |
-| Session close or high-effort task completion | SESSION-LOG.md (append metrics entry — effort, ambiguity, context level, tokens, time, workflow, features, cascades, friction, findings) |
+| Session close or high-effort task completion | SESSION-LOG.md (append metrics entry — effort, ambiguity, context level, tokens, time, user response, refinement delta, workflow, features, cascades, friction, findings). For high-effort tasks also: Management/DIGEST.md (append row — date, task, query, outcome, key changes, decisions, effort, time), Management/STATUS.md (if milestone) |
+| Significant milestone or phase completion | Management/STATUS.md (update current state, recent decisions, health indicators) |
+| New project component or module | .context/DOCS-MAP.md (add component mapping, check scaffolding rules for new docs/ proposals) |
+| docs/ file created or deleted | .context/DOCS-MAP.md (update inventory), docs/index.md (update navigation — create if it doesn't exist yet) |
 
 <!-- INSTRUCTION: Add project-specific cascade rules below the universal ones above. -->
 
+## Docs maintenance
+
+<!-- INSTRUCTION: This table tells the agent when to update human-facing docs.
+     For full component-to-docs mapping, see .context/DOCS-MAP.md. -->
+
+| Trigger | Update these docs/ files |
+|---------|------------------------|
+| Phase completed | docs/index.md (progress section — create from DOCS-MAP.md if it doesn't exist yet) |
+| Architecture decision | docs/index.md (architecture section), .context/DOCS-MAP.md (if new component) |
+| New project component | .context/DOCS-MAP.md (add mapping), docs/ (per DOCS-MAP.md scaffolding rules) |
+| {structural-change} | {specific docs/ files per DOCS-MAP.md component mapping} |
+
 ## Workflow
 
 Select based on query type:
 - **General task** — Review, Plan, Implement, Document, Update
 - **Code change** — Review, Plan, Implement, Context-sync, Update
 - **Context refresh** — Scan, Compare, Update-context, Cascade, Record
-- **First session** — Detect, Initialize, Map, Pair, Ready
-- **Discovery (brownfield)** — Inventory, Map-dependencies, Extract-patterns, Assess, Bootstrap
+- **First session (greenfield)** — Ask, Populate, Confirm (see onboarding protocol below)
+- **First session (brownfield)** — Scan, Ask, Confirm (see onboarding protocol below)
+
+## First session protocol
+
+<!-- AGENT: Follow this protocol on the FIRST session when methodology files contain only template placeholders. -->
+
+When PROJECT.md still contains `{placeholder}` text, this is a first session. Guide the user through onboarding — ask questions, show what you'll write, get confirmation before writing each file.
+
+### Greenfield onboarding (no existing codebase)
+
+**Stage 1 — Project vision** → populates PROJECT.md
+Ask the user:
+1. What is your project about? (1-2 sentences)
+2. Who is it for?
+3. What problem does it solve?
+4. What technologies, languages, or frameworks will you use?
+5. What are 2-3 guiding principles for this project?
+
+CHECKPOINT: Draft PROJECT.md from the answers. Show the user the draft. Wait for approval before writing.
+
+**Stage 2 — Architecture** → populates .context/BASE.md, PROJECT-PROFILE.md, .context/DOCS-MAP.md
+Ask the user:
+1. What are the main components or modules?
+2. How do they connect? (data flow, API calls, event-driven, etc.)
+3. What is the directory structure? (or what will it be?)
+4. What are the key dependencies?
+
+CHECKPOINT: Draft .context/BASE.md, PROJECT-PROFILE.md, and .context/DOCS-MAP.md (initial component-to-docs mapping based on architecture). Show the user. Wait for approval.
+
+**Stage 3 — Goals** → populates ROADMAP.md, PLAN.md
+Ask the user:
+1. What are your immediate goals? (next 1-3 sessions)
+2. What does "done" look like for this project?
+3. Can you break this into 2-4 phases?
+
+CHECKPOINT: Draft ROADMAP.md and PLAN.md (first task). Show the user. Wait for approval.
+
+**Stage 4 — Starting state** → populates STATE.md
+Ask the user:
+1. Any decisions already made? (tech choices, architecture, constraints)
+2. Any known blockers or risks?
+3. Any open questions you want tracked?
+
+CHECKPOINT: Draft STATE.md. Show the user. Wait for approval. Then begin normal work.
+
+### Brownfield onboarding (existing codebase)
+
+**Stage 1 — Scan** → reads existing files, writes nothing
+Read: package.json, README, directory structure, key config files, entry points.
+Present findings: "Here's what I found in your project: [summary]. Is this accurate?"
+
+CHECKPOINT: Wait for user to confirm or correct your understanding.
+
+**Stage 2 — Clarify** → populates PROJECT.md, PROJECT-PROFILE.md
+Ask targeted questions based on what the scan missed:
+1. What's the intent behind [pattern you found]?
+2. Are there conventions not captured in config? (naming, structure, etc.)
+3. What's the current state — active development, maintenance, exploration?
+
+CHECKPOINT: Draft PROJECT.md from scan + answers. Show the user. Wait for approval.
+
+**Stage 3 — Map** → populates .context/BASE.md, .context/DOCS-MAP.md
+Build codebase map from scan. Ask:
+1. Are there areas of the codebase I should understand deeply vs. ignore?
+2. Any architectural decisions I should know about that aren't documented?
+3. What are the most common types of changes you make?
+
+CHECKPOINT: Draft .context/BASE.md and .context/DOCS-MAP.md (component-to-docs mapping from scan results). Show the user. Wait for approval.
+
+**Stage 4 — Organize** → proposes entry point customization
+Based on understanding, propose:
+1. Scoping rules — which query types match this project?
+2. Specialist context files — which domains need their own .context/ file?
+3. Cascade rules — what project-specific dependencies exist?
+
+CHECKPOINT: Show proposed entry point customizations. Wait for approval before modifying this file.
+
+**Stage 5 — Starting state** → populates STATE.md, ROADMAP.md
+Propose initial state based on everything learned:
+1. Decisions already implicit in the codebase (document them)
+2. Current position (where is the project in its lifecycle?)
+3. Immediate goals
+
+CHECKPOINT: Draft STATE.md and ROADMAP.md. Show the user. Wait for approval. Then begin normal work.
+
+### Checkpoint rules
+
+- NEVER write to a methodology file without showing the user what you will write first
+- At each CHECKPOINT, present the draft as a code block the user can review
+- If the user says "looks good" or similar, write the file
+- If the user edits or corrects, incorporate changes and show the updated draft
+- If the user says "skip", leave the file as template placeholder
+- After all stages complete, summarize what was populated and begin normal work
+- For brownfield: `.context/REGISTRY.md` is deferred — do not create it during onboarding. It will be created automatically when the first file split occurs (reduces first-session cognitive load)
 
 ## Interaction level
 
@@ -70,21 +182,28 @@ tier: standard
 
 method_version: 1.5
 <!-- Tracks which methodology version generated this entry point -->
-<!-- Use `npx wwa status` to compare against latest -->
+<!-- Use `wwa status` to compare against latest -->
 
 ## CLI tools (optional)
 
-Available via `npx wwa` (zero-install) or `pip install wwa-tools`:
+Install: `npm install -g agent-method` (then use `wwa`), or `pip install wwa-tools`.
 
 | When you want to... | Run |
 |---------------------|-----|
-| Validate this entry point | `npx wwa check` |
-| See what type of project this is | `npx wwa scan` |
-| Test how a query routes | `npx wwa route "your question"` |
-| Extract a refinement report | `npx wwa refine` |
-| Check methodology version | `npx wwa status` |
-| Update methodology files | `npx wwa upgrade` |
-| See what an entry point should contain | `npx wwa init code` / `context` / `data` / `mix` |
+| Validate this entry point | `wwa check` |
+| See what type of project this is | `wwa scan` |
+| Test how a query routes | `wwa route "your question"` |
+| See current plan status | `wwa plan` |
+| Get implementation guidance | `wwa implement` |
+| View project review dashboard | `wwa review` |
+| Show management digest | `wwa digest` |
+| Session close + project snapshot | `wwa close` |
+| Extract a refinement report | `wwa refine` |
+| Extract a case study (with project tokens) | `wwa casestudy` |
+| Check docs coverage | `wwa docs` |
+| Check methodology version | `wwa status` |
+| Update methodology files | `wwa upgrade` |
+| Set up a new project | `wwa init code` / `context` / `data` / `mix` |
 
 <!-- INSTRUCTION: The agent can suggest these commands when the user asks about validation,
      project setup, or methodology updates. All commands auto-detect project type and find
@@ -99,7 +218,9 @@ Available via `npx wwa` (zero-install) or `pip install wwa-tools`:
 - Surface uncertainty as open questions in STATE.md — never guess silently
 - Keep intelligence layer files under 300 lines — split into index + components subdirectory when exceeded
 - Propose plans and wait for approval — the human controls direction
-- At session close or after any high-effort task, append a metrics entry to SESSION-LOG.md — include effort level, question ambiguity, context level, estimated tokens, and time. Never skip, never read previous entries during normal work
+- Document proportionally — low-effort tasks (status checks, lookups, clarifications) need no STATE.md or SESSION-LOG updates; high-effort tasks get full recording
+- SUMMARY.md is the session audit trail (date, plan, outcome, files, decisions, next). Management digest lives in Management/DIGEST.md
+- At session close or after any high-effort task, append a metrics entry to SESSION-LOG.md — include effort level, question ambiguity, context level, estimated tokens, time, user response (accepted/edited/revised/rejected/redirected), and for medium/high effort tasks: revision count, refinement magnitude (none/minor/moderate/major/rework), delta categories, and survival rate. Never skip, never read previous entries during normal work
 
 ## Do not
 
@@ -109,5 +230,6 @@ Available via `npx wwa` (zero-install) or `pip install wwa-tools`:
 - Defer STATE.md decision recording to end of session
 - Skip cascade checks after file changes
 - Load multiple specialist .context/ files for a single query
+- Record routine queries in STATE.md or SESSION-LOG.md — only decisions, blockers, and high-effort work warrant documentation
 
 <!-- INSTRUCTION: Add project-specific "do not" rules as you discover common mistakes -->

package/templates/starter/Management/DIGEST.md

@@ -0,0 +1,23 @@
+# Management Digest
+
+<!-- AGENT: Append a row for every HIGH-EFFORT task only.
+     This is the primary management-facing project record — managers and leads
+     read this to understand what significant work happened, without parsing
+     detailed session logs or operational files.
+
+     Low-effort tasks (lookups, status checks, clarifications) are NOT recorded here.
+     See SESSION-LOG.md for complete session data. -->
+
+## What qualifies as high-effort
+
+- Multi-file changes (3+ files)
+- Architectural or design decisions
+- Phase completions
+- Complex queries requiring research or multi-step execution
+- New feature implementations
+
+## Digest
+
+| Date | Task | Query | Outcome | Key Changes | Decisions | Effort | Time |
+|------|------|-------|---------|-------------|-----------|--------|------|
+<!-- Rows added automatically by agent for high-effort tasks -->

package/templates/starter/Management/STATUS.md

@@ -0,0 +1,46 @@
+# Project Status
+
+<!-- AGENT: Update this file after significant milestones (phase completions,
+     architectural decisions, blocker changes). This is the management-facing
+     health snapshot — read by leads to understand project state at a glance.
+
+     Do NOT update for routine work. Only update when the project's overall
+     status, direction, or risk profile changes. -->
+
+## Current state
+
+| Field | Value |
+|-------|-------|
+| Phase | {current phase} |
+| Status | {active / blocked / complete} |
+| Active work | {brief description of current task} |
+| Last milestone | {most recent completed phase or significant deliverable} |
+| Next milestone | {what's coming next} |
+
+## Recent decisions
+
+<!-- AGENT: Keep the 5 most recent significant decisions here.
+     Full decision history lives in STATE.md. -->
+
+| Date | Decision | Impact |
+|------|----------|--------|
+<!-- Last 5 significant decisions -->
+
+## Blockers & risks
+
+<!-- AGENT: List active blockers and known risks. Remove when resolved. -->
+
+| Type | Description | Since | Severity |
+|------|-------------|-------|----------|
+<!-- {blocker/risk} | {description} | {date} | {high/medium/low} -->
+
+## Health indicators
+
+<!-- AGENT: Update these after each high-effort task or milestone. -->
+
+| Indicator | Status | Notes |
+|-----------|--------|-------|
+| Scope | {stable / expanding / contracting} | {brief note} |
+| Velocity | {steady / accelerating / slowing} | {brief note} |
+| Technical debt | {low / medium / high} | {brief note} |
+| Context freshness | {current / slightly stale / stale} | {last refresh date} |

package/templates/starter/PROJECT.md

@@ -44,3 +44,37 @@
 1. {Principle 1}
 2. {Principle 2}
 3. {Principle 3}
+
+## Agent onboarding
+
+<!-- AGENT: Use these questions to populate this file during the first session.
+     Ask the user each question, draft this file from the answers, and show the
+     draft at the Stage 1 checkpoint before writing. Remove this section after
+     the file is populated — it's scaffolding, not permanent content. -->
+
+### Greenfield (no existing codebase)
+
+Ask the user:
+1. What is your project about? (1-2 sentences for the description above)
+2. Who is it for? (populate the Audiences table)
+3. What problem does it solve? (populate the Problem section)
+4. What technologies, languages, or frameworks will you use? (informs Solution + structure)
+5. What are 2-3 guiding principles for this project? (populate Principles)
+6. What is the top-level directory structure? (populate Project structure table)
+
+### Brownfield (existing codebase)
+
+<!-- AGENT: For brownfield projects, you've already scanned the project at Stage 1.
+     Pre-fill as much as possible from scan results. Only ask what you couldn't determine. -->
+
+Pre-fill from scan:
+- **Description**: infer from README, package.json description, or top-level docs
+- **Project structure**: build from directory listing — auto-populate the table
+- **Technologies**: extract from package.json, requirements.txt, config files, imports
+
+Ask the user only what the scan couldn't determine:
+1. Is this description accurate? (confirm or correct the auto-generated description)
+2. Who is the primary audience? (rarely inferable from code alone)
+3. What problem does this solve from the user's perspective? (intent, not implementation)
+4. What guiding principles drive decisions on this project? (conventions, priorities)
+5. Are there directories I should know about that aren't obvious from the structure? (hidden patterns, legacy areas)

package/templates/starter/Reviews/INDEX.md

@@ -0,0 +1,75 @@
+# Project Reviews
+
+<!-- AGENT: This is the review dashboard — a synthesized view of project intelligence.
+     Update sections when the corresponding source file changes significantly.
+
+     Source files: ROADMAP.md, PLAN.md, STATE.md, todos/backlog.md
+     When this file exceeds 300 lines, split sections into individual files
+     in this directory (roadmap.md, plan.md, state.md, backlog.md). -->
+
+## At a glance
+
+| Area | Status | Last updated |
+|------|--------|-------------|
+| Roadmap | {on track / behind / ahead} | {date} |
+| Plan | {active / blocked / between tasks} | {date} |
+| State | {N decisions, N blockers, N open questions} | {date} |
+| Backlog | {N items} | {date} |
+
+## Roadmap review
+
+<!-- AGENT: Synthesize from ROADMAP.md. Phase progress, milestone tracking. -->
+
+### Phase progress
+
+| Phase | Status | Completion |
+|-------|--------|------------|
+<!-- Populate from ROADMAP.md -->
+
+### Velocity notes
+
+<!-- Brief observations about project velocity and trajectory. -->
+
+## Plan review
+
+<!-- AGENT: Synthesize from PLAN.md. Current task status, execution patterns. -->
+
+### Current task
+
+<!-- What's being worked on, how it's progressing. -->
+
+### Execution patterns
+
+<!-- Observations about plan execution — revision patterns, task sizing accuracy. -->
+
+## State review
+
+<!-- AGENT: Synthesize from STATE.md. Decision trends, blocker aging, question resolution. -->
+
+### Decision summary
+
+- **Total decisions**: {count}
+- **Recent decisions** (last 5):
+
+<!-- List last 5 decisions from STATE.md -->
+
+### Blocker status
+
+<!-- Active blockers, how long they've been open, resolution progress. -->
+
+### Open questions
+
+<!-- Active open questions, aging analysis, resolution rate. -->
+
+## Backlog review
+
+<!-- AGENT: Synthesize from todos/backlog.md. Item counts, categories, aging. -->
+
+### Summary
+
+- **Total items**: {count}
+- **Categories**: {list with counts}
+
+### Aging
+
+<!-- How old are backlog items? Any that need attention? -->

package/templates/starter/SESSION-LOG.md

@@ -40,6 +40,27 @@ Append-only session observation log for case study data collection. Each session
 - **high**: Entry point + STATE.md + specialist context + multiple project files
 - **very high**: Extensive project context, multiple specialists, cross-file analysis
 
+**User response** (agent-observed — how did the user respond to the result?):
+- **accepted**: User proceeded to next step without changes
+- **edited**: User manually modified the agent's output
+- **revised**: User asked agent to redo or revise the result
+- **rejected**: User said no or declined the result entirely
+- **redirected**: User changed approach or gave new instructions
+
+**Refinement magnitude** (for medium/high effort only — how much changed from first attempt to final?):
+- **none**: Accepted as-is, 0% changed
+- **minor**: Small fixes — typos, naming, formatting (<10% changed)
+- **moderate**: Logic or structural changes, added/removed sections (10–50% changed)
+- **major**: Significant rework of approach or content (50–80% changed)
+- **rework**: Mostly rewritten, original approach abandoned (>80% changed)
+
+**Delta categories** (what kinds of changes were needed — select all that apply):
+- **accuracy**: Factual errors or incorrect implementation
+- **completeness**: Missing parts, incomplete coverage
+- **approach**: Wrong method or strategy
+- **scope**: Over-scoped or under-scoped
+- **style**: Formatting, naming, conventions
+
 ## Observation checklist
 
 At session close (or high-effort task completion), reflect on these before writing the entry:
@@ -54,6 +75,10 @@ At session close (or high-effort task completion), reflect on these before writi
 9. How ambiguous was the user's request? (low / medium / high)
 10. How much project context was loaded? (very low / low / medium / high / very high)
 11. Approximate token usage and time spent?
+12. How did the user respond to the result? (accepted / edited / revised / rejected / redirected)
+13. For medium/high effort: how many revision cycles before acceptance?
+14. What magnitude of change between first attempt and final result? (none / minor / moderate / major / rework)
+15. What categories of refinement were needed? (accuracy / completeness / approach / scope / style)
 
 ## Entry format
 
@@ -66,6 +91,10 @@ Tokens: ~{N}k | Time: ~{N} min
 Queries: {query types encountered}
 Features: {feature IDs activated}
 Cascades: {triggered}/{expected} | Decisions: {count}
+Response: {accepted / edited / revised / rejected / redirected}
+Revisions: {0 | count of revision cycles} | Magnitude: {none / minor / moderate / major / rework}
+Delta: {n/a | categories: accuracy, completeness, approach, scope, style} | Survival: ~{N}%
+Delta notes: {n/a | brief description of what changed between first attempt and final}
 Friction: {none | brief description}
 Finding: {none | observation with methodology implication}
 -->

package/templates/starter/SUMMARY.md

@@ -0,0 +1,27 @@
+# Summary
+
+<!-- AGENT: This file is the session audit trail — a chronological record of work done.
+     The management digest has moved to Management/DIGEST.md.
+     Append an entry after each session or significant task using the format below.
+     Never edit previous entries. -->
+
+## Session audit trail
+
+<!-- INSTRUCTION: Use this format for each entry:
+
+### {Date} — {Brief title}
+
+**Plan**: {What was planned for this session}
+**Outcome**: {What was actually accomplished}
+
+**Files created**:
+- {path/to/new-file.md}
+
+**Files updated**:
+- {path/to/updated-file.md} — {what changed}
+
+**Key decisions**:
+- {Decision and rationale — should match what's in STATE.md}
+
+**Next**: {What should happen in the following session — this is the bridge}
+-->

package/templates/starter/agentWorkflows/INDEX.md

@@ -0,0 +1,61 @@
+# Agent Workflows
+
+<!-- AGENT: This file tracks how the methodology performs in practice.
+     Update after high-effort sessions by reviewing SESSION-LOG.md patterns.
+
+     Source: SESSION-LOG.md entries, agent self-observation during sessions.
+     When this file exceeds 300 lines, split sections into individual files
+     in this directory (sessions.md, patterns.md, observations.md). -->
+
+## Workflow summary
+
+| Workflow | Times used | Last used | Typical effort |
+|----------|-----------|-----------|---------------|
+<!-- Populate from SESSION-LOG.md workflow field -->
+
+## Session patterns
+
+<!-- AGENT: Synthesize from SESSION-LOG.md. Look for patterns across sessions. -->
+
+### Effort distribution
+
+| Effort level | Count | Percentage |
+|-------------|-------|------------|
+| Low | {N} | {%} |
+| Medium | {N} | {%} |
+| High | {N} | {%} |
+
+### Common query types
+
+<!-- Which query types appear most often? -->
+
+### Acceptance rates
+
+<!-- How often is agent output accepted vs. revised? -->
+
+- **Accepted**: {count} ({%})
+- **Edited**: {count} ({%})
+- **Revised**: {count} ({%})
+- **Rejected**: {count} ({%})
+- **Redirected**: {count} ({%})
+
+## Behavioral patterns
+
+<!-- AGENT: Record patterns observed across sessions. What works well, what causes friction. -->
+
+### What works
+
+<!-- Patterns that consistently lead to accepted results. -->
+
+### Friction points
+
+<!-- Recurring issues, methodology rules that cause difficulty. -->
+
+## Observations
+
+<!-- AGENT: Record methodology observations — findings with implications for
+     how the methodology could be improved or adapted for this project. -->
+
+| Date | Observation | Implication | Severity |
+|------|-------------|-------------|----------|
+<!-- Append observations as they arise -->

package/templates/starter/intro/README.md

@@ -0,0 +1,37 @@
+# Methodology Overview
+
+This project uses the **wwa** (Working With Agents) methodology for AI-agent-assisted development. The methodology gives your AI agent persistent memory, structured workflows, and scoped context loading across sessions.
+
+## How it works
+
+Your agent reads an entry point file (CLAUDE.md, .cursorrules, or AGENT.md) at the start of every session. That file tells the agent:
+
+- **What to read** — scoping rules match your question to the right files
+- **What to update** — cascade rules keep dependent files in sync
+- **How to work** — workflows guide the agent through structured steps
+
+Key files the agent manages:
+
+| File | Purpose |
+|------|---------|
+| STATE.md | Decisions, blockers, current position (cross-session memory) |
+| PLAN.md | Current task with verification criteria |
+| ROADMAP.md | Phase breakdown with gate criteria |
+| .context/BASE.md | Core project context — architecture, codebase map |
+| .context/DOCS-MAP.md | Maps your project components to their documentation |
+
+## Your project's docs/
+
+The `docs/` folder is reserved for **your project's documentation** — API references, architecture guides, setup instructions, etc. It is not created at setup time. Instead, the agent proposes new docs/ files as your project grows, based on scaffolding rules in `.context/DOCS-MAP.md`.
+
+## Full documentation
+
+For the complete methodology guide, templates reference, and architecture docs:
+
+**https://github.com/anthropics/agent-method**
+
+Key pages:
+- [Quick Start](https://github.com/anthropics/agent-method/blob/main/docs/guides/quick-start.md)
+- [For Developers](https://github.com/anthropics/agent-method/blob/main/docs/guides/for-developers.md)
+- [File Roles](https://github.com/anthropics/agent-method/blob/main/docs/architecture/file-roles.md)
+- [CLI Tools](https://github.com/anthropics/agent-method/blob/main/docs/guides/for-developers/cli-tools.md)

package/templates/full/docs/index.md

@@ -1,46 +0,0 @@
-# {Project Name} — Documentation
-
-<!-- INSTRUCTION: This is the human-facing project dashboard.
-     It provides a high-level view of the project for non-agent audiences
-     (managers, reviewers, teammates). Keep it visual and navigable. -->
-
-## Project overview
-
-<!-- INSTRUCTION: Brief description of what the project does and its current state.
-     Link to PROJECT.md for the full vision. -->
-
-See [PROJECT.md](../PROJECT.md) for the full project vision and scope.
-
-## Current status
-
-<!-- INSTRUCTION: Update this when phases complete. Show progress at a glance. -->
-
-| Phase | Status | Gate |
-|-------|--------|------|
-| Phase 1 — {name} | {pending/in-progress/done} | {PASSED / not yet} |
-| Phase 2 — {name} | {pending} | {not yet} |
-
-## Architecture
-
-<!-- INSTRUCTION: High-level architecture description for human readers.
-     Diagrams, component descriptions, key design decisions. -->
-
-{Describe or diagram your project architecture}
-
-## Key decisions
-
-<!-- INSTRUCTION: Surface important decisions from STATE.md in a human-readable format.
-     Not every decision — just the ones that affect the project's direction. -->
-
-| Decision | Rationale | Date |
-|----------|-----------|------|
-| {Important decision} | {Why} | {When} |
-
-## Navigation
-
-<!-- INSTRUCTION: Add links to other docs as you create them. -->
-
-| Document | What it covers |
-|----------|---------------|
-| [PROJECT.md](../PROJECT.md) | Project vision and scope |
-| [ROADMAP.md](../ROADMAP.md) | Phase breakdown and progress |