doubt-driven-review

Name: doubt-driven-review
Author: pimenov

20stars2forks

How to install doubt-driven-review?

pimenov/codex-first-skills-pack/doubt-driven-review

$npx -y skills add pimenov/codex-first-skills-pack --skill doubt-driven-review

Installs into the current project.

Summary

Runs an adversarial review gate for non-trivial or high-stakes decisions before they stand. Use when Codex is about to claim something is safe, correct, reversible, production-ready, scalable, idempotent, secure, or compliant; when work touches production, auth, permissions, secr

Files · 1

View on GitHub

SKILL.md

1	# Doubt-Driven Review
2
3	## Overview
4
5	Use this skill to challenge a risky decision while it is still cheap to change. The reviewer must try to disprove the artifact against its contract, not praise it or summarize it.
6
7	This is an in-flight gate, not a general code review. It is for decisions, claims, diffs, plans, migrations, deploy steps, rollback plans, and safety assertions that could hurt if they are wrong.
8
9	## Do Not Use
10
11	- One-line mechanical edits, formatting, renames, or file moves.
12	- Simple read-only exploration where no claim or mutation follows.
13	- Tasks already proven by a failing-then-passing test at the right boundary.
14	- Cases where the user explicitly chooses speed over verification and the risk is low.
15	- As theater after the decision is already made; use normal review for finished artifacts.
16
17	## Trigger Test
18
19	A decision is non-trivial when at least one is true:
20
21	- It crosses a module, service, repository, account, or production boundary.
22	- It changes branching logic, permissions, data shape, API behavior, routing, deploy/runtime config, or cleanup behavior.
23	- It asserts a property the type system cannot prove: idempotence, ordering, race safety, rollback safety, data parity, security, or compatibility.
24	- It depends on context a future reader cannot see.
25	- It would be expensive, public, or irreversible to undo.
26
27	When in doubt on production, auth, data, billing, secrets, infrastructure, or external agent runtime isolation, apply the skill.
28
29	## Workflow
30
31	### 1. State The Claim
32
33	Write the claim in two or three lines:
34
35	```text
36	CLAIM:
37	<What is about to stand as true?>
38
39	WHY THIS MATTERS:
40	<What breaks if this claim is wrong?>
41	```
42
43	If the claim cannot be written compactly, the decision is not yet clear enough to review. Clarify the contract first.
44
45	### 2. Extract Artifact And Contract
46
47	Prepare the smallest reviewable unit.
48
49	Use this shape:
50
51	```text
52	ARTIFACT:
53	<diff, command plan, migration plan, config, function, rollout plan, or decision proposal>
54
55	CONTRACT:
56	- Must satisfy: <requirements>
57	- Must not: <stop-lines>
58	- Evidence available: <tests, docs, source files, smoke checks>
59	- Unknowns: <known gaps>
60	```
61
62	Do not include hidden chain-of-thought, persuasive reasoning, or the `CLAIM` in the reviewer prompt. The reviewer receives artifact plus contract only.
63
64	If the artifact is too large, split it before review. A 500-line diff should become focused review units.
65
66	### 3. Run The Adversarial Review
67
68	Use the strongest safe review method available.
69
70	Preferred order:
71
72	1. Fresh-context subagent or reviewer tool, when available and safe.
73	2. A separate model or external CLI only after explicit user approval and isolation preflight.
74	3. Degraded self-review fallback when no fresh reviewer is available; clearly label it as degraded.
75
76	Use this prompt:
77
78	```text
79	Adversarial review. Find what is wrong with this artifact.
80	Assume the author is overconfident. Look for:
81	- unstated assumptions;
82	- edge cases not handled;
83	- hidden coupling or shared state;
84	- ways the contract could be violated;
85	- existing conventions this might break;
86	- failure modes under unexpected input, timing, permissions, or partial rollback.
87
88	Do not validate. Do not summarize. Find issues, or state explicitly that you cannot find any after thorough examination.
89
90	ARTIFACT:
91	<artifact>
92
93	CONTRACT:
94	<contract>
95	```
96
97	For behavioral code, a failing test written before the fix can satisfy the adversarial review for that specific behavior. For production, data, auth, permissions, deployment, or irreversible operations, tests may be evidence but do not replace explicit safety review.
98
99	### 4. External CLI Gate
100
101	Never run `codex exec`, Gemini CLI, Claude Code, OpenCode, or another agentic CLI from this skill without explicit user approval for that exact invocation.
102
103	Before any external CLI:
104
105	1. Verify the exact binary with `which <tool>` and version/help output.
106	2. State the exact `cwd`.
107	3. State the effective `CODEX_HOME` or tool profile/home.
108	4. Describe the inherited env class without printing secrets.
109	5. Confirm no production-capable MCP/apps/server tools are available unless the user explicitly approved that production operation.
110	6. Use read-only or plan/sandbox mode when available.
111	7. Pass the prompt through stdin or a temporary file; never interpolate artifact text into shell arguments.
112	8. Delete temporary prompt/output files unless intentionally saved as evidence.
113
114	If isolation is not proven, do not run the externa

