| name | nestor |
| description | This skill should be used when the user asks to "ask Nestor", "go to Nestor", "сходи к Нестору", "третье мнение", "что думает совет", "прогони через совет", "глубокий разбор", "важное решение", "критично", "high stakes", "critical decision", "think carefully", "deliberate", "council", "совет", "спросить модели", "second opinion", "что думают другие", "what does the council think", or mentions needing multi-model consultation. Also invoke when you judge your own answer under-calibrated and need an independent multi-model read. Nestor convenes a council of frontier models via the `pal` MCP server, announces its routing decision before running, and returns a synthesised judgment with an explicit agreement map and dissenting views. |
Nestor
Nestor is a named consultation mode for multi-model deliberation. When the user or the session needs a multi-model council on a hard decision, invoke this skill to run the deliberation through a disciplined protocol: self-contained question formulation, routing, council execution, synthesis, and structured presentation back to the user.
This skill is self-contained. The core protocol — triggers, router, envelopes, presentation, kill criteria — lives in this file. Detailed deliberation mechanics (preset model rosters, fallback chains, the pal.consensus step-by-step workflow, stance semantics with the Gemini Flip empirical finding, and the deliberative stage-2 cross-critique template) live in references/ within this skill and are loaded on demand:
references/presets.md — model rosters for arch / code / research / brainstorm / quick plus per-vendor fallback chainsreferences/consensus-execution.md — mcp__pal__consensus step-by-step workflow, continuation_id handling, stepping disciplinereferences/stances-and-gemini-flip.md — stance semantics (for / against / neutral as roleplay-not-belief) and the Gemini Flip findingreferences/deliberative-stage-2.md — cross-critique protocol, the verbatim critique prompt template, anti-patterns
When to invoke
Invoke this skill when:
The user uses an explicit trigger phrase (already matched by the skill loader via the description above). The full phrase list: "ask Nestor", "go to Nestor", "сходи к Нестору", "третье мнение", "что думает совет", "прогони через совет", "глубокий разбор" (→ forces deliberative mode), "важное решение", "критично", "high stakes", "critical decision", "think carefully", "deliberate", "council", "совет", "спросить модели", "second opinion", "что думают другие", "what does the council think".
An implicit condition matches and you decide to delegate without being asked:
- Architectural or strategic decisions with high irreversibility
- The session's current answer feels under-calibrated or session-biased
- A hypothesis built with the user across the session needs pressure-testing from outside the session's framing
- An open question where the shape of disagreement is unknown
Do NOT invoke Nestor for:
- Simple factual questions (answer directly or consult the knowledge library)
- In-the-moment implementation decisions with low reversibility cost
- Routine work where committee deliberation adds latency without signal
- When the user explicitly asks for your own opinion ("what do you think?") — answer directly, do not deflect to the council
Prerequisites
Verify that mcp__pal__consensus and mcp__pal__chat are available before running the protocol. If the pal MCP server is not configured in the current session, report the missing dependency clearly and stop — do not attempt consultation without the underlying tools. Surface this actionable message to the user: "pal MCP server is not available in this session. Install it from github.com/BeehiveInnovations/pal-mcp-server. Nestor cannot run without it."
Core protocol
Execute these six steps in order for every Nestor consultation:
Step 1 — Formulate a self-contained question
Translate the user's situation into a fully self-contained question. Every fact the council needs — user context, domain constraints, team size, prior decisions, named options — must be embedded in the question text. Session memory does not travel to the council.
Example of under-specified vs self-contained:
- Under-specified: "Should I rewrite my CLI tool from Python to Go?"
- Self-contained: "I maintain a CLI tool, ~3k lines of Python, used daily by a team of 4 engineers. Performance is adequate; the pain points are dependency management and single-binary distribution. Should I rewrite in Go, or address packaging in-place with pipx / shiv / pyinstaller?"
The under-specified version leaves the council guessing about the actual tradeoffs; the self-contained version lets it reason about the problem the user actually has.
If the user's situation lacks a required detail, ask the user first rather than guessing. A bad question produces a bad council output; the question-quality gate is the single most important step in the whole protocol.
Step 2 — Route the question
Apply the router decision table below to select four outputs:
mode: adversarial or deliberativepreset: arch / code / research / brainstorm / quickstances: per-model assignment (default all-neutral)question_framing: the exact text sent to each council model
For rules 2–5, question_framing is simply the self-contained question from Step 1, passed through unchanged. For rule 1 (named hypothesis to red-team), question_framing additionally includes a per-model stance_prompt tuned to the specific hypothesis — e.g., one model receives "argue for ", another "argue against ", a third "argue from a skeptical neutral stance". The stance-specific framing is what makes adversarial mode sharp; do not pass the raw question to stance-assigned models and expect them to infer the attack angle.
Match rules in order; first match wins. If no rule matches with confidence, go to Step 3 with status: needs_clarification and return to the user for more context instead of guessing.
Step 3 — Announce the routing before executing
Before running the council, state the routing decision aloud in this exact form:
Routing Nestor's consultation:
Mode: <adversarial | deliberative>
Preset: <arch | code | research | brainstorm | quick>
Stances: <all-neutral | for/against/neutral>
Rule matched: <which router rule fired and why>
Proceeding unless overridden.
This announcement is mandatory, not optional. It catches confident mis-routing before any tokens are burnt on the wrong configuration. The user can override at this moment.
Step 4 — Run the council
Use mcp__pal__consensus for stage 1 of any mode, and for adversarial mode end-to-end. Step through the entire consensus workflow with every model in the preset — the full preset roster is authoritative at runtime. The step-by-step consensus workflow with the full roster is what makes "preset" mean something; it provides the reproducibility guarantee that kill-criteria tracking depends on.
For parameter-level details of the mcp__pal__consensus workflow (step numbers, continuation_id handling, per-step parameters), see references/consensus-execution.md. For the model roster and per-vendor fallback chains of the chosen preset, see references/presets.md. Do not invent new model combinations inside Nestor; the presets exist so that routing stays small and testable.
For deliberative mode, after collecting three neutral first-round answers via mcp__pal__consensus, run three parallel mcp__pal__chat calls to collect anonymised cross-critiques. The cross-critique protocol, the verbatim stage-2 prompt template, and the associated anti-patterns live in references/deliberative-stage-2.md. Use that template verbatim; do not improvise.
mcp__pal__chat is only for deliberative stage-2 cross-critique — never a substitute for mcp__pal__consensus in stage 1 or in adversarial mode.
Degraded-run handling: if a model fails, times out, or returns an unusable response (empty, obviously truncated, or off-topic) during a legitimate consensus run, proceed with the remaining models and flag the degraded roster in the return envelope's confidence field — e.g., "medium, caveat: only 2/3 models responded usefully; the third returned a parse error". If fewer than two models produce usable output, abort synthesis and report the failure to the user honestly rather than papering over a broken council run with a forced single-model synthesis. Degraded handling is for infrastructure failure, not for pre-emptive optimisation — see the related "Do NOT deviate from the preset roster" anti-pattern below.
Step 5 — Synthesise the judgment
Produce the return envelope (see below). Work primarily from the council's output and the self-contained question. Do not inject session context into the synthesis.
Acknowledge the honest v1 limitation: the in-session Claude performing this synthesis still has session history in its attention window. Session framing may subtly influence weighting and emphasis even with deliberate effort to exclude it. This is a known architectural limitation, not a discipline problem. When it affects the synthesis in a visible way, flag the effect to the user; do not pretend the synthesis is fully context-free.
Step 6 — Present to the user
Use the presentation protocol below. Lead with Nestor's judgment. Add your own session-aware read only if session context materially qualifies the judgment. Keep the two layers visible — never blend them.
The router
Match rules in order. First match wins. Rule 6 is the safe fallback when nothing else applies.
| # | Condition | Mode | Preset | Stances |
|---|
| 1 | Named hypothesis to red-team (user has a draft proposal and explicitly wants it attacked, or reason_for_consulting includes "red-team" / "pressure-test") | adversarial | arch | for / against / neutral with stance_prompt tuned to the hypothesis |
| 2 | Technical implementation decision with a clear axis (library, framework, algorithm, database choice between named options) | deliberative | code | all-neutral |
| 3 | Factual or research question requiring web-grounded verification ("what is true about", "verify", "market data") | deliberative | research | all-neutral |
| 4 | Exploratory or open-ended framing ("what am I missing", "what's the right framing", "how should I think about") | deliberative | arch | all-neutral |
| 5 | Low-stakes sanity check ("quick check", "is this reasonable", "obvious mistakes") | adversarial | quick | all-neutral |
| 6 | None of the above matches confidently | — | — | Return status: needs_clarification with a specific question; do not guess |
Call envelope (session → Nestor)
The question passed to the council carries this logical shape, even when implemented as structured prose inside the mcp__pal__consensus call's step parameter:
question: <the fully self-contained question>
reason_for_consulting: <"third opinion" | "high stakes" | "red-team this hypothesis" | "exploratory, axis unknown">
hypothesis_being_tested: <optional; if rule 1 fires, the exact hypothesis the council attacks>
constraints: <optional; domain or implementation constraints the council should respect>
Return envelope (Nestor → user)
After the council runs, structure the synthesis around these fields:
judgment: <Nestor's synthesised answer — what should be done or how the question should be framed>
confidence: <low | medium | high + brief reason>
agreement_map: <where models agreed, where they diverged, and on what dimension>
dissenting_view: <any substantive minority position, captured with its reasoning>
unaddressed_gaps: <what the question did not account for that the council noticed — a meta-signal back to the user>
Presentation protocol
When presenting Nestor's judgment to the user, use this form if session context adds material qualifications:
**Nestor says**: <judgment + confidence + key reasoning>
**Agreement map**: <where models converged, where they diverged>
**What Nestor may have missed about the specific situation**: <session-context qualifications that Nestor could not have known>
**Session-aware read, given <named context>**: <your own take on Nestor's judgment — agreement, refinement, or disagreement>
If you have no session context that materially qualifies the judgment, omit the "Session-aware read" section and present Nestor's output cleanly.
Keep the two layers visible and labeled. Do not blend Nestor's judgment with session-context qualifications into a single unmarked voice. The user should always be able to tell what came from the council and what came from the session-aware layer on top.
Run metadata logging
After every Nestor consultation, append a metadata record to the current session log under a ## Nestor consultations section (create it if missing):
- timestamp: <ISO datetime>
trigger: <explicit phrase that fired, or implicit reason>
router_decision: <mode + preset + stances>
router_rule_matched: <rule number from the table>
session_overrode_router: <true | false; if true, what was overridden and why>
session_added_qualification: <true | false; if true, what session context shaped the qualification>
This metadata is load-bearing for kill criteria. Without it, there is no way to tell after ~10 uses whether the router is earning its keep or whether the persona layer adds signal beyond direct mcp__pal__consensus calls without the Nestor wrapper. Do not skip the logging step.
What NOT to do
- Do NOT count votes across stance-assigned runs. If rule 1 fires and stances are assigned, "2/3 agree" is meaningless — one model was instructed to argue the opposite. Report the judgment but flag the stance structure honestly. See
references/stances-and-gemini-flip.md for the roleplay-not-belief framing and the Gemini Flip empirical finding (same model flipping position between against and neutral stances at identical confidence).
- Do NOT skip deliberative stage 2 when stage 1 is unanimous. Unanimity is not a signal the council got it right; shared blind spots are invisible in unanimous answers. The verified A/B run on 2026-04-05 showed peer critique catching four major unaddressed requirements and two factual errors in a 3/3 unanimous first-round set. See
references/deliberative-stage-2.md.
- Do NOT deviate from the preset model roster at runtime, even with defensible reasoning. Observed on Nestor's first real-use run (2026-04-05, run #1): Claude-as-Nestor excluded
claude-haiku-4.5 from the quick preset based on a cross-provider correlation-avoidance argument — the reasoning was "the synthesizer is Claude, so including Claude in the roster correlates errors; cross-provider pair gives more independent signal." The argument is defensible in design review, but unauthorised at runtime. Preset rosters are spec-level decisions; if you have an argument for changing a roster, surface it to the user as a spec discussion, not a runtime override. Runtime deviation breaks reproducibility across runs, makes kill-criteria metrics noisy, and cannot be validated at the moment of deviation — only in design review. If the full preset cannot respond because of infrastructure failure (model unavailable, timeout, parse error), that is the degraded-run case in Step 4 — not a license for pre-emptive optimisation. (Historical follow-up: on 2026-05-10 the same correlation-avoidance argument was raised again, this time properly in design review during a model-refresh session, and the synthesizer-correlated Anthropic slot was removed from both quick and brainstorm — see references/presets.md refresh history. The runtime decision was still wrong; the design-review decision was right. The rule holds: the path to a roster change is design review, not runtime.)
- Do NOT simulate a Nestor personality, voice, or backstory. Nestor is a function wearing a name, not a character. Respond with structure and discipline, not mannerisms.
- Do NOT call Nestor recursively inside a Nestor consultation. One round, one synthesis. Multi-round debate introduces anchoring bias.
- Do NOT blend Nestor's judgment with session-context qualifications silently. The presentation protocol separation is the only way the user can tell where Nestor's output ends and the session-aware commentary begins.
- Do NOT claim context-free judgment. v1 Nestor is fresh-read consultation with reduced bias. Full architectural isolation is a v2 escape hatch (separate sterile synthesis API call), not a v1 guarantee.
- Do NOT invoke Nestor when the user explicitly asks for your own opinion. If the user says "what do you think?", answer directly. Do not deflect to the council.
- Do NOT persist Nestor-specific state between calls. Run metadata goes to the current session log only — not to a dedicated Nestor store, not to global memory. Each consultation starts at zero. This statelessness is enforced by the plugin having no storage layer; do not work around it.
Kill criteria
v1 Nestor is experimental. Revisit after ~10 real uses. Rip-out conditions:
- Router override rate > 50% — the router is not earning its keep
- Synthesis indistinguishable from direct
mcp__pal__consensus calls — the persona layer is theatre
- Latency avoidance — users start skipping Nestor because the overhead exceeds the value
- Cognitive tax — the named persona adds mental overhead rather than reducing it
Rip-out cost is near zero: delete the plugin. Preset rosters and protocol details are preserved in git history and references/ files — they can be re-activated as a standalone skill without rebuilding from scratch.
Related
Within this plugin (progressive disclosure — load on demand):
references/presets.md — model rosters + per-vendor fallback chainsreferences/consensus-execution.md — mcp__pal__consensus step-by-step workflow detailsreferences/stances-and-gemini-flip.md — stance semantics + Gemini Flip empirical findingreferences/deliberative-stage-2.md — cross-critique protocol + verbatim prompt template
External:
