doubt-driven-development

Name: doubt-driven-development
Author: addyosmani

11kinstalls8.6kforks

How to install doubt-driven-development?

addyosmani/agent-skills/doubt-driven-development

$npx -y skills add addyosmani/agent-skills --skill doubt-driven-development

Installs into the current project.

Summary

Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations), or any time a confident

Files · 1

View on GitHub

SKILL.md

1	# Doubt-Driven Development
2
3	## Overview
4
5	A confident answer is not a correct one. Long sessions accumulate context that quietly turns assumptions into "facts" without anyone noticing. Doubt-driven development is the discipline of materializing a fresh-context reviewer — biased to disprove, not approve — before any non-trivial output stands.
6
7	This is not `/review`. `/review` is a verdict on a finished artifact. This is an in-flight posture: non-trivial decisions get cross-examined while course-correction is still cheap.
8
9	## When to Use
10
11	A decision is non-trivial when at least one of these is true:
12
13	- It introduces or modifies branching logic
14	- It crosses a module or service boundary
15	- It asserts a property the type system or compiler cannot verify (thread safety, idempotence, ordering, invariants)
16	- Its correctness depends on context the future reader cannot see
17	- Its blast radius is irreversible (production deploy, data migration, public API change)
18
19	Apply the skill when:
20
21	- About to make an architectural decision under uncertainty
22	- About to commit non-trivial code
23	- About to claim a non-obvious fact ("this is safe", "this scales", "this matches the spec")
24	- Working in code you don't fully understand
25
26	When NOT to use:
27
28	- Mechanical operations (renaming, formatting, file moves)
29	- Following a clear, unambiguous user instruction
30	- Reading or summarizing existing code
31	- One-line changes with obvious correctness
32	- Pure tooling operations (running tests, listing files)
33	- The user has explicitly asked for speed over verification
34
35	If you doubt every keystroke, you ship nothing. The skill applies only to non-trivial decisions as defined above.
36
37	## Loading Constraints
38
39	This skill is designed for the main-session orchestrator, where Step 3 (DOUBT, detailed below) can spawn a fresh-context reviewer.
40
41	- Do NOT add this skill to a persona's `skills:` frontmatter. A persona that follows Step 3 would spawn another persona — the orchestration anti-pattern explicitly forbidden by `references/orchestration-patterns.md` ("personas do not invoke other personas").
42	- If you find yourself applying this skill from inside a subagent context (where Claude Code prevents nested subagent spawn): the preferred path is to surface to the user that doubt-driven cannot run nested and let the main session handle it. As a last resort only, a degraded self-questioning fallback exists — rewrite ARTIFACT + CONTRACT as a fresh self-prompt with a hard mental separator from your prior reasoning, and walk Steps 1–5. This is not fresh-context review (you carry your own context with you), so flag the result as degraded and prefer escalation whenever the user is reachable.
43
44	## The Process
45
46	Copy this checklist when applying the skill:
47
48	```
49	Doubt cycle:
50	- [ ] Step 1: CLAIM — wrote the claim + why-it-matters
51	- [ ] Step 2: EXTRACT — isolated artifact + contract, stripped reasoning
52	- [ ] Step 3: DOUBT — invoked fresh-context reviewer with adversarial prompt
53	- [ ] Step 4: RECONCILE — classified every finding against the artifact text
54	- [ ] Step 5: STOP — met stop condition (trivial findings, 3 cycles, or user override)
55	```
56
57	### Step 1: CLAIM — Surface what stands
58
59	Name the decision in two or three lines:
60
61	```
62	CLAIM: "The new caching layer is thread-safe under the
63	read-heavy workload described in the spec."
64	WHY THIS MATTERS: a race here corrupts user data and is
65	hard to detect in QA.
66	```
67
68	If you can't write the claim that compactly, you have a vibe, not a decision. Surface it before scrutinizing it.
69
70	### Step 2: EXTRACT — Smallest reviewable unit
71
72	A fresh-context reviewer needs the artifact and the contract, not the journey.
73
74	- Code: the diff or the function — not the whole file
75	- Decision: the proposal in 3–5 sentences plus the constraints it has to satisfy
76	- Assertion: the claim plus the evidence that supposedly supports it (kept distinct from the Step 1 CLAIM block, which is the orchestrator's hypothesis under scrutiny)
77
78	Strip your reasoning. If you hand over conclusions, you'll get back validation of your conclusions. The unit must be small enough that a reviewer can hold it in mind in one read — if it's a 500-line PR, decompose first.
79
80	### Step 3: DOUBT — Invoke the fresh-context reviewer
81
82	The reviewer's prompt must be adversarial. Framing decides the answer.
83
84	```
85	Adversarial review. Find what is wrong with this artifact.
86	Assume the author is overconfident. Look for:
87	- Unstated assumptions
88	- Edge cases not handled
89	- Hidden coupling or shared state
90	- Ways the contract could be violated
91	- Existing conventi

People who liked this also viewed

6 picks

Type

doubt-driven-development

11kinstalls8.6kforks

View on GitHub

How to install doubt-driven-development?

addyosmani/agent-skills/doubt-driven-development

$npx -y skills add addyosmani/agent-skills --skill doubt-driven-development

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Doubt-Driven Development
2
3	## Overview
4
5	A confident answer is not a correct one. Long sessions accumulate context that quietly turns assumptions into "facts" without anyone noticing. Doubt-driven development is the discipline of materializing a fresh-context reviewer — biased to disprove, not approve — before any non-trivial output stands.
6
7	This is not `/review`. `/review` is a verdict on a finished artifact. This is an in-flight posture: non-trivial decisions get cross-examined while course-correction is still cheap.
8
9	## When to Use
10
11	A decision is non-trivial when at least one of these is true:
12
13	- It introduces or modifies branching logic
14	- It crosses a module or service boundary
15	- It asserts a property the type system or compiler cannot verify (thread safety, idempotence, ordering, invariants)
16	- Its correctness depends on context the future reader cannot see
17	- Its blast radius is irreversible (production deploy, data migration, public API change)
18
19	Apply the skill when:
20
21	- About to make an architectural decision under uncertainty
22	- About to commit non-trivial code
23	- About to claim a non-obvious fact ("this is safe", "this scales", "this matches the spec")
24	- Working in code you don't fully understand
25
26	When NOT to use:
27
28	- Mechanical operations (renaming, formatting, file moves)
29	- Following a clear, unambiguous user instruction
30	- Reading or summarizing existing code
31	- One-line changes with obvious correctness
32	- Pure tooling operations (running tests, listing files)
33	- The user has explicitly asked for speed over verification
34
35	If you doubt every keystroke, you ship nothing. The skill applies only to non-trivial decisions as defined above.
36
37	## Loading Constraints
38
39	This skill is designed for the main-session orchestrator, where Step 3 (DOUBT, detailed below) can spawn a fresh-context reviewer.
40
41	- Do NOT add this skill to a persona's `skills:` frontmatter. A persona that follows Step 3 would spawn another persona — the orchestration anti-pattern explicitly forbidden by `references/orchestration-patterns.md` ("personas do not invoke other personas").
42	- If you find yourself applying this skill from inside a subagent context (where Claude Code prevents nested subagent spawn): the preferred path is to surface to the user that doubt-driven cannot run nested and let the main session handle it. As a last resort only, a degraded self-questioning fallback exists — rewrite ARTIFACT + CONTRACT as a fresh self-prompt with a hard mental separator from your prior reasoning, and walk Steps 1–5. This is not fresh-context review (you carry your own context with you), so flag the result as degraded and prefer escalation whenever the user is reachable.
43
44	## The Process
45
46	Copy this checklist when applying the skill:
47
48	```
49	Doubt cycle:
50	- [ ] Step 1: CLAIM — wrote the claim + why-it-matters
51	- [ ] Step 2: EXTRACT — isolated artifact + contract, stripped reasoning
52	- [ ] Step 3: DOUBT — invoked fresh-context reviewer with adversarial prompt
53	- [ ] Step 4: RECONCILE — classified every finding against the artifact text
54	- [ ] Step 5: STOP — met stop condition (trivial findings, 3 cycles, or user override)
55	```
56
57	### Step 1: CLAIM — Surface what stands
58
59	Name the decision in two or three lines:
60
61	```
62	CLAIM: "The new caching layer is thread-safe under the
63	read-heavy workload described in the spec."
64	WHY THIS MATTERS: a race here corrupts user data and is
65	hard to detect in QA.
66	```
67
68	If you can't write the claim that compactly, you have a vibe, not a decision. Surface it before scrutinizing it.
69
70	### Step 2: EXTRACT — Smallest reviewable unit
71
72	A fresh-context reviewer needs the artifact and the contract, not the journey.
73
74	- Code: the diff or the function — not the whole file
75	- Decision: the proposal in 3–5 sentences plus the constraints it has to satisfy
76	- Assertion: the claim plus the evidence that supposedly supports it (kept distinct from the Step 1 CLAIM block, which is the orchestrator's hypothesis under scrutiny)
77
78	Strip your reasoning. If you hand over conclusions, you'll get back validation of your conclusions. The unit must be small enough that a reviewer can hold it in mind in one read — if it's a 500-line PR, decompose first.
79
80	### Step 3: DOUBT — Invoke the fresh-context reviewer
81
82	The reviewer's prompt must be adversarial. Framing decides the answer.
83
84	```
85	Adversarial review. Find what is wrong with this artifact.
86	Assume the author is overconfident. Look for:
87	- Unstated assumptions
88	- Edge cases not handled
89	- Hidden coupling or shared state
90	- Ways the contract could be violated
91	- Existing conventi

People who liked this also viewed

6 picks

Type