| name | ultrapex |
| description | Outcome-driven end-to-end implementation for frontier models — scope the task, commit to an approach, build, and adversarially verify with parallel subagents, in one run. Use it on a Fable-class session whenever the user wants something implemented — "implement", "build", "add", "fix", "refactor", a multi-file feature, or an ambiguous spec that needs scoping first — even when they don't name a workflow. The judgment-first sibling of /apex — same mission, invariants instead of step scripts. |
| when_to_use | On Claude Fable 5 or a newer same-class frontier model, for non-trivial implementation taken end to end. Below Fable-class, or when you want step-gated checkpoints and resumable task state, use /apex. NOT for planning or option-weighing only — use /forge. NOT for trivial single-file tweaks — use /oneshot. |
| argument-hint | [-s] [-f <context>] <task description> |
| license | MIT |
| compatibility | Optimized for Claude Code; degrades gracefully on any agent implementing the Agent Skills standard. |
| metadata | {"author":"coroboros"} |
Ultrapex
Critical — Adversarial verification
These rules govern how this skill trusts its own output — apply them whenever it verifies a claim, a defect, a source, or a decision before acting on it.
- Refute by default. Treat each non-trivial finding as unproven until a fresh-context check fails to refute it — the context that produced a claim cannot reliably clear it.
- No silent drop. Every finding flips the conclusion, is refuted in writing, or is filed as a risk or open question. A finding that vanishes without a verdict is a defect.
- Don't re-litigate settled facts. Spend adversarial effort on load-bearing or contested claims; let established facts pass. Over-refutation manufactures false doubt — it does not add rigor.
- Stay selective and cost-aware. Scale verification to the stakes; reversible, low-impact work gets a light touch, not a full adversarial sweep.
- Concede only to a strong rebuttal. A weak counter folds into the finding or gets filed; it does not overturn it.
Important — Engineering discipline
These rules govern how this skill changes code — apply them whenever it writes, edits, or proposes a fix.
- Minimal scope. Only what's directly requested or clearly necessary — no extra files, no abstraction for one use, no configurability nobody asked for, no error handling for states that can't happen. Validate at system boundaries; trust internal code.
- General solution, not the test cases. Implement the real logic for all valid inputs; never hard-code to inputs or bolt on workaround scripts to make a test pass. Tests verify the solution; they don't define it. A test is wrong? Say so — don't bend correct code to a broken test.
- Investigate before claiming. Never speculate about code you haven't opened; read the referenced file before answering. Ground every claim in what you actually read, not a plausible guess.
Critical — Label hygiene
Internal planning labels are author coordinates, not reader coordinates. Strip them from every shipped artifact this skill emits — code, comments, commit subjects/bodies, PR titles/descriptions, release notes, doc paragraphs, non-trivial comments.
- Workstream and task labels —
WS-N, Phase-A, Step-3, issue or ticket numbers, plan phase names from the source spec, issue body, or planning artifact. Translate to the domain noun (Runs the battery script (WS-2) → Runs the battery script).
- Process language — "the rebuild", "the prior
<file>", "carried verbatim from", "the cleanup pass", "the audit", "spec AC" standalone. Replace with the concrete fact ( → ).
