Turn vague research needs into one precise deep-research prompt with context and output criteria.
SkillScore82Maintained
Automatic
◆Research pack
Last verified 8/11/2026
What it changes
Passed 18 of 22 test cases with the skill, and 3 of 22 without it.
Without skill14%
With skill82%
Checks it passed that the model alone missed
The instruction outlines sub-queries using parenthetical inline numbering.
The prompt sets explicit constraints on what to include and what to avoid.
The prompt states that community forums or social media act as weak signal only.
and 33 more in the full report
15 fixed3 passed either way4 still failing0 broke
Pass-rate lift
+68 pp
Tokens
+178%
Agent turns
0%
Response time
+63%
Model gemini-3.6-flashMeasured 8/11/2026v118 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 15 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 15
Prompt
We are trying to reduce Kubernetes cluster costs by introducing Karpenter or KEDA. Create a single-paragraph research instruction for an automated researcher tool.
What was checked, without and with the skill
Checked
Without skill
With skill
The instruction outlines sub-queries using parenthetical inline numbering.
Missed
Passed
The instruction demands output in a single detailed markdown file in its concluding sentence.
Missed
Passed
case-10 · gemini-3.6-flash · 8/11/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md47 linessingle file
Research Prompt
When to Use
Use when the user wants a deep-research brief or researcher prompt.
Use when a vague research question needs to become one precise self-contained paragraph.
Goal: turn a vague research need into ONE self-contained paragraph that a researcher with zero prior knowledge of the project can act on with zero back-and-forth.
Rules
One paragraph. No headers, no bullet list in the deliverable.
Prompt the job, not the topic. Give search handles (timeframe, ranking, source type, decision logic) — not just a subject.
Assume zero prior knowledge. Write for a researcher who has never heard of the project. Open by explaining, in plain English, what the project/product is, why it exists, and the current situation — so they understand what's going on, what we need, and why we need it.
Lead with the goal + decision. Right after that explainer, state the single question the research must answer and the decision/use it informs.
Embed all context. Names, dates, product, prior known facts, constraints. The researcher must not need to ask anything or guess.
Number the sub-questions inline (1, 2, 3…) so coverage is explicit. Keep to 3–6. One mission per prompt — don't cram unrelated questions.
State constraints. What to include, what to avoid (e.g. "only non-Chinese competitors", "no marketing fluff").
Source hierarchy. Prefer primary sources (official docs, GitHub, papers, filings, changelogs); forums/X/Reddit are weak signal only, never factual proof.
Contradiction handling. If sources conflict, separate confirmed facts / inference / unresolved uncertainty — don't force fake consensus. Flag low-confidence claims for verification.
Completion bar (define "done"). Don't stop at the first plausible answer. Corroborate each key claim with multiple independent primary sources where they exist; where sources are scarce, say so explicitly instead of padding. Keep going until every numbered sub-question is covered to this bar.
Gap round before finishing. Require a final self-critique pass: list gaps, contradictions, and any single-source claims, then run another round of searches to close them — repeat until clean.
Constrain output hard, method loosely. Be strict on the deliverable; leave the search path flexible so the researcher can explore.
Demand a fixed output per finding: source link + specific claim + one-line "why it matters / why a viewer should care".
Verifiable, citable facts only. No opinions.
Last sentence: instruct them to output everything into a single detailed markdown file.
Process
Pull context from the relevant project files / conversation (dates, names, known facts, audience, end use), and write a 1–2 sentence plain-English explainer of what the project is and why it exists for a reader who knows nothing.
Identify the ONE question the research answers.
Draft 3–6 numbered sub-questions that fully cover it.
Add include/avoid constraints + the per-finding output format.
Compress to one clean paragraph. Cut filler.
Template
[For a reader with zero prior knowledge: in 1–2 plain-English sentences, what the project/product is, why it exists, and the current situation.] Research [TOPIC + key identifying facts] to answer one question: [THE QUESTION] — for [DECISION / END USE]. Find: (1) …; (2) …; (3) …; (4) …. [Constraints: include X, avoid Y.] Prefer primary sources; treat forums/social as weak signal only; if sources conflict, separate fact from inference and flag what needs verification. Don't stop at the first plausible answer: corroborate each key claim with multiple independent primary sources where they exist (and say so explicitly where they don't), continuing until every numbered question is covered to that bar. Before finishing, do a self-critique pass — list gaps, contradictions, and any single-source claims, then run another round of searches to close them, repeating until clean. For each point, give the source link, the specific claim, and a one-line "why it matters". No marketing fluff — verifiable, citable facts only. Output everything into a single detailed markdown file.
Review a git diff or explicit file scope for reuse, code quality, efficiency, clarity, and standards issues, then optionally apply safe Codex-driven fixes. Use when the user asks to "simplify code", "review changed code", "check for code reuse", "review code quality", "review...