Lifecycle Integration
In one line: Skills chain output-to-input through committed files; subagent-driven development runs one fresh agent per task so context never pollutes across tasks.
The three lifecycle patterns integrate through two mechanisms: the Superpowers skill system and the subagent-driven development model.
Skill Chaining
Each Superpowers skill produces output that serves as input for the next skill in the lifecycle:
| Skill | Output | Consumed By |
|---|---|---|
/brainstorming | Problem analysis, candidate approaches | /writing-plans |
/writing-plans | One design artifact: specification + ordered task list | /test-driven-development or /executing-plans |
/test-driven-development | Implemented code with passing tests | /verification-before-completion |
/systematic-debugging | Root cause analysis, reproduction steps | /test-driven-development (for the fix) |
/verification-before-completion | Verified completion evidence | /requesting-code-review |
/requesting-code-review | Review findings and dispositions | /finishing-a-development-branch or back to implementation |
/finishing-a-development-branch | Merged branch, updated documentation | Next task or session end |
The skills do not share state directly. Each skill operates on files (source code, design documents, plan files, test output) that persist in the repository. This file-based integration means that skill transitions are auditable — the design document, the plan, the test output, and the review findings are all committed artifacts that can be inspected after the fact.
Subagent-Driven Development
Subagent-driven development is the default execution model: a fresh subagent per plan task, so context from earlier tasks does not pollute later ones. Three roles (detailed in Section 5.4):
- Orchestrator (human or primary session) — reads the plan, dispatches per task, reviews output between tasks, decides proceed-or-revise. Directs and reviews; does not implement.
- Implementer (subagent) — receives one task with its context, implements (TDD or code-first), verifies, reports. Builds what it is directed to build.
- Reviewer (agent) — checks output for spec compliance and code quality. Validates; does not implement.
This separation of concerns prevents the common failure mode where a single session accumulates bias toward its own implementation and loses the ability to critically evaluate its own output.
When to use /executing-plans instead: Use a single session working sequentially when subagent dispatch is impractical — parallel sessions already running, a plan of 3 or fewer low-complexity tasks, or tightly coupled tasks that repeatedly modify the same code. The choice is pragmatic, not a quality decision: both paths converge at the same verification and review gates.
Lifecycle Transition Triggers:
| Trigger | Lifecycle | Entry Point |
|---|---|---|
| New feature request or architectural change | Full Cycle | /brainstorming |
| Bug report or test failure | Bug Fix Cycle | /systematic-debugging |
| Pull request from another developer | Code Review Cycle | Stage 1: Spec Compliance |
| Refactoring initiative | Full Cycle (abbreviated) | /writing-plans (skip brainstorm if scope is clear) |
| Dependency update or migration | Full Cycle | /brainstorming (if breaking changes) or /writing-plans (if straightforward) |
| Documentation update | Direct implementation | No lifecycle required for content-only changes |