/iterative-development

name: iterative-development
description: Use when implementing a project with a large, comprehensive, or ambiguous spec — extracts requirements with proof obligations, defines a walking skeleton with its first journey scenario, then loops through audited sprints that continuously build a behavior evidence corpus. Completion means passing evidence, not just finished stories.

Iterative Development

Overview

Orchestrator for the iterative-development plugin. Drives the full autonomous lifecycle: extract requirements with proof obligations and behavior scenarios from human spec collateral, define a walking skeleton that passes its first journey scenario, then loop through audited sprints that continuously build a reusable behavior evidence corpus. Completion means the product has passing behavior evidence at the correct seam for every externally observable requirement — not just that stories are marked done. Every evaluative gate uses parallel adversarial review (PAR).

This is an alternative to `superpowers:writing-plans → superpowers:subagent-driven-development` for projects where the upfront-planning approach would lose the plot.

When to Use

• Spec is large, comprehensive, or ambiguous (10+ files, 100+ requirements)
• You need the product to be in a working, testable state at every iteration boundary
• You want an autonomous audited loop rather than a single upfront plan
• The writing-plans flow has lost the plot on this project before

Do NOT use for small, bounded projects — `superpowers:writing-plans → superpowers:subagent-driven-development` is simpler and more appropriate.

The Autonomous Loop

Bootstrap (first invocation)

1. Check `docs/superpowers/iterations/` for existing state. If found, skip to **Resume** below. 2. Invoke `extracting-requirements` on the human-provided spec path.

• Chunks the spec, classifies by taxonomy (journeys → E2E, domains → integration, etc.)
• Dispatches parallel extraction subagents that produce stories with proof obligations AND behavior scenarios
• Aggregates stories into per-epic files, scenarios into behavior-scenarios.md
• Builds coverage ledger with both story AND scenario coverage
• Produces `docs/superpowers/iterations/requirements/`, `docs/superpowers/iterations/behavior-scenarios.md`, `docs/superpowers/iterations/behavior-corpus.md`

3. Invoke `scoping-the-simplest-core` on the resulting backlog.

• Defines the walking skeleton iteration (ITER-0000) + ordered follow-on iterations
• Runs citation check + PAR scope review
• Produces `docs/superpowers/iterations/roadmap.md`
• Walking skeleton must close at least one journey scenario (not just compile)
• Applies story splitting when stories have heterogeneous-dependency ACs

Main loop

while True:
    check_for_human_interrupt()

    if not roadmap has pending iterations:
        if last audit was clean:
            run final behavior-evidence audit (see below)
            if behavior audit clean:
                break  # done
            # else: audit found uncovered surfaces or weak evidence, new iterations added
        # else: audit found gaps, new iterations were added, continue

    run next iteration:
        - running-an-iteration (sentinel baseline → scope review → decompose code + evidence tasks → implementing-tasks → impacted + sentinel scenario runs → wrap up)
    
    audit:
        - auditing-progress (PAR paired auditors, three-tier: deep evidence + impacted behavior + sentinel corpus)
        - if gaps: append to backlog, revise roadmap, continue
        - if clean: mark last_audit_clean, continue

Final behavior-evidence audit

Before declaring the project complete, verify that the product has adequate behavior evidence — not just that all stories are marked done:

1. List every major user-facing surface from the original spec (settings panes, UI flows, CLI commands, journeys, etc.) 2. For each surface, verify that:

• Corresponding stories exist AND are implemented
• Corresponding scenarios exist AND have passing evidence at the correct seam
• Journey scenarios that cross multiple surfaces are passing E2E

3. Check the behavior corpus index for completeness:

• Every journey spec file has at least one JOURNEY-NNNN scenario
• Every scenario has a non-TBD execution command
• All sentinel scenarios pass

4. Flag any surface with:

• No corresponding story (extraction under-scoped)
• No corresponding scenario (evidence gap)
• Evidence at a weaker seam than the requirement demands
• Manual-residual scenarios that could be automated

5. If gaps found: create new stories/scenarios/iterations, continue the loop

The final question is: "Can the system point to passing behavior evidence for every externally observable requirement the spec describes?" Not: "Are the stories done?"

Resume (re-invocation with existing state)

All process state lives in artifact files:

• `docs/superpowers/iterations/requirements/` (backlog with story status and proof obligations)
• `docs/superpowers/iterations/behavior-scenarios.md` (scenario cards with stable IDs)
• `docs/superpowers/iterations/behavior-corpus.md` (execution index)
• `docs/superpowers/iterations/roadmap.md` (iteration plan with status)
• `docs/superpowers/iterations/iteration-log.md` (completed iteration history)

On re-invocation: read `roadmap.md`, find the next pending iteration, and continue from there. There is no ephemeral in-memory state to recover. The command "continue iterative development with the existing plan" always works.

If the orchestrator crashed mid-iteration, the partially-completed iteration's git commits are preserved. On resume, the next un-started iteration picks up. If the in-progress iteration left the code in a broken state, treat it as a gap — the audit will catch it and add corrective work.

Human Interrupt Protocol

The loop runs without human intervention. The only way the human injects new information mid-run