Doubt-Driven Development
Challenge non-trivial decisions with a fresh adversarial review before they stand.
The skill explicitly requires user confirmation for cross-model calls, limits transmitted material to ARTIFACT+CONTRACT, and recommends read-only sandboxes, stdin transport, and explicit failure disclosure, reducing external-effect and injection risks. Points are deducted because it does not systematically address sensitive code or secret-data handling, least-privilege details, recovery, or source verification; publisher identity is also unverified by the stated registry.
The workflow is internally coherent, with applicability boundaries, a five-step loop, failure feedback, a three-cycle stop condition, and preflight checks for external CLIs. Static review cannot reproduce the key invocation path, which depends on Claude Code personas, referenced files, external CLIs, and version-specific flags. Execution and dependency uncertainty therefore reduce the score and keep it below the static ceiling.
Trigger and non-trigger conditions are relatively precise, covering high-stakes, unfamiliar, and irreversible decisions while distinguishing main-session and subagent use. Points are deducted because the core capability requires an orchestration environment able to spawn a fresh-context reviewer, parts of the guidance are Claude Code-specific, and no Chinese-language or mainland-China network adaptation is documented.
The skill provides overview, triggers, loading constraints, process steps, anti-rationalization guidance, red flags, and a verification checklist, with concrete examples; repository context supplies MIT licensing, CI, and maintainer information. Points are deducted because the skill lacks its own version, changelog, standalone dependency notes, maintenance/update path, and troubleshooting for missing references or agents.
The CLAIM→EXTRACT→DOUBT→RECONCILE→STOP process is directly usable for reviewing non-trivial decisions and gives actionable guidance on adversarial prompts, finding classification, and bounded iteration. Points are deducted because results depend on an orchestrator actually providing isolated review and interactive confirmation, with no representative output or comparative-benefit evidence supplied.
The skill contains auditable checklists, explicit stop criteria, and pre-invocation validation requirements, while repository CI checks overall skill structure and an evaluation runner. Points are deducted because the supplied test fixture is unrelated to this skill, no dedicated tests cover the doubt cycle, and no third-party execution evidence or independent corroboration is present; static evidence supports only limited verification.
- The core process depends on a main-session orchestrator capable of creating a fresh-context reviewer; unsupported environments may fall back to degraded self-review.
- Cross-model review may send proprietary code, personal data, or secrets to an external CLI; the skill does not define redaction, data classification, or provider boundaries.
- Example flags for Claude Code, Gemini CLI, and Codex CLI may change by version and must be rechecked and authorized before invocation.
- The documentation is English-centric and provides no evidence for Chinese triggering, interaction, or review quality.
What does this skill do, and when should you use it?
Doubt-Driven Development requires a fresh-context reviewer to challenge every non-trivial decision before it is finalized. It is intended for correctness-first situations such as production work, security-sensitive logic, irreversible operations, and unfamiliar code. The workflow moves from stating a claim to extracting the artifact and contract, running an adversarial review, reconciling findings, and stopping under bounded conditions. It is an in-flight posture, not a verdict on a finished artifact.
It asks the orchestrator to state the decision and why it matters, then isolate the smallest reviewable artifact and its contract. A fresh-context reviewer is given only the artifact, contract, and an adversarial prompt that asks for unstated assumptions, edge cases, hidden coupling, contract violations, broken conventions, and unexpected-input failures. The orchestrator classifies each finding as a contract misread, actionable issue, trade-off, or noise, and stops when findings are trivial, three cycles are complete, or the user overrides the process.
- An engineer preparing a non-trivial production change wants an independent search for failure modes before committing.
- A developer working in unfamiliar code needs architectural assumptions challenged while correction is still inexpensive.
- A security-focused team is changing sensitive logic and wants an explicitly adversarial review in flight.
- A team planning a production deploy, data migration, or public API change needs to examine irreversible blast radius.
What are this skill's strengths and limitations?
- Provides a concrete five-step process for non-trivial decisions.
- Uses adversarial framing to look for failures instead of merely validating conclusions.
- Defines finding classifications and a three-cycle bound.
- Targets high-stakes situations including production, security-sensitive, and irreversible work.
- Requires an orchestration environment capable of providing a fresh-context reviewer.
- Cannot perform nested review from a subagent context according to the skill text.
- The supplied material includes no reviewer implementation, test suite, or quality measurements.
- Adds review time and cost compared with mechanical operations or explicit, unambiguous instructions.
How do you install this skill?
Install only this skill from the repository:
npx skills add addyosmani/agent-skills --skill doubt-driven-development
The README does not document another individual-skill installation command.
How do you use this skill?
Before a non-trivial decision, ask: "Apply doubt-driven development to this decision." Follow CLAIM → EXTRACT → DOUBT → RECONCILE → STOP. The skill is designed for a main-session orchestrator with a fresh-context reviewer; in a subagent context, nested review is not supported.
How does this skill compare with similar options?
The skill distinguishes itself from /review: /review gives a verdict on a finished artifact, while Doubt-Driven Development challenges non-trivial decisions during execution so course correction remains cheap.