agentleFS
Sign inStart free
yjhqweryjhqwer/yjh-discipline/skills/doubt-driven-development/SKILL.md

doubt-driven-development

Skill1 starsChanged 2 months agoMITView on GitHub

Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when a decision modifies branching logic, crosses a module or service boundary, asserts a property no compiler can check, depends on unseen context, has an irreversible blast radius, settles a prior-art verdict (Adopt/Extend/Compose/Build), or any time a confident output would be cheaper to verify now than to debug later.

64 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use constraint-driven-development, using-agent-skills and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MrCipherSmithSkill

    constraint-driven-development

    Use when a project needs a persistent, measurable quality bar — starting a project without documented standards, 'set up constraints', or when coverage/perf/a11y thresholds get re-debated per-PR. Produces CONSTRAINTS.md with enforceable numbers, ratchets, and a guard against silent weakening. NOT for throwaway prototypes or a one-off CI setup.

    Also in 17 projects that use this

  • LLl0k0laDSkill

    using-agent-skills

    Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.

    Also in 38 projects that use this

  • HK-hubSkill

    observability-and-instrumentation

    Instruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.

    Also in 36 projects that use this

  • LLl0k0laDSkill

    shipping-and-launch

    Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.

    Also in 46 projects that use this

  • HK-hubSkill

    deprecation-and-migration

    Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when deciding whether to maintain or sunset existing code.

    Also in 33 projects that use this

  • +5 more from LLl0k0laD
  • +2 more from HK-hub

The file

Create a free account to mount
Files
SKILL.md

Doubt-Driven Development

A decision that was never attacked is not validated — it is untested. Before a non-trivial decision becomes the plan, a fresh-context reviewer whose only job is to prove it wrong gets one swing at it.

When it fires

Any of:

  • the change modifies branching logic
  • it crosses a module or service boundary
  • it asserts a property no compiler or type-checker can verify
  • it depends on context the decision-maker cannot see
  • its blast radius is irreversible (production auth, security-sensitive logic, data migration, public-facing actions)
  • a prior-art verdict (Adopt / Extend / Compose / Build) is about to be recorded

When it stays silent (exclusions)

Mechanical operations; changes the user explicitly prescribed; reading and summarizing; one-line obvious changes; pure tooling work; and any time the user has chosen speed over verification. When "non-trivial" is genuinely unclear, the cost asymmetry decides: a refutation run costs minutes, debugging a confident wrong decision costs hours.

Procedure

  1. FRAME — Write the decision as an ARTIFACT (the plan, design, or verdict itself) plus a CONTRACT (the acceptance criteria it must meet). The artifact never travels with the author's reasoning or self-defense.

  2. REFUTE — Dispatch a fresh-context subagent with the artifact and contract only:

    Adversarial review. Find what is wrong with this artifact. Assume the author is overconfident. Check it against the contract only. Do NOT validate. Do NOT summarize. Report every gap as: claim → why it fails → what evidence would change your mind.

  3. RESOLVE — Fix the artifact for each surviving gap and re-run the refuter. Maximum 3 cycles; if the third cycle still refutes, stop and take the decision to the human with both sides summarized.

The refuter never sees the author's justification — only what was decided and the bar it must clear. Fresh context is the point: no shared enthusiasm, no sunk-cost politeness.

Extended from addyosmani/agent-skills doubt-driven-development (MIT); trigger list extended with prior-art verdicts.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free