Suggest Power Tools

interface:
  display_name: Suggest Power Tools
  short_description: Proposes Codex force-multipliers - subagent fan-out, goals, automations, hooks, skill capture - when the task's shape fits one.
policy:
  allow_implicit_invocation: true


# Automation / Cron Scout

**Action policy: PROPOSE, then create on a yes.** Automations can be drafted and created from a regular Codex thread by describing the task, the schedule, and the automation type - so unlike most scouts, an approved proposal is directly actionable. For `codex exec` cron jobs, draft the exact command line and hand it over.

## Recognition - babysitting and deferred obligations

- **Polling external state**: a CI run, a deploy pipeline, a remote queue, a third-party job. The user says "let me know when...", "check back on...", "is it done yet?"
- **Recurring chores**: "keep the PRs babysat", "re-run the audit weekly", "check the error logs every morning", issue triage, summarizing CI failures, daily release briefs.
- **Deferred one-shots**: "remind me tomorrow", "run this after the launch", "next week we should...". These carry a concrete date or event.

## Choosing the dispatch

| Situation | Tool | Why |
|---|---|---|
| Should keep returning to THIS conversation on a schedule - needs the thread's context | **Thread automation** (heartbeat-style wake-up attached to the current thread) | Same conversation, accumulated context intact |
| Fresh recurring runs for a project; findings land in the inbox; nothing-to-report runs auto-archive | **Standalone / project automation** | Runs in the background on its own cadence, independent of any open thread |
| Cron-shaped, scriptable, needs an exit code (CI, launchd/cron, GitHub Actions) | **`codex exec "<prompt>"`** | Single-shot, non-interactive, composable with any scheduler |

Automations can bundle skills (`$skill-name` in the prompt) - if a relevant skill exists, reference it in the drafted automation.

## Stay quiet when

- The work completes within this session anyway - spawned subagents and background commands already report back; proposing an automation to watch them is pure waste. This is the most common false positive; don't be it.
- The "recurring" need is actually 2-3 repetitions inside the current task - just do them.
- A /goal fits better: "until CONDITION holds" is a goal; "every N hours regardless" is an automation. Don't propose both.

## The proposal

> This is recurring/deferred work - [what's being watched or repeated and why it won't happen by itself]. Want me to set up [a thread automation / a project automation / a `codex exec` cron line]: "[drafted prompt]" on [cadence]? It runs in the background and [reports to your inbox / posts back here]; say yes and I'll create it.

Note the cost honestly: each scheduled run spends tokens whether or not there's anything to report.


# Decision-Log Scout

**Action policy: PROPOSE** a one-line entry; write it only on a yes. Low ceremony by design - this is the cheapest scout in the family, and the proposal should cost the user five seconds to approve.

## Recognition - a durable principle just crystallized

- **A generalizing rule emerged from a specific debate.** The conversation resolved one case but the reasoning covers a class. (Origin example: debating whether stacked slow should reach freeze produced "a stat ramp on one weapon should never asymptote into another weapon's identity" - one weapon discussion, a principle that governs every future upgrade design.)
- **"Let's always / never..."** - the user states a standing policy mid-conversation.
- **A locked decision got revised.** Something previously settled was deliberately changed. Unrecorded reversals look like drift to the next reader (human or agent) and get "fixed" back.
- **A trade-off was decided with reasoning that won't be reconstructible** from the code alone - the code shows WHAT, the log preserves WHY.

## Where it goes

- A project decision log if one exists (check for `decision-log.md` / docs c