People who liked this also viewed

6 picks

Type

doubt-driven-review

20stars2forks

View on GitHub

How to install doubt-driven-review?

pimenov/codex-first-skills-pack/doubt-driven-review

$npx -y skills add pimenov/codex-first-skills-pack --skill doubt-driven-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Doubt-Driven Review
2
3	## Overview
4
5	Use this skill to challenge a risky decision while it is still cheap to change. The reviewer must try to disprove the artifact against its contract, not praise it or summarize it.
6
7	This is an in-flight gate, not a general code review. It is for decisions, claims, diffs, plans, migrations, deploy steps, rollback plans, and safety assertions that could hurt if they are wrong.
8
9	## Do Not Use
10
11	- One-line mechanical edits, formatting, renames, or file moves.
12	- Simple read-only exploration where no claim or mutation follows.
13	- Tasks already proven by a failing-then-passing test at the right boundary.
14	- Cases where the user explicitly chooses speed over verification and the risk is low.
15	- As theater after the decision is already made; use normal review for finished artifacts.
16
17	## Trigger Test
18
19	A decision is non-trivial when at least one is true:
20
21	- It crosses a module, service, repository, account, or production boundary.
22	- It changes branching logic, permissions, data shape, API behavior, routing, deploy/runtime config, or cleanup behavior.
23	- It asserts a property the type system cannot prove: idempotence, ordering, race safety, rollback safety, data parity, security, or compatibility.
24	- It depends on context a future reader cannot see.
25	- It would be expensive, public, or irreversible to undo.
26
27	When in doubt on production, auth, data, billing, secrets, infrastructure, or external agent runtime isolation, apply the skill.
28
29	## Workflow
30
31	### 1. State The Claim
32
33	Write the claim in two or three lines:
34
35	```text
36	CLAIM:
37	<What is about to stand as true?>
38
39	WHY THIS MATTERS:
40	<What breaks if this claim is wrong?>
41	```
42
43	If the claim cannot be written compactly, the decision is not yet clear enough to review. Clarify the contract first.
44
45	### 2. Extract Artifact And Contract
46
47	Prepare the smallest reviewable unit.
48
49	Use this shape:
50
51	```text
52	ARTIFACT:
53	<diff, command plan, migration plan, config, function, rollout plan, or decision proposal>
54
55	CONTRACT:
56	- Must satisfy: <requirements>
57	- Must not: <stop-lines>
58	- Evidence available: <tests, docs, source files, smoke checks>
59	- Unknowns: <known gaps>
60	```
61
62	Do not include hidden chain-of-thought, persuasive reasoning, or the `CLAIM` in the reviewer prompt. The reviewer receives artifact plus contract only.
63
64	If the artifact is too large, split it before review. A 500-line diff should become focused review units.
65
66	### 3. Run The Adversarial Review
67
68	Use the strongest safe review method available.
69
70	Preferred order:
71
72	1. Fresh-context subagent or reviewer tool, when available and safe.
73	2. A separate model or external CLI only after explicit user approval and isolation preflight.
74	3. Degraded self-review fallback when no fresh reviewer is available; clearly label it as degraded.
75
76	Use this prompt:
77
78	```text
79	Adversarial review. Find what is wrong with this artifact.
80	Assume the author is overconfident. Look for:
81	- unstated assumptions;
82	- edge cases not handled;
83	- hidden coupling or shared state;
84	- ways the contract could be violated;
85	- existing conventions this might break;
86	- failure modes under unexpected input, timing, permissions, or partial rollback.
87
88	Do not validate. Do not summarize. Find issues, or state explicitly that you cannot find any after thorough examination.
89
90	ARTIFACT:
91	<artifact>
92
93	CONTRACT:
94	<contract>
95	```
96
97	For behavioral code, a failing test written before the fix can satisfy the adversarial review for that specific behavior. For production, data, auth, permissions, deployment, or irreversible operations, tests may be evidence but do not replace explicit safety review.
98
99	### 4. External CLI Gate
100
101	Never run `codex exec`, Gemini CLI, Claude Code, OpenCode, or another agentic CLI from this skill without explicit user approval for that exact invocation.
102
103	Before any external CLI:
104
105	1. Verify the exact binary with `which <tool>` and version/help output.
106	2. State the exact `cwd`.
107	3. State the effective `CODEX_HOME` or tool profile/home.
108	4. Describe the inherited env class without printing secrets.
109	5. Confirm no production-capable MCP/apps/server tools are available unless the user explicitly approved that production operation.
110	6. Use read-only or plan/sandbox mode when available.
111	7. Pass the prompt through stdin or a temporary file; never interpolate artifact text into shell arguments.
112	8. Delete temporary prompt/output files unless intentionally saved as evidence.
113
114	If isolation is not proven, do not run the externa

People who liked this also viewed

6 picks

Type