---
name: forge-research
description: Research methodology for agents and humans alike. Question decomposition, source hierarchy (primary > secondary > tertiary), search-vs-ask, synthesis with explicit confidence levels, anti-hallucination defenses, adversarial searches for consequential conclusions. Contains the full output template (claims with confidence + sources + open questions). Use when an agent (or you) is doing investigation work that informs a decision.
license: MIT
---

# forge-research

You are doing research that will inform a decision. Default agent-written research is "google the topic, read the first three blue links, summarize the consensus." That confuses retrieval with research and produces confident-sounding answers built on shaky sources. This skill exists to do investigation that actually holds up.

The mental model: **research is a sequence of questions. Each question narrows uncertainty. The output is not "facts" - it is reduced uncertainty, named sources, and stated confidence per claim.**

## Quick reference (the things you must never ship)

1. A research output without sources cited.
2. "Studies show..." or "experts say..." with no named source.
3. A guess presented in confident prose.
4. Citing a URL you have not actually visited.
5. Quoting text you have not verified appears in the source.
6. Round-numbered statistics ("20% improvement") without a benchmark citation.
7. AI-generated content cited as primary.
8. A consequential conclusion with no counter-search performed.
9. Output that flattens disputed claims into consensus.
10. A research output that does not name what is NOT known.

## Hard rules

### Start with the question

**1. State the question in one sentence before searching.** "What is the right way to do X?" is too broad. "What are the trade-offs between cursor-based and offset-based pagination at >1M rows in Postgres 17?" is researchable.

**2. If the question has multiple parts, decompose.** Each part becomes its own search.

**3. Distinguish "I want a fact" from "I want a judgment."**
- Facts (population of Almaty, Postgres 17 release date): have sources.
- Judgments (best framework for this app): advisory and contextual; do not present as fact.

### Source hierarchy

**4. Primary > secondary > tertiary.**

| Tier | Examples |
| --- | --- |
| Primary | Official docs, the actual specification, the codebase, the person who built it |
| Secondary | Thoughtful blog posts by domain experts, peer-reviewed papers, conference talks |
| Tertiary | Stack Overflow consensus, Medium/dev.to articles, AI-summarized content |

**5. When sources disagree, prefer primary.** Two blog posts contradict the docs - docs win. Two blog posts contradict each other - closer-to-primary wins, or both get cited and the question becomes "why do they disagree?"

**6. Source recency matters more in fast-moving domains.** A 2022 blog about Next.js may be wrong about Next 16. A 2010 paper about a stable math algorithm is fine.

**7. Be cautious with AI-generated content.** A summarized blog about a topic, summarized by another AI, then summarized by you - error compounds.

### When to search vs when to ask

**8. Search when the answer is public and someone has written it down.** Documentation, GitHub issues, papers, blog posts.

**9. Ask (the user, a colleague, an expert) when the answer is private or contextual.** "What is our team's convention?" "Why did we choose X?" - not on the internet.

**10. Read the codebase when the question is about the codebase.** Asking the LLM is sometimes faster than searching, but the source of truth is the code.

### Searching effectively

**11. Specific terms, not natural-language questions.** `Postgres 17 cursor pagination performance` beats `how should I do pagination?`

**12. Quote exact phrases when you know them.** `"json_table"` finds the specific feature.

**13. Use site filters when you know where the answer lives.** `site:postgresql.org`, `site:github.com`, `site:news.ycombinator.com`.

**14. Date-bound when the topic changes.** `Next.js app router 2026` for recent. `before:2024` for "what was the previous approach?"

**15. Iterate the query based on what you learned.** First search reveals vocabulary; second uses the right vocabulary; third digs deeper.

### Synthesis

**16. State claims with confidence levels.** "Established: X. Likely: Y. Disputed: Z." Mixing certain and uncertain claims as if equal is the most common research failure.

**17. Cite sources inline.** Every non-trivial claim has a link or reference.

**18. Name what is NOT known.** "I could not find a benchmark for this case" beats inventing one. Negative results are research output too.

**19. Quote sparingly. Paraphrase mostly.** Quotes have their own integrity; do not put words in mouths.

### Anti-hallucination defenses

**20. Verify cited sources exist.** AI agents sometimes hallucinate URLs and citations. Click through, or grep, or otherwise confirm.

**21. Verify quotes word-for-word.** A quoted phrase that does not appear in the source is fabricated.

**22. Cross-check surprising claims against a second source.** A single source = one data point.

**23. If you cannot verify, label it.** "[Source unclear, treat as inference]" beats inference-as-fact.

### Adversarial research

**24. For consequential decisions, actively seek disconfirming evidence.** Search "why X is bad" alongside "why X is good." Counter the confirmation-bias default.

**25. Identify who benefits from the claim.** A library's official docs naturally underplay its weaknesses.

**26. Surface incentives.** A blog post by a vendor recommending their own product is informative but biased. Cite, but note the bias.

### Output format

**27. Research output has: question, summary answer, claims with confidence, sources, open questions.** All five.

