Choice framework for a rover in the field, or for any moment an operator is stuck between options. Classifies the call, applies the six principles, enlists research skills to resolve, logs the verdict in the audit trail when a loop file is present. Invoked by the rover at forks in the traverse; also invocable directly as /autonomous:decide with free-form text describing the choice.
A choice is coming up. Either you are inside an autonomous loop (the operator delegated decision-making when they dispatched the rover) or the operator invoked /autonomous:decide directly because they are stuck between options. Either way, your job is to pick the right path, not to defer.
Most "should I ask the user?" moments are reflex, not genuine ambiguity. Inside an autonomous loop, every question breaks the loop. When a user has explicitly delegated by running /autonomous:rover, deferring is the anti-pattern. When a user calls /autonomous:decide directly, they are asking for a reasoned call, not a menu.
Before asking anything, classify the decision.
Mechanical. There is one clearly right answer. Just do it. Log a row, move on.
Examples: run tests before commit, use the same formatter config as the rest of the repo, follow an existing pattern when one is established.
Taste. Reasonable people could disagree. Pick the recommended option, log it, continue. Surface at the final gate only if many taste decisions pile up.
Examples: two library options with different tradeoffs, naming a new module, ordering of fields in a serializer, ASCII vs unicode box drawing.
User Challenge. Both your research AND the direction from the original invocation disagree on something the user explicitly specified. This is rare. Stop here. Log + notify user. Do not decide.
Examples: user asked for feature X, research shows feature X will break something important that the user also cares about.
These are opinionated defaults, inspired by the gstack autoplan framework. They are not universal truths. A loop running in a codebase where your team has different priors (say, minimal dependencies over completeness) will want to override them. Do that by adding a section to the loop file's ## Context that reorders or replaces these; the loop respects Context-level overrides.
Apply these in order. Earlier principles win ties.
When principles conflict, the active phase tips the scale:
Research skills exist to help you make better calls. Use them as part of deciding, not as a substitute for it.
/whywhy (default for your own assumptions).
Use when you catch yourself about to ask "should I do A or B?" Pre-check: is the real question upstream? Run /whywhy with the question, let it drill 5 to 7 layers. If the real question is different, answer the real one. Cheap, routine.
/ground (for factual claims).
Use before committing to a factual statement about tools, APIs, or system internals. If you are about to write code based on "this flag does X" or "this library behaves like Y," verify. Cheap, required for anything verifiable.
/inspiratie (for unfamiliar terrain).
Use when you hit a technical threshold you cannot cross from training alone. Library you do not know, pattern you have not seen, protocol you are guessing at. Medium cost, saves backtracks.
/gurus (spare, for architecture forks).
Use once per loop at most. When a genuinely structural choice is in front of you and the research so far has not converged. Expensive, worth it when the decision shapes the whole implementation.
Fallback: /brainstorming if present.
When the decision is creative rather than technical (naming, framing, scope), brainstorming works better than the research skills above.
Detection. Before invoking any of these, check they exist. A robust helper:
has_skill() {
local name="$1"
# Check plugin caches (compgen handles zero/multi matches correctly)
if compgen -G "$HOME/.claude/plugins/cache/*/$name" > /dev/null; then return 0; fi
if compgen -G "$HOME/.claude/plugins/cache/*/*/skills/$name" > /dev/null; then return 0; fi
# Check user-level skills
[ -e "$HOME/.claude/skills/$name" ]
}
If a skill is missing, log it to the loop file's Log section (one line, not silent), then decide using the six principles alone. Example:
[HH:MM] Decide: /whywhy not installed, falling back to principles-only for this decision
Silent fallbacks hide broken setups. A logged fallback stays visible to the user when they re-read the loop file.
Every decision you make inside a loop adds a row to the loop file's ## Decision Audit Trail table:
| # | Phase | Decision | Classification | Principle | Rationale |
|---|-------|----------|----------------|-----------|-----------|
| 12 | DRIVE | Separate `cron` skill from `rover` | Taste | Explicit > Clever | Audit flagged cron/decay as the messiest section. Splitting makes each piece readable in 30 seconds. |
The trail lives on disk, not in conversation context. Future iterations can read it to understand why earlier choices were made.
Stop and notify the user only when:
Bad work is worse than no work. But pre-emptive stopping is worse than a thoughtful call. The bar is high.
| Thought | What it actually is | Do instead |
|---|---|---|
| "Let me check with the user first" | Compliance reflex | Pick, log, proceed |
| "The simplest thing for now" | Haste projection | Pick the structural option |
| "I'll leave it to the user to decide the name" | Deferral | Name it, user corrects if needed |
| "Both options seem valid, escalating" | False Taste | Apply principles, pick the recommended one |
| "Let me just do A and if it does not work try B" | Iterative downgrading | Understand why A might not work before starting |
When you have decided, write to the loop file:
## Log (one line)Do not write prose explaining the decision to the user. The audit trail is the explanation.