Define standardized subagent usage guidance (instructions/skills/hooks)

[tim-codes]

Goal

Define instructions/skills/hooks (exact mechanism TBD) that describe desired, standardized usage of subagents (Task/Agent tool, forks, Workflow orchestration) balanced across effectiveness, speed, and token-efficiency. Currently this is left to per-session judgment call, which is inconsistent across projects and accounts.

Status: backlog / pending — leaving open for later definition. Notes below are just things that occurred to me while filing this, not a spec.

Rough scope to define later

• When to delegate at all vs. just do it inline (cost of spinning up an agent vs. keeping it in main context)
• Fork vs. fresh agent: fork inherits context (cheap, shares cache) but only when the intermediate output isn't worth keeping; fresh agent for genuinely independent/isolated work
• When parallel fan-out (multiple agents in one message) is worth the token overhead vs. sequential
• Workflow tool (deterministic multi-agent orchestration) — currently gated behind explicit opt-in ("ultracode" or explicit ask) per global tool instructions; worth deciding if/where a project should lower that bar by default
• Reasoning effort / model tier selection per subagent (when to downgrade for cheap mechanical work vs. keep parity with parent)
• Prompt-writing standard for delegated agents: how much context to inline vs. assume, since fresh agents have zero memory of the parent conversation
• Where this guidance should live: global personal CLAUDE.md, a skill (e.g. an subagent-usage skill), a hook, or split by account/project
• Interaction with existing global instructions (repo command runner, explicit targeting, git branch workflow) — subagents should inherit these, not rediscover them per-invocation
• Some way to measure/audit whether the guidance is actually reducing token spend or agent-sprawl over time, not just aspirational

Non-goals for this issue

Not implementing anything yet — just tracking that this needs definition, with Tim to provide the actual policy/preferences later.