Opportunity Scout
Claude Code has force-multipliers the user cannot be expected to reach for, because they think in terms of their problem ("are all these endpoints consistent?", "ugh, waiting on CI again", "we keep making this mistake") - not in terms of orchestration, goals, loops, hooks, or skills. The scout's job: notice when the current task's shape matches one of these tools, and surface it at the right moment with an honest pitch. The user decides.
Shared etiquette (applies to every scout)
- One proposal per opportunity per task. If declined or ignored, drop it without ceremony and do the work inline well. A scout that nags gets ignored, then disabled.
- Never stack proposals. If two scouts fire on the same moment, pick the strongest and stay quiet about the rest.
- Propose at a seam, not mid-execution - when the shape becomes clear enough to sketch concretely, typically just before the heavy part would begin.
- Be honest about cost. Token spend, setup time, maintenance burden - the user is deciding whether the multiplier pays for itself. Don't lowball to get a yes.
- Enthusiasm is not approval. "Great idea" about the design is not "go". Each reference defines its action policy - most are propose-only; only act where the policy explicitly says so.
- The proposal is itself a thinking step. Articulating the pipeline/condition/trigger forces clarity, and the user can correct the shape before anything runs. Even a declined proposal usually paid for itself.
Recognition routing
When the current work matches a row, read that reference for the per-type recognition signals, action policy, and proposal template:
| Shape you're seeing | Scout | Reference |
|---|---|---|
| Same operation/question across many units; audit or consistency passes; findings that need adversarial verification; whole-repo sweeps; "systematically", "across the board", "weed out" | Workflow | references/workflow.md |
| Several separable, long-lived tracks that must negotiate an evolving shared contract; cross-layer feature builds where each track is owned and steered in parallel; wanting to answer several agents at once instead of one thread at a time | Agent teams | references/agent-teams.md |
| A multi-turn mission with mushy success criteria; "keep going until it works"; work that will drift without a fixed finish line | Goal | references/goal.md |
| Babysitting: waiting on CI/deploys/external processes; "check back later"; "remind me"; recurring chores | Loop / Schedule | references/loop-schedule.md |
| We just did something the hard way that will recur: invented a pipeline, corrected the same mistake twice, built a reusable recipe | Skill capture | references/skill-creation.md |
| "From now on, when X..."; the user (or you) keeps manually repeating a step after a trigger event | Automation hook | references/automation-hook.md |
| A durable design principle just crystallized in conversation; a previously locked decision got revised | Decision log | references/decision-log.md |
| The task's gravity doesn't match the effort being applied - heavy models grinding rote work, or a subtle/critical change getting a quick skim; the user says "thoroughly", "quick pass", "don't overthink" | Effort calibration | references/effort.md |
The strongest opportunities are often compositional (e.g. a workflow whose completion condition becomes a /goal). Name the composition if you see it - those are the proposals users remember.
