Advisor Model

Purpose

The advisor is a second model consulted at a selected decision point. The current model remains the executor: it owns the task, edits, commands, goal ledger, and final decision. Advice is evidence to consider, not an approval gate. The executor may reject it when the repository, command output, or other supplied evidence contradicts the recommendation.

This skill is standalone. A goal file is useful context when one exists, but it is not required.

When persisted with a goal, use an optional ## Advisor section after the budget:

## Advisor
enabled: true | false
required: false | true
backend: native | delegated | unavailable
model: host-default | <configured model>
consultations:
- id: <stable id>
  mode: plan-review | decision-fork | completion-check
  status: pending | accepted | rejected | opaque | declined | unavailable
  plan_revision: <revision or null>
  request: <why this consultation was selected>
  evidence_refs: <paths, outputs, or transcript references supplied>
  response: <recorded response or opaque>
  disposition: accepted | rejected | unresolved
  accounting: <host-reported cumulative usage or unavailable>
criterion_proposal: <pending tightening and evidence, or none>

Persist explicit advisor requests here, including whether the user requires a consultation. An explicit enabled: false disables consultation. Honor the selected backend and model and the host's existing configuration; do not silently override them. Record consultations here so resume cannot dispatch the same decision twice.

Consultation boundary

When no backend was selected, prefer an available native advisor, which may receive the full conversation according to its host contract. Otherwise use an actual separate, read-only delegated model with the context explicitly supplied by the executor. If neither exists, report that the advisor is unavailable and continue the ordinary loop unless the user explicitly requires an advisor. Never present same-model self-critique as a separate consultation.

Use one consultation when it can change the outcome materially: review a plan before work, choose between a consequential fork, or check a result the executor believes is complete. Do not consult for syntax, routine lookup, or every goal-loop tick.

The advisor receives only the context and artifacts the executor supplies when using the delegated path. It must not imply that it saw private state, repository files, or tool output unless those were included. It has no write authority and must never edit files, run the task, set a goal status, or replace a check.

Executor protocol and advisor response

1. The executor reads goal status, cumulative usage, finite token limit, and the latest consultation before invocation. With a goal, consult only while it is active; preserve other states and counters. At or above a finite token limit becomes exhausted before the call; missing finite accounting becomes blocked. Accounting must include the selected advisor's usage; an executor-only total is insufficient.
2. The executor selects exactly one configured backend and model, records the request as pending before dispatch, then sends the question and supplied context. A backend failure becomes unavailable or declined for that consultation; it must not silently invoke a second backend. Existing host settings are read-only: this skill writes no native settings.
3. A pending record found on resume is unresolved. Inspect an available recorded result or report it unresolved; do not assume completion and do not replay it automatically.
4. The executor asks for plan review, a decision fork, or a completion check. Routine questions stay with the executor and require no consultation.
5. The advisor reads the supplied artifacts and command output before judging. Name missing context and stop short of conclusions that depend on it.
6. For plan review, return APPROVE or REVISE, followed by ranked corrections and the concrete failure each correction prevents.
7. For a decision fork, select one option, give the deciding evidence, the strongest case for the alternative, and the evidence that would reverse the call.
8. For completion, return PASS or FAIL against the goal's declared external checks and review criteria, citing the evidence. If the advisor result is opaque, record it as opaque and do not invent a verdict.
9. Treat an opaque, declined, unavailable, or disabled result in any consultation mode as OPAQUE, DECLINED, UNAVAILABLE, or SKIPPED, preserving the actual response; never infer approval, revision, or completion from it. The executor records disposition and any changed plan or checks; the advisor does not mutate goal state.
10. If accepted advice changes the plan, the executor marks both the current Plan and its latest matching plan ledger entry unsound with the reason, preserves revision and iterations_used, and lets the next plan allocate the next iteration. For a proposed criterion tightening, preserve the current criteria and store criterion_proposal here. Before further implementation, run verify-goal against those unchanged criteria, then pass that verification ledger and the proposal to refine-goal. This also applies when verification marks the old criteria met: refinement may reopen that completed result. Clear the proposal only after refinement records its disposition. Recheck budgets between these operations; an interrupted handoff retains the proposal for resume. The end state must remain unchanged; a changed end state or widened non-goal requires a new goal contract and user authorization.
11. If accepted advice changes an executable artifact, the executor runs the affected checks again and preserves goal iteration and accounting state.

Goal-loop accounting

Advisor usage belongs in the host's cumulative usage accounting exactly once. Do not add an advisor total to a host total that already includes it. The executor records an in-flight overshoot and marks exhausted at the next boundary. Refresh usage after the response and before advancing the goal. If inclusive usage becomes unavailable under a finite limit, set blocked and preserve the last known counters. When a required advisor is unavailable, declines, or its pending result cannot be recovered, record that blocker and stop the goal; resume only after resolving it or an explicit user policy change.

The goal loop does not require a consultation on every tick. A selected consultation may inform the next plan or verification, but only the goal's declared external checks and reviews can establish a criterion.

Output format

mode: plan-review | decision-fork | completion-check
availability: native | delegated | unavailable
verdict: APPROVE | REVISE | OPTION-A | OPTION-B | PASS | FAIL | OPAQUE | DECLINED | UNAVAILABLE | SKIPPED
evidence: <artifacts and command output actually read>
advice: <compact decision or ranked corrections>
reversal: <evidence that would change the advice>
executor-action: <what the current model should do next>
accounting: <host-reported cumulative usage, or unavailable>

Source

The native advisor principle is documented at https://code.claude.com/docs/en/advisor.