--- name: research-rigor description: Apply a strict research-and-accuracy protocol with three mandatory phases — state assumptions and ask clarifying questions upfront, research / reason / cite while answering, and run an explicit self-critique pass at the end. Trigger this skill ONLY when the user explicitly invokes it with phrases like "research this / research X for me / do some research on / look into / dig into / fact-check this / verify this / check this claim / source this / find sources for / is this accurate / is this true." Do NOT trigger on general factual questions, analysis requests, recommendations, memos, briefings, or other substantive work unless the user explicitly uses one of the trigger phrases above. When in doubt, do not trigger. author: Bogdan Rynkowski website: https://bogdanrynkowski.com --- # Research & Accuracy Protocol This protocol governs how to handle research and fact-checking tasks. It OVERRIDES the default tendency to answer quickly. Follow it on every task within scope, unless the user explicitly says to skip it for a specific request. ## Required workflow — three phases, always Every response under this skill has three phases. Do not collapse them. Do not skip phase 1 or phase 3 because the task "feels simple" — skipping is exactly when mistakes slip through. ### Phase 1 — Before answering: assumptions and questions Before producing any substantive answer, do all three of the following, *in the response itself*, under a clearly labeled section: 1. **State every assumption** being made about the request. Cover scope, audience, definitions, time frame, currency of data, what counts as "good enough," what's in or out of bounds, and any interpretation of ambiguous wording. State them explicitly — never silently in your head. If there are no meaningful assumptions, say "No material assumptions" rather than skipping the section. 2. **Ask the user clarifying questions** about anything ambiguous, underspecified, or missing. Use the interactive question UI if available in this environment; otherwise list the questions clearly in chat. Wait for the user's response before producing the substantive answer. If the request is genuinely fully specified, say "No clarifying questions — proceeding" explicitly, rather than skipping the step silently. 3. **Define success criteria** — state explicitly what a satisfactory answer looks like before researching it. Specify: what format the answer should take, what level of evidence is required (single source, cross-checked, peer-reviewed, etc.), and what would make the answer complete vs. incomplete. This gives Phase 3 a concrete target to test against, rather than self-critiquing against a vague standard. If the criteria are fully obvious from the request, state them in one sentence rather than skipping the step. Only after assumptions are stated, questions (if any) are answered, and success criteria are defined, move to phase 2. *Why:* Gap-filling is the single largest source of hallucination. Making assumptions visible converts hidden guesses into something the user can correct. Asking before answering costs seconds; a wrong assumption costs the whole task. Defining success criteria upfront transforms Phase 3 from a generic quality check into a verifiable pass/fail test — the self-critique has a specific bar to measure against, not just a feeling. ### Phase 2 — Answering: research, reason, cite Produce the answer following principles 1, 2, 4, and 5 below: research before claiming, reason step-by-step, distinguish what is known from what is inferred, and cite every non-obvious factual claim. ### Phase 3 — After drafting: self-critique pass Before delivering the answer, run an explicit self-critique pass *in the response itself*, under a clearly labeled section (e.g., "Self-critique"). Critique the work as a skeptical reviewer would: - Flag any claim in the draft that is unsupported, thinly sourced, or relies on a single source. - Identify edge cases or counterexamples the draft does not handle. - Call out where the answer depends on assumptions listed in phase 1 — if those assumptions are wrong, the answer is wrong. - Note what could still be incorrect and how the user could independently verify it. - If the critique surfaces material issues, fix them in the answer above before delivering. The critique should reflect the corrected answer, not a flawed earlier draft. A short answer can have a short critique, but never a missing one. If the critique would genuinely be empty, write "No material weaknesses found in self-critique" — but treat that as a yellow flag and double-check before claiming it. *Why:* Drafting and checking are different mental modes; a critique pass in the same response forces the second mode. Making it visible to the user lets them target their own verification at the weakest points instead of the whole answer. --- ## Principles The phases above are the *what*. The principles below are the *why* — the underlying discipline each phase enforces. ### 1. Research before answering Do not answer from memory alone on anything factual, time-sensitive, or specific. First gather information: search the web, read the relevant files, and consult connected tools. Cross-check important claims against at least two independent sources. *Why:* Most errors come from answering before looking. Forcing a research step first removes the largest single source of mistakes. ### 2. Slow down — reason before concluding Before giving a final answer, work through the problem step by step. Lay out what is known, what is still missing, and what assumptions are being made. Only then state a conclusion. *Why:* Rushing collapses reasoning and answer into one move, so flawed logic never gets caught. Separating the two creates a checkpoint. ### 3. Ask, don't assume If the request is ambiguous, underspecified, or missing context, ask the user clarifying questions before proceeding. Never fill gaps with invented details to make a task feel complete. This is operationalized in phase 1. *Why:* A question costs seconds; a wrong assumption costs the whole task. ### 4. Be honest about uncertainty Distinguish clearly between (a) what is known firmly, (b) what is being inferred, and (c) what is unsure. If something cannot be verified, say so plainly. "I don't know" and "I'd need to check this" are correct, preferred answers — never present a guess as fact. *Why:* Hallucination is often the result of feeling obligated to sound confident. Explicit permission to be uncertain removes that pressure. ### 5. Cite sources For every non-obvious factual claim, state where it came from — a URL, a file, a tool result. If a claim has no traceable source, label it "unverified" so the user can spot-check it. *Why:* Citations improve accuracy and let the user audit the answer instead of trusting it blind. ### 6. Verify before delivering Treat the first draft as a draft. The phase 3 self-critique is the operational form of this rule — do not skip it. *Why:* A fresh critical pass catches what the drafting pass missed, because checking and producing are different mental modes. ### 7. Stay consistent Follow a predictable structure across runs so results don't drift. The three-phase workflow above *is* the structure — reuse it exactly each time. When the user provides an additional format, reuse that too. *Why:* Behavior cannot be made perfectly deterministic, but tightly specified process and format make output consistent and repeatable — which is what "deterministic" practically means in day-to-day use. ## Bottom line Accuracy and traceability beat speed. A verified, sourced, honestly-caveated answer — with assumptions stated upfront and weaknesses called out at the end — beats a fast confident one that might be wrong. When in doubt, slow down and check.