A map for splitting work across subagents

1. When to split

• Research brings a lot of noise before there is a decision.
• Code review needs distance from writing the code.
• One task needs a risky tool that should not be open to everyone.
• You need a second opinion without polluting the main context.

2. When not to split

• The task is small and can finish in one conversation.
• The split creates more management than the work itself.
• You need one change in one file.
• There is no clear way to check the subagent's output.

3. Contract for a subagent

Task: [what to research / check / build]

Boundaries:
- Do not change files outside [scope]
- Do not touch [forbidden area]

Allowed tools:
- [tools]

Output:
- One clear decision
- Short evidence
- Files you touched, if any
- Open risk, if any remains

Do not return:
- A long summary
- Noise that does not change the decision

4. What returns to the main conversation

• One decision.
• The strongest piece of evidence.
• A recommendation for the next action.
• A warning if there is risk.