agent-method 1.5.12

package/templates/starter/.context/METHODOLOGY.md

@@ -0,0 +1,228 @@
+# Methodology Reference
+
+Pair with: entry point (CLAUDE.md / .cursorrules / AGENT.md) + `.context/PROTOCOL.yaml`
+Use when: agent needs onboarding protocol, format specs, or operational depth beyond PROTOCOL.yaml
+
+Rules (scoping, cascade, conventions) live in `.context/PROTOCOL.yaml`. This file provides onboarding flows, format specifications, and operational details loaded on-demand.
+
+## First session protocol
+
+<!-- AGENT: Follow this protocol when PROJECT.md contains {placeholder} text. -->
+
+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. 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)
+
+Brownfield onboarding uses **segmented stages** driven by `registry/doc-tokens.yaml` categories. Each segment has a bounded context budget, scans only what it needs, asks 1-3 questions maximum, and checkpoints before the next. This prevents context overload and ensures the agent populates registries incrementally.
+
+**Segment 1 — Identity** (~500 tokens) → populates PROJECT-PROFILE.md, `registry/doc-tokens.yaml` (project section)
+Scan: package.json/config files, README, top-level directory listing only.
+Discover: project type (code/data/analytical/mixed), lifecycle stage, key tech stack.
+Ask (only what scan couldn't determine):
+1. What's the current state — active development, maintenance, exploration?
+
+CHECKPOINT: Present identity summary. Draft PROJECT-PROFILE.md + doc-tokens.yaml `project:` values. Wait for approval.
+
+**Segment 2 — Architecture** (~1500 tokens) → populates .context/BASE.md, PROJECT.md, .context/DOCS-MAP.md, doc-tokens.yaml `doc_graph`
+Scan: key source files (entry points, main modules), import graph, config files.
+Discover: system model, codebase map, component relationships, dependencies.
+**Doc structure scan** — also scan `docs/` directory (if present):
+- List all files in `docs/` — add each as a `doc_graph` node with category `docs`
+- Check for cross-references between docs (markdown links, .context/ references)
+- Create `reads_from` edges for discovered dependencies between documents
+- Create `cascades_to` edges where PROTOCOL.yaml cascade patterns apply
+- Write discovered graph to `doc-tokens.yaml` `doc_graph` section
+Ask (only what scan couldn't determine):
+1. Any architectural decisions not documented in code? (key patterns, constraints)
+2. Are there areas I should understand deeply vs. ignore?
+
+**Boundaries configuration** — if project has non-standard paths (e.g. registry not in .context/):
+- Uncomment `boundaries:` section in PROTOCOL.yaml
+- Set `registries.tokens` to actual token registry path
+- Set `visibility.internal` / `visibility.release` to match project structure
+- Set `distribution` rules to match .gitignore / .npmignore patterns
+
+CHECKPOINT: Draft .context/BASE.md (codebase map), PROJECT.md (vision), .context/DOCS-MAP.md, doc_graph edges. Show user. Wait for approval.
+
+**Segment 3 — Workflow alignment** (~500 tokens) → populates PROTOCOL.yaml customizations
+Read: `registry/feature-registry.yaml` (workflows, query patterns), discovered project type from Segment 1.
+Discover: which workflows apply (WF-01 through WF-08), which scoping query types are relevant.
+Ask:
+1. What are the most common types of changes you make? (maps to query types)
+
+CHECKPOINT: Show proposed PROTOCOL.yaml `scoping:` additions and workflow selection. Wait for approval.
+
+**Segment 4 — Convention alignment** (~500 tokens) → populates `registry/doc-tokens.yaml` names + `project_names`, PROTOCOL.yaml conventions
+Read: linting configs, CI/CD files, existing coding standards, doc-tokens.yaml `names:` section.
+Discover: naming patterns, existing conventions, project-specific terminology.
+**Terminology capture** — populate `doc-tokens.yaml` `project_names:`:
+For code projects: modules = services/libraries/components; apis = endpoints/routes; entities = models/schemas; conventions = naming/patterns.
+For data projects: modules = data sources/pipelines; apis = query interfaces; entities = schemas/dimensions/measures; conventions = validation rules.
+For analytical projects: modules = chains/evaluators; apis = prompt templates/tool interfaces; entities = domain concepts/evaluation criteria; conventions = composition patterns.
+- Scan source code for module/class/service names → add to `project_names.modules`
+- Scan API routes or endpoints → add to `project_names.apis`
+- Scan database schemas or data models → add to `project_names.entities`
+- Note naming conventions discovered → add to `project_names.conventions`
+Ask:
+1. Any conventions not captured in config? (naming, review process, etc.)
+
+CHECKPOINT: Show proposed doc-tokens.yaml `names:` additions, `project_names` entries, and PROTOCOL.yaml `conventions:` customizations. Wait for approval.
+
+**Segment 5 — State initialization** (~500 tokens) → populates STATE.md, ROADMAP.md
+Read: decisions discovered in Segments 1-4, open questions accumulated.
+Propose initial state:
+1. Decisions already implicit in the codebase (document them)
+2. Current position (lifecycle stage confirmed)
+3. Immediate goals (ask: what are your next 1-3 priorities?)
+
+CHECKPOINT: Draft STATE.md and ROADMAP.md. Show user. Wait for approval. Then begin normal work.
+
+### Post-onboarding: registry-driven documentation
+
+After brownfield onboarding completes, the agent uses the populated registries for all subsequent work:
+- **doc-tokens.yaml `names:`** — Reference after every query to ensure consistent terminology in documentation updates
+- **doc-tokens.yaml `tokens:`** — Reference for project-specific values (counts, versions, paths) when writing docs
+- **feature-registry.yaml** — Reference to identify which features were activated and which workflows apply to the current query
+- **doc-tokens.yaml `propagation_targets:`** — After changing any token value, check listed files for stale references
+
+### 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 — not created during onboarding
+
+## Interaction level
+
+The entry point's `mode` setting controls checkpoint density:
+
+| Level | Behavior |
+|-------|----------|
+| autonomous | Execute full plan, report at completion |
+| checkpoint | Propose plan, wait for approval, report at completion (default) |
+| collaborative | Back-and-forth at each step |
+| supervised | Explain intent before every file change |
+
+## Write obligation format specs
+
+These formats are referenced by `.context/PROTOCOL.yaml` cascade triggers.
+
+### SESSION-LOG.md metrics entry
+
+Each entry is a compact block with these fields:
+- **effort**: low | medium | high
+- **ambiguity**: low | medium | high
+- **context**: minimal | moderate | deep
+- **tokens**: estimated token count
+- **time**: session duration
+- **response**: accepted | edited | revised | rejected | redirected
+- **refinement delta** (medium/high effort only): revision count, magnitude (none/minor/moderate/major/rework), delta categories, survival rate
+- **workflow**: WF-XX workflow ID
+- **features**: comma-separated feature IDs used
+- **cascades**: number of cascade updates triggered
+- **friction**: description or "none"
+- **findings**: methodology-relevant observations or "none"
+
+### Management/DIGEST.md row
+
+| Date | Task | Query | Outcome | Key changes | Decisions | Effort | Time |
+
+Only high-effort tasks: 3+ files, architectural decisions, phase completions, complex multi-step queries, new feature implementations.
+
+### Management/STATUS.md update
+
+Update after milestones: current phase, active work, recent decisions (last 5), blockers, health indicators.
+
+## Safety invariants
+
+These rules are absolute — they hold regardless of profile, project type, or lifecycle stage:
+
+- **Never modify project source code** through methodology operations — only create/modify methodology files
+- **Never delete existing project files** — methodology integration is purely additive
+- **Never overwrite existing entry point content** — only append methodology sections
+
+## File scale management
+
+When any intelligence layer file exceeds 300 lines (~3,750 tokens):
+1. Split into index file (original path) + components subdirectory
+2. Index keeps active content + navigation table
+3. Components hold archived sections grouped by semantic boundary
+4. Update .context/REGISTRY.md (if it exists) with new file entries
+
+## Reporting layers
+
+Three directories separate reporting concerns from operational files:
+
+### Management/
+
+Management-facing project oversight. Managers read this, not STATE.md or SESSION-LOG.md.
+
+- **DIGEST.md** — Append a row for every high-effort task (see format spec above)
+- **STATUS.md** — Update after milestones (see format spec above)
+
+### Reviews/
+
+Synthesized views of intelligence layer files. Updated when doing a "project review" query.
+
+When doing project review or self-review (4-phase) sessions, use the **collection checklist** for consistent capture of usage, practice, issues, and improvements: see `docs/internal/review/collection-checklist.md` (if present in this repo).
+
+- **INDEX.md** — Dashboard with key metrics and links to drill-down files (full tier) or self-contained sections (starter tier).
+
+### agentWorkflows/
+
+Agent workflow performance analysis. Updated after high-effort sessions.
+
+- **INDEX.md** — Workflow summary, quick stats, links to analysis files (full tier) or self-contained sections (starter tier).
+
+### Audit trail format
+
+SUMMARY.md is the session audit trail. Each entry follows this structure:
+```
+### {date} — {brief description}
+**Plan**: {what was planned}
+**Outcome**: {what was done}
+**Files created**: {list}
+**Files updated**: {list}
+**Decisions**: {key decisions made}
+**Next**: {what should happen next session}
+```

package/templates/starter/.context/PROTOCOL.yaml

@@ -0,0 +1,165 @@
+# Agent Protocol — scoping, cascade, obligations, conventions
+# Read on: every session (entry point directs here)
+# Updated by: wwa upgrade | Validated by: wwa check
+# Close-stage: read close_check before ending any file-modifying response
+
+version: v1.6
+last_verified: "{date}"
+
+# === SCOPING: query type → file sets ===
+scoping:
+  planning:
+    reads: [REQUIREMENTS.md, ROADMAP.md]
+    writes: [STATE.md, PLAN.md]
+  context_refresh:
+    reads: [".context/*", "registry/doc-tokens.yaml", project structure]
+    writes: [".context/*", "registry/doc-tokens.yaml", "entry point if scoping affected"]
+  project_discovery:
+    reads: [project structure, package files, key source files, "registry/feature-registry.yaml", "registry/doc-tokens.yaml"]
+    writes: [.context/BASE.md, ".context/ specialists", "registry/doc-tokens.yaml", STATE.md]
+  methodology_guidance:
+    reads: [this file]
+    writes: []
+  phase_completion:
+    reads: [SUMMARY.md]
+    writes: [SUMMARY.md, STATE.md, ROADMAP.md]
+  backlog:
+    reads: [todos/backlog.md]
+    writes: [todos/backlog.md]
+  management_overview:
+    reads: [Management/DIGEST.md, Management/STATUS.md, STATE.md]
+    writes: [Management/STATUS.md, Management/DIGEST.md]
+  project_review:
+    reads: [Reviews/INDEX.md, "relevant source files"]
+    writes: ["Reviews/"]
+  workflow_analysis:
+    reads: [agentWorkflows/INDEX.md, SESSION-LOG.md]
+    writes: ["agentWorkflows/"]
+  docs_update:
+    reads: [.context/DOCS-MAP.md, "registry/doc-tokens.yaml", "relevant docs/"]
+    writes: ["docs/", .context/DOCS-MAP.md]
+  # CUSTOMIZE: add project-specific query types below
+  # Each should pair .context/BASE.md with one specialist.
+  # "{domain}":
+  #   reads: [.context/BASE.md, ".context/{SPECIALIST}.md"]
+  #   writes: ["{working files}"]
+
+# === CASCADE: change → propagation targets ===
+cascade:
+  decision_made:
+    target: STATE.md
+    section: decisions table
+    timing: same-response
+    directive: P-02
+  file_changed:
+    action: check this cascade section
+    timing: same-response
+    directive: P-03
+  phase_complete:
+    targets: [SUMMARY.md, STATE.md, ROADMAP.md]
+    actions: [append entry, update position, mark done]
+    timing: non-negotiable
+  requirements_change:
+    targets: [REQUIREMENTS.md, ROADMAP.md, PLAN.md]
+    condition: if current task affected
+  question_resolved:
+    target: STATE.md
+    action: "mark resolved with text — don't delete"
+  structure_changed:
+    targets: [.context/BASE.md]
+    condition: file created, deleted, renamed, or split
+  file_exceeds_300_lines:
+    action: split into index + components subdirectory
+  new_domain_area:
+    targets: [.context/BASE.md, entry point]
+    consider: new .context/ specialist file
+  lifecycle_stage_change:
+    targets: [PROJECT-PROFILE.md, STATE.md]
+  high_effort_task:
+    targets: [SESSION-LOG.md, Management/DIGEST.md]
+    condition: "materiality >= medium (3+ files, architectural decisions, phase completions)"
+    session_log_fields: [effort, ambiguity, context, tokens, time, response,
+                         refinement_delta, workflow, features, cascades, friction, findings]
+    digest_fields: [date, task, query, outcome, key_changes, decisions, effort, time]
+  milestone:
+    targets: [Management/STATUS.md]
+    fields: [current_state, recent_decisions, health_indicators]
+  new_component:
+    targets: [.context/DOCS-MAP.md]
+    check: scaffolding rules for new docs/ proposals
+  docs_changed:
+    targets: [.context/DOCS-MAP.md, docs/index.md]
+  terminology_established:
+    target: "registry/doc-tokens.yaml"
+    action: "populate tokens (project identity, counts) and names (project-specific terms)"
+    timing: during brownfield onboarding and when new patterns are discovered
+  registry_values_changed:
+    target: "files using changed values"
+    action: "check doc-tokens.yaml propagation_targets for stale values"
+    condition: "only files that reference the changed token"
+  doc_graph_changed:
+    target: "registry/doc-tokens.yaml"
+    section: doc_graph
+    timing: same-response
+    condition: "new file discovered, dependency link identified, or document structure changed"
+  # CUSTOMIZE: add project-specific cascade rules below
+
+# === WORKFLOWS: task pattern selection (Phase 7q-3: all standard workflows) ===
+workflows:
+  general_task: [Review, Plan, Implement, Document, Update]
+  code_change: [Review, Plan, Implement, Context-sync, Update]
+  context_refresh: [Scan, Compare, Update-context, Cascade, Record]
+  bootstrap: [Detect, Create-context, Populate, Validate]
+  greenfield_onboarding: [Ask, Populate, Confirm]
+  brownfield_onboarding: [Identity, Architecture, Workflow-align, Convention-align, State-init]
+  analytical_system: [Discover, Map-chains, Build-context, Compose, Evaluate, Refine]
+  specification_project: [Scope, Draft, Review, Align, Update]
+  discovery: [Scan, Identify, Map, Document, Cascade]
+  # Each segment: scan relevant subset → ask 1-3 questions → populate → checkpoint
+  # Driven by doc-tokens.yaml categories — see METHODOLOGY.md for full protocol
+
+# === CONVENTIONS (Phase 7q-3: P-01 … P-07, P-10 in numerical order) ===
+conventions:
+  - "Every code change is also a context change — update codebase map (P-01)"
+  - "Record decisions in STATE.md in the SAME response — never defer (P-02)"
+  - "After every file change, check cascade section above (P-03)"
+  - "Load .context/BASE.md + one specialist per query — never all .context/ files (P-04)"
+  - "Surface uncertainty as open questions in STATE.md (P-05)"
+  - "Propose plans and wait for approval — human controls direction (P-06)"
+  - "Keep intelligence layer files under 300 lines — split when exceeded (P-07)"
+  - "Document proportionally — low-effort: no STATE.md/SESSION-LOG; high-effort: full (P-10)"
+  - "After completing work, reference registry/doc-tokens.yaml names for consistent terminology"
+  - "Use registry/feature-registry.yaml to identify activated features and applicable workflows"
+
+# === CLOSE CHECK: scan before ending any file-modifying response ===
+close_check:
+  - "Decision made? → STATE.md decisions table"
+  - "File changed? → check cascade section above"
+  - "Phase complete? → SUMMARY.md + STATE.md + ROADMAP.md"
+  - "High effort? → SESSION-LOG.md + Management/DIGEST.md"
+  - "Structure changed? → .context/BASE.md"
+  - "Milestone? → Management/STATUS.md"
+  - "Docs changed? → .context/DOCS-MAP.md + docs/index.md"
+  - "New terminology or values? → registry/doc-tokens.yaml"
+
+# === BOUNDARIES: path resolution, visibility, distribution (Phase 7q-3: active by default) ===
+boundaries:
+  registries:
+    tokens: "registry/doc-tokens.yaml"
+    feature_registry: "registry/feature-registry.yaml"
+    docs_map: ".context/DOCS-MAP.md"
+    output: "docs/internal/"
+  visibility:
+    internal: [".context/", "research/", "todos/", "docs/internal/"]
+    release: ["docs/architecture/", "docs/workflow/", "docs/guides/", "templates/"]
+  scan:
+    include: ["docs/", ".context/", "templates/"]
+    exclude: ["node_modules/", ".git/"]
+  distribution:
+    git:
+      exclude: ["STATE.md", "PLAN.md", ".context/", "research/", "todos/"]
+    npm:
+      include: ["bin/", "lib/", "templates/"]
+      exclude: [".context/", "docs/internal/"]
+
+# A response that modifies files but skips triggered obligations is INCOMPLETE.

package/templates/starter/.cursorrules

@@ -0,0 +1,90 @@
+# {Project Name} — Agent Entry Point
+
+<!-- INSTRUCTION: Replace {Project Name} and write a 1-2 sentence project description below -->
+{Describe what your project does, its architecture, and key technologies.}
+
+## On every query
+
+1. This file is auto-loaded — read it first
+2. Read `STATE.md` for current position, decisions, blockers
+3. Read `.context/PROTOCOL.yaml` for scoping, cascade, and conventions
+4. Scope query against PROTOCOL.yaml `scoping:` section
+5. After work, check PROTOCOL.yaml `close_check` before ending response
+
+## Settings
+
+mode: checkpoint
+<!-- autonomous | checkpoint | collaborative | supervised -->
+<!-- checkpoint: propose plan, wait for approval, report at completion (default) -->
+
+tier: standard
+<!-- lite | standard | full -->
+<!-- lite: minimal rules, STATE.md only — for Haiku or simple projects -->
+<!-- standard: core rules + context pairing — for Sonnet (default) -->
+<!-- full: all rules, all intelligence layer files — for Opus or complex projects -->
+
+method_version: 1.6
+<!-- Use `wwa status` to compare against latest -->
+
+## CLI tools (optional)
+
+Install: `npm install -g agent-method` (then use `wwa`), or `pip install wwa-tools`.
+
+| When you want to... | Run |
+|---------------------|-----|
+| 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` |
+| Show dependency graph | `wwa deps` |
+| Generate document registry | `wwa doc-review` |
+| Check methodology version | `wwa status` |
+| Update methodology files | `wwa upgrade` |
+| Set up a new project | `wwa init` |
+| Run project discovery workflow | `wwa project-discovery` |
+| Run context refresh workflow | `wwa context-refresh` |
+| Run phase completion workflow | `wwa phase-complete` |
+| Show routing for backlog | `wwa backlog` |
+| Run planning workflow | `wwa plan-create` |
+| Run dependency analysis workflow | `wwa dependency-analysis` |
+| Run debt assessment workflow | `wwa debt-assessment` |
+| Run docs update workflow | `wwa docs-update` |
+| Run cross-reference workflow | `wwa cross-reference` |
+| Append to backlog / decision / finding / session / summary | `wwa add <type> [content]` |
+
+When doing **project review** or **self-review** sessions, use the collection checklist for capture format: `docs/internal/review/collection-checklist.md` (if present).
+
+<!-- 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
+     entry points automatically. Add --json for machine-readable output. -->
+
+## Do not
+
+- Modify project source code, tests, or pre-existing documentation through methodology operations — only create/modify methodology files (STATE.md, .context/, PLAN.md, etc.)
+- Delete existing project files during brownfield integration — methodology is additive only
+- Load files not in PROTOCOL.yaml scoping read-set for the current query type
+- 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 -->
+
+## First session
+
+<!-- AGENT: If PROJECT.md contains {placeholder} text, this is a first session. -->
+Follow the onboarding protocol in `.context/METHODOLOGY.md` — it guides you through
+greenfield (4 stages) or brownfield (5 stages) setup with checkpoints at each step.
+
+## Before ending this response
+
+Read `.context/PROTOCOL.yaml` `close_check`. For each triggered item,
+update the target file now. A response that modifies files but skips
+triggered obligations is incomplete.

package/templates/starter/AGENT.md

@@ -0,0 +1,90 @@
+# {Project Name} — Agent Entry Point
+
+<!-- INSTRUCTION: Replace {Project Name} and write a 1-2 sentence project description below -->
+{Describe what your project does, its architecture, and key technologies.}
+
+## On every query
+
+1. This file is auto-loaded — read it first
+2. Read `STATE.md` for current position, decisions, blockers
+3. Read `.context/PROTOCOL.yaml` for scoping, cascade, and conventions
+4. Scope query against PROTOCOL.yaml `scoping:` section
+5. After work, check PROTOCOL.yaml `close_check` before ending response
+
+## Settings
+
+mode: checkpoint
+<!-- autonomous | checkpoint | collaborative | supervised -->
+<!-- checkpoint: propose plan, wait for approval, report at completion (default) -->
+
+tier: standard
+<!-- lite | standard | full -->
+<!-- lite: minimal rules, STATE.md only — for Haiku or simple projects -->
+<!-- standard: core rules + context pairing — for Sonnet (default) -->
+<!-- full: all rules, all intelligence layer files — for Opus or complex projects -->
+
+method_version: 1.6
+<!-- Use `wwa status` to compare against latest -->
+
+## CLI tools (optional)
+
+Install: `npm install -g agent-method` (then use `wwa`), or `pip install wwa-tools`.
+
+| When you want to... | Run |
+|---------------------|-----|
+| Validate this entry point | `wwa check` |
+| See what type of project this is | `wwa scan` |
+| Test how a query routes | `wwa project-discovery` / `wwa context-refresh` / `wwa plan-create` (see CLI docs) |
+| 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` |
+| Show dependency graph | `wwa deps` |
+| Generate document registry | `wwa doc-review` |
+| Check methodology version | `wwa status` |
+| Update methodology files | `wwa upgrade` |
+| Set up a new project | `wwa init` |
+| Run project discovery workflow | `wwa project-discovery` |
+| Run context refresh workflow | `wwa context-refresh` |
+| Run phase completion workflow | `wwa phase-complete` |
+| Show routing for backlog | `wwa backlog` |
+| Run planning workflow | `wwa plan-create` |
+| Run dependency analysis workflow | `wwa dependency-analysis` |
+| Run debt assessment workflow | `wwa debt-assessment` |
+| Run docs update workflow | `wwa docs-update` |
+| Run cross-reference workflow | `wwa cross-reference` |
+| Append to backlog / decision / finding / session / summary | `wwa add <type> [content]` |
+
+When doing **project review** or **self-review** sessions, use the collection checklist for capture format: `docs/internal/review/collection-checklist.md` (if present).
+
+<!-- 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
+     entry points automatically. Add --json for machine-readable output. -->
+
+## Do not
+
+- Modify project source code, tests, or pre-existing documentation through methodology operations — only create/modify methodology files (STATE.md, .context/, PLAN.md, etc.)
+- Delete existing project files during brownfield integration — methodology is additive only
+- Load files not in PROTOCOL.yaml scoping read-set for the current query type
+- 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 -->
+
+## First session
+
+<!-- AGENT: If PROJECT.md contains {placeholder} text, this is a first session. -->
+Follow the onboarding protocol in `.context/METHODOLOGY.md` — it guides you through
+greenfield (4 stages) or brownfield (5 stages) setup with checkpoints at each step.
+
+## Before ending this response
+
+Read `.context/PROTOCOL.yaml` `close_check`. For each triggered item,
+update the target file now. A response that modifies files but skips
+triggered obligations is incomplete.

package/templates/starter/CLAUDE.md

@@ -0,0 +1,90 @@
+# {Project Name} — Agent Entry Point
+
+<!-- INSTRUCTION: Replace {Project Name} and write a 1-2 sentence project description below -->
+{Describe what your project does, its architecture, and key technologies.}
+
+## On every query
+
+1. This file is auto-loaded — read it first
+2. Read `STATE.md` for current position, decisions, blockers
+3. Read `.context/PROTOCOL.yaml` for scoping, cascade, and conventions
+4. Scope query against PROTOCOL.yaml `scoping:` section
+5. After work, check PROTOCOL.yaml `close_check` before ending response
+
+## Settings
+
+mode: checkpoint
+<!-- autonomous | checkpoint | collaborative | supervised -->
+<!-- checkpoint: propose plan, wait for approval, report at completion (default) -->
+
+tier: standard
+<!-- lite | standard | full -->
+<!-- lite: minimal rules, STATE.md only — for Haiku or simple projects -->
+<!-- standard: core rules + context pairing — for Sonnet (default) -->
+<!-- full: all rules, all intelligence layer files — for Opus or complex projects -->
+
+method_version: 1.6
+<!-- Use `wwa status` to compare against latest -->
+
+## CLI tools (optional)
+
+Install: `npm install -g agent-method` (then use `wwa`), or `pip install wwa-tools`.
+
+| When you want to... | Run |
+|---------------------|-----|
+| Validate this entry point | `wwa check` |
+| See what type of project this is | `wwa scan` |
+| Test how a query routes | `wwa project-discovery` / `wwa context-refresh` / `wwa plan-create` (see CLI docs) |
+| 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` |
+| Show dependency graph | `wwa deps` |
+| Generate document registry | `wwa doc-review` |
+| Check methodology version | `wwa status` |
+| Update methodology files | `wwa upgrade` |
+| Set up a new project | `wwa init` |
+| Run project discovery workflow | `wwa project-discovery` |
+| Run context refresh workflow | `wwa context-refresh` |
+| Run phase completion workflow | `wwa phase-complete` |
+| Show routing for backlog | `wwa backlog` |
+| Run planning workflow | `wwa plan-create` |
+| Run dependency analysis workflow | `wwa dependency-analysis` |
+| Run debt assessment workflow | `wwa debt-assessment` |
+| Run docs update workflow | `wwa docs-update` |
+| Run cross-reference workflow | `wwa cross-reference` |
+| Append to backlog / decision / finding / session / summary | `wwa add <type> [content]` |
+
+When doing **project review** or **self-review** sessions, use the collection checklist for capture format: `docs/internal/review/collection-checklist.md` (if present).
+
+<!-- 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
+     entry points automatically. Add --json for machine-readable output. -->
+
+## Do not
+
+- Modify project source code, tests, or pre-existing documentation through methodology operations — only create/modify methodology files (STATE.md, .context/, PLAN.md, etc.)
+- Delete existing project files during brownfield integration — methodology is additive only
+- Load files not in PROTOCOL.yaml scoping read-set for the current query type
+- 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 -->
+
+## First session
+
+<!-- AGENT: If PROJECT.md contains {placeholder} text, this is a first session. -->
+Follow the onboarding protocol in `.context/METHODOLOGY.md` — it guides you through
+greenfield (4 stages) or brownfield (5 stages) setup with checkpoints at each step.
+
+## Before ending this response
+
+Read `.context/PROTOCOL.yaml` `close_check`. For each triggered item,
+update the target file now. A response that modifies files but skips
+triggered obligations is incomplete.