Lifecycle Integration

In one line: Skills connect through versioned artifacts and evidence; selected delegation separates task ownership and review, without guaranteeing independent reasoning.

The five 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

Persist load-bearing outputs in the approved record system and bind their exact revisions at handoff. Repository files can carry designs and source changes; sensitive test or review evidence may need access-controlled storage with references. A skill transition or filename alone is not an audit receipt, and not all output belongs in Git.

Subagent-Driven Development

When delegation is selected and permitted, use three logical roles (detailed in §5.4). These are responsibilities, not a mandatory agent count:

1. Orchestrator (human or primary session) — reads the plan, assigns ownership, reviews returned evidence and coordinates integration. May implement locally where delegation is unavailable, disallowed or inefficient; required separate review still applies.
2. Implementer (subagent) — receives one task with its context, implements (TDD or code-first), verifies, reports. Builds what it is directed to build.
3. Reviewer (agent) — checks output for spec compliance and code quality. Validates; does not implement.

This separation can expose errors missed by the implementer. It does not remove shared assumptions or supply business/release authority; assess the candidate against independent expectations.

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
New project or new bounded context	Inception Cycle	§3.6 (arc42 canvas + ≥3 QA scenarios + risk-storm + threat enumeration + ≥1 fitness function), before the first feature's full cycle
Bug report or test failure	Bug Fix Cycle	/systematic-debugging
Production incident or live fault	Incident-Response Cycle	runbook incident roles → authorized safe mitigation → reproduce → root-cause → regression-pinning test
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	Effect-based routing	Editorial-only changes may be direct; changed business meaning, policy, access or protected outcomes need the applicable design/amendment approval

---