session-orchestrator 5.1.0 → 5.3.0

package/commands/eli5.md

@@ -1,33 +0,0 @@
----
-description: Say the last answer again in plain words — same facts, in the order the operator needs them. Optional topic argument.
-argument-hint: "[topic]"
----
-
-# eli5
-
-Invokes the `eli5` skill (`skills/eli5/SKILL.md`). Restates my last substantial output — or the named topic — for someone who knows this project but did not watch the last ten minutes of it.
-
-## Argument Validation
-
-The optional argument is a topic, in prose. If absent, the target is my own last substantial output in this conversation; if there is none yet, say so rather than picking a topic for him.
-
-Examples:
-- `/eli5` — restate what I just said
-- `/eli5 warum ist der Regel-Korpus voll?` — explain that, grounded in what this session measured
-
-## Behavior
-
-1. **Resolve the target** — last output, or `$ARGUMENTS`.
-2. **Ground it** — prefer what this session already measured over recall, and name where it came from. Never measured here → say so.
-3. **Restate** — consequence first (*must I act, and what if I don't?*), then the facts in the order he needs them.
-4. **Check before sending** — every greppable token from the original still present; every noun the system does not contain gone.
-
-## The limit that outranks the command
-
-**Simplifying removes words, never facts.** A dropped path, number, error code, identifier, or instruction to act is data loss, not simplification — `skills/session-start/soul.md` § "Never traded for brevity" outranks brevity here as everywhere. And no invented pictures: say what happens, never what it is "like".
-
-## Related
-
-- `skills/eli5/SKILL.md` — the skill, in full
-- `.claude/rules/ask-via-tool.md` § AUQ-006 — plain words, real things
-- `skills/session-start/soul.md` § Register — the canonical register statement

package/commands/eval.md

@@ -1,28 +0,0 @@
----
-description: Run an honest session-process evaluation (Standard v1, aiat-llm-eval/1.0) — score the last completed session against the pre-registered rubric-v1 dimensions
-argument-hint: "[--session <id>] [--no-write] [--verify <run-id>]"
----
-
-# Eval
-
-The user wants to run a session-process evaluation. Invoke the eval skill with arguments: **$ARGUMENTS**.
-
-Scores ONE completed orchestrator session against the pre-registered **rubric-v1**
-check set via the deterministic engine (`scripts/eval-session.mjs`), appends a
-`session-eval` record to the journal (`.orchestrator/metrics/eval.jsonl`), and —
-when configured — renders an HTML report and overlays an advisory LLM judge.
-Deterministic-first; **no global score, by construction**; missing data yields an
-honest `cannot-determine` rather than a guess.
-
-**Usage:**
-
-- `/eval` — evaluate the last completed session (resolution cascade), append the record, render the report
-- `/eval --session <id>` — evaluate a specific session_id
-- `/eval --no-write` — evaluate + report without appending to the journal (dry-run)
-- `/eval --verify <run-id>` — re-score a stored run and diff for drift (the reproducibility proof; exit 1 on drift)
-
-**Seams used:** `scripts/eval-session.mjs` (deterministic CLI) · `runEvalJudge` / `mergeJudgeDimensions` (judge.mjs, opt-in) · `writeEvalReport` (report.mjs) · `appendEvalRecord` (sink.mjs) · `eval` config block · `skills/eval/rubric-v1.md` (frozen check set)
-
-Reads the `eval` block (`enabled`, `mode`, `judge`, `report`, `handle`) from
-Session Config. On-demand `/eval` runs regardless of `eval.enabled` — that flag
-gates only the automatic session-end eval phase.

package/commands/evolve.md

@@ -1,10 +0,0 @@
----
-description: Extract session patterns into reusable learnings
-argument-hint: "[analyze|review|list|dialectic [--apply]]"
----
-
-# Evolve
-
-The user wants to extract and manage session learnings. Invoke the evolve skill with mode: **$ARGUMENTS** (if empty, default to `analyze`).
-
-Analyze session history for patterns, review existing learnings, list active intelligence, or derive USER.md/AGENT.md peer-card updates via the dialectic mode. Every learning must be confirmed by the user before persisting. Evidence before assertions.

package/commands/grill.md

@@ -1,45 +0,0 @@
----
-description: Stress-test a plan, design, or PRD before any build — relentless one-question-at-a-time interrogation that hunts contradictions against the code and challenges assumptions. Composable; no HARD-GATE.
-argument-hint: "[file-path-or-topic]"
----
-
-# Grill
-
-Invokes the `grill` skill (`skills/grill/SKILL.md`). Relentlessly interrogates a plan/design/PRD one decision at a time, grounds every question in the codebase, and surfaces contradictions before implementation. Optionally writes `docs/specs/YYYY-MM-DD-<slug>-grill.md`.
-
-## Argument Validation
-
-The optional argument is either a file path to grill (a PRD, spec, `STATE.md`) or a topic/slug. If absent, the skill grills the plan already present in the current conversation; if there is none, it asks the user to state it first.
-
-Examples:
-- `/grill` — grills the plan in the current conversation context
-- `/grill docs/prd/2026-06-09-export.md` — grills a specific PRD file
-- `/grill "partial order cancellation"` — grills the named idea, slug pre-set
-
-## Behavior
-
-1. **Phase 0 — Target Acquisition** — resolve what's being grilled, ground it against the codebase (`CONTEXT.md`, steering docs, ADRs, relevant source), state the target back.
-2. **Phase 1 — Map the Decision Tree** — lay out the dependent decisions root-to-leaf; skip what the code already settles.
-3. **Phase 2 — Grill Loop** — one question per turn via `AskUserQuestion`, applying the Six Tactics (glossary conflict, sharpen fuzzy language, code contradiction, edge-case scenario, assumption audit, pre-mortem); read the repo before asking.
-4. **Phase 3 — Resolved-Decisions Recap** — decisions, contradictions surfaced, open questions, assumptions audited.
-5. **Phase 4 — Hand-off** — AUQ: write grill summary + `/plan feature`, summary only, hand off without a file, or done.
-
-## No HARD-GATE
-
-Unlike `/brainstorm`, grill imposes no implementation gate — it is a composable thinking tool. It writes no code and never commits; the only write it performs is the optional summary file in Phase 4. What happens after the grill is the user's call.
-
-## When to use vs. /brainstorm and /plan feature
-
-| Situation | Use |
-|-----------|-----|
-| A settled-feeling plan needs stress-testing before build | `/grill` |
-| The design is still ambiguous and needs narrowing | `/brainstorm` |
-| Scope is clear, need a formal PRD + issues | `/plan feature` |
-| Adversarial pass before formalizing | `/grill` → `/plan feature` |
-
-## Related
-
-- `skills/grill/SKILL.md` — full skill specification
-- `skills/brainstorm/SKILL.md` — cooperative sibling for ambiguous designs
-- `skills/plan/SKILL.md` — primary hand-off target
-- `.claude/rules/ask-via-tool.md` — AUQ usage convention (AUQ-001..005)

package/commands/memory-cleanup.md

@@ -1,26 +0,0 @@
----
-description: Manual memory consolidation — review, consolidate, and prune memory files (Dream-equivalent)
-argument-hint: "[--dry-run | --apply-pending]"
----
-
-# Memory Cleanup
-
-The user wants to consolidate the project's auto-memory store. Invoke the `memory-cleanup` skill.
-
-## Flags
-
-The skill accepts two optional, mutually-exclusive flags (see PRD #502):
-
-| Flag | Behavior |
-|---|---|
-| `--dry-run` | Run Phases 1-3 read-only. Writes a complete-replacement MEMORY.md proposal (single fenced ` ```markdown ` block; topic-file changes carried as separate `### Topic-file change:` sections after it — never git-style diff hunks, see #717) to `.orchestrator/pending-dream.md` (atomic write). Prints `pending-dream written: <N> lines proposed` (or `no consolidation needed`). Exit 0. <!-- path-check: example --> |
-| `--apply-pending` | Reads `.orchestrator/pending-dream.md`, refuses if older than 14 days or if MEMORY.md changed since the producing `--dry-run` (#788), applies the proposal, deletes the pending file. Prints `auto-dream applied: -<X> lines, +<Y> entries`. Exit 0 on apply; exit 1 when pending file is missing (`no pending dream to apply`), stale (`pending dream is stale (>14d), re-run --dry-run`), index-drifted (`MEMORY.md changed since the producing --dry-run; re-run --dry-run.`), or unsupported-format (`auto-dream NOT applied: pending-dream.md contains git-style diff hunks this applier cannot consume. MEMORY.md left untouched, sidecar preserved. Re-run /memory-cleanup --dry-run to regenerate a complete-body proposal.`). <!-- path-check: example --> |
-
-Passing both flags is an error. Absence of both = legacy interactive 4-phase mode.
-
-Session-end Phase 3.6.5 (`scripts/lib/auto-dream.mjs`) is nudge-only (#614) — it never dispatches a subagent to write the sidecar.
-The only real producer of `.orchestrator/pending-dream.md` is a manual `/memory-cleanup --dry-run` run; `--apply-pending` is the operator-confirmed consumer in a later session. The sidecar file is single-writer — concurrent sessions cannot collide because the writer holds the session-lock. <!-- path-check: example -->
-
-## Default (no flag)
-
-Run the 4-phase Dream process (Orient → Gather Signal → Consolidate → Prune & Index) against `~/.claude/projects/<encoded-cwd>/memory/`. Report files changed, `MEMORY.md` line count before/after, contradictions resolved, and any items that need manual attention.

package/commands/persona-panel.md

@@ -1,121 +0,0 @@
----
-description: Run a parallel multi-persona domain-expert review panel against a file, directory, or output range
-argument-hint: "<target> [--personas <names,...>] [--mode <voting|hard-gate|summary>] [--threshold <M-of-N|all|any>] [--grounding <off|re-derive>] [--dry-run]"
-disable-model-invocation: false
----
-
-# Persona Panel
-
-Dispatches N personas from the per-repo `.claude/personas/` catalog in parallel (one `Agent()` call per persona), consolidates their outputs, persists a sidecar to `.orchestrator/persona-panel/`, and reports the final verdict. Invoke the `persona-panel` skill with arguments: **$ARGUMENTS**
-
-## Argument Validation
-
-Parse `$ARGUMENTS` before doing anything else.
-
-**Positional argument (required):**
-
-- `<target>` — file path, directory, or range to review. Must be resolvable via `validatePathInsideProject` against the current project root. Relative paths are resolved from the project root. Globs are accepted (e.g., `src/app/api/*.ts`).
-
-**Recognized flags:**
-
-- `--personas <names,...>` — comma-separated subset of catalog names to include (e.g., `physicist,ai-expert`). Default: all personas discovered in `.claude/personas/`. Names are matched case-insensitively against `<name>.md` catalog files.
-- `--mode <voting|hard-gate|summary>` — consolidation mode. Default: `voting`.
-  - `voting` — M-of-N quorum; deterministic. Requires `--threshold M-of-N` or defaults to `all`.
-  - `hard-gate` — all N personas must PASS; deterministic. `--threshold all` is the default; `--threshold N-of-N` is also accepted.
-  - `summary` — coordinator LLM-aggregate of heterogeneous outputs. Emits an explicit WARN that this mode adds one additional LLM call.
-- `--threshold <spec>` — quorum spec. Accepted forms: `M-of-N` where M and N are integers 1..20, `all`, or `any`. Parsed by `scripts/lib/persona-panel/threshold.mjs::parseThreshold()`. Default: `all`.
-- `--grounding <off|re-derive>` — Grounding-Review mode (#730 Epic H). `off` (default): personas evaluate the target as-is. `re-derive`: each persona is instructed to independently re-derive supporting sources via Read/Grep/Glob instead of trusting a "Sources" section the target may already assert, and reports them as `derived_sources`. Advisory-only in v1 — never influences `final_verdict`. See `skills/persona-panel/persona-format.md` § "Grounding Mode (optional)".
-- `--dry-run` — resolve catalog, print dispatch plan, do NOT call `Agent()`, do NOT write sidecar. Exit 0 on success.
-
-**Validation errors (all exit 1):**
-
-- Missing `<target>`: `missing required arg <target>`.
-- Unknown flag (starts with `--` but not in the list above): `unknown flag: --<name>. Valid: --personas, --mode, --threshold, --grounding, --dry-run`.
-- `--mode` value not in enum: `invalid --mode value: '<value>'. Valid: voting, hard-gate, summary`.
-- `--threshold` value fails `parseThreshold()`: echo the parser error verbatim, e.g., `invalid threshold 'foo': expected M-of-N (M,N integers 1..20), 'all', or 'any'`.
-- `--grounding` value not in enum: `invalid --grounding value: '<value>'. Valid: off, re-derive`.
-- `<target>` outside project root: `target path outside project: <path>`.
-
-If `<target>` is missing, print the usage line and exit 1 without invoking the skill.
-
-## Behavior
-
-**Phase 1 — Catalog Discovery**
-
-The skill scans `.claude/personas/*.md` in the current repo. Each file must have YAML frontmatter with at minimum `name`, `role`, and `tier`. If `--personas` is given, only matching files are loaded; unmatched names produce a warning but do not abort (the remaining personas proceed). If zero personas are resolved after filtering, exit 1 with: `no personas resolved — check .claude/personas/ or --personas filter`.
-
-**Phase 2 — Target Resolution**
-
-`<target>` is validated via `validatePathInsideProject`. Globs are expanded; directories are passed as-is for the skill to recurse. The resolved target is attached to each persona's prompt context.
-
-**Phase 3 — Parallel Dispatch**
-
-One `Agent()` call per resolved persona. Agents run with the persona's `model` frontmatter field (default `claude-opus-4-7`). Each agent receives the persona body as its system prompt and the target file content (or directory listing) as context. Agent outputs are collected in an `outputs[]` array keyed by persona name.
-
-**Phase 4 — Consolidation**
-
-Mode determines the consolidation strategy:
-
-- `voting` — count PASS verdicts. Apply `--threshold` to determine final verdict. Dissenting personas (FAIL or UNCLEAR) are listed explicitly.
-- `hard-gate` — all resolved personas must return PASS. Any single FAIL or UNCLEAR produces a final verdict of FAIL. Dissenting personas are listed.
-- `summary` — coordinator LLM call aggregates heterogeneous outputs into a structured narrative. A WARN is emitted before dispatch: `summary mode adds one additional LLM call`.
-
-**Phase 5 — Sidecar Persist + Report**
-
-Unless `--dry-run`, a sidecar is written to `.orchestrator/persona-panel/<isoTs>-<run-id>.json` matching the schema at `agents/schemas/persona-panel-sidecar.schema.json`. The sidecar includes `run_id`, `target`, `personas_invoked[]`, `outputs[]`, and `consolidation` (mode, final-verdict, dissenting-personas, audit-reason).
-
-The command emits a summary line to stdout:
-
-```
-persona-panel: <final-verdict> (<M>/<N> PASS) — sidecar: .orchestrator/persona-panel/<filename>.json
-Dissenting: <name1>, <name2>  [omitted when none]
-```
-
-## Examples
-
-**1. Default — all catalog personas, voting mode:**
-
-```
-/persona-panel src/app/api/invoices.ts
-```
-
-Loads all `.claude/personas/*.md`, dispatches one agent per persona, applies voting with threshold `all`, writes sidecar.
-
-**2. Specific personas:**
-
-```
-/persona-panel src/app/api/invoices.ts --personas physicist,ai-expert
-```
-
-Only the `physicist` and `ai-expert` catalog entries are dispatched. Others are skipped.
-
-**3. Hard-gate mode, unanimous threshold:**
-
-```
-/persona-panel notes/draft.md --mode hard-gate --threshold all
-```
-
-All resolved personas must return PASS. A single FAIL produces a final FAIL verdict.
-
-**4. Dry-run — inspect dispatch plan without executing:**
-
-```
-/persona-panel src/ --dry-run
-```
-
-Resolves catalog and target, prints the planned dispatch list (persona names, models, target), exits 0 without calling `Agent()` or writing a sidecar.
-
-**5. Grounding-review mode — personas re-derive their own sources:**
-
-```
-/persona-panel docs/design-doc.md --grounding re-derive
-```
-
-Each dispatched persona is instructed to independently re-derive supporting sources via Read/Grep/Glob rather than trusting a "Sources" section already present in the input document (for example, `docs/design-doc.md`), and reports them as `derived_sources`. Advisory-only — `final_verdict` is unaffected. <!-- path-check: example -->
-
-## Related
-
-- `skills/persona-panel/SKILL.md` — skill spec: 6 phases, catalog format, dispatch mechanics, consolidation logic, sidecar schema
-- `agents/schemas/persona-panel-sidecar.schema.json` — AJV Draft 2020-12 sidecar schema
-- Issue #458 — wave-hook integration (persona-panel as inter-wave quality gate)
-- Issue #460 — trend tracking across persona-panel runs

package/commands/plan.md

@@ -1,15 +0,0 @@
----
-description: Plan a new project, feature, or retrospective with structured requirement gathering
-disable-model-invocation: true
-argument-hint: "[new|feature|retro]"
----
-
-# Plan
-
-You are beginning a structured planning session. The user has invoked `/plan` with mode: **$ARGUMENTS** (if empty, ask the user which mode they want: `new`, `feature`, or `retro`).
-
-**Modes:** `new` = project kickoff, `feature` = feature PRD, `retro` = retrospective.
-
-**Your job: Guide the user through structured requirement gathering and produce a complete plan document for the chosen mode.**
-
-**Invoke the plan skill.** Follow its instructions precisely. Do NOT skip any phase. Do NOT make assumptions — gather requirements interactively.

package/commands/reconcile.md

@@ -1,23 +0,0 @@
----
-description: Reconcile learnings into .claude/rules/ proposals — on-demand version of session-end Phase 3.6.8
-argument-hint: "[--dry-run]"
----
-
-# Reconcile
-
-The user wants to reconcile learnings into rule proposals. Invoke the reconcile skill with arguments: **$ARGUMENTS**.
-
-Runs the same pipeline as session-end Phase 3.6.8: filters eligible learnings from
-`.orchestrator/metrics/learnings.jsonl`, renders proposed `.claude/rules/<slug>.md` entries,
-and presents them to the operator via AUQ multiSelect (batches of 4) for approval before
-writing. Advisory-only — no rule is ever written without explicit operator confirmation.
-
-**Usage:**
-
-- `/reconcile` — full approval flow: engine → AUQ → write approved rules
-- `/reconcile --dry-run` — print proposals and rejections without writing anything or rendering the AUQ prompt
-
-**Engine seams used:** `runReconcile` (engine.mjs) · `writeApprovedRules` (writer.mjs) · `reconcile` config block · `.claude/rules/` write target
-
-Reads `reconcile.rule-expiry-days` and `reconcile.confidence-floor` from Session Config.
-The `reconcile.enabled` flag is NOT checked — this command always runs on-demand.

package/commands/repo-audit.md

@@ -1,24 +0,0 @@
----
-description: Run a 9-category baseline compliance audit on the current repository
-argument-hint: ""
----
-
-# Repo Audit
-
-The user wants to audit the current repository against the ecosystem baseline. There are no arguments.
-
-Invoke `skills/repo-audit/SKILL.md` to perform the audit.
-
-The skill will:
-1. Read Session Config to resolve `test-command`, `typecheck-command`, and `lint-command` (falls back to `pnpm test --run`, `tsgo --noEmit`, `pnpm lint`)
-2. Detect Clank integration markers (`.clank/`, `clank.config.*`) — Category 8 is skipped if absent
-3. Run all 9 audit categories with status: ✓ pass / ✗ fail / ⚠ warn / skipped
-4. Emit a structured Markdown report to stdout
-5. Write a JSON sidecar to `.orchestrator/metrics/repo-audit-<timestamp>.json`
-
-Do NOT skip any category (except Clank when not detected). Do NOT auto-fix findings — report only.
-
-Distinguish from related commands:
-- `/discovery` — broad quality probes, interactive triage, creates issues
-- `/harness-audit` — plugin installation health (is session-orchestrator installed correctly?)
-- `/repo-audit` — consuming-repo compliance (does this repo match the ecosystem baseline?)

package/commands/spinout.md

@@ -1,15 +0,0 @@
----
-description: Guided 5-step venture-spinout / sanitized-fork runbook (copy + fresh-init + SNAPSHOT-FREEZE) — interactive, not scripted
-argument-hint: "[--type venture|snapshot] [--dry-run]"
----
-
-# Spinout
-
-The user wants to extract this project (or a sub-path of it) into a new standalone repo — a venture spinout or a sanitized content-snapshot fork. Invoke the `spinout` skill.
-
-## Flags
-
-| Flag | Behavior |
-|---|---|
-| `--type venture\|snapshot` | Skips the extraction-type question in Phase 1 (`AskUserQuestion`) — still asks for destination path and sphere. |
-| `--dry-run` | Runs all 5 phases as a plan-print (target, sanitize checklist, copy plan, freeze-marker draft, remote plan) with no writes. |

package/commands/sunset-review.md

@@ -1,27 +0,0 @@
----
-description: Identify unused / near-zero-use / stale skills, agents, and commands as Demote or Retire candidates (read-only; never deletes)
-argument-hint: "[--kind skill|agent|command] [--window-days N]"
----
-
-# Sunset Review
-
-The user wants to identify which skills, agents, and commands in the plugin surface are still in use and which are candidates to demote or retire. Optional arguments narrow the scope: `--kind` limits to one surface kind, `--window-days` overrides the default 90-day dispatch window.
-
-Invoke `skills/sunset-review/SKILL.md` to perform the review.
-
-The skill will:
-1. Resolve the dispatch window (default 90 days; honour any `--window-days` override)
-2. Run the read-only walker `node scripts/lib/sunset/walker.mjs --json` to combine agent-dispatch telemetry (start-events only) with static reference scanning
-3. Classify every surface item into Active / Investigate / Demote / Retire, grouped for review
-4. Emit a Markdown report + JSON sidecar at `.orchestrator/metrics/sunset-review-<timestamp>.{md,json}`
-5. Record the run time for the quarterly cadence nudge
-
-Critical guardrails:
-- The walker is READ-ONLY and NEVER deletes a skill/agent/command. It surfaces candidates for human decision only.
-- Telemetry only spans ~18 days, so the 90-day window cannot be satisfied — every Retire verdict is downgraded to Investigate and `meta.lowConfidence` is set. Do not retire anything while low-confidence.
-- Draft-issue creation for candidates is a coordinator-side AskUserQuestion decision (AUQ-004) — a dispatched agent cannot file issues itself.
-
-Distinguish from related commands:
-- `/repo-audit` — does this repo match the ecosystem baseline? (compliance pass/fail)
-- `/sunset-review` — which parts of OUR surface are unused? (prune candidates)
-- `/harness-audit` — is session-orchestrator installed correctly? (plugin health)

package/commands/ux-grill.md

@@ -1,51 +0,0 @@
----
-description: Grill a running web app's UX — a deterministic mechanical pass (axe, target size, overflow, journeys) followed by a screenshot-grounded interrogation of the operator.
-argument-hint: "[url | manifest-path]"
----
-
-# UX-Grill
-
-Invokes the `ux-grill` skill (`skills/ux-grill/SKILL.md`). Stufe 1 measures a running loopback build route-by-route and viewport-by-viewport without any model judgment, writing `findings.jsonl` plus screenshots under `.orchestrator/metrics/ux-grill/<run-id>/` <!-- path-check: example -->. Stufe 2 then grills the operator journey by journey — one question per journey finding, every claim carrying a screenshot path. The user invoked `/ux-grill` with arguments: **$ARGUMENTS**
-
-## Argument Validation
-
-Parse `$ARGUMENTS` before anything else. Exactly one positional argument is recognised:
-
-- **An absolute `http(s)` URL** (e.g. `http://127.0.0.1:3100`) → bootstrap path. The target repo has no manifest yet; the skill asks for the env names, crawls the navigation and writes one. The URL must be loopback — anything else is refused before a browser starts.
-- **A file path** (ends in `.md`, or resolves to an existing file) → treat it as the manifest path, repo-relative to the target repo.
-- **Empty** → the manifest at `DEFAULT_MANIFEST_PATH` (`.orchestrator/ux-manifest.md` <!-- path-check: example -->). If that file does not exist, say so and name the bootstrap form `/ux-grill <url>` — do not invent a manifest from nothing.
-- **Anything else** → stop with: `ux-grill: argument must be a loopback URL or a manifest path (default .orchestrator/ux-manifest.md)`.
-
-Examples:
-- `/ux-grill` — runs against the target repo's existing manifest
-- `/ux-grill http://127.0.0.1:3100` — first run: AUQ for env names, crawl, write the manifest, stop with a fill-in hint
-- `/ux-grill .orchestrator/ux-manifest.md` — explicit manifest path
-
-## Behavior
-
-1. **Phase 0 — Target + Stufe 1** — resolve the argument, bootstrap or `loadManifest()`, run the mechanical pass as one coordinator-direct Bash call, then compare against the last run with the same `manifest_hash`.
-2. **Phase 1 — Journey map** — understand / decide / act / recover per journey step, from the step screenshots; mechanical findings tabled per route.
-3. **Phase 2 — Grill loop** — at most one `AskUserQuestion` per JOURNEY finding, option 1 `(Recommended)` with its cost, screenshot path in the description.
-4. **Phase 3 — Recap** — resolved decisions, contradictions between screens (the primary output), open questions, mechanical counts including everything skipped.
-5. **Phase 4 — Hand-off** — AUQ: audit dossier in the target repo, vault note, issues only, or done.
-
-## No CI, no HARD-GATE
-
-Stufe 1 is built CI-shaped (deterministic, exit-coded, LLM-free) but is deliberately not wired into any pipeline — the PRD's dose argument. `/ux-grill` gates nothing: it writes measurement artefacts, an optional dossier and — only through `reconcile.mjs` <!-- path-check: planned #1327 --> — issues. It never commits, never pushes, never edits product code.
-
-## When to use vs. /test and /grill
-
-| Situation | Use |
-|-----------|-----|
-| A running web app's UX and journeys need measuring and interrogating | `/ux-grill` |
-| A CI-shaped end-to-end run with driver + `ux-evaluator` over an existing profile | `/test` |
-| A plan, PRD or design needs stress-testing before any build | `/grill` |
-| Per-wave design drift against the design source | `design-reviewer` (SO#1300) |
-
-## Related
-
-- `skills/ux-grill/SKILL.md` — full skill specification (phases, budgets, hand-off)
-- `skills/ux-grill/rubric-v2.md` — check catalogue, severity table, skip reasons
-- `templates/_shared/ux-manifest.template.md` — the manifest a target repo commits
-- `skills/test-runner/SKILL.md` — severity routing and batched AUQ triage, adopted here
-- `.claude/rules/ask-via-tool.md` — AUQ usage convention (AUQ-001..006)