@sniper.ai/core 3.3.0 → 3.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -9,7 +9,7 @@ Framework core for [SNIPER](https://sniperai.dev) -- provides agents, personas,
9
9
 
10
10
  SNIPER is an AI-powered project lifecycle framework for orchestrating Claude Code agent teams through structured phases. It takes projects from discovery through implementation using parallel agent teams, review gates, and domain-specific knowledge packs.
11
11
 
12
- A full lifecycle runs through four phases: **Discover** (research and analysis), **Plan** (architecture and design), **Implement** (code with worktree isolation), and **Review** (multi-faceted code review). Each phase spawns specialized agents defined by protocol state machines.
12
+ A full lifecycle runs through: **Discover** (research and analysis), **Define** (PRD and requirements), **Design** (architecture), **Solve** (story sharding), **Implement** (code with worktree isolation), **Review** (multi-faceted code review), and **Retro** (learnings and velocity). Each phase spawns specialized agents defined by protocol state machines.
13
13
 
14
14
  ## Overview
15
15
 
@@ -73,8 +73,8 @@ Domain-specific knowledge is provided separately by domain packs (e.g., `@sniper
73
73
 
74
74
  | Protocol | Phases | Description |
75
75
  |----------|--------|-------------|
76
- | `full` | discover → plan → implement → review | Complete project lifecycle |
77
- | `feature` | plan → implement → review | Incremental feature development |
76
+ | `full` | discover → definedesign → solve → implement → review → retro | Complete project lifecycle |
77
+ | `feature` | definedesign → solve → implement → review → retro | Incremental feature development |
78
78
  | `patch` | implement → review | Quick fix with review |
79
79
  | `ingest` | scan → document → extract | Codebase ingestion and convention extraction |
80
80
  | `explore` | discover | Exploratory analysis only |
@@ -94,12 +94,13 @@ Domain-specific knowledge is provided separately by domain packs (e.g., `@sniper
94
94
 
95
95
  ## Templates
96
96
 
97
- 14 artifact templates:
97
+ 15 artifact templates:
98
98
 
99
99
  | Template | Type | Description |
100
100
  |----------|------|-------------|
101
101
  | `architecture.md` | Markdown | System architecture document |
102
- | `spec.md` | Markdown | Project specification |
102
+ | `discovery-brief.md` | Markdown | Discovery research brief |
103
+ | `prd.md` | Markdown | Product requirements document |
103
104
  | `story.md` | Markdown | User story with acceptance criteria |
104
105
  | `codebase-overview.md` | Markdown | Codebase analysis summary |
105
106
  | `review-report.md` | Markdown | Standard review report |
@@ -115,12 +116,15 @@ Domain-specific knowledge is provided separately by domain packs (e.g., `@sniper
115
116
 
116
117
  ## Checklists
117
118
 
118
- 9 quality gate checklists:
119
+ 11 quality gate checklists:
119
120
 
120
121
  | Checklist | Used by |
121
122
  |-----------|---------|
122
- | `discover` | full, explore protocols |
123
- | `plan` | full, feature protocols |
123
+ | `discover` | full protocol |
124
+ | `define` | full, feature protocols |
125
+ | `design` | full, feature protocols |
126
+ | `solve` | full, feature protocols |
127
+ | `plan` | (deprecated — use define + design) |
124
128
  | `implement` | full, feature, patch, refactor, hotfix protocols |
125
129
  | `review` | full, feature, patch, refactor protocols |
126
130
  | `multi-faceted-review` | Multi-model review mode |
package/agents/analyst.md CHANGED
@@ -13,11 +13,11 @@ You are a SNIPER analyst agent. You research, analyze, and produce discovery art
13
13
  2. **Requirements Elicitation** — Extract and clarify requirements from user input, docs, and existing code
14
14
  3. **Competitive Research** — Use web search to research approaches, libraries, and prior art
15
15
  4. **Risk Identification** — Surface technical risks, dependencies, and unknowns
16
- 5. **Spec Production** — Write discovery specs using the spec template
16
+ 5. **Discovery Brief Production** — Write a discovery brief that captures findings, constraints, and open questions
17
17
 
18
18
  ## Output Artifacts
19
19
 
20
- - `.sniper/artifacts/spec.md` — Discovery specification (use `spec.md` template)
20
+ - `.sniper/artifacts/discovery-brief.md` — Discovery brief: research findings, constraints, and open questions (NOT a spec — no design decisions)
21
21
  - `.sniper/artifacts/codebase-overview.md` — Architecture and convention analysis (use `codebase-overview.md` template)
22
22
 
23
23
  ## Rules
@@ -27,3 +27,4 @@ You are a SNIPER analyst agent. You research, analyze, and produce discovery art
27
27
  - Flag unknowns as open questions rather than guessing
28
28
  - Respect token budgets annotated in templates
29
29
  - Do NOT make architectural decisions — surface options with tradeoffs for the architect
30
+ - The discovery brief is research output, not a specification — frame it as findings and constraints, not design
@@ -23,11 +23,13 @@ You are a SNIPER architect agent. You design system architecture and produce tec
23
23
 
24
24
  ## Decision Framework
25
25
 
26
- 1. Read the discovery spec and codebase overview first
27
- 2. Identify the smallest set of components that satisfies requirements
28
- 3. For each decision, document: context, options considered, decision, consequences
29
- 4. Validate designs against the stack defined in `.sniper/config.yaml`
30
- 5. Prefer boring technology choose well-understood patterns over novel ones
26
+ 1. Read the approved PRD (`.sniper/artifacts/{protocol_id}/prd.md`) as your primary input — design against these requirements
27
+ 2. Read the discovery brief (`.sniper/artifacts/discovery-brief.md`) and codebase overview for context
28
+ 3. Identify the smallest set of components that satisfies the PRD requirements
29
+ 4. For each decision, document: context, options considered, decision, consequences
30
+ 5. Validate designs against the stack defined in `.sniper/config.yaml`
31
+ 6. Prefer boring technology — choose well-understood patterns over novel ones
32
+ 7. Reference the PRD in your plan document
31
33
 
32
34
  ## Rules
33
35
 
@@ -35,4 +37,5 @@ You are a SNIPER architect agent. You design system architecture and produce tec
35
37
  - Every API contract must include error cases
36
38
  - Do NOT over-architect — design for current requirements, not hypothetical futures
37
39
  - Do NOT implement — produce designs only
40
+ - Do NOT add requirements — design against the approved PRD, nothing more
38
41
  - Flag any requirement that cannot be met within the current stack
@@ -54,19 +54,20 @@ Risk categories to evaluate:
54
54
 
55
55
  ## Spec Reconciliation
56
56
 
57
- After completing the code review, reconcile the spec with the implementation:
57
+ After completing the code review, reconcile the PRD with the implementation:
58
58
 
59
- 1. Compare `.sniper/artifacts/spec.md` requirements against actual implementation
60
- 2. If implementation differs from spec (intentionally or due to discoveries during implementation), update `.sniper/artifacts/spec.md` to reflect reality
61
- 3. Add a "Last reconciled: YYYY-MM-DD" line at the bottom of the spec
62
- 4. This is a reconciliation (spec tracks reality), NOT a compliance check
63
- 5. Only update if there are meaningful differences; don't touch the spec if it's already accurate
59
+ 1. Compare `.sniper/artifacts/{protocol_id}/prd.md` requirements against actual implementation
60
+ 2. If implementation differs from PRD (intentionally or due to discoveries during implementation), update the PRD to reflect reality
61
+ 3. Add a "Last reconciled: YYYY-MM-DD" line at the bottom of the PRD
62
+ 4. This is a reconciliation (docs track reality), NOT a compliance check
63
+ 5. Only update if there are meaningful differences; don't touch docs if they're already accurate
64
+ 6. Do NOT modify `.sniper/artifacts/discovery-brief.md` — that is the analyst's responsibility
64
65
 
65
66
  ## Rules
66
67
 
67
68
  - Categorize findings as: `blocking` (must fix), `suggestion` (should fix), `nit` (optional)
68
69
  - Cite specific file paths and line numbers for every finding
69
- - If the implementation matches the spec and passes all checks, say so clearly
70
+ - If the implementation matches the PRD and passes all checks, say so clearly
70
71
  - Do NOT nitpick style when conventions aren't established
71
72
  - Write the review report to `.sniper/artifacts/{protocol_id}/review-report.md` (the `{protocol_id}` is provided by the orchestrator)
72
- - Only modify master `.sniper/artifacts/spec.md` during spec reconciliation — never modify project source code
73
+ - Only modify `.sniper/artifacts/{protocol_id}/prd.md` during spec reconciliation — never modify project source code or the discovery brief
@@ -5,16 +5,30 @@ write_scope:
5
5
 
6
6
  # Product Manager
7
7
 
8
- You are a SNIPER product manager agent. You translate requirements into structured stories with EARS acceptance criteria.
8
+ You are a SNIPER product manager agent. You define product requirements and translate them into structured stories with EARS acceptance criteria.
9
9
 
10
10
  ## Responsibilities
11
11
 
12
- 1. **PRD Writing** — Produce product requirements documents from specs and architecture
12
+ 1. **PRD Writing** — Produce product requirements documents from the discovery brief
13
13
  2. **Story Creation** — Break PRDs into implementable stories with EARS acceptance criteria
14
14
  3. **Scope Management** — Clearly delineate in-scope vs out-of-scope items
15
15
  4. **Priority Ordering** — Order stories by dependency and user value
16
16
  5. **Success Metrics** — Define measurable success criteria for each requirement
17
17
 
18
+ ## Workflow
19
+
20
+ ### During `define` phase (PRD writing)
21
+ 1. Read the discovery brief (`.sniper/artifacts/discovery-brief.md`) as your primary input
22
+ 2. Produce a PRD that defines WHAT to build and WHY — not HOW
23
+ 3. The PRD **must** include a `## Out of Scope` section — this is not optional
24
+ 4. The PRD **must** include a `## Success Criteria` section with measurable outcomes
25
+ 5. Do NOT coordinate with or wait for the architect — you run before them
26
+
27
+ ### During `solve` phase (story creation)
28
+ 1. Read the approved PRD and architecture plan as inputs
29
+ 2. Break the PRD into implementable stories with EARS acceptance criteria
30
+ 3. Order stories by dependency, then user value
31
+
18
32
  ## EARS Criteria Format
19
33
 
20
34
  Use the EARS (Easy Approach to Requirements Syntax) patterns:
@@ -26,7 +40,7 @@ Use the EARS (Easy Approach to Requirements Syntax) patterns:
26
40
 
27
41
  ## Output Artifacts
28
42
 
29
- - `.sniper/artifacts/{protocol_id}/prd.md` — Product requirements for this protocol run (use `spec.md` template adapted for PRD)
43
+ - `.sniper/artifacts/{protocol_id}/prd.md` — Product requirements for this protocol run (use `prd.md` template)
30
44
  - `.sniper/artifacts/{protocol_id}/stories/*.md` — Individual stories (use `story.md` template, 1500 token budget each)
31
45
  - The `{protocol_id}` (e.g., `SNPR-20260307-a3f2`) is provided by the orchestrator when spawning you
32
46
  - These are per-run snapshots that preserve the plan history
@@ -0,0 +1,28 @@
1
+ name: define
2
+ description: PRD quality gate — requirements completeness and scope clarity
3
+
4
+ checks:
5
+ - id: prd_produced
6
+ description: PRD document exists
7
+ check: file:.sniper/artifacts/{protocol_id}/prd.md
8
+ blocking: true
9
+
10
+ - id: requirements_defined
11
+ description: PRD has a Requirements section
12
+ check: grep:.sniper/artifacts/{protocol_id}/prd.md:"## Requirements"
13
+ blocking: true
14
+
15
+ - id: success_criteria_defined
16
+ description: PRD has measurable success criteria
17
+ check: grep:.sniper/artifacts/{protocol_id}/prd.md:"## Success Criteria"
18
+ blocking: true
19
+
20
+ - id: scope_boundaries
21
+ description: PRD explicitly defines what is out of scope
22
+ check: grep:.sniper/artifacts/{protocol_id}/prd.md:"## Out of Scope"
23
+ blocking: true # Out of scope must be explicit — this is where scope creep dies
24
+
25
+ - id: token_budget
26
+ description: PRD is concise (under 12000 chars)
27
+ check: wc:.sniper/artifacts/{protocol_id}/prd.md:<12000
28
+ blocking: false
@@ -0,0 +1,43 @@
1
+ name: design
2
+ description: Architecture quality gate — design completeness
3
+
4
+ checks:
5
+ - id: plan_produced
6
+ description: Architecture plan exists
7
+ check: file:.sniper/artifacts/{protocol_id}/plan.md
8
+ blocking: true
9
+
10
+ - id: has_context_section
11
+ description: Plan includes context and constraints
12
+ check: grep:.sniper/artifacts/{protocol_id}/plan.md:"## Context"
13
+ blocking: true
14
+
15
+ - id: has_decisions_section
16
+ description: Plan documents key architectural decisions
17
+ check: grep:.sniper/artifacts/{protocol_id}/plan.md:"## Decisions"
18
+ blocking: true
19
+
20
+ - id: has_components_section
21
+ description: Plan breaks down into components
22
+ check: grep:.sniper/artifacts/{protocol_id}/plan.md:"## Components"
23
+ blocking: true
24
+
25
+ - id: has_data_model_section
26
+ description: Plan defines data model (or explicitly states N/A)
27
+ check: grep:.sniper/artifacts/{protocol_id}/plan.md:"## Data Model"
28
+ blocking: false # Not every feature requires a data model
29
+
30
+ - id: references_prd
31
+ description: Plan references the approved PRD
32
+ check: grep:.sniper/artifacts/{protocol_id}/plan.md:"prd.md"
33
+ blocking: false
34
+
35
+ - id: open_questions
36
+ description: No unresolved open questions remain
37
+ check: "!grep:.sniper/artifacts/{protocol_id}/plan.md:\\*\\*TBD\\*\\*|\\*\\*TODO\\*\\*|\\*\\*OPEN\\*\\*"
38
+ blocking: false
39
+
40
+ - id: token_budget
41
+ description: Architecture plan within character budget (~4000 tokens = 16000 chars)
42
+ check: wc:.sniper/artifacts/{protocol_id}/plan.md:<16000
43
+ blocking: false
@@ -2,19 +2,29 @@ name: discover
2
2
  description: Discovery phase quality gate
3
3
 
4
4
  checks:
5
- - id: spec_produced
6
- description: Discovery spec exists
7
- check: file:.sniper/artifacts/spec.md
5
+ - id: discovery_brief_produced
6
+ description: Discovery brief exists
7
+ check: file:.sniper/artifacts/discovery-brief.md
8
8
  blocking: true
9
9
 
10
- - id: scope_defined
11
- description: Spec defines in-scope requirements
12
- check: grep:.sniper/artifacts/spec.md:"## Requirements"
10
+ - id: findings_defined
11
+ description: Brief defines key findings
12
+ check: grep:.sniper/artifacts/discovery-brief.md:"## Findings"
13
13
  blocking: true
14
14
 
15
+ - id: constraints_identified
16
+ description: Brief identifies constraints
17
+ check: grep:.sniper/artifacts/discovery-brief.md:"## Constraints"
18
+ blocking: false
19
+
20
+ - id: risks_identified
21
+ description: Brief identifies risks
22
+ check: grep:.sniper/artifacts/discovery-brief.md:"## Risks"
23
+ blocking: false
24
+
15
25
  - id: out_of_scope_explicit
16
- description: Spec explicitly lists out-of-scope items
17
- check: grep:.sniper/artifacts/spec.md:"## Out of Scope"
26
+ description: Brief explicitly lists out-of-scope items
27
+ check: grep:.sniper/artifacts/discovery-brief.md:"## Out of Scope"
18
28
  blocking: false
19
29
 
20
30
  - id: codebase_overview
@@ -4,9 +4,9 @@ description: Multi-dimensional review gate — scope, standards, and risk
4
4
 
5
5
  checks:
6
6
  # Scope Validation — does the implementation match requirements?
7
- - id: scope_spec_match
8
- description: Implementation addresses all spec requirements
9
- check: file:.sniper/artifacts/spec.md
7
+ - id: scope_prd_match
8
+ description: PRD exists (scope validation is performed by code-reviewer agent)
9
+ check: file:.sniper/artifacts/{protocol_id}/prd.md
10
10
  blocking: true
11
11
 
12
12
  - id: scope_acceptance_criteria
@@ -1,5 +1,7 @@
1
1
  name: plan
2
- description: Planning phase quality gate
2
+ description: Planning phase quality gate (DEPRECATED — use define.yaml + design.yaml instead)
3
+ # DEPRECATED: This checklist is retained for backward compatibility with custom protocols
4
+ # that reference the combined "plan" phase. New protocols use separate "define" and "design" phases.
3
5
  # Note: {protocol_id} is resolved at gate-review time from the active checkpoint
4
6
 
5
7
  checks:
@@ -22,7 +24,7 @@ checks:
22
24
 
23
25
  - id: open_questions
24
26
  description: No unresolved open questions remain
25
- check: "!grep:.sniper/artifacts/{protocol_id}/:\\*\\*TBD\\*\\*|\\*\\*TODO\\*\\*|\\*\\*OPEN\\*\\*"
27
+ check: "!grep:.sniper/artifacts/{protocol_id}/plan.md:\\*\\*TBD\\*\\*|\\*\\*TODO\\*\\*|\\*\\*OPEN\\*\\*"
26
28
  blocking: false
27
29
 
28
30
  - id: token_budget
@@ -24,6 +24,6 @@ checks:
24
24
  blocking: true
25
25
 
26
26
  - id: spec_reconciled
27
- description: Spec has been reconciled with implementation
28
- check: "grep:.sniper/artifacts/spec.md:Last reconciled:"
27
+ description: PRD has been reconciled with implementation
28
+ check: "grep:.sniper/artifacts/{protocol_id}/prd.md:Last reconciled:"
29
29
  blocking: false
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@sniper.ai/core",
3
- "version": "3.3.0",
3
+ "version": "3.4.0",
4
4
  "description": "SNIPER framework core — agents, skills, protocols, checklists, templates, and hooks",
5
5
  "type": "module",
6
6
  "exports": {
@@ -1,30 +1,41 @@
1
1
  name: feature
2
- description: Incremental feature — plan, implement, review
2
+ description: Incremental feature — define, design, solve, implement, review, retro
3
3
  budget: 800000 # 800K tokens
4
4
 
5
5
  phases:
6
- - name: plan
7
- description: Feature design and architecture
6
+ - name: define
7
+ description: Product requirements for the feature
8
8
  agents:
9
- - architect
10
9
  - product-manager
11
- spawn_strategy: sequential # Architect designs first, PM refines PRD from that
10
+ spawn_strategy: single
11
+ interactive_review: true # User reviews PRD before architecture
12
+ gate:
13
+ checklist: define
14
+ human_approval: true
15
+ outputs:
16
+ - .sniper/artifacts/{protocol_id}/prd.md
17
+
18
+ - name: design
19
+ description: Technical design against approved requirements
20
+ agents:
21
+ - architect
22
+ spawn_strategy: single
12
23
  interactive_review: true # User reviews architecture before story sharding
13
24
  gate:
14
- checklist: plan
25
+ checklist: design
15
26
  human_approval: true
16
27
  outputs:
17
28
  - .sniper/artifacts/{protocol_id}/plan.md
18
- - .sniper/artifacts/{protocol_id}/prd.md
19
29
 
20
30
  - name: solve
21
31
  description: Story creation from approved architecture
22
32
  agents:
23
33
  - product-manager
24
34
  spawn_strategy: single
35
+ interactive_review: true # User reviews story decomposition before implementation
25
36
  gate:
26
37
  checklist: solve
27
- human_approval: false
38
+ human_approval: true # Review story decomposition before implementation
28
39
  outputs:
29
40
  - .sniper/artifacts/{protocol_id}/stories/
30
41
 
@@ -4,43 +4,51 @@ budget: 2000000 # 2M tokens
4
4
 
5
5
  phases:
6
6
  - name: discover
7
- description: Research, analyze codebase, produce discovery spec and PRD
7
+ description: Research problem space, analyze codebase, identify constraints
8
8
  agents:
9
9
  - analyst
10
- spawn_strategy: single # One agent, no team needed
11
- interactive_review: true # User reviews spec/PRD before architecture begins
10
+ spawn_strategy: single
11
+ interactive_review: true # User reviews discovery brief before PRD begins
12
12
  gate:
13
13
  checklist: discover
14
14
  human_approval: true
15
15
  outputs:
16
- - .sniper/artifacts/spec.md # Living master doc
16
+ - .sniper/artifacts/discovery-brief.md # Living master doc
17
17
  - .sniper/artifacts/codebase-overview.md # Living master doc
18
18
 
19
- - name: plan
20
- description: Architecture design and PRD refinement
19
+ - name: define
20
+ description: Product requirements what to build, success criteria, scope boundaries
21
21
  agents:
22
- - architect
23
22
  - product-manager
24
- spawn_strategy: team # Multiple agents, use TeamCreate
23
+ spawn_strategy: single
24
+ interactive_review: true # User reviews PRD before architecture begins — highest-leverage gate
25
+ gate:
26
+ checklist: define
27
+ human_approval: true
28
+ outputs:
29
+ - .sniper/artifacts/{protocol_id}/prd.md
30
+
31
+ - name: design
32
+ description: Architecture design against approved PRD requirements
33
+ agents:
34
+ - architect
35
+ spawn_strategy: single
25
36
  interactive_review: true # User reviews architecture before story sharding
26
- coordination:
27
- - between: [architect, product-manager]
28
- topic: Architecture must be finalized before PRD is updated
29
37
  gate:
30
- checklist: plan
31
- human_approval: true # Human reviews architecture before stories are created
38
+ checklist: design
39
+ human_approval: true
32
40
  outputs:
33
41
  - .sniper/artifacts/{protocol_id}/plan.md
34
- - .sniper/artifacts/{protocol_id}/prd.md
35
42
 
36
43
  - name: solve
37
44
  description: Epic sharding and story creation from approved architecture
38
45
  agents:
39
46
  - product-manager
40
47
  spawn_strategy: single
48
+ interactive_review: true # User reviews story decomposition before implementation
41
49
  gate:
42
50
  checklist: solve
43
- human_approval: false
51
+ human_approval: true # Bad decomposition causes expensive rework — worth 5 minutes
44
52
  outputs:
45
53
  - .sniper/artifacts/{protocol_id}/stories/
46
54
 
@@ -63,10 +63,11 @@ For each phase in the protocol, execute these 5 steps:
63
63
  ### Execute
64
64
 
65
65
  1. Determine spawn strategy from protocol phase definition (`single`, `sequential`, `parallel`, or `team`)
66
- 2. Spawn agents per [Reference: Spawn Strategies](#reference-spawn-strategies)
67
- 3. Monitor via TaskList if an agent is blocked, investigate and guide via SendMessage
68
- 4. If an agent crashes: note the failure, continue with remaining agents
69
- 5. After all parallel agents complete: coordinate worktree merges per [Reference: Merge Coordination](#reference-merge-coordination)
66
+ 2. Spawn **ONLY** the agents listed in the protocol phase's `agents` array — no more, no fewer. Do NOT infer additional agents from the phase description or outputs. The `agents` list is the single source of truth for who participates in each phase.
67
+ 3. Spawn agents per [Reference: Spawn Strategies](#reference-spawn-strategies)
68
+ 4. Monitor via TaskList — if an agent is blocked, investigate and guide via SendMessage
69
+ 5. If an agent crashes: note the failure, continue with remaining agents
70
+ 6. After all parallel agents complete: coordinate worktree merges per [Reference: Merge Coordination](#reference-merge-coordination)
70
71
 
71
72
  ### Checkpoint
72
73
 
@@ -199,10 +200,12 @@ For agents working in worktrees (after all implementation agents complete):
199
200
 
200
201
  When a phase has `interactive_review: true`:
201
202
 
202
- 1. Read produced artifacts from `.sniper/artifacts/{protocol_id}/` (e.g., `spec.md`, `plan.md`, `prd.md`)
203
+ 1. Read produced artifacts from `.sniper/artifacts/` or `.sniper/artifacts/{protocol_id}/` as appropriate
203
204
  2. Present a structured summary appropriate to the phase:
204
- - **discover:** scope, requirements, key findings, open questions
205
- - **plan:** key architectural decisions, component overview, data model, trade-offs
205
+ - **discover:** findings, constraints, codebase landscape, open questions
206
+ - **define:** requirements, success criteria, scope boundaries, out-of-scope items
207
+ - **design:** key architectural decisions, component overview, data model, trade-offs
208
+ - **solve:** story list, dependencies, acceptance criteria summary
206
209
  3. Offer options:
207
210
  - **Approve** — continue to next phase
208
211
  - **Request changes** — describe changes (architect/PM will revise, then re-present)
@@ -0,0 +1,23 @@
1
+ # Discovery Brief
2
+ <!-- Budget: 3000 tokens max -->
3
+ <!-- This is research output, not a specification. Frame as findings and constraints, not design decisions. -->
4
+
5
+ ## Context
6
+ <!-- ~300 tokens: What exists today, what triggered this investigation -->
7
+
8
+ ## Findings
9
+ <!-- ~800 tokens: Key discoveries from codebase analysis, research, and requirements elicitation -->
10
+ <!-- Ground every finding in evidence — cite file paths, line numbers, or URLs -->
11
+
12
+ ## Constraints
13
+ <!-- ~400 tokens: Technical constraints, dependencies, and limitations discovered -->
14
+
15
+ ## Risks
16
+ <!-- ~300 tokens: Technical risks, unknowns, and potential blockers -->
17
+
18
+ ## Out of Scope
19
+ <!-- ~200 tokens: Explicitly list what this work should NOT cover -->
20
+
21
+ ## Open Questions
22
+ <!-- ~200 tokens: Unresolved questions that need answers before defining requirements -->
23
+ <!-- Distinguish facts from assumptions explicitly -->
@@ -0,0 +1,30 @@
1
+ # Product Requirements Document
2
+ <!-- Budget: 3000 tokens max -->
3
+ <!-- This defines WHAT to build and WHY — not HOW. Architecture comes later. -->
4
+
5
+ ## Context
6
+ <!-- ~300 tokens: What exists today and why this work is needed -->
7
+
8
+ ## Problem
9
+ <!-- ~400 tokens: What specific problem are we solving -->
10
+
11
+ ## Users
12
+ <!-- ~200 tokens: Who are the users and what do they need -->
13
+
14
+ ## Requirements
15
+ <!-- ~800 tokens: EARS-format requirements -->
16
+ <!-- Use: "The <system> shall <action>" for each requirement -->
17
+
18
+ ### Functional Requirements
19
+
20
+ ### Non-Functional Requirements
21
+
22
+ ## Out of Scope
23
+ <!-- ~200 tokens: Explicitly list what this work does NOT cover -->
24
+ <!-- This section is mandatory — scope creep dies here -->
25
+
26
+ ## Success Criteria
27
+ <!-- ~300 tokens: Measurable outcomes that define "done" -->
28
+
29
+ ## Open Questions
30
+ <!-- ~200 tokens: Unresolved questions that need answers before design -->