Agent skill
nw-execute
Dispatches a single roadmap step to a specialized agent for TDD execution. Use when implementing a specific step from a roadmap.json plan.
Install this agent skill to your Project
npx add-skill https://github.com/nWave-ai/nWave/tree/main/nWave/skills/nw-execute
SKILL.md
NW-EXECUTE: Atomic Task Execution
Wave: EXECUTION_WAVE | Agent: Dispatched agent (specified by caller)
Overview
Dispatch a single roadmap step to an agent. Orchestrator extracts step context from roadmap so agent never loads the full roadmap.
Syntax
/nw-execute @{agent} "{feature-id}" "{step-id}"
Context Files Required
docs/feature/{feature-id}/deliver/roadmap.json— Orchestrator reads once, extracts step contextdocs/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 asmodelparameter to Agent tool. If"inherit", omitmodel(inherits from session).tdd_phases: If["RED_UNIT", "GREEN"](lean), modify the TDD_PHASES section in the DES template to only include those 2 phases. Remove PREPARE/RED_ACCEPTANCE/COMMIT instructions.refactor_pass: Iffalse, skip COMMIT phase refactoring instructions.
Dispatcher Workflow
- Parse Parameters — Extract agent name, feature ID, and step ID from invocation. Gate: all three parameters present and non-empty.
- Load Rigor Profile — Read
.nwave/des-config.jsonkeyrigor(default: standard if absent). Gate: config loaded or default applied. - Validate Context Files — Confirm
docs/feature/{feature-id}/deliver/roadmap.jsonandexecution-log.jsonexist. Gate: both files present; report path-not-found if missing. - Extract Step Context — Grep roadmap for
step_id: "{step-id}"with ~50 lines context. Gate: step found; report available step IDs if missing. - Invoke Agent — Call Agent tool with DES template below, applying rigor model and phases from step 2. Gate: Agent tool called, not executed inline.
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-{skill-name}/SKILL.md
Always load at PREPARE: tdd-methodology.md, quality-framework.md
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 docs/product/architecture/brief.md and 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
Execute in order:
0. PREPARE - Load context, verify prerequisites
1. RED_ACCEPTANCE - Activate or write acceptance test (PRIMARY TBU DEFENSE)
If TASK_CONTEXT includes test_file: locate it, remove @skip/@ignore/@pending/xit/.skip/[Ignore] marker
from the target scenario, run it — must fail for business logic reason (not import/syntax error).
If no test_file in TASK_CONTEXT: write a new failing acceptance test from acceptance_criteria.
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. Fix it before proceeding.
2. RED_UNIT - Write failing unit test (or integration test for adapter/infrastructure
code — adapters use real infrastructure, never mocked unit tests)
3. GREEN - Minimal code to pass tests
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 — go back to RED_ACCEPTANCE and fix it.
Never move to new task or stop without committing green code.
4. COMMIT - Stage and commit with conventional message
Include git trailer: `Step-ID: {step-id}` (required for DES verification)
Example:
feat(feature-id): implement feature X
Step-ID: 02-01
# QUALITY_GATES
- All tests pass before COMMIT
- No skipped phases without blocked_by reason
- Coverage maintained or improved
# OUTCOME_RECORDING
After ACTUALLY EXECUTING each phase, record via DES CLI:
PYTHONPATH=$HOME/.claude/lib/python $(command -v python3 || command -v python) -m des.cli.log_phase \
--project-dir docs/feature/{feature-id}/deliver \
--step-id {step-id} \
--phase {PHASE_NAME} \
--status EXECUTED \
--data PASS
For SKIPPED phases (genuinely not applicable):
PYTHONPATH=$HOME/.claude/lib/python $(command -v python3 || command -v python) -m des.cli.log_phase \
--project-dir docs/feature/{feature-id}/deliver \
--step-id {step-id} \
--phase {PHASE_NAME} \
--status SKIPPED \
--data "NOT_APPLICABLE: reason"
CLI enforces real UTC timestamps and validates phase names.
Do NOT manually edit execution-log.json.
Use the DES CLI to record phase outcomes and create log files.
Python resolution: `$(command -v python3 || command -v python)` — works on macOS (python3 only), Linux, and Windows.
CRITICAL: Only the executing agent calls the CLI.
Orchestrator MUST NEVER write phase entries — only the agent that performed the work. A log entry without actual execution is a **violation that DES detects and that will cause integrity verification to fail**, blocking finalize.
# RECORDING_INTEGRITY
Valid Skip Prefixes: NOT_APPLICABLE, BLOCKED_BY_DEPENDENCY, APPROVED_SKIP, CHECKPOINT_PENDING
Anti-Fraud Rules:
- NEVER write EXECUTED for phases you did not actually perform
- NEVER invent timestamps — DES CLI generates real UTC timestamps
- DES audits all entries; integrity violations block finalize
# BOUNDARY_RULES
- Only modify files listed in step's files_to_modify
- Do not load roadmap.json
- Do not modify execution-log.json structure (append only)
- NEVER write execution-log entries for phases you did not execute
# TIMEOUT_INSTRUCTION
Target: 30 turns max. If approaching limit, COMMIT current progress.
If GREEN complete (all tests pass), MUST commit before returning — even at turn limit.
Configuration:
- subagent_type: extracted agent name
- Turn limits are defined in each agent's
maxTurnsfrontmatter field (not as a tool parameter)
Error Handling
- Invalid Agent — Report available agents from the agent registry. Gate: error message returned, no invocation attempted.
- Missing Context Files — Report exact path not found for roadmap or execution-log. Gate: clear path reported.
- Step Not in Roadmap — Report available step IDs from roadmap. Gate: list of valid IDs returned.
- Dependency Failure — Explain which blocking tasks are incomplete. Gate: blocking step IDs named explicitly.
Resume vs Restart
When subagent times out:
| Last Completed Phase | Action | Rationale |
|---|---|---|
| GREEN (or later) | Resume | Only COMMIT remains (~5 turns) |
| RED_UNIT with partial GREEN | Resume | Preserves implementation progress |
| PREPARE or RED_ACCEPTANCE | Restart | Little context worth replaying |
Resume costs ~50% more tokens/call due to context replay (measured: 3.7K vs 2.5K tokens/call). For <5 remaining turns, resume is efficient. For 15+ turns, restart is cheaper.
Examples
/nw-execute @nw-software-crafter "des-us007-boundary-rules" "02-01"
/nw-execute @nw-researcher "auth-upgrade" "01-01"
/nw-execute @nw-software-crafter "des-us007" "03-01" # retry after failure
TDD_PHASES
{{MANDATORY_PHASES}}
Success Criteria
- Agent invoked via Agent tool (dispatcher does not execute the work)
- Step context extracted from roadmap and passed in prompt
- Agent appended phase events to execution-log.json
- Agent did not load roadmap.json
Next Wave
Handoff To: /nw-review for post-execution review Deliverables: Updated execution-log.json|implementation artifacts|git commits
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
nw-research
Gathers knowledge from web and files, cross-references across multiple sources, and produces cited research documents. Use when investigating technologies, patterns, or decisions that need evidence backing.
nw-distill
Acceptance test creation methodology for the DISTILL wave. Domain knowledge for the acceptance designer agent: port-to-port principle, prior wave reading, wave-decision reconciliation, graceful degradation, and document back-propagation.
nw-review-output-format
YAML output format and approval criteria for platform design reviews. Load when generating review feedback.
nw-ddd-tactical
Tactical DDD — aggregate design rules, entities, value objects, domain events, repositories, domain services, and anti-pattern detection
nw-infrastructure-and-observability
Infrastructure as Code patterns (Terraform, Kubernetes), observability design (SLOs, metrics, alerting, dashboards), and pipeline security stages. Load when designing infrastructure, observability, or security scanning.
nw-par-critique-dimensions
Platform design review critique dimensions and severity levels. Load when reviewing CI/CD pipelines, infrastructure, deployment strategies, observability, or security designs.
Didn't find tool you were looking for?