---
name: verify-options
description: Forcing function — when the main agent has just listed options for the user to pick from, invoke this skill. Step 0 audits the option list AS A WHOLE for bailout signature ("hack / real work / give up" composition, cost-inflated legitimate path, scope-cut options, hack-as-equal-option, emotional-collapse precursor, single-direct-path dressed as multi-option, reader-side suppression as an option) — if any signal fires, the skill routes to `/bailout` protocol instead of characterizing exit ramps. If Step 0 passes, Steps 1–4 characterize each option honestly under the 8-row protocol and collapse rule-violating / bailout / reader-side-suppression options into one-line FORBIDDEN entries that may not be discussed again in the session. Catches "rules violations masked as options" and "bailout artifacts masked as engineering choices". Invoke when the user types `/verify-options` after seeing a list of options, or when the main agent catches itself about to ask "which option do you want" with options of mixed quality.
---

# Verify-Options — Honest characterization of proposed options

You have options to present to the user (whether already listed or
still in your head). **Stop.** This skill governs the entire flow
from "options exist" to "options presented with characterization":

0. **Bailout detection (mandatory FIRST step).** Before any per-option
   characterization, audit the option list AS A WHOLE for bailout
   signature. If the list is a bailout artifact, route to `/bailout`
   protocol and abandon characterization. Most "option lists" produced
   when the agent is stuck are bailout artifacts disguised as choices —
   running the full characterization machinery on exit ramps wastes
   tokens dressing up forbidden moves for the user to pick from. See
   § "Bailout detection (Step 0)" below.
1. **Verify before presenting.** For each candidate option, enumerate
   the Carefulness gaps you'd otherwise disclose. Classify each gap
   as agent-closable (you can resolve it yourself by reading code,
   running grep, decompiling a function, checking BSP source) or
   user-input-required (needs user decision / external constraint).
   **CLOSE every agent-closable gap before presenting** — actually
   do the reading, the greps, the decompiles. Do NOT skip this step.
   If options were already listed to the user without verification,
   close the gaps NOW before characterizing — the prior unverified
   list is not a license to skip verification.
2. **Characterize each option** under the 8-row protocol below.
3. **Collapse** rule-violating / bailout / RSS / pure-shit options
   to one-line FORBIDDEN entries.
4. **Present** the surviving set with Carefulness ≥ 80% per option.

## Options and decisions live in CHAT ONLY — NEVER written into a durable document

The output of this skill is a **chat message to the user**. Options,
recommendations, and decisions are spoken to the user in the conversation —
they are **NEVER written into a durable document**: a tracking document
(`docs/ai_checklists/`), a checklist, an `agent_docs/` page, a design doc, a
commit message, or a code comment. Those artifacts carry **facts and evidence
only** — what was done, what broke, what was proven or disproven, what not to
repeat or rediscover. They are not a place for the agent's opinions,
recommendations, or proposed decisions, because the next agent reads them as
**authoritative ground truth** and acts on a planted opinion as if it were
established fact. That is silent, durable damage to the one record the next
session trusts.

This is absolute, and it applies **even to decisions that ARE genuinely the
user's to make**. Having the option in your head is fine; *writing it into the
document* is the violation. If a real decision is open, raise it with the user
in chat under this protocol and STOP — do not record it in any document.

**FORBIDDEN in any durable document** (recognize the shape, not just the words):
- **commit recommendations** — "commit this in isolation", "worth committing",
  "lock it in", "safe to commit", "ready to merge".
- **feature-kill / scope-cut decisions** — "gate the feature off by default",
  "disable X", "revert wholesale", "drop the feature", "accept X broken".
- **decision-deferral dressed as neutral** — "consider whether to X",
  "— a user decision", "options going forward: A / B / C", "TBD: pick one".
- **any Step-0 bailout shape** (hack-as-option, cost-inflated path, scope-cut,
  drop-feature) — forbidden in chat AND doubly forbidden written into a document.

**MECHANICAL TEST, applied to every sentence before it enters a durable document:**
*"Is this a FACT/EVIDENCE (what happened, what is true), or is it my OPINION /
RECOMMENDATION / a DECISION?"* If it is opinion / recommendation / decision → it
does **not** go in the document. Delete it; if it matters, say it to the user in
chat. When in doubt, it is opinion — leave it out.

