/execute
Dispatches one unit of DELIVER work to a specialized agent for TDD execution. Runs a single roadmap.json step through the TDD cycle.
> /plugin marketplace add nWave-ai/nWave > /plugin install nw@nwave-marketplace
How it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/execute
Context preview
What this command does when you run it.
Dispatches one unit of DELIVER work to a specialized agent for TDD execution. Runs a single roadmap.json step through the TDD cycle.
Command definition
execute.mddescription: "Dispatches one unit of DELIVER work to a specialized agent for TDD execution. Runs a single roadmap.json step through the TDD cycle."
argument-hint: '[agent] [feature-id] [step-id] - Example: @nw-software-crafter "auth-upgrade" "01-01"'
NW-EXECUTE: Atomic Task Execution
**Wave**: EXECUTION_WAVE | **Agent**: Dispatched agent (specified by caller)
Overview
Dispatch one unit of DELIVER work to an agent: a single roadmap step. `/nw-execute` extracts the step from `roadmap.json` and dispatches it for the 3-phase TDD canon; the agent appends phase events to `execution-log.json`.
Syntax
/nw-execute @{agent} "{feature-id}" "{step-id}"Context Files Required
- `docs/feature/{feature-id}/deliver/roadmap.json` — Orchestrator reads once, extracts step context
- `docs/feature/{feature-id}/deliver/execution-log.json` — Agent appends only (never reads)
Rigor Profile Integration
Before dispatching the agent, read rigor config from `.nwave/des-config.json` (key: `rigor`). If absent, use standard defaults.
- **`agent_model`**: Pass as `model` parameter to Agent tool. If `"inherit"`, omit `model` (inherits from session).
- **`tdd_phases`**: Modify the TDD_PHASES section in the DES template to match the configured phases. The 3-phase canon (ADR-025) is `[RED, GREEN, COMMIT]`; the lean variant is `[RED, GREEN]`. Legacy 5-phase contract (`[PREPARE, RED_ACCEPTANCE, RED_UNIT, GREEN, COMMIT]`) and its lean variant (`[RED_UNIT, GREEN]`) remain supported for audit-log replay of pre-2026-05-07 commits. Remove omitted phases' instructions from the template.
- **`refactor_pass`**: If `false`, skip COMMIT phase refactoring instructions.
Dispatcher Workflow
1. Parse parameters: agent name|feature ID|step ID 2. Read rigor profile from `.nwave/des-config.json` (default: standard) 3. Validate roadmap.json and execution-log exist 4. Grep roadmap.json for `step_id: "{step-id}"` with ~50 lines context 5. Extract step fields and invoke Agent tool with DES template below, applying rigor model and phases
Agent Invocation
@{agent}
Use this DES template verbatim. Fill `{placeholders}` from roadmap. Without DES markers, hooks cannot validate.
<!-- DES-VALIDATION : required -->
<!-- DES-PROJECT-ID : {feature-id} -->
<!-- DES-STEP-ID : {step-id} -->
# DES_METADATA
Step: {step-id}
Feature: {feature-id}
Command: /nw-execute
# AGENT_IDENTITY
Agent: {agent-name}
# SKILL_LOADING
Before starting TDD phases, read your skill files for methodology guidance.
Skills path: ~/.claude/skills/nw/{agent-name}/
Always load before RED: tdd-methodology.md, quality-framework.md (3-phase canon, ADR-025) — legacy 5-phase logs reference loading at PREPARE.
Load on-demand per phase as specified in your Skill Loading Strategy table.
# TASK_CONTEXT
{step context from roadmap - name|description|acceptance_criteria|test_file|scenario_name|quality_gates|implementation_notes|dependencies|estimated_hours|deliverables|files_to_modify}
# DESIGN_CONTEXT
{Summary of architectural decisions relevant to this step, extracted by the orchestrator from design wave artifacts (architecture-design.md, component-boundaries.md, wave-decisions.md). Include: component structure, dependency boundaries, technology choices, and any design constraints that affect implementation. If no design artifacts exist, write "No design artifacts available — use project conventions."}
# TDD_PHASES
3-phase canon (ADR-025, 2026-05-07). Execute in order:
1. RED - Activate the pre-authored acceptance test (PRIMARY TBU DEFENSE); write PBT unit tests ONLY if the AT cannot reach GREEN without them.
AT activation: If TASK_CONTEXT includes test_file, locate it and remove the @skip/@ignore/@pending/xit/.skip/[Ignore] marker from the target scenario (the AT scaffold was authored by DISTILL — DELIVER does NOT re-author ATs). Run it — must fail for business logic reason (not import/syntax error). Fail-for-right-reason gate: collected ≥ 1, failures ≥ 1, no collection errors, semantic AssertionError / expected-exception-not-thrown.
PORT-TO-PORT PRINCIPLE: The acceptance test exercises the scenario through
the driving port (application service, orchestrator, CLI handler, API controller),
not a decomposed helper or internal class. A correctly-written port-to-port test
makes TBU structurally impossible — if a new function were missing or unwired,
THIS test stays RED. That is the entire point: GREEN is unreachable without wiring.
Litmus test: "If I delete the call-site that wires the new code, does this test fail?"
If no → the test is at the wrong level. Stop and flag to orchestrator (DISTILL re-author needed).
Conditional unit-test authoring: write PBT unit tests (or integration tests for adapter/infrastructure code — adapters use real infrastructure, never mocked unit tests) ONLY when the AT requires them to reach GREEN. If the AT can pass via direct minimal implementation, skip unit-test authoring inside RED.
2. GREEN - Minimal code to pass AT + any unit tests authored in RED.
After GREEN: run FULL test suite. If all pass, proceed to COMMIT immediately.
Smell test: if any new function is only called from test code, your acceptance
test is at the wrong abstraction level — stop and flag.
Never move to new task or stop without committing green code.
3. COMMIT - Commit this step's owned files via `des-commit` (parallel-safe).
Use `des-commit` instead of raw `git add` / `git commit`. It holds an
exclusive lock and commits ONLY the paths you pass, so a parallel agent's
staged work is never swept into your commit (issue #51 / ADR-027). Pass
EVERY file you created or modified for this step (production + tests) as
`--owned-paths`; anything omitted is not committed.des-commit \ --owned-paths <all files this step created/modified> \ --step-id {step-id} \ --message "feat(feature-id): implement feature X"
The `Step-Id: {step-id}` trailer (required for DES vRead more
description: "Dispatches one unit of DELIVER work to a specialized agent for TDD execution. Runs a single roadmap.json step through the TDD cycle." argument-hint: '[agent] [feature-id] [step-id] - Example: @nw-software-crafter "auth-upgrade" "01-01"'
NW-EXECUTE: Atomic Task Execution
**Wave**: EXECUTION_WAVE | **Agent**: Dispatched agent (specified by caller)
Overview
Dispatch one unit of DELIVER work to an agent: a single roadmap step. `/nw-execute` extracts the step from `roadmap.json` and dispatches it for the 3-phase TDD canon; the agent appends phase events to `execution-log.json`.
Syntax
/nw-execute @{agent} "{feature-id}" "{step-id}"Context Files Required
- `docs/feature/{feature-id}/deliver/roadmap.json` — Orchestrator reads once, extracts step context
- `docs/feature/{feature-id}/deliver/execution-log.json` — Agent appends only (never reads)
Rigor Profile Integration
Before dispatching the agent, read rigor config from `.nwave/des-config.json` (key: `rigor`). If absent, use standard defaults.
- **`agent_model`**: Pass as `model` parameter to Agent tool. If `"inherit"`, omit `model` (inherits from session).
- **`tdd_phases`**: Modify the TDD_PHASES section in the DES template to match the configured phases. The 3-phase canon (ADR-025) is `[RED, GREEN, COMMIT]`; the lean variant is `[RED, GREEN]`. Legacy 5-phase contract (`[PREPARE, RED_ACCEPTANCE, RED_UNIT, GREEN, COMMIT]`) and its lean variant (`[RED_UNIT, GREEN]`) remain supported for audit-log replay of pre-2026-05-07 commits. Remove omitted phases' instructions from the template.
- **`refactor_pass`**: If `false`, skip COMMIT phase refactoring instructions.
Dispatcher Workflow
1. Parse parameters: agent name|feature ID|step ID 2. Read rigor profile from `.nwave/des-config.json` (default: standard) 3. Validate roadmap.json and execution-log exist 4. Grep roadmap.json for `step_id: "{step-id}"` with ~50 lines context 5. Extract step fields and invoke Agent tool with DES template below, applying rigor model and phases
Agent Invocation
@{agent}
Use this DES template verbatim. Fill `{placeholders}` from roadmap. Without DES markers, hooks cannot validate.
<!-- DES-VALIDATION : required -->
<!-- DES-PROJECT-ID : {feature-id} -->
<!-- DES-STEP-ID : {step-id} -->
# DES_METADATA
Step: {step-id}
Feature: {feature-id}
Command: /nw-execute
# AGENT_IDENTITY
Agent: {agent-name}
# SKILL_LOADING
Before starting TDD phases, read your skill files for methodology guidance.
Skills path: ~/.claude/skills/nw/{agent-name}/
Always load before RED: tdd-methodology.md, quality-framework.md (3-phase canon, ADR-025) — legacy 5-phase logs reference loading at PREPARE.
Load on-demand per phase as specified in your Skill Loading Strategy table.
# TASK_CONTEXT
{step context from roadmap - name|description|acceptance_criteria|test_file|scenario_name|quality_gates|implementation_notes|dependencies|estimated_hours|deliverables|files_to_modify}
# DESIGN_CONTEXT
{Summary of architectural decisions relevant to this step, extracted by the orchestrator from design wave artifacts (architecture-design.md, component-boundaries.md, wave-decisions.md). Include: component structure, dependency boundaries, technology choices, and any design constraints that affect implementation. If no design artifacts exist, write "No design artifacts available — use project conventions."}
# TDD_PHASES
3-phase canon (ADR-025, 2026-05-07). Execute in order:
1. RED - Activate the pre-authored acceptance test (PRIMARY TBU DEFENSE); write PBT unit tests ONLY if the AT cannot reach GREEN without them.
AT activation: If TASK_CONTEXT includes test_file, locate it and remove the @skip/@ignore/@pending/xit/.skip/[Ignore] marker from the target scenario (the AT scaffold was authored by DISTILL — DELIVER does NOT re-author ATs). Run it — must fail for business logic reason (not import/syntax error). Fail-for-right-reason gate: collected ≥ 1, failures ≥ 1, no collection errors, semantic AssertionError / expected-exception-not-thrown.
PORT-TO-PORT PRINCIPLE: The acceptance test exercises the scenario through
the driving port (application service, orchestrator, CLI handler, API controller),
not a decomposed helper or internal class. A correctly-written port-to-port test
makes TBU structurally impossible — if a new function were missing or unwired,
THIS test stays RED. That is the entire point: GREEN is unreachable without wiring.
Litmus test: "If I delete the call-site that wires the new code, does this test fail?"
If no → the test is at the wrong level. Stop and flag to orchestrator (DISTILL re-author needed).
Conditional unit-test authoring: write PBT unit tests (or integration tests for adapter/infrastructure code — adapters use real infrastructure, never mocked unit tests) ONLY when the AT requires them to reach GREEN. If the AT can pass via direct minimal implementation, skip unit-test authoring inside RED.
2. GREEN - Minimal code to pass AT + any unit tests authored in RED.
After GREEN: run FULL test suite. If all pass, proceed to COMMIT immediately.
Smell test: if any new function is only called from test code, your acceptance
test is at the wrong abstraction level — stop and flag.
Never move to new task or stop without committing green code.
3. COMMIT - Commit this step's owned files via `des-commit` (parallel-safe).
Use `des-commit` instead of raw `git add` / `git commit`. It holds an
exclusive lock and commits ONLY the paths you pass, so a parallel agent's
staged work is never swept into your commit (issue #51 / ADR-027). Pass
EVERY file you created or modified for this step (production + tests) as
`--owned-paths`; anything omitted is not committed.des-commit \ --owned-paths <all files this step created/modified> \ --step-id {step-id} \ --message "feat(feature-id): implement feature X"
The `Step-Id: {step-id}` trailer (required for DES vAI agents that guide you from idea to working code, with human judgment at every gate. nWave runs inside Claude Code. It breaks feature delivery into seven waves (discover, diverge, discuss, design, devops, distill, deliver).
Repo: nWave-ai/nWave
Other commands on nwave.
- /buddy
nWave concierge — ask any question about methodology, project state, commands, migration, or troubleshooting. Read-only, contextual answers.
Open command - /bugfix
Bug fix workflow: root cause analysis → user review → regression test + fix via TDD
Open command - /continue
Detects current wave progress for a feature and resumes at the next step. Scans docs/feature/ for artifacts.
Open command - /deliver
Orchestrates the full DELIVER wave end-to-end (roadmap > execute-all > finalize). Use when all prior waves are complete and the feature is ready for implementation.
Open command - /design
Designs system architecture with C4 diagrams and technology selection. Use when defining component boundaries, choosing tech stacks, or creating architecture documents.
Open command - /devops
Designs CI/CD pipelines, infrastructure, observability, and deployment strategy. Use when preparing platform readiness for a feature.
Open command

