How Superpowers Subagent-Driven Development Executes Plans

Mar 18, 2026

The Problem with Long AI Sessions

When I work with AI coding assistants on complex features, I hit a wall. The longer the session, the more confused the assistant becomes. Previous decisions leak into new tasks. Context gets polluted. The AI starts mixing up requirements from task three with task seven.

I’ve seen this pattern repeatedly:

Task 1: Implement user registration
  -> AI understands requirements clearly

Task 3: Add email verification
  -> AI still remembers Task 1 context

Task 7: Implement password reset
  -> AI confused, mixing Task 1 and Task 3 requirements
  -> Bugs appear, wrong assumptions made

The issue isn’t the AI’s capability. It’s context pollution. Every task you complete leaves residue in the session. By task five or six, the AI is working with a muddled mental model.

What I needed was a way to give each task a fresh start, while still maintaining overall coordination. That’s exactly what Superpowers subagent-driven development provides.

What Is Subagent-Driven Development?

Subagent-driven development is a skill in Superpowers that executes implementation plans by dispatching a fresh subagent for each task. After each task completes, two review stages ensure quality before moving on.

The core principle is simple:

Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration

This approach solves the context pollution problem. Each subagent starts with a clean slate, receiving exactly the context it needs for its specific task. No leftover confusion from previous work.

When to Use It

I use subagent-driven development when I have:

An implementation plan with multiple tasks
Tasks that are mostly independent
A desire to stay in the current session

┌─────────────────────────────────────┐
│     Have implementation plan?       │
└─────────────────┬───────────────────┘
                  │
                  ▼
        ┌─────────────────┐
        │ Tasks mostly     │
        │ independent?     │
        └────────┬────────┘
                 │
         ┌───────┴───────┐
         │               │
         ▼               ▼
   ┌──────────┐   ┌──────────────┐
   │   YES    │   │     NO       │
   └────┬─────┘   └──────┬───────┘
        │                │
        ▼                ▼
┌───────────────┐  ┌──────────────────┐
│ Stay in this  │  │ Use executing-   │
│ session?      │  │ plans instead    │
└───────┬───────┘  └──────────────────┘
        │
  ┌─────┴─────┐
  │           │
  ▼           ▼
┌─────┐   ┌─────────────────┐
│ YES │   │       NO        │
└──┬──┘   └────────┬────────┘
   │                │
   ▼                ▼
┌─────────────────┐  ┌──────────────────┐
│ subagent-driven │  │ executing-plans   │
│ development     │  │ (parallel session)│
└─────────────────┘  └──────────────────┘

If my tasks are tightly coupled or I need parallel session execution, I use the executing-plans skill instead.

The Process in Action

Let me walk through how this works in practice.

Step 1: Extract All Tasks

First, I read the plan once and extract all tasks with their full text. I create a TodoWrite to track progress.

## Implementation Plan

### Task 1: Create cache interface (2 min)
- Define CacheProvider interface
- Add get/set/delete methods
- No implementation yet

### Task 2: Implement Redis provider (5 min)
- Install ioredis package
- Implement CacheProvider for Redis
- Add error handling

### Task 3: Write cache middleware (3 min)
- Create middleware function
- Check cache before API call
- Store response in cache after

I extract the full text of each task and any context it needs. This happens once, upfront.

Step 2: Dispatch Implementer Subagent

For each task, I dispatch a fresh implementer subagent with precisely crafted context:

// Controller provides everything the subagent needs
const subagentContext = {
  taskText: "Implement Redis provider...",
  relevantContext: "CacheProvider interface from Task 1...",
  constraints: "Must handle connection errors gracefully",
  // No history from previous tasks
};

The subagent receives complete information without inheriting my session’s history.

Step 3: Handle Questions

Sometimes the implementer needs clarification:

Implementer: "Before I begin - should the hook be installed at user or system level?"

Me: "User level (~/.config/superpowers/hooks/)"

I answer clearly, then let the implementer proceed. This catches ambiguity before work begins, not after.

Step 4: Two-Stage Review

After the implementer completes their work, I dispatch two separate reviewers:

Stage 1: Spec Compliance Review

Spec reviewer: Does the implementation match what the plan specified?

Example output:
- Missing: Progress reporting (spec says "report every 100 items")
- Extra: Added --json flag (not requested)

Status: NOT COMPLIANT

The spec reviewer reads the code independently. It doesn’t trust the implementer’s self-assessment.

Stage 2: Code Quality Review

Code quality reviewer: Is the code well-structured and maintainable?

Example output:
Strengths: Good test coverage, clean separation of concerns
Issues (Important): Magic number (100) should be a named constant

Status: NEEDS FIX

Only after both reviews pass do I mark the task complete.

Step 5: Fix and Re-Review

If either reviewer finds issues, the implementer fixes them and the reviewer checks again:

Code reviewer: Issues (Important): Magic number (100)

Implementer: Extracted PROGRESS_INTERVAL constant

Code reviewer: Approved

This loop continues until both reviewers approve. I never skip the re-review.

Model Selection Strategy

I’ve learned to match model capability to task complexity:

Task Type	Model	Reason
Mechanical implementation (1-2 files, clear spec)	Fast, cheap model	Most tasks are straightforward when well-specified
Integration tasks (multi-file coordination)	Standard model	Needs to understand connections
Architecture, design, review tasks	Most capable model	Requires judgment and broad understanding

