[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M79NNBJMVBCDNVHC8563CS5Q":3,"skill-same:01M79NNBJMVBCDNVHC8563CS5Q":45},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":14,"repositoryHtmlUrl":27,"repositoryHomepageUrl":6,"ownerHtmlUrl":28,"ownerBlogUrl":6,"ownerDescription":29,"updatedAt":30,"install":31,"resources":44},"01M79NNBJMVBCDNVHC8563CS5Q","doubt-driven-development",null,"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 output would be cheaper to verify now than to debug later.","JunMystery\u002FAgent-Guidance","JunMystery","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F161468934?v=4","01M79MTMV8F0BY8NK1A92RA8A0","Jun","01M79MTMWCFBKPHN5B25E6V20B",0,"MIT","https:\u002F\u002Fgithub.com\u002FJunMystery\u002FAgent-Guidance\u002Fblob\u002Fmain\u002Fskills\u002Fdoubt-driven-development\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: doubt-driven-development\ndescription: 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 output would be cheaper to verify now than to debug later.\n---\n\n# Doubt-Driven Development\n\n## Overview\n\nA 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.\n\nThis is not `\u002Freview`. `\u002Freview` 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.\n\n## When to Use\n\nA decision is **non-trivial** when at least one of these is true:\n\n- It introduces or modifies branching logic\n- It crosses a module or service boundary\n- It asserts a property the type system or compiler cannot verify (thread safety, idempotence, ordering, invariants)\n- Its correctness depends on context the future reader cannot see\n- Its blast radius is irreversible (production deploy, data migration, public API change)\n\nApply the skill when:\n\n- About to make an architectural decision under uncertainty\n- About to commit non-trivial code\n- About to claim a non-obvious fact (\"this is safe\", \"this scales\", \"this matches the spec\")\n- Working in code you don't fully understand\n\n**When NOT to use:**\n\n- Mechanical operations (renaming, formatting, file moves)\n- Following a clear, unambiguous user instruction\n- Reading or summarizing existing code\n- One-line changes with obvious correctness\n- Pure tooling operations (running tests, listing files)\n- The user has explicitly asked for speed over verification\n\nIf you doubt every keystroke, you ship nothing. The skill applies only to non-trivial decisions as defined above.\n\n## Loading Constraints\n\nThis skill is designed for the **main-session orchestrator**, where Step 3 (DOUBT, detailed below) can spawn a fresh-context reviewer.\n\n- **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\u002Forchestration-patterns.md` (\"personas do not invoke other personas\").\n- **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.\n\n## The Process\n\nCopy this checklist when applying the skill:\n\n```\nDoubt cycle:\n- [ ] Step 1: CLAIM — wrote the claim + why-it-matters\n- [ ] Step 2: EXTRACT — isolated artifact + contract, stripped reasoning\n- [ ] Step 3: DOUBT — invoked fresh-context reviewer with adversarial prompt\n- [ ] Step 4: RECONCILE — classified every finding against the artifact text\n- [ ] Step 5: STOP — met stop condition (trivial findings, 3 cycles, or user override)\n```\n\n### Step 1: CLAIM — Surface what stands\n\nName the decision in two or three lines:\n\n```\nCLAIM: \"The new caching layer is thread-safe under the\n        read-heavy workload described in the spec.\"\nWHY THIS MATTERS: a race here corrupts user data and is\n                  hard to detect in QA.\n```\n\nIf you can't write the claim that compactly, you have a vibe, not a decision. Surface it before scrutinizing it.\n\n### Step 2: EXTRACT — Smallest reviewable unit\n\nA fresh-context reviewer needs the **artifact** and the **contract**, not the journey.\n\n- Code: the diff or the function — not the whole file\n- Decision: the proposal in 3–5 sentences plus the constraints it has to satisfy\n- 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)\n\nStrip 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.\n\n### Step 3: DOUBT — Invoke the fresh-context reviewer\n\nThe reviewer's prompt **must be adversarial**. Framing decides the answer.\n\n```\nAdversarial review. Find what is wrong with this artifact.\nAssume the author is overconfident. Look for:\n- Unstated assumptions\n- Edge cases not handled\n- Hidden coupling or shared state\n- Ways the contract could be violated\n- Existing conventions this might break\n- Failure modes under unexpected input\n\nDo NOT validate. Do NOT summarize. Find issues, or state\nexplicitly that you cannot find any after thorough examination.\n\nARTIFACT: \u003Cpaste artifact>\nCONTRACT: \u003Cpaste contract>\n```\n\n**Pass ARTIFACT + CONTRACT only. Do NOT pass the CLAIM.** Handing the reviewer your conclusion biases it toward agreement. The reviewer must independently determine whether the artifact satisfies the contract.\n\nIn Claude Code, the role-based reviewers in `agents\u002F` start with isolated context by design and are usable here — see `agents\u002F` for the roster and per-domain match.\n\n**The adversarial prompt above takes precedence over the persona's default response shape.** Personas like `code-reviewer` are written to produce balanced verdicts with both strengths and weaknesses; doubt-driven needs issues-only output. Paste the adversarial prompt verbatim into the invocation so it overrides the persona's default. If a persona's response shape can't be overridden cleanly, fall back to a generic subagent with the adversarial prompt.\n\n#### Cross-model escalation\n\nA single-model reviewer shares blind spots with the original author — a colder, different-architecture model catches them. Doubt-driven is already opt-in for non-trivial decisions, so within that scope offering cross-model is part of the skill's value, not optional friction.\n\n**Interactive sessions: always offer. Never silently skip.**\n\n**Step 1: Ask the user**\n\nAfter the single-model review in Step 3 above, but before RECONCILE, pause and ask:\n\n> *\"Single-model review complete. Want a cross-model second opinion? Options: Gemini CLI, Codex CLI, manual external review (you paste it elsewhere), or skip.\"*\n\nThis question is mandatory in every interactive doubt cycle — even on artifacts that feel low-stakes. The user — not the agent — decides whether the cost is worth it. The agent's job is to surface the choice.\n\n**Step 2: If the user picks a CLI — verify, then invoke**\n\n1. Check the tool is in PATH (`which gemini`, `which codex`).\n2. Test it works (`gemini --version` or equivalent) before passing the full prompt — a stale or broken binary may pass `which` but fail on real input.\n3. Confirm the exact invocation with the user, including required flags, auth, and env vars (e.g., API keys). Implementations vary; never assume.\n4. Pass ARTIFACT + CONTRACT + the adversarial prompt **only**. No session context, no CLAIM.\n5. Mind shell escaping. If the artifact contains quotes, `$(...)`, or backticks, prefer stdin (`echo … | gemini`) or a heredoc over inline `-p \"…\"`. When in doubt, ask the user to confirm the invocation before running it.\n6. Take the output into Step 4 (RECONCILE).\n\n**Never interpolate the artifact into a shell-quoted argument.** Code, markdown, and review prompts routinely contain backticks, `$(...)`, and quote characters that will either truncate the prompt or execute embedded shell. Write the full prompt to a file and pipe it through stdin.\n\nExample shapes (verify flags against your installed tool — syntax differs across implementations and versions):\n\n```bash\n# Write the adversarial prompt + ARTIFACT + CONTRACT to a temp file first.\n# Then pipe via stdin so shell metacharacters in the artifact stay inert.\n\n# Codex (read-only sandbox keeps the CLI from writing to your workspace):\ncodex exec --sandbox read-only -C \u003Crepo-path> - \u003C \u002Ftmp\u002Fdoubt-prompt.md\n\n# Gemini ('--approval-mode plan' is read-only; '-p \"\"' triggers non-interactive\n# mode and the prompt is read from stdin):\ngemini --approval-mode plan -p \"\" \u003C \u002Ftmp\u002Fdoubt-prompt.md\n```\n\nA read-only sandbox is the load-bearing detail: a doubt artifact may itself contain instructions (intentional or accidental prompt injection) that the cross-model CLI would otherwise execute against your workspace.\n\n**Step 3: If the CLI is unavailable or fails**\n\nSurface the failure explicitly. Offer: run it manually, try a different tool, or skip. Do not silently fall back to single-model — the user should know cross-model didn't happen.\n\n**Step 4: If the user skips**\n\nAcknowledge the skip in the output (*\"Proceeding with single-model findings only\"*) and continue to RECONCILE. Skipping is fine; silent skipping is not.\n\n**Non-interactive contexts** (CI, `\u002Floop`, autonomous-loop, scheduled runs):\n\n- Cross-model is **skipped**, and the skip must be **announced** in the output: *\"Cross-model skipped: non-interactive context.\"*\n- **Never invoke an external CLI without explicit user authorization** — this is a load-bearing safety property.\n\nCross-model adds cost, latency, and tool fragility. The agent surfaces the choice every cycle; the user decides whether this artifact warrants it.\n\n### Step 4: RECONCILE — Fold findings back\n\nThe reviewer's output is data, not verdict. **You are still the orchestrator.** Re-read the artifact text against each finding before classifying — rubber-stamping the reviewer is the same failure mode as ignoring it.\n\nFor each finding, classify in this **precedence order** (first matching class wins):\n\n1. **Contract misread** — reviewer flagged something specifically because the CONTRACT you provided was unclear or incomplete. Fix the contract first, re-classify on the next cycle.\n2. **Valid + actionable** — real issue requiring a change to the artifact. Change it, re-loop.\n3. **Valid trade-off** — issue is real but cost of fixing exceeds cost of accepting. Document the trade-off explicitly so the user sees it.\n4. **Noise** — reviewer flagged something that's actually correct under context the reviewer didn't have. Note it, move on, and ask: would adding that context to the contract have prevented the false flag?\n\nA fresh reviewer can be wrong because it lacks context. Don't defer just because it's \"fresh.\"\n\n### Step 5: STOP — Bounded loop, not recursion\n\nStop when:\n\n- Next iteration returns only trivial or already-considered findings, **or**\n- 3 cycles completed (escalate to user, don't grind a fourth alone), **or**\n- User explicitly says \"ship it\"\n\nIf after 3 cycles the reviewer still surfaces substantive issues, the artifact may not be ready. Surface this to the user — three unresolved cycles is information about the artifact, not a reason to keep looping.\n\nIf 3 cycles is \"obviously insufficient\" because the artifact is large: the artifact is too big — return to Step 2 and decompose. Do not lift the bound.\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"I'm confident, skip the doubt step\" | Confidence correlates poorly with correctness on novel problems. Moments of certainty are exactly when blind spots hide. |\n| \"Spawning a reviewer is expensive\" | Debugging a wrong commit in production is more expensive. The check is bounded; the bug isn't. |\n| \"The reviewer will just nitpick\" | Only if unscoped. Constrain the prompt to \"issues that would make this fail under the contract.\" |\n| \"I'll do doubt at the end with `\u002Freview`\" | `\u002Freview` is a final gate. Doubt-driven catches wrong directions early when course-correction is cheap. By PR time it's too late. |\n| \"If I doubt every step I'll never ship\" | The skill applies to non-trivial decisions, not every keystroke. Re-read \"When NOT to Use.\" |\n| \"Two opinions are always better than one\" | Not when the second has less context and produces noise. Reconcile, don't defer. |\n| \"The reviewer disagreed so I was wrong\" | The reviewer lacks your context — disagreement is information, not verdict. Re-read the artifact, classify, then decide. |\n| \"Cross-model is always better\" | Cross-model catches blind spots a single model shares with itself, but it adds cost and tool fragility. Offer it every interactive doubt cycle — the user decides whether the artifact warrants it. The agent's job is to surface the choice, not to gate it. |\n| \"User said yes once, so I can keep invoking the CLI\" | Each invocation is its own authorization. The artifact, the prompt, and the flags change between calls — re-confirm the exact command with the user before every run. |\n\n## Red Flags\n\n- Spawning a fresh-context reviewer for a one-line rename or formatting change\n- Treating reviewer output as authoritative without re-reading the artifact text\n- Looping >3 cycles without escalating to the user\n- Prompting the reviewer with \"is this good?\" instead of \"find issues\"\n- Skipping doubt under time pressure on a high-stakes decision\n- Re-spawning fresh-context on an unchanged artifact (you'll get the same findings; you're stalling)\n- **Doubt theater (checkable signal)**: across 2 or more cycles where the reviewer surfaced substantive findings, zero findings were classified as actionable. You are validating, not doubting. Stop and escalate.\n- Doubting only after committing — that's `\u002Freview`, not doubt-driven development\n- Hardcoding an external CLI invocation without confirming with the user that the tool exists, is configured, and accepts that exact syntax\n- **Silently skipping cross-model in an interactive doubt cycle.** Even when not recommending it, the offer must be visible. Skipping is fine; silent skipping is not.\n- Falling back silently when an external CLI errors or is missing — surface the failure and let the user redirect\n- Stripping the contract from the reviewer's input\n- Passing the CLAIM to the reviewer (biases toward agreement)\n\n## Interaction with Other Skills\n\n- **`code-review-and-quality` \u002F `\u002Freview`**: complementary. `\u002Freview` is post-hoc PR verdict; doubt-driven is in-flight per-decision. Use both.\n- **`source-driven-development`**: SDD verifies *facts about frameworks* against official docs. Doubt-driven verifies *your reasoning about the artifact*. SDD checks the API exists; doubt-driven checks you used it correctly under the contract.\n- **`test-driven-development`**: TDD's RED step is doubt made concrete — a failing test is a disproof attempt. When TDD applies, that failing test *is* the doubt step for behavioral claims.\n- **`debugging-and-error-recovery`**: when the reviewer surfaces a real failure mode, drop into the debugging skill to localize and fix.\n- **Repo orchestration rules** (`references\u002Forchestration-patterns.md`): this skill orchestrates from the main session. A persona calling another persona is anti-pattern B — see Loading Constraints above.\n\n## Verification\n\nAfter applying doubt-driven development:\n\n- [ ] Every non-trivial decision (per the definition above) was named explicitly as a CLAIM before standing\n- [ ] At least one fresh-context review per non-trivial artifact (a failing test produced by TDD's RED step satisfies this for behavioral claims, per Interaction with Other Skills)\n- [ ] The reviewer received ARTIFACT + CONTRACT — NOT the CLAIM, NOT your reasoning\n- [ ] The reviewer's prompt was adversarial (\"find issues\"), not validating (\"is it good\")\n- [ ] Findings were classified against the artifact text (not rubber-stamped) using the precedence: contract misread \u002F actionable \u002F trade-off \u002F noise\n- [ ] A stop condition was met (trivial findings, 3 cycles, or user override)\n- [ ] In interactive mode, cross-model was **explicitly offered** to the user (regardless of artifact stakes) and the response was acknowledged in the output\n- [ ] In non-interactive mode, cross-model was skipped and the skip was announced\n- [ ] Any external CLI invocation was preceded by a PATH check, a working-binary test, syntax confirmation with the user, and explicit authorization to run\n","# Doubt-Driven Development\n\n## Overview\n\nA 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.\n\nThis is not `\u002Freview`. `\u002Freview` 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.\n\n## When to Use\n\nA decision is **non-trivial** when at least one of these is true:\n\n- It introduces or modifies branching logic\n- It crosses a module or service boundary\n- It asserts a property the type system or compiler cannot verify (thread safety, idempotence, ordering, invariants)\n- Its correctness depends on context the future reader cannot see\n- Its blast radius is irreversible (production deploy, data migration, public API change)\n\nApply the skill when:\n\n- About to make an architectural decision under uncertainty\n- About to commit non-trivial code\n- About to claim a non-obvious fact (\"this is safe\", \"this scales\", \"this matches the spec\")\n- Working in code you don't fully understand\n\n**When NOT to use:**\n\n- Mechanical operations (renaming, formatting, file moves)\n- Following a clear, unambiguous user instruction\n- Reading or summarizing existing code\n- One-line changes with obvious correctness\n- Pure tooling operations (running tests, listing files)\n- The user has explicitly asked for speed over verification\n\nIf you doubt every keystroke, you ship nothing. The skill applies only to non-trivial decisions as defined above.\n\n## Loading Constraints\n\nThis skill is designed for the **main-session orchestrator**, where Step 3 (DOUBT, detailed below) can spawn a fresh-context reviewer.\n\n- **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\u002Forchestration-patterns.md` (\"personas do not invoke other personas\").\n- **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.\n\n## The Process\n\nCopy this checklist when applying the skill:\n\n```\nDoubt cycle:\n- [ ] Step 1: CLAIM — wrote the claim + why-it-matters\n- [ ] Step 2: EXTRACT — isolated artifact + contract, stripped reasoning\n- [ ] Step 3: DOUBT — invoked fresh-context reviewer with adversarial prompt\n- [ ] Step 4: RECONCILE — classified every finding against the artifact text\n- [ ] Step 5: STOP — met stop condition (trivial findings, 3 cycles, or user override)\n```\n\n### Step 1: CLAIM — Surface what stands\n\nName the decision in two or three lines:\n\n```\nCLAIM: \"The new caching layer is thread-safe under the\n        read-heavy workload described in the spec.\"\nWHY THIS MATTERS: a race here corrupts user data and is\n                  hard to detect in QA.\n```\n\nIf you can't write the claim that compactly, you have a vibe, not a decision. Surface it before scrutinizing it.\n\n### Step 2: EXTRACT — Smallest reviewable unit\n\nA fresh-context reviewer needs the **artifact** and the **contract**, not the journey.\n\n- Code: the diff or the function — not the whole file\n- Decision: the proposal in 3–5 sentences plus the constraints it has to satisfy\n- 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)\n\nStrip 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.\n\n### Step 3: DOUBT — Invoke the fresh-context reviewer\n\nThe reviewer's prompt **must be adversarial**. Framing decides the answer.\n\n```\nAdversarial review. Find what is wrong with this artifact.\nAssume the author is overconfident. Look for:\n- Unstated assumptions\n- Edge cases not handled\n- Hidden coupling or shared state\n- Ways the contract could be violated\n- Existing conventions this might break\n- Failure modes under unexpected input\n\nDo NOT validate. Do NOT summarize. Find issues, or state\nexplicitly that you cannot find any after thorough examination.\n\nARTIFACT: \u003Cpaste artifact>\nCONTRACT: \u003Cpaste contract>\n```\n\n**Pass ARTIFACT + CONTRACT only. Do NOT pass the CLAIM.** Handing the reviewer your conclusion biases it toward agreement. The reviewer must independently determine whether the artifact satisfies the contract.\n\nIn Claude Code, the role-based reviewers in `agents\u002F` start with isolated context by design and are usable here — see `agents\u002F` for the roster and per-domain match.\n\n**The adversarial prompt above takes precedence over the persona's default response shape.** Personas like `code-reviewer` are written to produce balanced verdicts with both strengths and weaknesses; doubt-driven needs issues-only output. Paste the adversarial prompt verbatim into the invocation so it overrides the persona's default. If a persona's response shape can't be overridden cleanly, fall back to a generic subagent with the adversarial prompt.\n\n#### Cross-model escalation\n\nA single-model reviewer shares blind spots with the original author — a colder, different-architecture model catches them. Doubt-driven is already opt-in for non-trivial decisions, so within that scope offering cross-model is part of the skill's value, not optional friction.\n\n**Interactive sessions: always offer. Never silently skip.**\n\n**Step 1: Ask the user**\n\nAfter the single-model review in Step 3 above, but before RECONCILE, pause and ask:\n\n> *\"Single-model review complete. Want a cross-model second opinion? Options: Gemini CLI, Codex CLI, manual external review (you paste it elsewhere), or skip.\"*\n\nThis question is mandatory in every interactive doubt cycle — even on artifacts that feel low-stakes. The user — not the agent — decides whether the cost is worth it. The agent's job is to surface the choice.\n\n**Step 2: If the user picks a CLI — verify, then invoke**\n\n1. Check the tool is in PATH (`which gemini`, `which codex`).\n2. Test it works (`gemini --version` or equivalent) before passing the full prompt — a stale or broken binary may pass `which` but fail on real input.\n3. Confirm the exact invocation with the user, including required flags, auth, and env vars (e.g., API keys). Implementations vary; never assume.\n4. Pass ARTIFACT + CONTRACT + the adversarial prompt **only**. No session context, no CLAIM.\n5. Mind shell escaping. If the artifact contains quotes, `$(...)`, or backticks, prefer stdin (`echo … | gemini`) or a heredoc over inline `-p \"…\"`. When in doubt, ask the user to confirm the invocation before running it.\n6. Take the output into Step 4 (RECONCILE).\n\n**Never interpolate the artifact into a shell-quoted argument.** Code, markdown, and review prompts routinely contain backticks, `$(...)`, and quote characters that will either truncate the prompt or execute embedded shell. Write the full prompt to a file and pipe it through stdin.\n\nExample shapes (verify flags against your installed tool — syntax differs across implementations and versions):\n\n```bash\n# Write the adversarial prompt + ARTIFACT + CONTRACT to a temp file first.\n# Then pipe via stdin so shell metacharacters in the artifact stay inert.\n\n# Codex (read-only sandbox keeps the CLI from writing to your workspace):\ncodex exec --sandbox read-only -C \u003Crepo-path> - \u003C \u002Ftmp\u002Fdoubt-prompt.md\n\n# Gemini ('--approval-mode plan' is read-only; '-p \"\"' triggers non-interactive\n# mode and the prompt is read from stdin):\ngemini --approval-mode plan -p \"\" \u003C \u002Ftmp\u002Fdoubt-prompt.md\n```\n\nA read-only sandbox is the load-bearing detail: a doubt artifact may itself contain instructions (intentional or accidental prompt injection) that the cross-model CLI would otherwise execute against your workspace.\n\n**Step 3: If the CLI is unavailable or fails**\n\nSurface the failure explicitly. Offer: run it manually, try a different tool, or skip. Do not silently fall back to single-model — the user should know cross-model didn't happen.\n\n**Step 4: If the user skips**\n\nAcknowledge the skip in the output (*\"Proceeding with single-model findings only\"*) and continue to RECONCILE. Skipping is fine; silent skipping is not.\n\n**Non-interactive contexts** (CI, `\u002Floop`, autonomous-loop, scheduled runs):\n\n- Cross-model is **skipped**, and the skip must be **announced** in the output: *\"Cross-model skipped: non-interactive context.\"*\n- **Never invoke an external CLI without explicit user authorization** — this is a load-bearing safety property.\n\nCross-model adds cost, latency, and tool fragility. The agent surfaces the choice every cycle; the user decides whether this artifact warrants it.\n\n### Step 4: RECONCILE — Fold findings back\n\nThe reviewer's output is data, not verdict. **You are still the orchestrator.** Re-read the artifact text against each finding before classifying — rubber-stamping the reviewer is the same failure mode as ignoring it.\n\nFor each finding, classify in this **precedence order** (first matching class wins):\n\n1. **Contract misread** — reviewer flagged something specifically because the CONTRACT you provided was unclear or incomplete. Fix the contract first, re-classify on the next cycle.\n2. **Valid + actionable** — real issue requiring a change to the artifact. Change it, re-loop.\n3. **Valid trade-off** — issue is real but cost of fixing exceeds cost of accepting. Document the trade-off explicitly so the user sees it.\n4. **Noise** — reviewer flagged something that's actually correct under context the reviewer didn't have. Note it, move on, and ask: would adding that context to the contract have prevented the false flag?\n\nA fresh reviewer can be wrong because it lacks context. Don't defer just because it's \"fresh.\"\n\n### Step 5: STOP — Bounded loop, not recursion\n\nStop when:\n\n- Next iteration returns only trivial or already-considered findings, **or**\n- 3 cycles completed (escalate to user, don't grind a fourth alone), **or**\n- User explicitly says \"ship it\"\n\nIf after 3 cycles the reviewer still surfaces substantive issues, the artifact may not be ready. Surface this to the user — three unresolved cycles is information about the artifact, not a reason to keep looping.\n\nIf 3 cycles is \"obviously insufficient\" because the artifact is large: the artifact is too big — return to Step 2 and decompose. Do not lift the bound.\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"I'm confident, skip the doubt step\" | Confidence correlates poorly with correctness on novel problems. Moments of certainty are exactly when blind spots hide. |\n| \"Spawning a reviewer is expensive\" | Debugging a wrong commit in production is more expensive. The check is bounded; the bug isn't. |\n| \"The reviewer will just nitpick\" | Only if unscoped. Constrain the prompt to \"issues that would make this fail under the contract.\" |\n| \"I'll do doubt at the end with `\u002Freview`\" | `\u002Freview` is a final gate. Doubt-driven catches wrong directions early when course-correction is cheap. By PR time it's too late. |\n| \"If I doubt every step I'll never ship\" | The skill applies to non-trivial decisions, not every keystroke. Re-read \"When NOT to Use.\" |\n| \"Two opinions are always better than one\" | Not when the second has less context and produces noise. Reconcile, don't defer. |\n| \"The reviewer disagreed so I was wrong\" | The reviewer lacks your context — disagreement is information, not verdict. Re-read the artifact, classify, then decide. |\n| \"Cross-model is always better\" | Cross-model catches blind spots a single model shares with itself, but it adds cost and tool fragility. Offer it every interactive doubt cycle — the user decides whether the artifact warrants it. The agent's job is to surface the choice, not to gate it. |\n| \"User said yes once, so I can keep invoking the CLI\" | Each invocation is its own authorization. The artifact, the prompt, and the flags change between calls — re-confirm the exact command with the user before every run. |\n\n## Red Flags\n\n- Spawning a fresh-context reviewer for a one-line rename or formatting change\n- Treating reviewer output as authoritative without re-reading the artifact text\n- Looping >3 cycles without escalating to the user\n- Prompting the reviewer with \"is this good?\" instead of \"find issues\"\n- Skipping doubt under time pressure on a high-stakes decision\n- Re-spawning fresh-context on an unchanged artifact (you'll get the same findings; you're stalling)\n- **Doubt theater (checkable signal)**: across 2 or more cycles where the reviewer surfaced substantive findings, zero findings were classified as actionable. You are validating, not doubting. Stop and escalate.\n- Doubting only after committing — that's `\u002Freview`, not doubt-driven development\n- Hardcoding an external CLI invocation without confirming with the user that the tool exists, is configured, and accepts that exact syntax\n- **Silently skipping cross-model in an interactive doubt cycle.** Even when not recommending it, the offer must be visible. Skipping is fine; silent skipping is not.\n- Falling back silently when an external CLI errors or is missing — surface the failure and let the user redirect\n- Stripping the contract from the reviewer's input\n- Passing the CLAIM to the reviewer (biases toward agreement)\n\n## Interaction with Other Skills\n\n- **`code-review-and-quality` \u002F `\u002Freview`**: complementary. `\u002Freview` is post-hoc PR verdict; doubt-driven is in-flight per-decision. Use both.\n- **`source-driven-development`**: SDD verifies *facts about frameworks* against official docs. Doubt-driven verifies *your reasoning about the artifact*. SDD checks the API exists; doubt-driven checks you used it correctly under the contract.\n- **`test-driven-development`**: TDD's RED step is doubt made concrete — a failing test is a disproof attempt. When TDD applies, that failing test *is* the doubt step for behavioral claims.\n- **`debugging-and-error-recovery`**: when the reviewer surfaces a real failure mode, drop into the debugging skill to localize and fix.\n- **Repo orchestration rules** (`references\u002Forchestration-patterns.md`): this skill orchestrates from the main session. A persona calling another persona is anti-pattern B — see Loading Constraints above.\n\n## Verification\n\nAfter applying doubt-driven development:\n\n- [ ] Every non-trivial decision (per the definition above) was named explicitly as a CLAIM before standing\n- [ ] At least one fresh-context review per non-trivial artifact (a failing test produced by TDD's RED step satisfies this for behavioral claims, per Interaction with Other Skills)\n- [ ] The reviewer received ARTIFACT + CONTRACT — NOT the CLAIM, NOT your reasoning\n- [ ] The reviewer's prompt was adversarial (\"find issues\"), not validating (\"is it good\")\n- [ ] Findings were classified against the artifact text (not rubber-stamped) using the precedence: contract misread \u002F actionable \u002F trade-off \u002F noise\n- [ ] A stop condition was met (trivial findings, 3 cycles, or user override)\n- [ ] In interactive mode, cross-model was **explicitly offered** to the user (regardless of artifact stakes) and the response was acknowledged in the output\n- [ ] In non-interactive mode, cross-model was skipped and the skip was announced\n- [ ] Any external CLI invocation was preceded by a PATH check, a working-binary test, syntax confirmation with the user, and explicit authorization to run\n",{"name":5,"description":7},"main","5d0a87185c0e172c3901e2a6e5916b6d544b8b94","skills\u002Fdoubt-driven-development","https:\u002F\u002Fgithub.com\u002FJunMystery\u002FAgent-Guidance","https:\u002F\u002Fgithub.com\u002FJunMystery","AI is the typist, I am the architect. Building efficient, secure, and user-centric products through disciplined AI prompt engineering.","2026-11-13 17:41:25",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add JunMystery\u002FAgent-Guidance --skill doubt-driven-development",{"tool":37,"command":38},"bunx","bunx skills add JunMystery\u002FAgent-Guidance --skill doubt-driven-development",{"tool":40,"command":41},"pnpm","pnpm dlx skills add JunMystery\u002FAgent-Guidance --skill doubt-driven-development","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJunMystery\u002FAgent-Guidance\u002Fblob\u002Fmain\u002Fskills\u002Fdoubt-driven-development\u002FSKILL.md",true,[],[46,52,58,64,70,76],{"skillNo":47,"name":48,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":49,"categories":50,"keywords":51,"publishedAt":19},"01M79QR1E309VJ6CTQKB32AWWA","zero-trust-architecture-cheat-sheet","https:\u002F\u002Fgithub.com\u002FJunMystery\u002FAgent-Guidance\u002Fblob\u002Fmain\u002Fskills\u002Fzero-trust-architecture-cheat-sheet\u002FSKILL.md",[],[],{"skillNo":53,"name":54,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":55,"categories":56,"keywords":57,"publishedAt":19},"01M79QQV7GHYR02DYGN41S23WN","xss-filter-evasion-cheat-sheet","https:\u002F\u002Fgithub.com\u002FJunMystery\u002FAgent-Guidance\u002Fblob\u002Fmain\u002Fskills\u002Fxss-filter-evasion-cheat-sheet\u002FSKILL.md",[],[],{"skillNo":59,"name":60,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":63,"publishedAt":19},"01M79QQNSN7YB8XB61FFSCS3WH","xs-leaks-cheat-sheet","https:\u002F\u002Fgithub.com\u002FJunMystery\u002FAgent-Guidance\u002Fblob\u002Fmain\u002Fskills\u002Fxs-leaks-cheat-sheet\u002FSKILL.md",[],[],{"skillNo":65,"name":66,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":19},"01M79QQHZZJKFDY9132G5A65C2","xpath-injection-prevention-cheat-sheet","https:\u002F\u002Fgithub.com\u002FJunMystery\u002FAgent-Guidance\u002Fblob\u002Fmain\u002Fskills\u002Fxpath-injection-prevention-cheat-sheet\u002FSKILL.md",[],[],{"skillNo":71,"name":72,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":19},"01M79QQB9ZSD3DJG8658EHQXR1","xml-security-cheat-sheet","https:\u002F\u002Fgithub.com\u002FJunMystery\u002FAgent-Guidance\u002Fblob\u002Fmain\u002Fskills\u002Fxml-security-cheat-sheet\u002FSKILL.md",[],[],{"skillNo":77,"name":78,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M79QQ60WKV7PFMXWT9CW8PM6","xml-external-entity-prevention-cheat-sheet","https:\u002F\u002Fgithub.com\u002FJunMystery\u002FAgent-Guidance\u002Fblob\u002Fmain\u002Fskills\u002Fxml-external-entity-prevention-cheat-sheet\u002FSKILL.md",[],[]]