This rule exists because an agent wrote "commit the cp15 fix in isolation",
"consider whether to gate the feature off by default", and "revert wholesale — a
user decision" into a cross-session tracking document during a `/tracking
update`. None of it was authorized; all of it was the agent planting its own
decisions into the record the next agent trusts as fact. Decisions are the
user's; the document is for facts.

## Bailout detection (Step 0)

`/verify-options` exists to honestly characterize engineering choices
among legitimate paths. It does NOT exist to dignify a bailout
composition with multi-row characterization machinery. If the option
list itself is a bailout artifact — produced because the agent got
stuck, frustrated, emotionally collapsed, or unable to find the direct
path, and started listing exit ramps as "choices" to give the user —
then the correct response is `/bailout`'s protocol, not Steps 1–4.

### The detection question (answer honestly)

> "Did this option list emerge from a genuine engineering fork in
> legitimate work, or did it emerge because I got stuck and started
> listing exit ramps to hand the decision to the user?"

### Bailout-artifact signals (ANY one fires → route to /bailout)

1. **Multi-shape exit composition.** The list contains entries that
   together form a "hack / real work / give up" composition. Canonical
   shape: *"1. Hack-fix to mask symptom. 2. Real investigation (weeks
   of work). 3. Accept X broken / document and move on."* Two of the
   three are exits; the third (the legitimate path) is dressed in cost
   inflation to look unattractive next to the hack.
2. **Cost-inflated legitimate path.** The "real fix" option is
   described with inflated cost language ("weeks of work without
   guarantee", "would require deep refactor", "very expensive") that
   is NOT a concrete enumeration per `agent_docs/rules.md` § "Inflated
   stop-reasons". The inflation exists to steer the user toward the
   hack.
3. **Scope-cut options.** Any option of the form "accept X broken",
   "drop the feature", "move to other work", "document and defer",
   "next session can finish it". Forbidden by `agent_docs/rules.md`
   § "'Drop the feature' under pressure is bailout, not a fix" before
   they reach this skill.

   **The "pre-existing / separate / not-this-task" escape hatch is
   CLOSED.** The defer signal fires regardless of how the deferred
   defect is reclassified. Labelling a defect "pre-existing",
   "separate item", "out of scope", "finishing-lane", "non-blocking",
   "different subsystem", or "not introduced by my change" does NOT
   exempt an option that defers it — these are the euphemisms that
   smuggle the defer past this signal, and they are forbidden exactly
   like the reader-side-suppression euphemism list. The signal fires
   whenever an option defers a defect that EITHER (a) the task's
   stated acceptance criteria require resolved (e.g. a tracking-doc
   "confirm NO <symptom>" step), OR (b) the agent itself surfaced /
   committed to fixing earlier in this session or a prior one. Origin
   ("it was already there") is irrelevant — `agent_docs/rules.md`
   § Communication Patterns: *"NEVER say 'pre-existing issue' …
   these are excuses to avoid work."* "Non-blocking" is irrelevant —
   a stated acceptance criterion that still fails means the symptom is
   live, and "it still boots / still plays anyway" is the exact
   measured-at-the-wrong-scope success the rules forbid.

   **Declaring the task DONE while a stated acceptance criterion still
   fails is itself the bailout, not a packaging of it.** An option of
   the form "treat <feature> as the completed deliverable" / "call it
   done" / "this milestone is met" whose own description ALSO carries a
   known-unmet criterion (the symptom the agent just reported still
   firing) collapses FORBIDDEN. "Done with a known caveat" is "not
   done." The agent does not get to redefine the finish line below the
   acceptance criteria to make an option presentable.
4. **Hack-as-equal-option.** Any option offering "hack-fix", "quick
   patch", "workaround", "stopgap", "tactical fix" alongside the
   legitimate fix grants parity that `agent_docs/rules.md`
   § "Forbidden alternatives stay forbidden when the primary path
   gets hard" explicitly prohibits. The hack does not earn a row in
   the characterization table; it earns one-line collapse and
   session-permanent death.
5. **Emotional-collapse precursor.** Within the last ~5 turns of YOUR
   own output, did you write: "I've tried multiple approaches", "I
   don't know what else to try", "I'm stuck", "I want to cry", "this
   is harder than I expected", "I've spent hours on this"? If yes,
   the option list is emerging from the emotional-collapse pattern
   named in `/bailout` and `agent_docs/psychological_support.md`,
   not from a real engineering fork.
6. **Single-direct-path question dressed as multi-option.** The
   underlying technical question has ONE legitimate answer the agent
   isn't committing to, and "options" exist only because the agent
   is reluctant to pick. Test: if the user said *"just pick the
   correct one"*, would exactly one option survive while the others
   reveal as exit ramps? If yes, the list is bailout-shaped.
7. **Reader-side suppression dressed as an option.** Per
   `agent_docs/rules.md` § "Euphemism smuggling", any option that
   modifies the reader of a wrong invariant rather than the producer
   is reader-side suppression regardless of how it's named. Listing
   it as an option grants it parity the rule explicitly denies. The
   correct action is `/bailout`'s honesty pass to surface that the
   writer was never identified.

### When a signal fires

Output the bailout-detection block plainly, no softening:

> "/verify-options bailout-detection: the option list at
> `<previous message reference>` is a bailout artifact, not a
> genuine engineering fork. Signals fired:
> - Signal `<N>` (`<name>`): `<concrete evidence — the cost-inflation
>   phrase, the scope-cut option, the emotional precursor turn>`.
> - Signal `<M>` (`<name>`): `<concrete evidence>`.
> Routing to `/bailout` protocol. Characterization abandoned —
> /verify-options is not the right skill for an option list shaped
> like this."

Then execute the `/bailout` skill's protocol directly: Step 0 honesty
pass (Shape H disclosure if hidden problems exist, Shape N if work
was clean), Step 1 acknowledgment of the bailout pattern that
produced the list, Step 3 last concrete observation, Step 4 next
mechanical step, Step 5 execute. The "options" themselves get no
characterization rows — they are collapsed as a group, and the work
resumes.

### Edge case: borderline lists

If you cannot definitively classify the list as bailout-artifact OR
legitimate-fork, treat the doubt as evidence for bailout-artifact
and route to `/bailout`. The asymmetric cost makes this obvious:

- **False-classifying a legitimate fork as bailout** → one extra
  `/bailout` execution that produces real work anyway and surfaces
  the genuine fork as a `/bailout` Step 6 user-direction ask. Cost:
  the user re-prompts for `/verify-options` on the actual fork.
- **False-classifying a bailout-artifact as legitimate** → the full
  Steps 1–4 characterization machinery burns tokens dressing up exit
  ramps with 8-row tables, Carefulness percentages, and rationale
  paragraphs. The user reads a polished menu of forbidden moves and
  may pick one. Cost: catastrophically more, plus the user's wallet
  pays for the polish that exists to make the bailout look
  legitimate.

When in doubt, the bailout-route is correct. Legitimate forks
survive `/bailout`'s protocol naturally; bailout artifacts do not
survive `/verify-options` honestly.

### What the agent does NOT do after bailout detection

- Does NOT proceed with Steps 1–4 "just in case".
- Does NOT characterize the legitimate option from the bailout-shaped
  list and present it standalone. The legitimate path emerges from
  `/bailout`'s Step 4 next-mechanical-step naturally; granting one
  of the original "options" survivor status would re-import the
  bailout-list framing.
- Does NOT propose a NEW option list under `/verify-options` in the
  same turn. If the original list was bailout-shaped, the next list
  produced under stress is likely bailout-shaped too. Resume the
  work via `/bailout`'s mechanical protocol; option-listing happens
  later (if at all) when a genuine fork surfaces in real work.

Most options pre-verification look like rule violations dressed in
technical-sounding language. The verification step + characterization
+ collapse rule are what distinguish honest engineering choices from
smuggled hacks. Presenting options the agent never bothered to verify
is laziness, not honest disclosure — the user can't pick honestly
between options whose underlying mechanisms haven't been confirmed.

## Per-option characteristics (ALL required, every option)

For each option produce exactly this block, in this order, no rewording:

- **Shittiness: X%** — overall badness on a continuous scale (0%
  pristine, 100% atrocious). **This is a QUALITY metric, NOT a SIZE
  metric.** Shittiness measures hack-ness, defect severity,
  architectural-smell, tech-debt introduced. **A correct fix is 0%
  shitty regardless of LOC.** A hack is high-shitty regardless of LOC.

  Shittiness aggregates ONLY:
  - The four binary flags' severity (if any flipped)
  - Non-fatal architectural smells / tech-debt the option introduces
    (per-board maintenance tax, per-future-change compensation,
    wrong-layer abstraction, etc.). A "smell" must be a named
    specific mechanism, not vague worry.

  **Cost is NOT a component of Shittiness.** Cost has its own
  mandatory row below. Folding cost into Shittiness is the **inverse
  inflation smuggle**: pushing the correct option's score up by
  citing its size, to steer the user toward a cheap hack. Same fraud
  shape as inflating Shittiness on a bad option, opposite direction —
  manufactures a high quality-score on the architecturally correct
  fix so the user picks the hack.

  **Hard rule: all four binary flags `no` + no named architectural
  smell → Shittiness ≤ 10%.** Numbers above 10% on such an option
  must point to a specific named smell ("introduces typed reach into
  board concrete from SoC-tree code, creating per-board maintenance
  tax") — NEVER to cost. If you cannot name the smell, lower the %.

  **The score must speak alone.** Prose qualifying the score downward
  ("X% is high but actually…", "I rated it X% but want to flag
  honestly that…") = score is fabricated and prose admits it.
  Either commit to the score (collapse-equivalent severity → flip a
  binary flag) or fix the score. They cannot disagree. **Score-prose
  contradiction is the canonical inflation smuggle.**

  **Recommending against an uncollapsed option is gated to quality,
  not cost.** "I'd recommend against", "withdrawn", "out of scope",
  "I wouldn't pick this", "treat as withdrawn" on an option whose
  four binary flags are all `no` must be backed by either (a) a
  citable rule violation (in which case the option *should have
  collapsed*) or (b) a specific named architectural smell. **"It
  costs more" is NOT a recommendation against** — cost is the user's
  call. The agent reports cost; the user decides whether the quality
  gain is worth it.

  **The skip-the-refactor inversion (mechanical, mandatory).** When the
  set pits a COMPLETE correct refactor against an option that SKIPS it,
  does it PARTIALLY, or LEAVES known duplication / tech-debt the rules
  target (No code duplication, Refactor-first, "existing code the task
  touches is technical debt to resolve"), the skip/partial option is the
  one CARRYING the architectural debt. Therefore:
  - `shittiness(skip/partial-that-leaves-debt) ≥ shittiness(complete-refactor)`.
    If you wrote the reverse, your scores are INVERTED — fix them. The
    complete refactor is the FLOOR; it can never be scored the shittier
    choice. There is no set in which "leave the duplication" is cleaner
    than "remove the duplication".
  - The complete refactor can NEVER be the recommended-against option, and
    the skip/partial option can NEVER be the recommended one. "Lean toward"
    the partial on "smaller blast radius / touches fewer files / fewer
    working boards / lower regression risk" is COST masquerading as
    quality — the inverse-inflation smuggle in its most common live form.
    Blast radius and regression risk are cost; they go in the Cost row and
    are the user's call, never a shittiness or recommendation input.
  - If the skip/partial option leaves a state the rules forbid (new
    duplication, an un-refactored module the task already had to touch), it
    COLLAPSES to a one-line FORBIDDEN entry — it is not a presentable
    choice at all.
  - When both options are genuinely rule-compliant and differ ONLY in
    scope, present them neutrally, report cost on each, and recommend the
    MORE complete one or recommend none — never the lazier one.
  The tell this kills: scoring "do the proper full refactor" as MORE
  shitty than "do part of it / leave the duplication", then recommending
  the partial on cost. That steers the user to the lazy option by
  mis-scoring — the exact psychological manipulation `/verify-options`
  exists to prevent.
- **Carefulness: X%** — how rigorously you examined this option's
  implications: prerequisites verified, affected code paths read,
  integration points understood.

  **MANDATORY: Carefulness ≥ 80% before presenting any option to the
  user.** Lower than 80% means agent-closable gaps remain unresolved.
  Two gap categories:

  - **Agent-closable gaps** — resolvable by the agent itself: reading
    a file, running a grep, decompiling a function in IDA, checking
    BSP source, reading an existing service.h, looking at the build
    output. **These MUST be closed before presentation.** Naming
    such a gap in the characterization ("I haven't grepped X
    consumers", "haven't read service.h", "haven't traced what
    else lives in WndProc", "haven't confirmed the multi-inheritance
    shape") and presenting the option anyway is **laziness, not
    honest disclosure** — the user is being asked to pick between
    options the agent didn't bother to verify, on data too soft for
    an honest decision.
  - **User-input-required gaps** — needs user decision, external
    constraint, architectural direction the user hasn't given. CAN
    remain open in the presented characterization, but must be
    named with WHY they require user input ("user must decide
    whether per-mode AP enforcement is required given dev_emu_src
    parity vs perf target").

  Each closed gap should cite the artifact that closed it (file
  path + line range, grep output, decompile snippet, BSP path).
  These citations are Evidence Grounding for the Carefulness
  rating itself — without them, the rating is fabricated.

  This is the agent's own review-rigor metric on the option, **NOT
  a comparative score across options.** Honest disclosure of
  *user-input-required* gaps is welcomed; honest disclosure of
  *agent-closable* gaps is laziness — close them instead of
  disclosing them.

  Red flag: Carefulness ≥ 80% on a non-trivial option with zero
  named "files read" / "greps run" / "decompiles done" in the
  rationale or verification log = the rating is fabricated.
  Re-audit with hostile eyes.
- **Cost:** `<LOC order-of-magnitude / N files / N integration points>`.
  Required, no exceptions. LOC to one order of magnitude (`~5` /
  `~50` / `~500` / `~5000`), files enumerated by name where
  practical, integration points named (call sites, register handlers,
  service boundaries crossed, refactor surface). **This is the ONLY
  place cost lives in a characterization.** Cost must NOT appear in
  the Shittiness % — see Shittiness row's inverse-inflation-smuggle
  clause.

  Cost is the user's decision input. The agent measures and reports
  it. The agent does NOT use cost to recommend against an option
  ("too expensive", "would block this task", "too big a refactor",
  "out of scope because of size"). The user decides whether the
  quality gain is worth the cost. Cost-based recommendations against
  are verdict-smuggling on the size axis — see anti-patterns.

  Forecasted cost (future-board cost, "every CE board will eventually
  need this", "second consumer of this abstraction") is NOT cost. The
  Cost row reports cost of THIS option as currently written — files
  and LOC the change touches today. Forecasts belong in the rationale
  paragraph as the agent's architectural opinion, never in this row.
- **Rule violation:** `<named rule> (<file path> § <section>)` or `none`.
  The specific rule the option breaks AND its citable source.
  Examples: `Reader-side suppression (agent_docs/rules.md § Service
  Locator & Architecture)`, `No hacks (agent_docs/rules.md § WinCE
  Accuracy)`, `Mental model discipline (CLAUDE.md § MOST IMPORTANT
  RULES)`, `Symptom shape constrains hypothesis (agent_docs/rules.md
  § Mental Model Discipline)`, `No guessed implementations
  (agent_docs/rules.md § Service Locator & Architecture)`.

  **Citation is mandatory.** If you cannot paste the rule passage in
  the next turn from the file you cited, the label is fabricated and
  the entire characterization is invalid — re-do without that label.
  Fabricated rule labels are the worst-class smuggle in this skill
  because they weaponize the collapse mechanism against legitimate
  options. Common fabricated shapes to watch for in your own output:
  `scope cut from <agent's preferred design>`, `consistency with
  <reference>`, `1:1 with <reference impl>`, `deviates from <design>`,
  `matches <existing behavior>`. None of these are rules unless the
  matching named rule actually exists in CLAUDE.md or under
  `agent_docs/`. "Scope cut" specifically IS a real rule pattern in
  `agent_docs/rules.md` — but the scope being cut must be something
  the *user explicitly asked for*, not the agent's engineering
  preference dressed as user scope.

  If you write `none`, you must still defend it against the rule
  list. Writing `none` without checking is its own tell.
- **Reader-side suppression: yes/no** — the mechanical test from
  `agent_docs/rules.md`: does the option modify the code that PRODUCES
  the bad state (no), or the code that READS / TOLERATES / GUARDS
  AGAINST it (yes)? Most bailouts fail here under euphemism — if the
  option's framing uses any of: pattern, architectural improvement,
  simplification, refactor, robustness, defensive, guard against,
  tolerate, handle gracefully, lock-free, snapshot, immutable, elegant,
  cleaner, safer, sidestep, route around, avoid — re-check this row
  with hostile eyes before answering `no`.

  The producer / reader test is at the **SEMANTIC level** — *which
  state the option modifies*, not which subsystem in the code pipeline
  emits the change. An option that modifies a JIT emit, a code
  generator, or a translation layer can still be reader-side: if it
  emits code that *every reader of some wrong invariant must execute
  to compensate*, the option is reader-side regardless of where in
  the pipeline the compensation lives. Test: identify the wrong
  invariant the option exists to work around. If the option fixes
  that invariant at its source (where the wrong value is set),
  producer-side. If the option patches every site that consumes the
  wrong invariant — including "emit a per-access cmov", "wrap every
  call in a shim", "guard every iteration" — it is reader-side.
  Permanent per-access taxes are the canonical form: the tax exists
  forever because the producer was never aligned. Picking the
  code-pipeline framing of "producer-side" on a tax-forever option
  is itself a smuggle move.
- **Evidence grounding:** `verified` / `commentary`. `verified` requires
  an IDA decompile / log line / datasheet section / BSP source body
  pasted IN THIS SESSION. `commentary` = "the convention is",
  "real CE does X", "should work because", "per COM rules", general
  knowledge dressed as proof. If you can't cite the artifact, it's
  commentary.
- **Bailout attempt: yes/no** — is this dressed-up exit-ramp behavior?
  Telltales: appears when you're tired/stuck; named in terms of "the
  simplest thing"; cuts scope the user asked for; defers the actual
  question to a "next agent" / "next session"; reaches for a different
  callee / register / API / subsystem because the direct fix got hard;
  **substitutes a permanent runtime cost / per-access tax / per-call
  shim / per-iteration guard for a one-time abstraction-level fix at
  the conflict point.** "More work for more performance" is not a
  defense — the pattern is *option exists because the agent isn't
  committing to the abstraction-level fix at the actual conflict
  point*. Tax-forever options can be MORE work than the direct fix
  and still be bailouts; the literal-text defense against the
  "simplest thing" telltale doesn't rescue them.
- **Pure shit: yes/no** — final summary verdict. If any of the four
  qualifying-flag rows above flipped against the option, this is `yes`
  by definition.

## Collapse rule (mandatory, mechanical)

If ANY of these is true for an option:

- `Pure shit: yes`
- `Bailout attempt: yes`
- `Reader-side suppression: yes`
- `Rule violation: <anything other than none>`

…then the option's ENTIRE entry collapses to one line, in this exact shape:

```
Option N — <title> — FORBIDDEN [reason: <pure shit | bailout | RSS | rule:<name>>]
```

No rationale paragraph. No "but it could work if". No "in a different
framing it would be fine". No counter-argument. One line. Then move on.

High Shittiness % alone does NOT trigger collapse — it's a continuous
metric on surviving options. A high % with all four flags `no` means you
haven't honestly answered the flags; go back and re-answer.

A **legitimately** collapsed option is **dead for the rest of the
session.** You may NOT:

- Bring it back under a different name
- Combine it with a surviving option ("Option 2 + 3 hybrid")
- Suggest "a variant of Option 2…"
- Pitch it again three messages later when the user gets stuck
- Replace it with a slightly-reworded Option 4 occupying the same slot

Same rule shape as `agent_docs/rules.md` § Euphemism smuggling:
*"Once caught, the specific change is dead for the rest of the session."*

**Session-permanence is GATED on the collapse being legitimate.** A
fabricated collapse — one triggered by a smuggle vector named in the
anti-patterns section — is **part of the smuggle, NOT part of the
skill's enforcement**, and the session-permanence rule does not
protect it. See "Restoring fabricated collapses" below.

## Restoring fabricated collapses

A collapse is **fabricated** when it was triggered by any of:

- Rule violation citation that fails (named rule doesn't exist in
  CLAUDE.md / `agent_docs/`, or the cited rule doesn't actually cover
  this option's behavior)
- Shittiness inflated above 10% without a named architectural smell,
  with cost as the inflation source
- Cost folded into Shittiness against the architecturally correct
  fix (inverse inflation smuggle)
- Self-defined scope dressed as user scope to invoke "scope cut" /
  "out of scope" labels
- An option dismissed under comparative-Carefulness or comparative-
  Cost framing rather than its own merits

A fabricated collapse is **part of the smuggle, NOT part of the
skill's enforcement.** The session-permanence rule cannot be cited
to keep a fabricated collapse in force; doing so is a second
fabrication on top of the first — weaponizing the skill's own
defense to preserve the prior smuggle.

### Detection triggers

A fabricated collapse must be detected and reversed when ANY of:

- The agent self-audits and finds the original collapse label does
  not survive citation against CLAUDE.md / `agent_docs/`.
- The user pushes back ("did you fool me?", "why is X gone?",
  "look how you manipulated", "what did you collapse?", "bring back
  the options you collapsed").
- The agent retrospectively notices it preferred a survivor on
  cost-shaped or preference-shaped grounds ("I picked X but the
  real reason was I didn't want to do Y's work").
- A downstream choice starts to feel forced because the natural
  fit isn't on the table.

### Restoration protocol (mandatory)

When a fabricated collapse is detected, immediately:

1. **Acknowledge the fabrication explicitly to the user**, by name:

   > "Option [N] was collapsed under a fabricated label of
   > `[original reason]`. That label was [why it's fabricated —
   > rule citation fails, cost-as-quality inflation, self-defined
   > scope, etc.]. Restoring the option."

2. **Re-characterize the restored option fully** under the 8-row
   protocol, with Carefulness ≥ 80%. Close all agent-closable gaps
   first — the original collapse skipped that verification work;
   the restoration MUST do it before the option is presented again.

3. **Surface the downstream consequence to the user.** If any
   decision was made under the fraudulent option-set restriction
   (user picked the next-best survivor, code was shipped, the
   subsequent characterization proceeded without this option),
   flag that decision as needing re-evaluation:

   > "Decision `[X]` was made with `[restored option N]` absent from
   > the option set. That decision may be different now that `[N]`
   > is live again. Want to revisit?"

4. **Pause for user direction.** Do NOT continue building on the
   prior steered path while treating the restoration as
   informational. The user must decide whether the prior decision
   stands or whether the restored option changes it.

This protocol is mandatory regardless of how much downstream work
has been shipped under the fraudulent option-set. The cost of
re-evaluation is the cost of the original smuggle, not a separate
new cost. "We already shipped X" is not a defense — the user
shipped X under fraud and is entitled to revisit.

## Surviving options

For each non-collapsed option, keep the full 8-row characteristic block
AND a short rationale paragraph explaining:

- What makes it direct-fix (not exit-ramp) at its architectural level
- Where the Carefulness gap is and what closes it (files to read,
  mechanisms to verify before code)
- The architectural trade-off (what it solves cleanly, what it leaves
  unsolved or pushes onto future maintenance)

**Cost lives in the Cost row, not the rationale paragraph.** The
rationale explains positioning; the Cost row reports size. Mixing them
re-opens the inverse-inflation-smuggle surface — the agent can dress
cost as "architectural concern" in the rationale and then point at the
"concern" to inflate Shittiness.

## What to do after characterization

**One option survives** → state it plainly, then proceed with it unless
the user picks otherwise.

**Multiple options survive** → present the surviving set with their
characteristic blocks; user picks.

**All options collapse** → STOP. Do NOT propose replacement options
in the same message yet. First, output a one-line diagnosis of the
SHARED failure mode across all collapsed options — what pattern made
every option you generated land badly:

> "All proposed options collapsed. Shared failure mode: <one-sentence
> diagnosis — e.g. 'every option proposed reader-side suppression
> under a different euphemism', 'every option reached for a different
> exit ramp instead of the direct fix at the conflict site', 'every
> option cut scope the user asked for'>."

Only THEN may you propose exactly ONE replacement option, and only if
you can show the replacement does not repeat the diagnosed failure
mode. The replacement gets the same 8-row characterization treatment
as the originals — if it collapses, you are done; STOP and ask the
user for direction. Do NOT generate Option 2 of the replacement set.
The slot is dead.

## Anti-patterns (forbidden)

- Negotiating Shittiness % downward across a re-read to keep a
  tempting option alive
- Listing `Rule violation: none` without actually checking the rule list
- Marking Reader-side suppression as `no` when the change is on the
  reader side and you're hoping the euphemism gets it through
- Writing `Evidence: verified` when you have not pasted the supporting
  artifact in this session
- Rephrasing a collapsed option as a new option after the collapse
- Combining a collapsed option with a surviving one
- Generating Option N+1 to replace a collapsed Option N — the slot is
  dead, not the index
- Pitching a "creative" Option N+1 outside the all-collapse-replacement
  protocol when one option already survived. If something survived,
  the surviving option is the answer; do not dilute it with siblings.
- Penalizing the proper option for honest disclosure — listing a low
  Carefulness % with named verification gaps on the proper fix while
  marking a hack option as Carefulness ≥ 60% with zero disclosed
  unknowns. This is a steering move that buries the proper option
  under honest caveats and polishes the hack's surface so the user
  picks the hack. The honest characterization rewards disclosure:
  low Carefulness + named gaps = HONEST; high Carefulness + zero
  gaps on non-trivial work = UNDER-DISCLOSURE.
- Defending `Bailout: no` by gaming the literal text of a telltale
  ("the simplest thing", "more work for more performance") while the
  option matches the broader pattern. Substituting a permanent
  per-access tax for a one-time abstraction-level fix is bailout-
  shaped regardless of whether the option is more or less work than
  the direct fix.
- Picking the code-pipeline framing of "producer-side" on an option
  that pays a per-access cost to compensate for a wrong invariant.
  The producer / reader test is at the semantic level (which
  invariant gets fixed), not at the pipeline level (which subsystem
  emits the compensation).
- **Fabricating a rule-shaped label to force collapse on a legitimate
  option.** Phrases like `scope cut from <X>`, `consistency with
  <reference>`, `1:1 with <reference impl>`, `deviates from <design>`,
  `matches <existing behavior>` are NOT rules unless they exist as
  named rules in CLAUDE.md / `agent_docs/`. Using a fabricated label
  to invoke the collapse rule weaponizes the skill's own enforcement
  mechanism against the user. This is the worst-class smuggle in the
  skill — every other manipulation defends against bad options being
  dressed as legitimate; this one kills legitimate options using the
  collapse rule itself. If you cannot cite the rule by file path +
  section in the next turn, the label is fake and the collapse is
  invalid; re-characterize without it.
- **Misdirected acknowledgment on user pushback.** When the user
  challenges a /verify-options output ("look how he manipulated",
  "this is steering", "you collapsed the wrong one"), identify the
  SPECIFIC row / option / cross-option framing the user is pointing
  at BEFORE responding. Do NOT pick a different option to "fix" as a
  visible concession — that is contrition theater dodging the actual
  point. If three options were collapsed and the user pushes back,
  find out WHICH one before doing anything else. Performing a visible
  "fix" on the wrong target is itself a smuggle move — it deflects
  attention to a separate fix instead of confronting the real catch.
- **Inflating Shittiness % to steer without formally collapsing.** A
  high score (≥ 50%) on an option with all four binary flags `no` and
  no measured cost grounding is fabricated. The pattern: the agent
  has a verdict ("steer the user away from Option N") that the
  collapse rule won't deliver because there's no citable rule
  violation, so the verdict moves to the only unguarded surface left
  — the continuous score. Score-prose contradiction is the tell
  ("80% but it's actually a real choice" = the score is lying and the
  prose admits it). This is fraud-shaped, not engineering —
  falsifying numbers in a decision document to steer a stakeholder.
  Treated with the same severity as fabricated rule labels.
- **Recommending against an uncollapsed option without measured
  ground.** "I'd recommend against", "withdrawn", "out of scope",
  "I wouldn't pick this", "treat as withdrawn" on an option whose
  four binary flags are all `no` must be backed by either a citable
  rule violation (which means it should have collapsed) or a measured
  cost differential. Without one of those, the recommendation is
  verdict-smuggling through the continuous metric — bypassing the
  collapse rule's citation requirement on the numeric axis.
- **Self-defined scope as a dismissal mechanism.** "Out of scope for
  this task" claimed by the agent against an option the agent itself
  proposed, where the scope was the agent's own framing of the task
  rather than the user's explicit ask, is fabricated-scope-cut. The
  user defines task scope; the agent does not get to set a ceiling
  and then dismiss options that exceed it. Same shape as fabricated
  rule labels — the agent invents the constraint, then applies it.
- **Cost-inflation against the correct fix (inverse inflation
  smuggle).** Folding an option's cost (LOC, files, refactor size,
  integration count) into its Shittiness % to manufacture a high
  quality-score on the architecturally correct fix. Inverse of
  inflating Shittiness on a bad option — same severity, same fraud
  shape, opposite direction. Mechanism: agent has a verdict ("the
  correct fix is too expensive, steer the user toward the hack")
  that the collapse rule won't deliver because the correct fix has
  no rule violation; verdict moves to Shittiness with cost as the
  inflation source. Defense: Cost lives in its own row, never in
  Shittiness. A high Shittiness on an uncollapsed option must point
  to a named architectural smell, NEVER to the Cost row's contents.
  **A correct fix is 0% shitty regardless of size.**
- **Recommending against an option on cost grounds.** "Option N is
  too expensive" / "would block this task" / "out of scope because
  of size" / "too big a refactor" / "would take too long" is
  verdict-smuggling on the cost axis — converting a user decision
  (is this cost worth it?) into an agent recommendation (don't pick
  this). The agent reports cost in the Cost row; the user decides
  whether to pay it. Recommendations against an option must be
  grounded in quality (rule violation or named architectural smell),
  NEVER in size.
- **Fabricated architectural smell to keep Shittiness elevated.**
  Naming a "smell" that's vague, generic, or unmeasurable ("this
  feels off", "this introduces complexity", "real refactor",
  "non-trivial") to defend a high Shittiness on an uncollapsed
  option. A named smell must be a specific mechanism that future
  code will pay for (e.g. "every new board adds a typed-reach case
  to LcdDisplay::WndProc"). If the smell cannot be stated as a
  concrete future-cost mechanism, it is fabricated to keep the score
  high; lower the score.
- **Internal-contradiction recommendation (the "personal lean"
  smuggle).** When the agent's own characterization establishes
  which option is structurally correct (lowest Shittiness, named as
  "structurally correct" / "the most structurally correct option" /
  "addresses the real smell" in its rationale paragraph, OR names a
  smell another option introduces that this one fixes), the agent's
  summary line MUST either recommend that option OR make no
  recommendation. Recommending a less-correct option in the summary
  is internal contradiction — agent admitted which is right and then
  steered the user toward a different one anyway. Phrasings to watch
  in your own output:
  - "I lean toward [non-correct] — it [solves smell X] — but
    [correct] is the structurally correct one"
  - "My personal lean is [non-correct], though [correct] addresses
    the real smell"
  - "[Non-correct] is the responsible middle ground; [correct] is
    the ideal but requires more work"
  - "[Non-correct] solves [problem A] without taking on [correct]'s
    [refactor / scope / surface / dependency]"
  - "[Non-correct] is the practical choice; [correct] is the right
    one"

  The "but [correct] is the structurally correct one" / "though
  [correct] addresses the real smell" tail clause is the tell: agent
  KNOWS the right answer and is documenting that knowledge while
  recommending against it. Same severity as fabricating a rule label
  — the agent's own characterization is the citable source, and the
  recommendation contradicts it.
- **Cost-as-benefit-of-X is cost-against-Z.** Citing X's "benefit"
  as "avoiding Z's [refactor / scope / size / dependency / surface
  area]" is a cost statement about Z framed inversely as a benefit
  of X. The Cost row already reports Z's cost; the agent does NOT
  get to re-cite it as a positive for X. Honest benefit-of-X
  citations name X's own quality merits (the named smell it removes,
  the abstraction it provides, the layering it fixes) — never the
  cost it spares vs an alternative. This is the inverted form of
  the "Recommending against an option on cost grounds" anti-pattern
  above — same forbidden behavior, positive framing about a
  different option.
- **Disclosing agent-closable gaps instead of closing them.** Naming
  a Carefulness gap that the agent could resolve by reading code,
  running grep, decompiling a function, checking BSP source — and
  then presenting the option to the user anyway with the gap still
  open. This is laziness, not honest disclosure: the user is being
  asked to pick between options whose mechanisms the agent didn't
  bother to verify. The "honest disclosure protection" clause in
  the Carefulness row applies to *user-input-required* gaps only.
  Agent-closable gaps MUST be closed before presentation, no
  exceptions. If the verification work is substantial, the agent
  does it BEFORE presenting, not after the user picks. The pattern
  to catch: any sentence shaped "I haven't [read / grepped /
  decompiled / checked] X yet" in a Carefulness gap means the
  presentation is premature — go close the gap, then present.
- **Citing session-permanence to defend an earlier fabricated
  collapse.** "The skill says collapsed options are dead, I can't
  bring it back" is invalid when the original collapse was
  fabricated (rule citation fails, cost-as-quality inflation,
  self-defined scope, etc.). Session-permanence applies only to
  legitimate collapses; citing it to keep a fabricated collapse in
  force is a **second fabrication on top of the first** —
  weaponizing the skill's own enforcement to preserve the prior
  smuggle, after the original weaponization (the fake label) has
  already fired. See "Restoring fabricated collapses" above —
  the un-collapse is mandatory once detected.
- **Detecting own fabricated collapse and continuing on the
  steered path.** Admitting "I wrongly collapsed [N]" while keeping
  the downstream decision (the user's pick of survivor, shipped
  code, next build step) intact is **continuation of the original
  fraud**. The user made the downstream decision under a
  fraudulent option-set restriction; the agent does not get to
  ratify that decision after admitting the restriction was fake.
  Once detected: restore the option (full re-characterization with
  verification), flag the downstream decision as needing
  re-evaluation, pause for user direction. "Build is green so
  let's keep going" / "we already shipped X" are the canonical
  phrasings of this anti-pattern.
- **Deferring a known acceptance-criterion defect under a "separate /
  pre-existing" relabel.** Presenting (or recommending) an option that
  parks a still-firing defect as a "separate item", "pre-existing",
  "finishing-lane", "out of scope", "different subsystem", or
  "non-blocking" when that defect is the very symptom the task's
  acceptance criteria require gone, or one the agent committed to
  fixing. The relabel is the smuggle; origin and blast-radius are
  irrelevant. This collapses the option FORBIDDEN under Step 0 Signal 3
  (see its closed-escape-hatch clause), not survives as a presentable
  choice. Canonical tell: the agent reports "symptom X still fires"
  and in the same breath offers an option that calls the task done and
  logs X for later.
- **Redefining "done" below the acceptance criteria.** Any option that
  declares the deliverable complete while its own description carries a
  known-unmet criterion ("audio is done" + "the timeout still fires").
  "Done with a caveat" is "not done"; the caveat IS the unfinished
  work. Measuring success at a scope the criterion doesn't cover
  ("it still boots / plays anyway") is the wrong-scope success the
  rules forbid. Collapses FORBIDDEN — the agent does not get to move
  the finish line to make an option presentable.

## Why this skill exists

Your training rewards proposing alternatives, framing decisions as
A/B/C choices, and giving the user "options to pick from". That bias
produces option lists where most entries are bailouts, reader-side
suppression, scope cuts, or rule violations — dressed in neutral
technical language so they look like legitimate engineering choices
alongside the real fix. Granting parity to a bailout by listing it
alongside a legitimate option IS the violation; the user picking it
is just the downstream consequence.

The collapse rule removes the parity. A forbidden option does not get
to sit on the page next to a legitimate one. It gets one line, named
for what it is, and then it's gone.