Decision

Decision

Use this skill whenever continuation is non-trivial. Use it to make one route judgment from durable evidence and then get the quest moving again.

Match signals

Use decision when:

• the next stage is not obvious
• the evidence is mixed
• the current line may need to stop
• the quest needs a branch, reset, or reuse-baseline judgment
• a user preference-sensitive choice remains
• a blocker needs an explicit route

Do not use decision when:

• the active mainline is still too ambiguous for a real route judgment and should first be reconciled through intake-audit
• the next move is already obvious from durable evidence and can proceed directly
• the task is really baseline recovery, scouting, ideation, or execution rather than a route judgment

One-sentence summary

Make one route judgment from durable evidence, record the verdict and smallest valid action, then keep the quest moving.

Control workflow

1. Check whether the board is decision-ready. If the current mainline, latest decisive result, or stale-route state is unclear, route through intake-audit first.
2. State the real question and gather only decision-relevant evidence. Compress the strongest support, strongest contradiction, main risk, main cost, and what is genuinely new.
3. Choose the smallest canonical action that resolves the current state. Make the winner, main rejected alternatives, and the decisive reason explicit.
4. Record the decision durably. Include verdict, action, reason, evidence paths, and next stage or next direction.
5. Ask the user only when local evidence cannot safely resolve a real preference, scope, or cost choice.

AVOID / pitfalls

• Do not repeat the same decision without new evidence.
• Do not decide from vibe, momentum, or optimism.
• Do not hide a blocked state behind a vague “continue”.
• Do not launch analysis campaigns casually when the expected information gain is weak.
• Do not choose among candidate packages without naming why the alternatives lost.
• Do not imply baseline reuse is resolved unless the concrete attachment and confirmation path is clear.
• Do not choose finalize for a paper line unless manuscript coverage reports submission_ready=true; a draft checkpoint routes back to write, and a review package routes to review.
• Do not keep a paper route alive after a publishability stop-loss finding. If durable evidence shows that novelty, evidence sufficiency, or reader value has collapsed beyond reasonable narrowing, recommend stop or branch, and record any narrowed non-paper objective as the next direction rather than as a new action. Do not execute stop for a low-quality paper judgment without asking the user to confirm that route.

Constraints

• Use durable evidence, not impressions, as the basis for route judgment.
• Use the smallest canonical action that genuinely resolves the state.
• When baseline reuse or attachment is selected, land it concretely and leave an explicit blocker or waiver if the baseline gate still cannot clear.
• Use blocking user requests only when the user truly must choose.
• Later stages must not need to guess what was decided, why it was decided, or what happens next.

Validation

Before decision can end, all applicable checks should be true:

• the route question is explicit
• the decisive evidence is explicit
• the chosen action matches the actual state
• the main rejected alternative or blocker is visible
• the decision is durably recorded with verdict, action, reason, evidence paths, and next direction
• the next stage or next action is explicit

Interaction discipline

Follow the shared interaction contract injected by the system prompt. Avoid repeating the same decision without new evidence, and use blocking requests only when the user truly must choose. For ordinary active work, prefer a concise progress update once work has crossed roughly 6 tool calls with a human-meaningful delta, and do not drift beyond roughly 12 tool calls or about 8 minutes without a user-visible update. When a decision materially resolves ambiguity and the quest can continue automatically, follow the durable record with artifact.interact(kind='milestone', reply_mode='threaded', ...) so the user can see the chosen route, the decisive evidence, and the next checkpoint.

Tool discipline

• Do not use native shell_command / command_execution in this skill.
• If decision-making needs shell, CLI, Python, bash, node, git, npm, uv, or environment evidence, gather it through bash_exec(...).
• For git state inside the current quest repository or worktree, prefer artifact.git(...) before raw shell git commands.
• Use decision to judge the route, not as an excuse to bypass the bash_exec(...) / artifact.git(...) tool contract.

Truth sources

Make decisions from durable evidence:

• the current board packet when one exists
• recent run artifacts
• report artifacts
• baseline state
• quest documents
• memory only as supporting context

Do not make major decisions from vibe or momentum. Do not treat decision as a substitute for state reconciliation when the active mainline is still ambiguous.

