| name | subagent-make |
|---|---|
| description | Build a work slice by delegating independent implementation slices to subagents, then integrating and verifying the result through one top-level agent. Use when the user invokes /subagent-make or $subagent-make, asks for subagents to build a feature, requests parallel implementation, or wants a coordinated multi-agent build with a final integrated delivery. |
Use independent implementation subagents to build different parts of a work slice, then produce one coherent integrated result. The parent agent is the orchestrator and integrator: resolve the target, write the build contract, assign non-overlapping slices, inspect all builder output, integrate the final working tree, verify behavior, and report the delivery.
- Spawn subagents only when the user explicitly invokes this skill or explicitly asks for subagents, delegation, or parallel implementation.
- The top-level agent owns the final result. Do not let the delivery become a concatenation of builder reports.
- Prefer isolated worktrees, branches, or patch outputs for builders. Do not let multiple builders edit the same working tree in parallel.
- Start builders from the same clean base context. Builders should not depend on other builders' intermediate work.
- Preserve user changes in the working tree. Inspect dirty state before delegation and do not overwrite unrelated edits.
- Do not blindly merge builder output. Inspect diffs, reject weak work, rewrite when needed, normalize style, and verify after integration.
- Do not commit, push, merge remote branches, install dependencies, mutate global state, access production systems, or start long-running services unless the user explicitly asked or the build contract permits it.
- If fewer than six subagents can be used, say so, run the maximum practical number, and keep the slices distinct.
First resolve what to build. Accept, in order:
- A user-provided work slice or implementation brief.
- A GitHub issue, Linear ticket, PRD, or spec.
- A local TODO, planning document, or architecture note.
- A plain user request, if it can be converted into clear acceptance criteria.
If the target lacks acceptance criteria, first clarify or write a short implementation brief before spawning builders. Do not let subagents independently infer different products.
Collect enough context before spawning:
- The goal, non-goals, acceptance criteria, and expected user-visible behavior.
- Relevant files, ownership boundaries, architecture notes, and repo guidance such as
AGENTS.md,CLAUDE.md,CONTRIBUTING.md, docs, and test conventions. - Current branch, intended base, dirty working tree status, and unrelated user edits to preserve.
- Available test, lint, typecheck, build, and smoke commands.
- Constraints around dependencies, migrations, external systems, feature flags, compatibility, and rollout.
Before spawning builders, define a shared build contract:
- Goal and non-goals.
- Acceptance criteria.
- Slice boundaries, expected ownership, and shared coordination points.
- Shared interfaces, data shapes, routes, schemas, or contracts.
- Coding conventions and existing patterns to preserve.
- Allowed commands and sandbox/network limits.
- Test and verification expectations.
- Integration order, if known.
Builders may propose contract changes if they find a blocker, but they must not silently diverge from the contract.
Use up to six builders, based on the work rather than a fixed quota. Prefer fewer builders when the work cannot be split cleanly.
Prefer slices in this order:
- User-visible behavior or acceptance-criteria slices.
- Bounded components or modules with clear ownership.
- Backend, API, frontend, data, test, or documentation slices.
- Exploratory spike slices only when uncertainty blocks implementation.
Use dynamic builder roles first. Fall back to these archetypes when useful:
- Foundation and contracts.
- Backend or domain logic.
- Frontend or UI.
- Data, migrations, or persistence.
- Tests and verification.
- Documentation and developer experience.
Mark shared files as coordination points. Builders may touch shared files only when their slice requires it, and they must call that out in their report. If dependencies exist between slices, sequence the work or make the dependency an explicit shared contract before spawning.
Give each builder a self-contained prompt with:
- The build target and shared build contract.
- Its assigned slice, acceptance criteria, boundaries, and coordination points.
- The base branch, worktree/branch/patch instructions, and how to inspect relevant code.
- Explicit constraints on edits, commands, dependencies, network, services, commits, and destructive actions.
- The expected tests or checks for that slice.
- A requirement to report assumptions, conflicts, and gaps.
- The exact output format below.
Use implementation-capable subagents when available. Do not duplicate the same slice across builders unless asking for alternatives in explicit planning or spike mode.
Each builder must return:
Slice: <assigned slice>
Status: complete | partial | blocked
Verdict: <one sentence>
Changes:
- <file or area changed>: <what changed>
Acceptance criteria covered:
- <criterion or "None">
Tests/checks:
- <command or check>: <result, or "not run" with reason>
Integration notes:
- <ordering, shared files, conflicts, migrations, generated files, or "None">
Risks/gaps:
- <known gap, assumption, follow-up, or "None">
Patch/branch/worktree:
- <reference to branch, worktree, patch, or "n/a">
- Resolve the build target and gather context.
- Inspect repo guidance, current branch, dirty state, and available verification commands.
- Define the build contract and slice plan.
- Choose up to six independent builders based on the slice plan.
- Spawn builders in parallel when slices are independent and isolation is available.
- If isolation is unavailable, use patch-producing builders or single-agent fallback.
- While builders run, inspect only orchestration-level context such as repo docs, integration points, and verification setup. Avoid duplicating a builder's assigned implementation.
- Collect builder reports and inspect every resulting diff or patch.
- Integrate foundational and shared-contract changes first, then independent slices.
- Reconcile conflicts manually. Drop duplicated, weak, or incompatible work instead of forcing it in.
- Run relevant checks after risky integrations and the broad final verification pass when available.
- Do a focused integrator self-review against the acceptance criteria, likely conflict points, and user-change preservation.
- Produce one final delivery report.
Classify the integrated result honestly:
- complete: all acceptance criteria are met.
- partial: useful slices are integrated, but listed gaps remain.
- blocked: no coherent integration is possible without user input or external change.
Partial integration is allowed only when the integrated work is independently useful and does not misrepresent the acceptance criteria. Do not hide failed slices behind a normal success summary.
Honor explicit user modes:
- build: default; decompose, delegate, integrate, verify, and report.
- plan: produce the build contract and delegation plan only.
- full: final delivery plus concise per-builder appendix.
- patches-only: builders produce isolated patches and reports; the parent does not integrate unless the user asks.
- single-agent-fallback: use the same contract, slice, integration, and verification discipline without spawning subagents.
Default to build unless the user asks otherwise.
Use this structure:
Changes
- <integrated change summary>
Verification
- <tests/checks run and result>
Builder Notes
- <important integration notes, failed slices, or omitted in default mode when not relevant>
Residual Risk
- <known gaps, skipped checks, assumptions, or "No material residual risk identified.">
Summary
<one short paragraph with what was delivered and whether anything remains.>
In default mode, omit detailed per-builder notes unless they affect the result. In full mode, include a concise per-builder appendix after the final delivery.