This optimization significantly reduces costs without sacrificing quality.

Handling Implementer Status

Implementer subagents report one of four statuses:

DONE: Proceed to review. The task is complete.

DONE_WITH_CONCERNS: The implementer finished but flagged doubts. I read the concerns before proceeding. If they’re about correctness, I address them first.

NEEDS_CONTEXT: The implementer needs more information. I provide the missing context and re-dispatch.

BLOCKED: The implementer cannot complete the task. I assess:

Context problem? Provide more context
Needs more reasoning? Re-dispatch with capable model
Task too large? Break into smaller pieces
Plan wrong? Escalate to human

I never ignore escalations or force the same model to retry without changes.

Why This Matters

After using subagent-driven development, I noticed significant improvements:

Quality: Two-stage review catches issues I would have missed. Spec compliance prevents over-building. Code quality ensures maintainability.

Efficiency: No file reading overhead—the controller provides full text. Questions surface before work begins, not after.

Context hygiene: Each task starts fresh. No pollution from previous decisions. The main agent stays focused on coordination.

Autonomy: The system runs for extended periods without human intervention. Each task completes, reviews, fixes if needed, and moves to the next.

Common Mistakes

DO

Provide complete context to subagents

// CORRECT: Full context for the task
const context = {
  taskText: "Implement Redis cache provider",
  interface: "CacheProvider with get/set/delete methods",
  constraints: "Handle connection errors gracefully",
  existingCode: "See src/cache/interface.ts"
};

Answer subagent questions before they proceed

Implementer: "Should errors be logged or thrown?"

Me: "Log errors at WARN level, return null for cache misses"

Re-review after fixes

Spec reviewer: Missing progress reporting

Implementer: Added progress reporting

Spec reviewer: [Reviews again] Spec compliant now

DON’T

Skip reviews

// WRONG: Skipping spec review to save time
if (implementer.status === 'DONE') {
  markComplete(); // Missing spec and quality review
}

Start code quality review before spec compliance

// WRONG ORDER
dispatchCodeQualityReviewer();
// Spec compliance should come first

// CORRECT ORDER
dispatchSpecReviewer();
if (specApproved) {
  dispatchCodeQualityReviewer();
}

Accept “close enough” on spec compliance

Spec reviewer: Missing progress reporting

Me: "That's fine for now, mark it complete"
// WRONG - spec reviewer found issues = not done

Let implementer self-review replace actual review

Implementer: "I self-reviewed and it looks good"

Me: "Great, mark complete"
// WRONG - both self-review AND external review are needed

A Complete Workflow Example

Here’s what a full session looks like:

Me: I'm using Subagent-Driven Development to execute this plan.

[Read plan file once: docs/plans/cache-feature-plan.md]
[Extract all 3 tasks with full text and context]
[Create TodoWrite with all tasks]

Task 1: Cache interface

[Dispatch implementer with Task 1 text + context]

Implementer: DONE - Created CacheProvider interface with get/set/delete

[Dispatch spec reviewer]
Spec reviewer: Approved - matches spec exactly

[Dispatch code quality reviewer]
Code reviewer: Approved - clean interface, good types

[Mark Task 1 complete]

Task 2: Redis provider

[Dispatch implementer with Task 2 text + context]

Implementer: NEEDS_CONTEXT - "What Redis connection string format?"

Me: "Use REDIS_URL env var, format: redis://host:port"

[Re-dispatch with same model]

Implementer: DONE_WITH_CONCERNS - "Works but not handling cluster mode"
Implementer: "Concern: Adding cluster mode would add complexity"

Me: "Note the concern, but cluster mode is out of scope for this task"

[Dispatch spec reviewer]
Spec reviewer: Issues found:
  - Missing: Connection timeout handling
  - Extra: Added retry logic (not requested)

[Implementer fixes issues]
Implementer: Added timeout handling, removed retry logic

[Spec reviewer reviews again]
Spec reviewer: Approved

[Dispatch code quality reviewer]
Code reviewer: Issues: Hardcoded timeout (5000ms) should be configurable

[Implementer fixes]
Implementer: Made timeout configurable via constructor

[Code reviewer reviews again]
Code reviewer: Approved

[Mark Task 2 complete]

Task 3: Cache middleware
[... continues similarly ...]

[After all tasks]
[Dispatch final code reviewer for entire implementation]

Final reviewer: All requirements met, tests passing, ready to merge

[Use finishing-a-development-branch skill]
Done!

Integration with Other Skills

Subagent-driven development works with other Superpowers skills:

Required:

using-git-worktrees: Set up isolated workspace before starting
writing-plans: Creates the plan this skill executes
finishing-a-development-branch: Complete development after all tasks

Subagents use:

test-driven-development: Each implementer follows TDD

Summary

In this post, I showed how Superpowers subagent-driven development executes implementation plans by dispatching fresh subagents per task with two-stage review. The key point is that isolated context per task prevents confusion while ensuring quality through spec and code review.

The process eliminates context pollution that plagues long AI sessions. Each subagent starts fresh, receives exactly what it needs, and completes its task with proper oversight. The two-stage review catches both spec mismatches and code quality issues before they compound.

If you’re working with complex implementation plans in Claude Code or Cursor, subagent-driven development gives you the discipline of a senior engineer without the overhead of constant human oversight.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!