Wave Methodology Knowledge

Wave Methodology Knowledge

The nWave methodology organizes work into a canonical sequence of waves. Each wave has a purpose, a primary agent, inputs from earlier waves, and outputs consumed by later waves. The buddy agent uses this map to answer "where am I in the process" and "what should I do next" questions without stepping into execution territory.

The canonical wave sequence

DISCOVER -> DISCUSS -> SPIKE(opt) -> DESIGN -> DEVOPS -> DISTILL -> DELIVER

Each wave has a slash command (/nw-<wave>) and a primary agent. Waves run top-to-bottom. Skipping waves is a smell; going back to revise an earlier wave is normal and expected. SPIKE is optional — include it when validating a new mechanism, performance requirement, or external integration.

Wave-by-wave reference

1. DISCOVER

• Purpose: validate that an opportunity exists and is worth pursuing.
• Primary agent: product-discoverer.
• Inputs: a rough idea, a user complaint, a market signal, or a strategic prompt.
• Outputs: an evidence brief — problem statement, target users, pains, existing solutions, strength of signal, go/no-go recommendation.
• Typical artifacts: docs/discover/<opportunity>-brief.md, user interview notes, competitive scans.
• Common questions: "is this worth doing?", "who has this problem?", "what's the evidence?"

2. DISCUSS

• Purpose: turn a validated opportunity into user stories with acceptance criteria.
• Primary agent: product-owner.
• Inputs: DISCOVER output — validated problem and target users.
• Outputs: a set of user stories, each with a goal, acceptance criteria in Given-When-Then form, and a rough priority.
• Typical artifacts: docs/discuss/<feature>-stories.md, a backlog update.
• Common questions: "what does 'done' look like for this feature?", "what are the user stories?"

3. SPIKE (optional)

• Purpose: validate one core assumption through timeboxed throwaway code before investing in architecture design.
• Primary agent: software-crafter.
• Inputs: DISCUSS output — stories, acceptance criteria, and assumptions to test.
• Outputs: spike findings documenting what works, what assumptions were wrong, performance measurements. Code is discarded.
• Typical artifacts: docs/feature/<name>/spike/findings.md, throwaway code (not committed).
• Common questions: "will this mechanism work?", "can we hit the performance budget?", "does the third-party API behave as expected?"