Can Four Sub‑Agents Ship a Feature Overnight? A Deep Dive into the 4‑Agent Pipeline vs Superpowers

Agent Context Choking Problem

Many developers use Claude Code, Cursor, or Codex in a single long session that handles requirement understanding, code reading, implementation, testing, test fixing, and PR creation. After a couple of hours the agent starts repeating rejected solutions, forgetting test cases, and re‑reading files it has already processed. zodchiii diagnoses that packing planning, coding, testing, and review notes into one context window causes quality to collapse, whereas keeping four specialists in narrow contexts remains much more stable. This insight has appeared in AutoGen, CrewAI, and LangGraph, but most developers have not applied it to their daily coding tools.

Minimal Recipe: Four Files + One Command

zodchiii’s solution relies only on Claude Code’s built‑in sub‑agent capability, four markdown files, and a slash command. The core mechanism is the handoff file : each agent writes its output to a fixed path, and the next agent reads only that file, preventing contamination from previous reasoning.

.pipeline/
├── spec.md            # Planner output
├── changes.md         # Coder output
├── test-results.md    # Tester output
└── review.md          # Reviewer output

The four agents have strict responsibilities:

Planner (model: opus) reads, greps, glob, writes; writes a detailed spec.md that a junior engineer can follow.

Coder (model: sonnet) reads spec.md, writes implementation to changes.md.

Tester (model: sonnet) reads changes.md, writes tests, runs them, and must stop on failure.

Reviewer (model: opus) read‑only; inspects git diff plus all handoff files and decides SHIP / NEEDS WORK / BLOCK.

Key details:

Planner and Reviewer use opus for higher‑quality judgment; Coder and Tester use the cheaper sonnet model.

Tester cannot modify code; it only writes test-results.md and halts on failure, ensuring the reviewer sees the real problem.

Reviewer tools are read‑only, preventing it from “fixing on the fly.”

The orchestrator is a slash command .claude/commands/ship.md that sequentially invokes the four sub‑agents, proceeding to the next stage only after the handoff file for the current stage exists.

/ship add ratelimiting to login endpoint

How Superpowers Solves the Same Problem

Superpowers, created by Jesse Vincent and integrated into the Claude plugin marketplace, flips the approach: instead of a fixed pipeline, it teaches agents a set of 14 skills so they decide when to spawn sub‑agents.

brainstorming/                       # clarifies vague requirements
writing-plans/                       # breaks spec into executable steps for a junior engineer
test-driven-development/             # enforces RED → GREEN → REFACTOR
subagent-driven-development/         # creates a new sub‑agent per task with two review rounds
dispatching-parallel-agents/         # parallel dispatch for independent tasks
executing-plans/                     # sequential execution without sub‑agents
verification-before-completion/      # final verification step
requesting-code-review/              # proactively opens a review sub‑agent
receiving-code-review/               # processes review feedback
finishing-a-development-branch/      # final branch cleanup
systematic-debugging/                # four‑stage bug localization
using-git-worktrees/                # multi‑branch parallelism
writing-skills/                      # authoring new skills
using-superpowers/                   # meta‑skill that defines how other skills are triggered

The core is the subagent-driven-development skill: each task spawns a fresh sub‑agent and runs two review rounds—first for spec compliance, then for code quality. Unlike the fixed four‑agent roles, Superpowers lets each task contain a full implementation‑plus‑double‑review loop.

Two Paths for the Same Problem

Form : 4 fixed sub‑agents + 1 slash command vs. 14 skills with autonomous composition.

Trigger : explicit /ship <feature> command vs. automatic skill activation based on task needs.

Context Isolation : handoff files (spec/changes/…) vs. a new sub‑agent per task with two review rounds.

Model Allocation : opus for Planner/Reviewer, sonnet for Coder/Tester vs. no hard assignment; the agent chooses.

Testing Discipline : Tester must stop on failure vs. TDD skill enforces RED → GREEN → REFACTOR.

Review Discipline : read‑only Reviewer vs. double review (spec compliance then code quality).

Learning Curve : one‑post copy‑paste vs. understanding boundaries of 14 skills.

Suitable Scenarios : single feature, repeatable runs vs. end‑to‑end methodology from requirement to merge.

Environment Dependency : only Claude Code sub‑agents + slash command vs. best on a harness that supports skills (Claude Code, Codex, Copilot CLI).

My Choice

In practice the two approaches are not alternatives but can be nested. For a single well‑defined feature, start with zodchiii’s four‑agent pipeline to guarantee safety, and inside the Planner/Coder stages inject Superpowers skills such as brainstorming, writing-plans, and test-driven-development to improve quality.

For one clear feature:
└── Use the four‑agent pipeline as a safety net.
    └── Within Planner/Coder, enable Superpowers skills (brainstorming, writing‑plans, TDD) for higher quality.

Specific recommendations:

Planner: load brainstorming and writing-plans to produce a detailed spec.

Coder: load test-driven-development to follow RED → GREEN.

Tester: keep the “stop on failure” rule to avoid hidden bugs.

Reviewer: add Superpowers requesting-code-review for a two‑layer review (spec compliance then code quality).

If you just want a quick one‑night experiment, start with the minimal four‑agent recipe. For long‑term control of a repository, install Superpowers and let its skills trigger automatically in each session.

Easy‑to‑Miss Details

Never skip the handoff file; the orchestrator checks its existence before moving to the next stage.

Prevent the Tester from modifying code; otherwise it may silently make tests pass without fixing the underlying issue.

Read‑only tools for Reviewer are crucial; they enforce a strict separation of judgment and modification.

Use opus for judgment‑heavy tasks (Planner, Reviewer) and sonnet for execution‑heavy tasks (Coder, Tester) to balance cost and quality.

Avoid merging directly to the main branch; the pipeline stops at a “leave the branch for morning review” step because automatic merging remains risky.

Written for Sleep‑Deprived Developers

Both approaches aim to transfer human engineering discipline into agents: spec files become PRDs, changes.md becomes PR description, test-results.md becomes CI reports, and review.md becomes senior engineer comments. Treat agents as tireless interns that follow strict rules; they won’t replace a full‑night solo sprint, but they can reliably execute disciplined steps.