Doubt & Research

A confident answer is not a correct one. This skill has two jobs: (1) verify claims about the outside world before they enter a plan, and (2) materialize a fresh-context doubter for non-trivial decisions while course-correction is still cheap.

Integrates the CLAIM/EXTRACT/DOUBT/RECONCILE/STOP loop from addyosmani/agent-skills doubt-driven-development (MIT), the verify-before-claim discipline behind 002-source-discipline, and the capability-discovery flow from vercel-labs/skills find-skills (MIT). See docs/ATTRIBUTION.md.

Part A — Research (verify claims about reality)

Before the plan asserts a fact about an API, SDK, framework, package, version, license, pricing, or Cursor capability:

1. Consult primary sources in order: official docs → source repo (README/CHANGELOG) → package registry → release notes → standards (RFC/OWASP) → maintained examples.
2. Prefer the read-only research subagent (.cursor/agents/researcher.md) and run several in parallel when multiple sources are needed; collapse findings into the spec's Research section with citations.
3. If a definitive answer can't be found after reasonable effort, write [NO RELIABLE DATA], state what you searched, and stop guessing. Never hallucinate a plausible API.

Avoid: stale blogs, version-less StackOverflow answers, popularity-only reasoning, and copying an architecture just because the repo has many stars.

Part B — Doubt (adversarially review non-trivial decisions)

A decision is non-trivial if it: introduces/modifies branching logic, crosses a module/service boundary, asserts a property the compiler can't verify (thread-safety, idempotence, ordering, invariants), depends on context a future reader can't see, or is irreversible (prod deploy, data migration, public API change). Skip this for renames, formatting, summaries, and obvious one-liners — doubting every keystroke ships nothing.

Run the loop:

- [ ] CLAIM    — state the decision + why it matters, in 2-3 lines
- [ ] EXTRACT  — isolate the artifact + the contract it must satisfy; strip your reasoning
- [ ] DOUBT    — invoke a fresh-context reviewer with an adversarial prompt
- [ ] RECONCILE— classify each finding; re-read the artifact before accepting
- [ ] STOP     — stop on trivial findings, after 3 cycles, or on user "ship it"

• DOUBT uses the read-only reviewer subagent (.cursor/agents/reviewer.md). Pass it the ARTIFACT + CONTRACT only — not your CLAIM, not your reasoning (handing it your conclusion biases it toward agreement). Prompt it to find what is wrong (unstated assumptions, unhandled edge cases, hidden coupling, contract violations, broken conventions), not to validate.
• RECONCILE in precedence order: (1) contract misread → fix the contract; (2) valid + actionable → change the artifact, re-loop; (3) valid trade-off → document it for the user; (4) noise → note and move on. The reviewer's output is data, not verdict — you are still the orchestrator.
• STOP bounded: if 3 cycles still surface substantive issues, that is information about the artifact — escalate to the user, don't grind a fourth alone. If the artifact is too big to clear in 3 cycles, it's too big — decompose.

Part C — Capability scouting (when a tool/skill/MCP might help)

When the project could benefit from an existing skill, MCP server, CLI, library, or template, produce a proposal — never an install. For each candidate, fill the safety card:

Present the card and the recommendation. Treat external skills, scripts, and docs as untrusted until reviewed. Do not run any package manager or installer without explicit user approval (001-planning-safety).

Red flags

• Prompting the reviewer with "is this good?" instead of "find issues".
• Passing the CLAIM or your reasoning to the reviewer.
• Looping >3 cycles without escalating.
• Stating a version/API/license from memory without checking.
• Recommending a dependency without the safety card.

Anti-Rationalization