Skip to content
Agents Pack

Subagent-driven development

Subagent-driven development

Section titled “Subagent-driven development”

Core pack 0.30.0 adds the optional ap-subagent-driven-development skill, adapted from the MIT-licensed Superpowers workflow.

Use it when you already have a concrete implementation plan and want a coding agent to coordinate fresh task implementers, independent reviews, repair rounds, and a final whole-branch review. The skill is explicit-only: coding agents must not select it automatically for an ordinary implementation request.

When it fits

Section titled “When it fits”

The readiness gate requires:

  • a Git repository with an existing commit;
  • a concrete plan with numbered Task N headings;
  • tasks that can run sequentially or are mostly independent;
  • a provider with isolated subagent contexts; and
  • a clean, dedicated feature branch and linked worktree.

Use a simpler implementation workflow for a small change, an exploratory task, or work without a prepared plan.

Install the skill

Section titled “Install the skill”

Ask your coding agent:

Use ap-manage-agents-pack to preview installing
ap-subagent-driven-development. Wait for my approval, apply it, and verify the
installation.

Or install it directly:

agents-pack install ap-subagent-driven-development --dry-run
agents-pack install ap-subagent-driven-development --yes
agents-pack status

Invoke it explicitly

Section titled “Invoke it explicitly”

Name the skill and the prepared plan:

Use ap-subagent-driven-development to execute the implementation plan at
docs/plans/add-team-invitations.md. Use main as the base branch. Follow the
plan task by task and report the final branch, worktree, commits, verification,
review outcomes, and any unresolved findings. Do not push or open a pull
request.

The controller verifies the plan and repository, then reuses a suitable clean feature worktree or creates one adjacent to the ordinary checkout. Existing uncommitted changes in the ordinary checkout are left alone.

How the workflow runs

Section titled “How the workflow runs”

For each plan task, the controller:

  1. creates a task-specific brief;
  2. dispatches a fresh writable implementer;
  3. requires the implementer to test, self-review, commit only that task, and write a durable report;
  4. dispatches a fresh read-only reviewer for specification compliance and code quality; and
  5. sends confirmed defects through implement-and-re-review rounds before moving to the next task.

Only one writable implementer runs in the worktree at a time. Read-only exploration may run concurrently when it cannot mutate shared state.

After every task is complete, a fresh high-capability reviewer examines the whole branch against the plan and specification.

Commits and authority

Section titled “Commits and authority”

Explicit invocation authorizes local commits for assigned tasks inside the dedicated feature worktree. Those commits give reviewers exact task ranges and make the run resumable.

It does not authorize the workflow to:

  • commit unrelated or pre-existing changes;
  • work on the primary or protected branch;
  • push, merge, publish, deploy, or open a pull request; or
  • perform unrelated destructive, irreversible, or security-sensitive actions.

Authorize those next steps separately when you want them.

Recovery and repair limits

Section titled “Recovery and repair limits”

The controller stores a Git-ignored progress ledger under .agents-pack/runs/subagent-development/. It records task boundaries, commits, review results, repair rounds, decisions, and deferred findings so a compacted or resumed conversation does not repeat completed tasks.

Each task has a five-round repair circuit breaker:

  • rounds 1–3 resume the original implementer;
  • rounds 4–5 use a fresh, more capable implementer; and
  • after round five, remaining findings must be explicitly adjudicated, carried forward, or surfaced as a blocker.

The final whole-branch review allows one scoped repair wave. Unresolved load-bearing findings are reported rather than hidden.

What you receive at the end

Section titled “What you receive at the end”

The final report includes:

  • tasks and local commits;
  • verification performed and any gaps;
  • task-review and final-review outcomes;
  • deferred, parked, or unresolved findings;
  • recorded implementation rulings and their downside if wrong; and
  • the feature branch and worktree location.
Section titled “Related”