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 " 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 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.