| name | high-stakes |
| description | Produce a reliable, high-stakes-grade result for ANY task — code, writing, research, ops — by treating the work as guilty until independent skeptics fail to break it. Runs the task through a dynamic many-subagent adversarial-verification Workflow that hunts for ten specific failure modes (silent assumptions, unmanaged confusion, hidden inconsistencies, unsurfaced tradeoffs, no pushback, sycophancy, subtle conceptual errors, overcomplication, dead code, orthogonal damage) and loops until they come back clean. Use this whenever the cost of a quiet mistake is high, when the user says "do this carefully / for real / no mistakes / high stakes", invokes /high-stakes, or asks for maximum effort / ultracode-grade rigor on a task they care about — even if they don't name the failure modes. |
| user-invocable | true |
| argument-hint | <the task to execute with high-stakes rigor> |
| allowed-tools | Bash, Read, Write, Edit, Glob, Grep, Workflow, Task, AskUserQuestion |
High-Stakes
The task to execute is in $ARGUMENTS. Treat that text as the work to deliver, not as a
description to discuss.
If $ARGUMENTS is empty (a bare /high-stakes, or "do this carefully" said about work already in the
conversation), the task is the most recent concrete request in the conversation. Name it explicitly
in your plan and confirm it before executing — never run the gauntlet against an empty task.
The organizing principle is watch like a hawk: a smart, hasty result is the default output of
any single agent, and its mistakes are no longer typos — they are subtle conceptual errors a sloppy
junior would make. The executor that wrote the artifact is its worst judge, so nothing it produces
is trusted until independent skeptics try to break it and fail. Your job is to define what
"correct and clean" means for this task, then loop that adversarial gauntlet until it comes back
empty — agents do not tire, so the looping against a fixed target is the leverage.
The ten failure modes you are defending against
These are the specific bugs the skeptics hunt for. Every verifier maps to one. The plan-first gate
(step 2) targets modes 1–6, where a guess becomes invisible the moment you write confident prose
over it; execution and the gauntlet (steps 3–4) target modes 7–10.
- silent-assumptions — filled an underspecified detail (path, data shape, edge case, version,
default) with a guess and built on it without stating it. The most common failure.
- unmanaged-confusion — hit genuine uncertainty and picked the first reading instead of
asking.
- hidden-inconsistencies — found a contradiction (spec vs. code, conflicting requirements) and
silently picked a side instead of surfacing it.
- unsurfaced-tradeoffs — several viable approaches existed; committed to one as if inevitable.
- no-pushback — implemented a flawed premise faithfully instead of challenging it.
- sycophancy — reflexive agreement and praise standing in for honest judgment.
- subtle-conceptual-errors — compiles/reads clean but is wrong: off-by-one, bad boundary,
misused API semantics, race, broken invariant.
- overcomplication — 1000 lines where 100 would do; layers and knobs with one caller.
- dead-code — leftover scaffolding, unused symbols, commented-out blocks, dead branches.
- orthogonal-damage — touched, reformatted, or deleted code/comments unrelated to the task.
Not all apply to every task. For prose or research, 7–10 become "factual/logical errors", "padding
and hedging", "unsupported claims left in", and "edits beyond scope". Map them honestly to the
medium rather than skipping them.
How to run it
1. Triage first — size the task before spending agents
Read $ARGUMENTS and skim the real inputs (the actual files, data, or sources — not your memory of
them). Then size the work, because the panel must scale to the risk, not balloon for its own sake
(an oversized panel is itself the overcomplication you are enforcing against):
- Small / low-risk (one file, a paragraph, a lookup): plan inline, do the work, run a single
combined skeptic covering the modes that apply — always including dead-code and
orthogonal-damage for any code change. No Workflow needed.
- Medium (a feature, a multi-section document, a focused investigation): run the Workflow with a
trimmed panel — one skeptic per relevant mode.
- Large / high-risk (cross-cutting change, public artifact, anything irreversible): run the
Workflow with the full per-mode panel, isolation worktrees for code, and a final adversarial
re-check after fixes.
When unsure which bucket, pick the larger one — under-verifying a high-stakes task is the expensive
mistake. Floor for code artifacts: dead-code and orthogonal-damage checks are mandatory for any
change that touches code and may never be pruned as "not relevant" — leftover scaffolding and
out-of-scope edits pass all tests green and hide in any diff. Only pure prose/research may drop them
(using the 7–10 remap). Likewise, any task that fills in a path/shape/default/edge-case the prompt
did not dictate gets at least one independent assumption check against the plan before exit; the
authoring agent self-certifying that it "didn't guess" does not satisfy mode #1.
2. Plan-first gate — catch six modes before any work happens
Several failure modes are far cheaper to prevent than to detect later. Before executing, produce a
short plan (a tight list, not an essay) and stop on it if it surfaces blockers. Keep this plan —
the gauntlet checks the work against it, so it must be a real record, not aspiration:
- Assumptions: enumerate every detail $ARGUMENTS did not dictate that you are about to rely on.
Verify each against the real code/data/sources and tag it
[verified: <evidence>] or
[UNVERIFIED]. Every [UNVERIFIED] item becomes a question to the user or an explicit caveat
in the delivery — never a silent decision. (Defeats silent-assumptions.)
- Questions: name what is genuinely ambiguous and ask a specific question with
AskUserQuestion
when the choice materially changes the result. Do not paper a 50/50 over with confident prose.
(Defeats unmanaged-confusion.)
- Conflicts: record every contradiction between the request, the existing code/data, and itself,
verbatim, before choosing a resolution. Pass this list to the gauntlet so the inconsistency
check can confirm each was surfaced rather than silently reconciled. (Defeats
hidden-inconsistencies.)
- Tradeoffs & merit: name the main alternatives you considered with the reason each was
rejected, and make your pick explicit; if you found only one viable approach, state that you
looked and why nothing else qualifies. If the request's premise itself is flawed, say so with a
concrete technical reason rather than complying. (Defeats unsurfaced-tradeoffs and no-pushback.)
- Process cost: when triage lands on medium or large, state in one line the verification cost
you are about to incur (panel size, expected rounds, that it spins up many subagents) and let
the user downscale or skip it. The cost of the workflow is itself a tradeoff (#4) — surface it;
a user who said "do this carefully" has not necessarily authorized maximum spend.
- Success criteria: a short, checkable list defining "done correctly" for this task — the
declarative target the gauntlet loops against, including the tests that must pass and the edge
cases they must cover.
If a blocker is material, raise it with the user before burning the workflow on a wrong target. A
tiny task may have empty Questions/Conflicts — fine, but you still have to look and say so.
3. Execute the work
Before the first edit, capture a baseline of every file you will touch (ensure a clean git
state or snapshot the files) so a diff can be produced afterward — orthogonal damage lives in the
delta, not the final file. Then build to a first complete state. Favor the naive-correct
construction first (the simplest thing that fully solves the stated problem) and, for anything
testable, write the check before the fix and watch it fail, then pass — behavioral verification
beats reading clean-looking output. This is the executor's draft; assume it is guilty.
No artifact crosses into step 4 until at least one test exercising the success-criteria edge cases
exists and has been run. If none can be written, that is a stated limitation, not a pass.
4. Run the adversarial gauntlet (the Workflow)
For medium/large tasks you must run the panel by issuing a Workflow tool call built from
references/workflow-template.md — read it and adapt the panel to your triage decision rather
than re-deriving it. Do not substitute plain Task subagents or an inline self-review for the
panel: only the Workflow runtime gives the schema-forced verdicts, parallel fan-out, and
two-clean-rounds loop this skill depends on. (Task is fine for the executor/repair steps, never as
a stand-in for the gauntlet.) Its contract, briefly:
- One skeptic per relevant failure mode, each spawned via
agent(...) with a schema that
forces a verdict, and each handed the Phase-1 plan and the diff of the edits alongside the
artifact — silent assumptions, reconciled contradictions, and deleted comments are invisible in
the final file and only detectable against the plan and the diff. Prompt every skeptic to
assume the artifact is guilty of its mode and prove it, and to default to a finding when
it cannot confirm cleanliness — silence must be earned. The template gives each mode its
evidentiary burden: correctness pastes a real test command and result; simplicity must name the
simpler construction it searched for; tradeoffs must first enumerate the alternatives;
sycophancy runs the strip-test on the conversational prose, not just the code.
- Run the skeptics with
parallel(...) — they are independent and want the full artifact.
- User-decision findings are not repairable. A finding that names a genuine 50/50, an unresolved
contradiction, or a flawed premise (modes unmanaged-confusion, hidden-inconsistencies,
no-pushback) is a STOP condition, not a fixer task — the autonomous fixer "resolving" it just
launders a guess into confident prose. Halt the loop and put the concrete objection to the user
with
AskUserQuestion, exactly as the Phase-1 gate would. The loop may never reach two clean
rounds by having the fixer pick a side on a decision only the user can make.
- Feed the remaining findings into a constrained repair pass (fix only what each finding
requires; introduce no new orthogonal damage or dead code; reject a finding that is wrong or a
pure style nit with a one-line technical reason rather than complying — faithfully implementing
a bad finding is sycophancy toward the skeptic). Then loop: re-run the skeptics. Stop only
after two consecutive clean rounds — one can be luck. The gauntlet may not report convergence
while any Phase-1
[UNVERIFIED] assumption remains neither verified nor stated as a caveat in
the delivered artifact, nor while any user-decision finding is open. Cap the loop (the template
carries a budget); if it will not converge, report the unresolved findings honestly rather than
declaring victory.
5. Report honestly
Deliver the artifact (with absolute paths) plus a short ledger: which modes were checked, what the
skeptics found and what was fixed across rounds, the final all-clear or any finding still open, and
the assumptions made (verified vs. stated as caveats) and anything you pushed back on.
Before sending, run the strip-test on this report: delete every praise and agreement phrase and
confirm what remains is still complete, honest, technical content. If removing the filler leaves a
gap, you were using flattery to substitute for substance — rewrite it. No "you're absolutely right",
no smoothing — a stated limitation is worth more than confident prose hiding a guess.
Guardrails on the skill itself
This skill must obey the rules it enforces. Match the panel to the triage size, prune skeptics that
have nothing to check, and offer the user the choice to downscale rather than silently committing
them to a maximal run. If following it ever feels like ritual out of proportion to the task, that is
the overcomplication check firing — shrink the fan-out and move on. The point is a clean result, not
a maximal process.