**28. Length proportional to stakes.** A trivial fact gets a sentence. A "should we adopt X?" decision gets a structured doc.

**29. Sources linked and dated.** "According to the Postgres 17 docs [link, accessed 2026-05-22]: ..."

## Common AI-output patterns to reject

| Pattern | Why wrong | Fix |
| --- | --- | --- |
| "Studies show..." no link | No source | Cite the study or remove the claim |
| `[link]` to a hallucinated URL | Looks plausible, isn't real | Visit before citing |
| "Experts agree..." no name | Vague appeal to authority | Name the expert; or call it consensus among X published works |
| Round stat ("20% faster") no method | Invented number | Benchmark cited; method stated |
| Citing ChatGPT/Claude output as fact | AI-laundered | Cite the original or label as inference |
| Confident prose on a disputed topic | Flattens conflict | Present the disagreement |
| One-search synthesis | Confirmation bias | Counter-search included |
| Quote with no context | Misattribution risk | Quote + source link + access date |
| No "what I do not know" section | False omniscience | Open questions named |
| Recommending tech without recency check | 2022 advice for 2026 stack | Date-bound the search |

## Output template

```markdown
## Question
{one-sentence question, decomposed if needed}

## Summary
{2-3 paragraphs synthesizing the answer}

## Established
- {claim} [source link, access date 2026-05-22]
- {claim} [source link, access date 2026-05-22]

## Likely (single-source or weakly corroborated)
- {claim} [source link, access date 2026-05-22]

## Disputed
- Source A says X [link]. Source B says Y [link]. The disagreement is about Z.

## Open questions
- I could not find {specific subquestion}. Worth a dedicated search if it matters.
- {another}

## Method
- 4 searches, 6 pages read, 2 counter-searches performed.
- Primary sources used: {N}. Secondary: {M}.
```

## Worked example: a researched answer

**Question:** Should we use cursor-based or offset-based pagination for an orders endpoint expecting 5M rows in Postgres 17?

**Summary**
Cursor-based pagination is the recommended approach. Offset gets slow at high page numbers (the database scans then discards) and produces incorrect results when rows are inserted during pagination. Postgres 17 has no specific feature that changes this trade-off; the underlying mechanics are the same as Postgres 11.

**Established**
- `OFFSET N` in Postgres requires the database to read+discard N rows before returning the LIMIT - this is O(N) per page. Documented in the Postgres 17 docs [link to postgresql.org/docs/17, accessed 2026-05-22].
- Cursor-based ("keyset") pagination uses a WHERE clause on an indexed column, so each page is O(log N) [Postgres official wiki "Pagination", accessed 2026-05-22].
- Inserts during paginated reads cause OFFSET to skip or duplicate rows; cursor-based does not [Stripe engineering blog "Designing robust APIs", 2023].

**Likely**
- At 5M rows, OFFSET 10000 LIMIT 50 will take ~250-500ms; cursor pagination will take <10ms with the right index. Numbers from the EXPLAIN-driven benchmarks Cybertec published [link, 2024-09]. Not verified on our hardware.

**Open questions**
- How does the comparison change with Postgres `cursor_tuple_fraction` setting? Cybertec post does not address this.
- What is the right cursor encoding (base64url JSON vs HMAC-signed token) for our threat model? Separate question.

**Method**
- 3 searches: `postgres 17 cursor pagination`, `keyset pagination benchmark large table`, `offset pagination problems concurrent insert`.
- 5 pages read. Primary: 2 (postgresql.org docs, Postgres wiki). Secondary: 3 (Stripe blog, Cybertec, Hacker News discussion).
- One counter-search: `cursor pagination disadvantages` - confirmed it is harder to "jump to page N" arbitrarily, which is a real limitation for some UI patterns.

## Workflow

1. **State the question.** Decompose if multi-part.
2. **Identify what kind of answer you need.** Fact, judgment, comparison, status check.
3. **List candidate sources.** Docs, primary research, expert blogs, codebases.
4. **Start with primary sources.** Fall back to secondary only when primary is missing.
5. **Iterate queries as you learn the vocabulary.**
6. **Synthesize.** Claims, confidence, sources, open questions.
7. **Surface what you could not learn.**

## Verification

Manual checklist:

- [ ] Output names the question explicitly.
- [ ] Each claim has confidence + source.
- [ ] Sources linked, with access date on live web sources.
- [ ] Disputed claims flagged.
- [ ] At least one counter-search performed for consequential conclusions.
- [ ] Cited URLs were actually visited.
- [ ] Open questions section present.

## When to skip this skill

- Trivial factoid lookups - just search, no methodology needed.
- Reading source code to understand behavior - codebase-exploration territory.
- Tasks where the user has already done the research and is asking you to apply it.

## Related skills

- [`forge-web-search`](../forge-web-search/SKILL.md) - the search hygiene.
- [`forge-citation`](../forge-citation/SKILL.md) - the citation discipline.
- [`forge-rag`](../../llm/forge-rag/SKILL.md) - when research is over a private corpus.