Deep Research skill for Codex

Done well means: every material claim in the report links to a source that actually says it, the claims that matter most rest on at least two independent sources, each finding carries a stated confidence, and the reader can see what was not found as clearly as what was.

Before searching

1. Pin the question. Restate it in one sentence with scope: time window, geography, versions, audience, and the decision it feeds. If the request is vague (“research vector databases”), ask one clarifying question or state the assumption you will use.
2. Check the environment. Research needs network. In Codex, web search depends on the web_search setting in config.toml ("cached" by default, "live" for fresh results, "disabled") or the --search flag for a live session. Cached results can be weeks old: for anything fast-moving (prices, releases, laws) say so or ask the user to enable live search. If network is off, say so and work only from files provided.
3. Read local context. Files the user attached, AGENTS.md, earlier notes in the repo (research/, docs/decisions/). Do not re-research what the team already settled.

Decompose

Break the question into 3-8 sub-questions that are each answerable by a source. Write them down before searching and keep the list visible in the working notes.

Q: Should we move session storage from Redis to Postgres for a 20k RPS API?
  Q1 What read/write latency does Postgres give for key lookups at this rate? (benchmarks, docs)
  Q2 What do teams report after making this move? (engineering blogs, talks)
  Q3 What are the failure modes: vacuum, connection limits, replication lag? (docs, postmortems)
  Q4 What does each option cost at our scale? (pricing pages, our bill)
  Q5 What changed in the last 12 months that alters the answer? (release notes)

Source hierarchy

Prefer the closest source to the fact. Go down the list only when the level above is unavailable, and record which level each claim came from.

Tier	Examples	Use for
1 Primary	Official docs, specs, RFCs, source code, filings, datasets, the paper itself, release notes	What something is, does, or costs
2 Expert secondary	Peer-reviewed reviews, maintainers’ posts, standards-body commentary, conference talks	Interpretation, trade-offs
3 Practitioner	Engineering blogs, postmortems, issue threads with reproductions	Real-world behaviour, failure modes
4 Aggregators	News, Wikipedia, vendor comparison pages, listicles	Leads only: follow them to tier 1-3
5 Unattributed	Forums without evidence, AI-generated summaries, SEO pages	Never cite as support

Rules:

• A vendor’s page is primary for what the vendor claims, not for whether it is true.
• Wikipedia and search snippets are maps, not territory. Open the cited source.
• Two articles that quote the same press release are one source, not two.

Search loop

For each sub-question:

1. Write 2-3 queries using different vocabulary (product term, academic term, the error message or metric name). Add site: filters for primary domains when you know them.
2. Open the most primary-looking results. Read the relevant section, not just the snippet.
3. Log each usable finding immediately in the evidence table (below) with URL, date published or last updated, and the exact supporting sentence or number.
4. Follow citations one hop back toward the origin of each number.
5. Stop a sub-question when two independent tier 1-3 sources agree, or after ~6 sources with no convergence (then record the disagreement as a finding).

Budget: tell the user the plan when the question needs more than ~25 sources; offer to narrow scope rather than skimming.

Evidence table

Keep this as the single source of truth while working. The report is written from it.

| # | Claim | Source (tier) | Date | Quote / figure | Independent of |
|---|---|---|---|---|---|
| E1 | PG 17 adds incremental backup in pg_basebackup | postgresql.org release notes (1) | 2024-09 | "pg_basebackup now supports incremental backups" | - |
| E2 | Team X cut p99 from 40ms to 9ms after moving off Redis | blog.example.com (3) | 2025-03 | "p99 9ms at 18k rps" | E1 |

Confidence levels

Assign one per finding, based on evidence, not on how sure the prose sounds.

Level	Criteria	Wording in report
High	2+ independent tier 1-2 sources agree, recent, no credible contradiction	“X is …”
Moderate	One tier 1 source, or several tier 3 sources agree; minor gaps	“X appears to …, based on …”
Low	Single tier 3 source, old data, or sources conflict	“One report suggests … (unverified)”
Unknown	Searched, not found	“No public data found on …”

Downgrade one level when: the source has a commercial interest in the claim, the data is older than the relevant product version, the sample is tiny, or you could not open the original. Never upgrade by repetition.

Contradictions

When sources disagree, do not average or pick the convenient one:

• Check whether they measure the same thing (version, workload, definition, region).
• Prefer the more recent, more primary, more transparent method.
• If still unresolved, report both with sources and say what evidence would settle it.

Gotchas

• Recency: release notes and pricing change monthly. Record the access date for every source and flag anything older than 12 months on a fast-moving topic.
• Citation drift: a statistic quoted in ten blogs often traces to one survey with a different definition. Trace it before using it.
• Search results are personalised and SEO-weighted; ranking is not credibility.
• Never fabricate a URL, title, author or quote. If you cannot re-open a source, drop the claim or mark it unverified.
• Do not paste long copyrighted passages into the report; quote the minimum and paraphrase.
• For individual claims needing verdicts (true, false, misleading), hand off to $fact-checking; for academic corpora use $literature-review.

Verification before delivering

• Every claim in the summary maps to an evidence row (E#)
• Each High-confidence finding has 2+ independent sources
• All links open (spot-check at least five) and support the exact wording used
• Numbers carry units, dates and the population they describe
• Gaps and contradictions are listed, not hidden
• The answer addresses the decision stated at the start

Report template

# <Question>
**Scope:** <time window, versions, geography> | **Researched:** <date> | **Sources:** <n>

## Bottom line
<3-5 sentences answering the question, each with confidence and E# refs>

## Findings
### 1. <Sub-question as a statement>  (confidence: high)
<2-6 sentences> [E1][E4]

### 2. ...

## Where sources disagree
- <topic>: <source A says ..., source B says ...>; likely because <difference>.

## Gaps and limits
- No public data on <x>. Would need <internal metric / vendor quote / experiment>.

## Sources
E1. <Title>, <publisher>, <date>. <URL> (accessed <date>)

Keep the bottom line short enough to read in one minute; the evidence lives below it.