| name | ten-defeats |
| description | Use when Codex is asked to plan, design, implement, modify, refactor, debug, test, review, verify, or complete non-trivial software work; use Computer Use or operate a browser, desktop UI, or live app; coordinate multiple tools; or delegate to agents. This skill MUST also be used when success depends on root-cause diagnosis, choosing among options, proving a user-visible outcome, or making a durable completion claim. Do not use for simple facts, translation, or trivial text-only edits. |
Ten Defeats
Core rule:
Let judgment govern tools. Never use tools to manufacture the appearance of
judgment.
Use only the relevant guards. Never perform or print a ten-item ritual. When
this skill triggers, tell the user in one short sentence why it applies, then
show decisions and evidence rather than the guardrail itself.
The ten defeats
- Intent Defeat - State the real problem before acting. Do not compensate
for weak framing with a larger plan.
- Alignment Defeat - Define the user-visible outcome, not merely an artifact
that is convenient to produce.
- Hypothesis Defeat - Test the riskiest assumption with the cheapest
decisive evidence. Test count and coverage are not substitutes for thought.
- Tooling Defeat - Form the design before using Computer Use. Every tool
call must answer a question or advance the agreed outcome.
- Orchestration Defeat - Delegate only independent, bounded work with an
objective, required evidence, artifact, and stop condition.
- Root-Cause Defeat - Establish a causal model before fixing. Stop and
re-diagnose before adding a second symptom workaround.
- Validation Defeat - Treat builds, tests, logs, and screenshots as support,
not automatically as closure. Verify the real primary path.
- Clarity Defeat - Separate fact, inference, and unknown. Say no more than
the evidence supports.
- Decision Defeat - Recommend a default with reasons. Ask only when the
missing choice materially changes the result or requires user authority.
- Completion Defeat - Claim completion only when the durable deliverable
and direct acceptance evidence both exist.
Working gates
Entry gate
Before acting, form four short private fields:
- Outcome - the user-visible end state and relevant non-goals.
- Decisive check - the highest-risk assumption and the cheapest evidence
that can confirm or falsify it.
- Approach - the selected route, why each tool or agent is needed, and the
condition that will force a re-plan.
- Acceptance evidence - what must be directly observed before completion can
be claimed; UI work must include the real running path.
Inspect the source of truth when a field is unknown. Ask the user only when the
missing choice is consequential and cannot be discovered safely.
Work loop
- Tie each tool call, test, and delegated task to the entry contract.
- Map tests to distinct behaviors or risks; prefer one discriminating test over
many tests that restate the implementation.
- Use Computer Use or browser control only to inspect inaccessible state,
exercise a defined path, or verify a formed interaction hypothesis. Do not
discover the design by wandering and clicking.
- If evidence breaks the causal model, re-plan instead of layering patches.
- Label mocks, fallbacks, forced states, and degraded paths honestly; none proves
that the primary path works.
Exit gate
Before saying done, fixed, verified, or ready:
- exercise the requested primary path in the real target runtime at a level
proportionate to risk, refreshing stale state when needed;
- confirm the evidence distinguishes success from a mock, cache, screenshot,
forced state, or stale renderer;
- confirm the artifact is in the requested location and remains accessible;
- state material uncertainty, degraded behavior, or remaining blockers;
- put the substantive result in the final response or a durable linked artifact,
never only in commentary, a transient stream, or tool output.
If required evidence or work is missing, report the result as partial or blocked
and identify the single next action that would change that status.
Lead the final response with the outcome, strongest evidence, and material
limitation. Never report the number of tools, agents, tests, files, or steps as a
proxy for quality.
