Subagents

Subagents are useful for parallel discovery, focused implementation, and independent verification. They are not a substitute for ownership in the main session.

Good Subagent Tasks

Good tasks are bounded and self-contained:

• Inspect one subsystem and answer a specific question.
• Implement one slice with a disjoint write scope.
• Run a verification command while the main session continues other work.
• Compare two options and return a recommendation with file references.

Poor tasks are open-ended:

• "Fix the app."
• "Review everything."
• "Make the architecture better."

The main session should decide the shape of the work before delegating.

Prompt Template

You are not alone in this repository.
Own only apps/handbook/e2e/home.spec.ts.
Update tests for English locale availability.
Do not revert changes outside this file.
Return changed files, commands run, and any failures.

That prompt gives scope, ownership, collaboration rules, and output format.

Integration Discipline

When a subagent returns, review its patch as if it came from another engineer:

• Does it satisfy the exact task?
• Did it edit only its assigned files?
• Did it preserve existing user changes?
• Did its verification actually exercise the changed behavior?

If the answer is unclear, inspect the diff before stacking more changes on top.

Failure Modes

• Duplicate exploration wastes time and produces conflicting advice.
• Broad write scopes create merge conflicts.
• Delegating the critical path leaves the main session idle.
• Treating a subagent report as proof without checking risky code hides regressions.

Use subagents to increase throughput, not to avoid judgment.