Doubt-Driven Development helps you catch mistakes before they become big problems. It works by having a fresh reviewer look at important decisions with the goal of finding flaws, not agreeing. This is useful when working in code you do not fully understand or when a single mistake could hurt users or break a system.
The process has five steps. First you write down the decision you are making and why it matters. Then you isolate the code or plan and strip away your own reasoning. Next you call in a reviewer who sees the problem for the first time and tries to prove it is wrong. After that you compare all findings to your original idea. Finally you stop when only small issues remain or after three rounds.
Anyone who writes important code can use this approach. It is not for simple changes like renaming files or following clear instructions. Use it when correctness matters more than speed and when a quick check now saves hours of debugging later.
Global
mkdir -p ~/.claude/skills/doubt-driven-developmentProject
mkdir -p .claude/skills/doubt-driven-developmentSource Repository
Improve Codebase Architecturemattpocock/skills
Scan your codebase for architecture improvements with visual reports and pick one to refactor
Web Design Guidelinesvercel-labs/agent-skills
Review your UI code for compliance with web interface guidelines
Caveman Reviewjuliusbrussee/caveman
Ultra-compressed one-line code review comments that cut noise
Zoom Outmattpocock/skills
Get a big picture view of your code with a simple map of modules and callers
Codebase Designmattpocock/skills
Create deep modules with tiny interfaces and lots of hidden logic for testability
Requesting Code Reviewobra/superpowers
Catch code issues early with focused automated reviews before every merge
Request Refactor Planmattpocock/skills
Plan safe code refactors with tiny commits and clear GitHub issues
Receiving Code Reviewobra/superpowers
Think first, then code. Verify feedback before making changes. Stay objective