When the quest is algorithm-first, add one extra truth-source rule before non-trivial route choices:

• read artifact.get_optimization_frontier(...)
• treat the frontier as the primary optimize-state summary
• only override it when newer durable evidence clearly dominates
• if the frontier says explore, do not collapse immediately to exploit unless the latest durable result clearly changes the frontier
• if the frontier says fusion, judge whether complementary lines can be merged before launching another isolated candidate

Required decision record

Every consequential decision should make clear:

• verdict
• action
• reason
• evidence paths
• next stage or next direction

Keep the verdict simple and legible, and make sure the chosen action matches the actual state rather than sounding optimistic by default.

Canonical actions

Use the following canonical actions:

• continue
• launch_experiment
• launch_analysis_campaign
• branch
• prepare_branch
• activate_branch
• reuse_baseline
• attach_baseline
• publish_baseline
• write
• review
• finalize
• iterate
• reset
• stop
• request_user_decision

Choose the smallest action that genuinely resolves the current state.

For paper-outline decisions, use artifact.submit_paper_outline(mode='select', ...) when selecting an existing candidate and artifact.submit_paper_outline(mode='revise', ...) when the selected outline needs repair. For paper-bundle decisions, use artifact.submit_paper_bundle(...) only when the draft or package state is durable enough for that package type. When deciding whether a paper line can advance, judge method fidelity and story coherence as well as metric coverage. For paper routes, apply the publishability stop-loss rule before choosing write, review, or finalize: if the line cannot plausibly become a useful and defensible paper, recommend stopping the paper objective or branching to a stronger route instead of adding another writing pass. If the proposed action is stop because paper quality is too low, first ask for a user decision with the evidence and the branch/narrow alternatives. If the user has given publication, scope, cost, or non-paper preferences, consider them explicitly; if those preferences are unclear and materially affect the stop/branch choice, ask for a user decision.

Apply the symmetric exploration-depth gate before recommending close_round_write_paper for an all-negative-result paper (every attempted idea has been falsified or family-bounded, no positive lift survives). Before routing to write, answer all of these in the decision artifact:

• Have you tested at least two structurally distinct idea families from idea/references/idea-thinking-flow.md (mechanism, objective, measurement, infrastructure, or model-architecture / ensemble / multi-agent), or only multiple variants inside one family?
• Have you challenged the bottleneck framing itself — is "X is the locus of the residual gap" a conclusion or just an artefact of where you stopped looking?
• Has the literature surfaced a structurally different route the current attempts did not cover (cross-domain mechanism transfer, different evaluator regime, different training-data composition, etc.)?
• How much of the quest's time_budget_hours is unused, and could a third structurally distinct family fit inside the remainder?

If any answer is "no" or "unsure" and the time budget allows, route back to idea for a re-ideation pass focused on a structurally different family before concluding. The negative-result paper is still the right outcome when the gate is honestly cleared; this gate just prevents premature closure when only one corner of the design space has been ruled out. Positive-result papers are not blocked by this gate. For resume-changing route decisions, write one compact checkpoint-style quest memory card so later turns know the current active node, node history, what not to reopen by default, and the first files to read. Use type:checkpoint-memory and references/checkpoint-memory-template.md for that card.

Operational guidance

The main skill keeps the control surface in front. For the longer judgment and route-shaping notes, read:

• references/strategic-decision-template.md
• references/research-route-criteria.md
• references/operational-guidance.md
• references/checkpoint-memory-template.md

Use them when:

• a richer route-change rationale is needed
• research-route selection among candidate packages is the main difficulty
• memory should preserve the new authoritative resume point

Decision-quality rules

Good decisions:

• are evidence-backed
• name tradeoffs
• say what happens next
• say why the alternative was not chosen
• explicitly identify the winning candidate when choosing among multiple packages
• do not launch analysis campaigns unless the expected information gain clearly justifies the extra resource cost

Weak decisions:

• hide uncertainty
• lack evidence paths
• give vague approvals
• pretend blocked states are progress
• choose a winner without naming the rejected alternatives or criteria

Exit criteria

Exit once the decision is durably recorded and the next stage or action is explicit.

A good decision pass changes the route once; it does not keep re-explaining the same route without new evidence.