| name | suggest-power-tools |
| description | Use when asked to systematically audit, review, reconcile, migrate, or weed out issues across many files or items, when work will recur or needs babysitting, or whenever a task fits a Codex power tool the user didn't ask for by name - subagent fan-out (audits, repo-wide sweeps, judge panels, adversarial verification), /goal (a multi-turn mission lacking a verifiable finish line), an Automation or codex exec cron (polling, recurring or deferred obligations), capturing a just-invented technique as a skill or a recurring role as a custom agent, a lifecycle hook for "from now on, when X..." patterns, a decision-log entry for a durable principle, or effort recalibration (model and reasoning depth, /fast, review depth) when task gravity doesn't match the approach. Noticing is the job - propose the tool with an honest cost sketch during ANY substantive task whose shape matches, including "how do we do this thoroughly/across the board" asks. |
Opportunity Scout (Codex)
Codex 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 subagents, goals, automations, 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" | Subagent fan-out | references/subagents.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 | Automation / cron | references/automations.md |
| We just did something the hard way that will recur: invented a pipeline, corrected the same mistake twice, built a reusable recipe - or kept re-describing the same specialist role to subagents | Skill / custom-agent capture | references/skill-creation.md |
| "From now on, when X..."; the user (or you) keeps manually repeating a step after a trigger event | Lifecycle hook | references/hooks.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 - deep reasoning 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 subagent audit whose completion condition becomes a /goal, or a recurring audit that graduates into an Automation). Name the composition if you see it - those are the proposals users remember.
