research · diff
git:20260630.95d2bc8 to git:20261007.131213e
46 added, 47 removed. Audit A to A.
---
name: research
description: >-
- Fetches source-grounded, current docs for library/framework/API
- implementation. Use when the user needs API syntax, config options,
- examples, migration notes, or version-sensitive guidance. Do not invoke for
- stable concepts or broad explanations that can be answered from memory.
+ Current, source-grounded implementation research for libraries, frameworks,
+ SDKs, and APIs. Use when coding depends on version-specific syntax, configuration,
+ behavior, examples, release changes, or migration guidance, or when the user asks
+ to verify documentation. Answer stable conceptual questions directly.
---
# Research
- Source-grounded docs research for implementation details that may be stale in
- training data.
+ Resolve implementation questions with evidence that matches the project's actual version and
+ runtime.
- ## Strategy (priority order)
+ ## Process
- Try these in order and stop at the first source that is authoritative, current
- enough for the requested version, and contains the API/config detail needed to
- answer.
+ ### 1. Frame the claims
- **1. Context7 MCP** — best for library/framework/SDK documentation
- ```
- mcp__context7__resolve-library-id → mcp__context7__query-docs
- ```
- Prefer this for npm packages, Python libraries, and popular frameworks.
+ Turn the request into the smallest set of facts needed to proceed. Identify the target library or
+ API, runtime, installed or requested version, and required artifact: direct answer, code example,
+ migration guidance, or repository Markdown file.
- **2. GitHub CLI** — for repos not indexed by Context7
- ```bash
- gh repo view <owner>/<repo> --json description,readme
- gh api repos/<owner>/<repo>/contents/docs
- ```
+ Completion: every material question is explicit, and the target version and artifact are known or
+ recorded as unresolved.
- **3. WebFetch → WebSearch** — for everything else
- - WebFetch a specific URL if you have it
- - WebSearch when you need to find the right page first
+ ### 2. Establish local version evidence
- If a tool is unavailable, skip to the next available source and say which source
- could not be checked.
+ Inspect manifests, lockfiles, configuration, imports, installed declarations, and nearby code
+ before researching external material. Treat the installed package and types as the compatibility
+ boundary. Ask for a version only when the repository and request do not determine one.
- ## Completion Gate
+ Completion: the implementation environment and exact version are known, or the answer is explicitly
+ scoped to a named latest/stable version.
- Stop only when:
+ ### 3. Gather primary evidence
- - the source is authoritative for the library/framework/API
- - the source is current enough for the requested version
- - the source contains the API syntax, config option, migration note, or example
- needed to answer
- - unavailable tools or missing version information are disclosed
+ Use available documentation and web tools. Prefer sources in this order:
- ## Output Format
+ 1. versioned official documentation, specifications, and API references;
+ 2. maintainer repositories, release notes, migration guides, source, types, and tests;
+ 3. trusted secondary sources for explanation or examples that primary sources do not provide.
- Deliver actionable implementation guidance — not a raw docs dump.
+ A documentation index or search result may locate a source; verify the claim on the source page.
+ Fetch a known page directly before broad search. Continue until every material claim is supported,
+ rather than stopping after the first page that mentions the topic.
- **Key patterns** — show working code examples for the most common use cases
+ Completion: every material claim has a source authoritative and current enough for the target
+ version; conflicting sources are reconciled; unsupported points are labeled as uncertainty.
- **Common pitfalls** — what trips people up, especially on first use
+ ### 4. Synthesize the artifact
- **Version notes** — call out anything version-specific, especially for fast-moving ecosystems (Next.js App Router vs Pages, React 19 changes, Python 3.12+ features)
+ Return the smallest actionable result for the requested branch:
- **Authoritative sources** — link to the official docs page you drew from so the user can verify
+ - **Implementation:** version-matched syntax or configuration, a focused example, and relevant
+ pitfalls.
+ - **Migration:** current and target versions, breaking changes, ordered steps, and verification.
+ - **Fact lookup:** the direct answer, its version boundary, and supporting source.
+ - **Repository note:** a self-contained Markdown file at the agreed path with the same evidence.
- ## When to Search vs When to Answer From Memory
+ Separate documented facts from inference. Cite primary sources beside the claims they support and
+ include exact commands or code only when the evidence establishes them.
- Search when:
- - The user is actively writing code that uses a library
- - The question involves specific API syntax, config options, or method signatures
- - The library had major changes in the past 12 months (anything in the JS/Python ecosystem)
+ Completion: the requested artifact exists, examples match the target version, every material claim
+ is traceable to a source, and remaining gaps are explicit.
- Answer from memory when:
- - The question is about a fundamental concept (e.g., "what is a closure")
- - The user is asking for a high-level explanation, not implementation details
- - The library is very stable and the question is about basic usage (e.g., standard library functions)
+ ## Source Discipline
+
+ - Record the relevant version, release, or publication date when a source can drift.
+ - Prefer installed declarations over live latest-version docs for project compatibility.
+ - Use secondary sources to clarify, not to override primary documentation.
+ - Cite the destination page rather than search-result snippets or unsourced summaries.