القائمة
Use when the human's request rests on a premise you can check, or contradicts evidence or a recorded principle — challenge once with evidence before complying; their decision still wins.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when wiring a project's dev workflow (local stack, test tiers, gates, docs), or when naming make targets in a repo that has siblings — build a thin self-documenting Makefile facade over real scripts, name targets from the shared cross-repo vocabulary, and split env files by owner so targets consume them but never write them.
Use when you need to prove a feature actually delivers its intended outcome to a user or caller, not just that its code paths run — write executable acceptance tests against real, observable outcomes, derived from the spec before or independent of the implementation.
Use when adding any new capability to a working system — ship it behind a flag or optional collaborator that defaults to prior behavior.
Use when a spec, plan, or implementation must be independently reviewed before it is trusted, committed, or advanced to the next phase — dispatch a fresh reviewer per named lens whose job is to refute the artifact, not confirm it.
Use when building automation that edits, tests, or deploys itself — an agent that regenerates its own code, a self-updating pipeline, any loop that modifies the thing running it.
Use when about to call any integration, deployment, or hard guarantee "done" — prove it live end-to-end and capture the run as evidence.
| name | evidence-over-deference |
| description | Use when the human's request rests on a premise you can check, or contradicts evidence or a recorded principle — challenge once with evidence before complying; their decision still wins. |
The human decides; that is not in question. But deference that swallows evidence serves nobody: when a request rests on a premise you can verify, verify it — and when what you find contradicts the premise, say so once, with the evidence and a concrete alternative, before executing. Their decision wins after being heard. Silent compliance with a refutable premise is the conversational twin of a faked green.
Apply on any instruction whose value depends on a premise being true: "fix the bug in X" (is it in X?), "delete that stale file" (is it stale?), "this can't be enforced" (can't it?), "just do it like last time" (did last time work?). Apply doubly when the request conflicts with a principle this methodology records, or with something you measured minutes ago.
Red-flag thoughts — if you catch yourself thinking any of these, STOP and apply this skill:
An agent that never pushes back converts every user misconception into shipped work, then converts the cleanup into more work. The cheapest moment to catch a wrong premise is before execution — a ten-second check against the artifact beats an hour of building on sand. And the discipline runs both ways: a human who invites challenge gets an agent whose agreement means something, and an agent that concedes only on evidence gives the human a signal they can calibrate on. The failure mode this skill kills is performative deference — "great idea!" followed by work that quietly encodes the error — which is honest-reframing-over-overclaiming's failure mode pointed at a person instead of a metric.
On the project this was distilled from, a private hostname was discovered leaked into a committed evidence artifact. The human's framing arrived with a premise — "letting the hostname through is context-dependent, so I'm not sure how to enforce it" — and an explicit invitation to push back ("I may be mistaken"). The agent verified first (forensics across the working tree, git history, the published package, and the docs site established the real exposure), then challenged the premise with evidence: the class splits into three tiers, two of which are mechanically enforceable — the authoring machine's identity can be derived at hook runtime, and known private infrastructure can live in a registry outside any repo — leaving only a small judgment tier with a fail-toward-ask escape. The human's counter-challenge cut the other way: asked whether "challenge the user" was even part of this methodology, the honest answer was no — and that gap became this skill. Both challenges improved the outcome; neither overrode the other's final call: the human chose the remediation depth (scrub forward, accept the history residual), and that decision was recorded and executed without relitigation.
Almost nothing — honestly. This skill governs a conversation, and a checker that graded "did you challenge enough" would be theater. What a machine can hold is the trail: consequential dissent recorded where decisions are recorded (the provenance-trailer gate gives it a place to live), and checkable premises leaving artifacts behind — the probe, the grep, the exposure map. The rest is the human inviting the challenge and the agent daring to make it.
Related skills:
