--- name: advisor-model description: 'Consult a separate model at a selected plan, fork, or completion decision while the current model retains execution ownership; use supplied context only, keep the consultation read-only, and never treat advice as a goal check.' --- # 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: ```markdown ## Advisor enabled: true | false required: false | true backend: native | delegated | unavailable model: host-default | consultations: - id: mode: plan-review | decision-fork | completion-check status: pending | accepted | rejected | opaque | declined | unavailable plan_revision: request: evidence_refs: response: disposition: accepted | rejected | unresolved accounting: criterion_proposal: ``` 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 ```text 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: advice: reversal: executor-action: accounting: ``` ## Source The native advisor principle is documented at https://code.claude.com/docs/en/advisor.