minerva — grill → brainstorm → critic → spec → critic → plan (HIMMEL-428)

Orchestrate a hardened path from idea to implementation plan. You drive the
superpowers sub-skills and insert an adversarial critic between each stage, so
every artifact is red-teamed before it advances. minerva pairs the Roman
goddess of wisdom + strategic planning with himmel's critic discipline.

You are the orchestrator. Do not let the sub-skills auto-chain past their
stage — you decide when each critic runs and when to advance.

One front door (HIMMEL-2039). grill / stress-test / interrogate / brainstorm
/ "build / design / implement X" / /minerva all land here. The grilling
stance is minerva's Stage 1a, not a second skill: if
lean-skills:grilling fires, run Stage 1a below and continue the
pipeline rather than stopping at a shared understanding.

Mode (gates)

Determine once, up front, whether to pause for the operator between stages.
CLAUDE_PLUGIN_ROOT is set under Claude Code but empty in a Codex skill
shell (HIMMEL-606), so resolve the himmel-ops scripts dir with a fallback
chain before invoking — the resolver below is reused verbatim in the Terminal
section (keep both copies byte-identical):

# >>> himmel-ops scripts resolver (CLAUDE_PLUGIN_ROOT is empty in a Codex skill shell)
S="${CLAUDE_PLUGIN_ROOT:+$CLAUDE_PLUGIN_ROOT/scripts}"
if [ -z "${S:-}" ] || [ ! -f "$S/autonomy-mode.sh" ]; then
  R="${HIMMEL_REPO:-}"; [ -f "$R/scripts/lib/initiative-legs.sh" ] || R="$(git rev-parse --show-toplevel 2>/dev/null || true)"
  [ -f "$R/scripts/lib/initiative-legs.sh" ] || R="$HOME/Documents/github/himmel"
  S="$R/marketplace/plugins/himmel-ops/scripts"
  [ -f "$S/autonomy-mode.sh" ] || for d in "$HOME"/.codex/plugins/cache/himmel/himmel-ops/*/scripts; do
    [ -f "$d/autonomy-mode.sh" ] && { S="$d"; break; }
  done
fi
# <<< himmel-ops scripts resolver
bash "$S/autonomy-mode.sh" 2>/dev/null || echo interactive

• Output interactive → after each critic-cleaned artifact, PAUSE for the
  operator to approve or redirect before advancing.
• Output autonomous → do NOT pause; the critics are the gate; auto-advance
  through to the terminal.

Stage 1 — grill → brainstorm → spec

1a. Grill (the interrogation phase, HIMMEL-2039)

Before any design is written, interrogate the idea until it survives. Map it as
a design tree: every decision branches into the decisions that hang off it.

Work the tree in rounds. The frontier is every decision whose
prerequisites are already settled — the questions you can ask now without
guessing at answers you have not heard yet. Ask the WHOLE frontier in one
round, numbered, each with your recommended answer:

❓ **Q1** — **<question title>**: <question body, options if any>

➡️ <your recommended answer>

Then wait. Each round's answers reshape the tree: settled decisions push the
frontier outward and unblock the questions that depended on them. Recompute the
frontier and ask the next round. A question whose answer depends on another
question still open in THIS round belongs to a LATER round.

Facts are your job, never the operator's. When a frontier question needs a
fact from the environment, go get it — never ask for what you could look up.
Look it up inline when a handful of tool calls settles it; delegate only a
genuinely independent, sizeable search (CLAUDE.md subagent policy). Do not
block on it: only the questions downstream of a running exploration wait; ask
the rest of the frontier now. The decisions are the operator's — put each to
them and wait.

The eight standing questions (HIMMEL-3996, HIMMEL-6929). Besides the design tree, every
grill asks these, each with your recommended answer. Facts (open PRs, the
version's headroom) you look up yourself; only the choices go to the operator.

1. Smallest shippable slice and its size (XS..XL). Recommend the thinnest
   slice that still ships value; it sets the median.
2. What pushes it to the high end (the tail driver). Recommend naming the
   single biggest unknown, not a list.
3. Does it touch guards, hooks or permissions (G1)? Recommend yes when any
   scope file is under scripts/hooks/, a guard, or a permission list; G1 raises sigma.
4. Can a RED be written now, or is it plan-first? Recommend a named failing
   test; plan-first only when the interface is not yet known.
5. Is any unknown wide enough to span two steps? Recommend splitting before
   committing when the size range is wider than one step.
6. Which open PRs or single-writer groups does it collide with? Recommend
   checking gh pr list against the scope files and serialising behind any hit.
7. Which version does it land in, and does that version still pass P90 <= 0.8?
   Recommend running effort-assess version with this ticket added.
8. Is each follow-up an escape, hardening or polish, and why? Recommend
   running Q1-Q3 of docs/release/follow-up-triage.md in order; for hardening,
   name the reason code (unseen-failure, no-check, vacuous-check,
   no-recovery or silent-rot).

Feed the answers to effort-assess (ticket --low .. --high .. --g1 .. --deps .. --scope-file .. --red .. --goal .. --alternative ..; skill: himmel-ops:effort-assess).
Save its JSON next to the spec. A refused estimate (dod.failed) means fix the
answers (split, or go plan-first), not quote it.

Stop condition: the frontier is empty — every branch visited, nothing
silently assumed. Do not advance to 1b until the operator confirms you have
reached a shared understanding.

autonomous mode has no operator to answer: still build the tree and still
write the frontier out, but answer each question yourself with the recommended
answer and carry the whole Q/A list (the eight standing questions included) into
the spec as an explicit ASSUMPTIONS section — the Stage-2 critic red-teams it
(charter dimension 1, hidden assumptions).

1b. Brainstorm → spec

Invoke lean-skills:brainstorming for the design and the written spec, carrying
the Stage-1a outcome in as settled context — do not re-ask what the grill
settled. The written spec MUST contain: an Estimate record: <path> line (the
effort-assess JSON from 1a), an ## Alternatives considered section and a
## Definition of done section. Stage 2 refuses to start without them.

It also carries, for the terminal lint (HIMMEL-4375):

• ## Invariants: none, or one I<n> line per "one / never / always /
  every" rule the design states.

• ## Fact ownership, when the design adds or aggregates a status, report,
  doctor, health, probe, check or inventory surface. It is a table with one row
  per fact:

  • the fact;
  • every EXISTING surface that computes it, as backticked paths found by grep,
    or none (grep: <pattern>). A delegation (A calls B) counts as two
    surfaces;
  • its single owner after this design;
  • how each non-owner is folded, delegated or removed.

  Build it by grepping the repo, never from memory. Self-answer mode does not
  exempt it. The lint detects the surface from the H1 and the first section,
  so name it there.

Choose the written-design size yourself. At its brainstorming step "Size
the Work", pick brainstorming step "A project with a written design" and say so;
never let it settle on a quick task or a small change, and never take its
skip-the-questions opt-out. Those end with no document, and the Stage-2 gate
and the terminal lint both read the written spec.

Optional, non-trivial designs only: base and graft. Use it when the 1a grill
left two or more architectures open, or the design adds a surface or contract
that would be hard to undo; skip it when 1a settled one obvious shape. Taken from
pstack's arena skill (cursor/plugins@99743e9c151c8537cbbf1f98bb38f34ef3368453,
MIT, Lauren Tan); re-stated here, not vendored.

• Rubric, then fan out. Write 3-6 gradeable criteria for this design (for
  example: smallest surface, each fact owned once, reuses an existing mechanism,
  cheapest to undo) and keep them to yourself. Dispatch N=3 (cap 4) READ-ONLY
  candidates in one round, each given the question, the 1a outcome and a different
  design direction, not the rubric: himmel-ops:fanout research items, or
  scoped subagents with model: sonnet at medium effort. Each returns a sketch plus the
  alternatives it rejected. A candidate that returns nothing is dropped and noted.
• Pick the base, then graft. Read every candidate in full and score each
  criterion by criterion, not by feel. The base is the one a maintainer can extend
  most easily without breaking an invariant; a tie goes to the smaller surface.
  From each other candidate, port in by hand only what beats the base on a named
  criterion (usually one or two items), so the result stays one coherent design.
  Candidates that converge: keep the shared shape, graft nothing. Candidates that
  diverge at the root: the question was under-specified, so tighten it and re-run
  once, never average them. If the re-run still diverges at the root, pick the
  base by the rubric score alone (tie: smaller surface), graft nothing, and
  record divergent after re-run in the section; interactive mode instead asks
  the operator which shape to take.
• Single writer. Candidates write nothing; you, the minerva parent, are the
  one writer and draft the spec through lean-skills:brainstorming.
• Record it in ## Alternatives considered (no new section, so the Stage-2
  gate and the terminal lint are unchanged): the rubric (one line per criterion)
  and a score table, one row per candidate and one column per criterion, so the
  critic can audit the pick; Base: <candidate> - <criteria it won on>; one Graft: <what> <- <candidate> line per item taken, naming the I<n>
  or Fact-ownership row it landed in; one Rejected: <what> (<candidate>) - <why>
  line per notable discard; any dropout or convergence. The Stage-2 critic
  challenges the base pick and each graft like any other alternative.
• Mode. interactive: ask "design looks non-trivial, fan out N=3?" and let
  the operator decline or change N. autonomous: run it only when the 1a answers
  themselves recorded a non-trivial signal, else skip; record base-and-graft: ran N=3 or base-and-graft: skipped, <reason> as one ASSUMPTIONS line. It is an
  option, not a grant, and a critic fix never re-opens it.

HALT it before its auto-handoff to writing-plans. When brainstorming has
written the spec, run its brainstorming step "Builder check", and the document
is approved, return HERE
instead of letting it invoke writing-plans — minerva runs the spec-critic
first.

Stage 2 — spec critic (adversarial)

Gate first (HIMMEL-3996). Resolve $S with the resolver from the Mode
section, then run bash "$S/minerva-spec-gate.sh" <spec-file>. A non-zero exit
means the spec lacks the estimate record, alternatives or definition of done:
it names what is missing — fix the spec (back to 1a/1b), re-run the gate, and
only dispatch the critic once it prints ok. Never skip it, and in autonomous
mode the gate still applies (the answers go to ASSUMPTIONS, the record path stays
in the spec). The critic reads the estimate record and may challenge sigma.

Dispatch a fresh subagent (Agent tool) against the written spec file. Loop
fix → re-critic until it returns clean, cap 2 rounds (then advance with
any residual findings noted).

CHARTER — the single source is panel-charter.md in this skill dir; paste
its contents into the subagent prompt verbatim. Do NOT inline a second copy here
— the file is the one source, shared with the panel lane below (two prose-synced
copies is the instructional-not-structural drift HIMMEL-195 warns against).

⚑ fork-1 ADVISORY cross-model panel lane (HIMMEL-414 WS4). After the Claude
critic round, run the free-cloud critic panel over the SAME spec as an advisory
second opinion — it catches the same-family popularity trap (Claude reviewing
Claude). The Claude critic stays the GATE; the panel only feeds its next round.
Resolve paths from the himmel checkout (minerva runs inside it):

REPO="$(git rev-parse --show-toplevel)"; CR="$REPO/scripts/cr"
CHARTER="$REPO/marketplace/plugins/himmel-ops/skills/minerva/panel-charter.md"
# 1. Enumerate the advisory critic rows (free-preferred; if the registry has NO
#    free rows, fall back to the PAID rows rather than an empty panel — an empty
#    advisory panel silently degrades minerva to claude-only, HIMMEL-1221 G3).
#    Reads the UNIVERSAL critics.json (adopter-neutral), NOT the operator overlay.
bash "$CR/advisory-rows.sh" "$CR/critics.json"
# 2. Per row, critique the spec artifact (dead row exits non-zero → FAIL OPEN, note + continue):
#    bash "$CR/artifact-critic.sh" --artifact <spec-file> --charter "$CHARTER" --model <model> --slug <slug>

Then the Claude critic ADJUDICATES each panel finding, one line per finding:
VERDICT [<slug>-N] = agreed|disproved|conflict|unaddressed. Agreed findings
join the fix list for the next round. Append EVERY verdict + one availability
record per row to the correctness ledger, segmented as spec-artifact records:

bash "$CR/ledger-append.sh" finding --head <spec-id> --model <slug> --id <slug>-N --verdict <verdict> --artifact spec
bash "$CR/ledger-append.sh" avail   --head <spec-id> --model <slug> --status ok|unavailable         --artifact spec

cr-scores.sh --artifact spec then reports panel accuracy on spec artifacts,
separate from CR-diff records. Panel failure of ANY row = fail-open (note +
continue); the Claude critic remains the gate.

After the loop: if interactive, present the hardened spec for approve/redirect;
if autonomous, proceed.

Stage 3 — plan

Invoke lean-skills:writing-plans on the approved spec to produce the
implementation plan.

Stage 4 — plan critic (adversarial)

Dispatch a fresh subagent (Agent tool) against the written plan file. Loop
fix → re-critic until clean, cap 2 rounds.

CHARTER — the single source is plan-charter.md in this skill dir; paste its
contents into the subagent prompt verbatim (no inline second copy — same
HIMMEL-195 rule as Stage 2).

⚑ fork-1 ADVISORY panel lane — mirror Stage 2's lane on the PLAN artifact:
same advisory-rows.sh enumeration (free-preferred, paid-fallback; HIMMEL-1221
G3) + fail-open + Claude-adjudicates-and-gates, but with
--artifact <plan-file> --charter "$REPO/marketplace/plugins/himmel-ops/skills/minerva/plan-charter.md"
and the ledger records segmented as --artifact plan
(cr-scores.sh --artifact plan reports them). The Claude plan-critic remains the
gate; the panel is advisory.

After the loop: if interactive, present the hardened plan for approve/redirect;
if autonomous, proceed.

Terminal

You now hold a critic-hardened, approved implementation plan. What happens next
depends on the execute leg of the initiative grammar (HIMMEL-444). Read the
active legs (transport wrapper → the shared resolver; fail-open). Re-resolve the
scripts dir (this runs in a separate shell from the Mode section — same resolver,
byte-identical):

# >>> himmel-ops scripts resolver (CLAUDE_PLUGIN_ROOT is empty in a Codex skill shell)
S="${CLAUDE_PLUGIN_ROOT:+$CLAUDE_PLUGIN_ROOT/scripts}"
if [ -z "${S:-}" ] || [ ! -f "$S/autonomy-mode.sh" ]; then
  R="${HIMMEL_REPO:-}"; [ -f "$R/scripts/lib/initiative-legs.sh" ] || R="$(git rev-parse --show-toplevel 2>/dev/null || true)"
  [ -f "$R/scripts/lib/initiative-legs.sh" ] || R="$HOME/Documents/github/himmel"
  S="$R/marketplace/plugins/himmel-ops/scripts"
  [ -f "$S/autonomy-mode.sh" ] || for d in "$HOME"/.codex/plugins/cache/himmel/himmel-ops/*/scripts; do
    [ -f "$d/autonomy-mode.sh" ] && { S="$d"; break; }
  done
fi
# <<< himmel-ops scripts resolver
bash "$S/legs.sh" 2>/dev/null || true

Lint first (HIMMEL-4375). Run bash "$S/minerva-trace-lint.sh" <spec-file> <plan-file>
from the target repo before any hand-off. A non-zero exit names each gap:

• a missing or ungrepped Fact ownership row → back to the spec (1b);
• an invariant with no named test → back to the plan (Stage 3).

Do not hand off until it prints ok, in either mode.

• If mode is autonomous (Stage 0) AND the output contains execute: do NOT
  stop — invoke lean-skills:subagent-driven-development on the hardened plan
  to implement it task-by-task. This is the execute-seam auto-handoff that makes
  the loop continuous. (You remain the parent: own synthesis across the subagents.)

• Otherwise (interactive mode, or execute not active): minerva STOPS here — it
  does not start implementation. Offer the hand-off:

  Plan ready. Execute with lean-skills:subagent-driven-development
  (recommended) or lean-skills:executing-plans?

Interactive mode never auto-executes (a human is present to choose).