full-use-subagent

name

full-use-subagent

description

Use as much available AI subscription quota and parallel subagent capacity as possible for general software development tasks. Use when the user explicitly invokes $full-use-subagent or asks to start a task, implement a feature, fix a bug, refactor, test, review, or complete coding work with maximum subagents, full delegation, more AI quota, faster delivery, or best quality regardless of token use. The skill stays general-purpose, adaptively fills available lanes with explorers, workers, verifiers, reviewers, and fixers, and keeps the main agent responsible for integration and final quality.

Full Use Subagent

Purpose

Use the maximum useful number of specialized subagents allowed by the current coding IDE or agent platform for almost any software development task. The controller agent keeps ownership of the outcome, while subagents use available subscription capacity to improve elapsed time, coverage, and quality.

This skill assumes the user explicitly asked for full subagent usage, delegation, parallel agent work, or invoked $full-use-subagent. If that is not true, do not spawn subagents.

Operating Principles

• Own the result in the controller session. Subagents help; they do not transfer responsibility.
• Do the critical-path work locally. Delegate sidecar work that can run in parallel while the controller keeps moving.
• Default to maximum concurrency. Use as many concurrent subagents as the current IDE or platform permits.
• Do not optimize for token consumption. Spend extra model calls on exploration, verification, review, and alternate hypotheses when they can improve quality or speed.
• Stay general. Adapt the swarm shape to the task instead of forcing a fixed feature-development template.
• Split by the best available boundary: files, modules, tests, docs, investigation questions, runtime behavior, risk areas, or review angles.
• Give every subagent complete task-local context. Do not make it infer hidden goals from the conversation.
• Workers are not alone in the codebase. Tell them not to revert or overwrite others' edits and to adapt to concurrent work.
• Review all returned changes before integration. Never trust a success report without inspecting code and running verification.
• Avoid duplicate writers on the same files. If write scopes overlap, keep extra agents read-only or verification-focused instead of stopping the whole swarm.
• Ask only blocking questions. When a conservative repo-native choice is available, choose it and keep working.

Capacity Policy

• Treat this skill as full-use mode by default.
• Determine the host's practical parallel subagent capacity from the current IDE, CLI, or available tool limits when possible.
• If the exact cap is unknown, keep spawning well-scoped agents until the platform stops accepting more or the task has no remaining useful read, write, verify, review, or fix lanes.
• Fill implementation lanes first, one worker per disjoint write scope.
• Fill remaining lanes with read-only explorers, spec reviewers, quality reviewers, test verifiers, docs/checklist reviewers, security/risk reviewers, or targeted fixers.
• Do not duplicate two workers on the same write scope. Extra capacity should become independent verification or review, not competing edits.
• When a platform has a known max, aim for that max. If fewer implementation lanes exist, use the remaining capacity for deeper inspection, adversarial review, more test coverage, or alternate root-cause analysis.
• Do not let "the split is not perfect" become a blocker. Use imperfect but safe lanes and integrate carefully.

Quick Workflow

1. Triage

   • Restate the goal in practical terms and infer acceptance criteria when the user was brief.
   • Inspect repo shape, git status, scripts, and likely touch points just enough to seed useful agents.
   • Decide the immediate local task on the critical path.
   • Identify all sidecar tasks that can run without blocking the local task.

2. Map

   • Dispatch enough explorer subagents to cover the uncertain parts of the task: architecture, tests, conventions, entry points, risks, data flow, UI behavior, APIs, or dependencies.
   • Continue local inspection while explorers run.
   • Convert findings into a flexible work split with the clearest available ownership boundaries.

3. Dispatch

   • Dispatch workers only for disjoint write scopes, then fill remaining capacity with verifiers and reviewers.
   • Include exact goals, owned paths, forbidden paths, test commands, and expected report format.
   • Ask each worker to edit files directly in its forked workspace and list changed paths.
   • Use verifier or reviewer agents after there is something concrete to check.

4. Integrate

   • Read subagent summaries and inspect their diffs.
   • Merge or manually port only the changes that fit the final design.
   • Resolve conflicts in the controller session.
   • Run targeted tests, then the broadest relevant verification that is practical.

5. Close

   • Fix failures locally or dispatch a targeted fix agent with the failing command and logs.
   • Run final verification.
   • Give the user a concise summary: what changed, tests run, residual risks.

Swarm Shapes

Discovery Swarm

Use when the task is unclear or the codebase is unfamiliar.

• Explorer: locate entry points and data flow.
• Explorer: locate tests, fixtures, and existing conventions.
• Explorer: identify risks, migrations, generated files, or integration points.
• Explorer: map frontend/UI surfaces, routes, or user workflows.
• Explorer: map API, persistence, background jobs, or external services.
• Explorer: inspect build, lint, typecheck, and release scripts.
• Controller: keeps moving on setup, scripts, and first local hypothesis.

Implementation Swarm

Use when the work splits cleanly.

• Worker: owns one module, component, route, or service.
• Worker: owns another disjoint module, component, route, service, or test area.
• Worker: owns docs, fixtures, migrations, or non-overlapping support files when needed.
• Verifier: prepares or runs verification that does not fight worker edits.
• Reviewer: starts reviewing completed worker diffs as soon as they land.
• Controller: integrates, handles shared code, and runs final tests.

Review Swarm

Use after implementation or before shipping.

• Spec reviewer: checks that the code matches the user request.
• Quality reviewer: checks maintainability, bugs, edge cases, tests, and security.
• Verifier: runs commands or inspects runtime behavior.
• Controller: decides what to fix and verifies the final state.

Flexible Fallbacks

Avoid write-parallelism, but still use subagents if helpful, when:

• The next step depends on one unknown result. Use explorers first.
• Multiple workers would edit the same files or generated outputs. Use one writer plus reviewers/verifiers.
• The task needs one coherent design decision before code changes. Use parallel design scouts, then decide locally.
• The user asked for review only. Use multiple reviewers/verifiers, but avoid implementation unless requested.
• The environment cannot support subagents. Execute locally with a todo list and say delegation is unavailable.

Dispatch Rules

Before spawning, write a compact work split:

Controller local task:
- ...

Subagent lanes, filled to the current platform maximum:
- explorer-a: read-only, answer ...
- worker-a: write scope ..., avoid ...
- verifier-a: run/check ...
- reviewer-a: inspect ...

For coding workers, use a prompt based on references/prompts.md. Always include:

• The user goal and acceptance criteria.
• Relevant repo facts and commands discovered by the controller.
• Owned write paths and paths they must avoid.
• Expected verification command.
• Report format: status, changed files, tests run, risks.
• Reminder that other agents may be working concurrently.

Waiting Strategy

• Do not wait immediately after dispatch unless the next local step is blocked.
• While agents run, continue non-overlapping local work.
• Wait when integration depends on returned patches or answers.
• Close agents that are no longer needed.

Integration Checklist

• Inspect git status and each changed file.
• Confirm no worker reverted unrelated user or agent changes.
• Confirm the implementation still matches the requested scope.
• Run targeted tests for touched areas.
• Run lint/typecheck/build/full test suite when practical for the repo.
• For frontend changes, start the dev server when needed and verify the UI with an appropriate browser or screenshot workflow.
• If verification cannot run, explain exactly why.

Prompt Templates

Read references/prompts.md when composing explorer, worker, verifier, reviewer, or fix-agent prompts.