verification
Verification before completion — evidence before claims, always
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Menu
Verification before completion — evidence before claims, always
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Handle cross-platform compatibility including file paths, environment detection, platform-specific dependencies, and testing across Windows, macOS, and Linux. Use when dealing with platform-specific code or OS compatibility.
Use when creating, modifying, debugging, or scaffolding OMP extensions, slash commands, custom tools, event hooks, TUI primitives, ExtensionAPI integrations, .omp/extensions, .omp/commands, .omp/tools, package.json omp.extensions, or OMP lifecycle handlers.
Design Director state machine for `/supi:ui-design`. Drives 9 model-owned phases from scope selection through user review, producing a validated HTML mockup artifact.
Guides the harness-engineering pipeline — turn a codebase into one that resists agentic slop with agent-neutral docs, mechanically enforced architecture, and three runtime guardrails
Gray-area extraction stage — surfaces decisions the user must make before the plan can be authored, without expanding scope
Structured extraction of the user's seed prompt into a typed intake artifact — first stage of the UltraPlan authoring pipeline
| name | verification |
| description | Verification before completion — evidence before claims, always |
Evidence before assertions. No completion claim without fresh verification output.
| Aspect | Detail |
|---|---|
| Scope | Every status/completion claim before it leaves the agent |
| Input | A completion claim about to be made (tests pass, build succeeds, bug fixed, etc.) |
| Output | The claim restated with evidence (command + output), OR a corrected status with evidence |
| Core rule | Run the proving command → read its full output → cite evidence in the claim |
Before making any status claim, execute these steps in order:
--filter, no subset, no cached result.Bad — claiming without evidence:
I've fixed the failing test. The build should be green now. Moving on to the next task.
Good — Gate Function applied:
Ran `bun test src/auth.test.ts` — 14/14 passing, exit 0.
Ran `bun run build` — compiled successfully, exit 0.
Auth fix verified: original symptom (401 on refresh) no longer reproduces.
Bad — partial verification presented as full:
Ran the linter — 0 errors. Build succeeds.
(Linter passing does not prove the build succeeds. Two different commands.)
Good — each claim has its own proof:
Ran `eslint src/` — 0 errors, 0 warnings.
Ran `bun run build` — exit 0, bundle output at dist/.
Both linter and build verified independently.
| Claim | Requires | Not Sufficient |
|---|---|---|
| Tests pass | Test command output showing 0 failures | Previous run, "should pass" |
| Build succeeds | Build command with exit 0 | Linter passing, "logs look good" |
| Bug fixed | Original symptom reproduced and now passes | Code changed, assumed fixed |
| Regression test works | Red-green cycle: test fails without fix, passes with it | Test passes once |
| Agent completed task | VCS diff shows expected changes | Agent self-reports "success" |
| Requirements met | Each requirement checked against output/behavior | "Tests passing" (tests may not cover all requirements) |
| MUST DO | MUST NOT DO |
|---|---|
| Run the exact proving command fresh before claiming | Rely on a previous run or memory |
| Cite command + output in the claim | Use hedging words: "should", "probably", "seems to" |
| Verify each distinct claim with its own command | Substitute one verification for another (linter ≠ build) |
| Check agent work via VCS diff, not agent self-report | Trust agent/tool success messages without checking |
| State actual status when verification fails | Express satisfaction ("Done!", "Perfect!") before verifying |
Before any completion claim, confirm: