Source-First Research¶

Load this before generating or editing skill content about a library, protocol, product, or format.

Skill pages are published as both MCP resources and human-readable HTML. Claims need labeled links to official documentation, with source code as the fallback when the docs do not settle the mechanic.

Research Order¶

1. Official documentation for the feature, API, or format under edit. Prefer the current stable docs for the version the skill targets.
2. Source code only when documentation is missing, internally contradictory, version-gated, or too thin to explain the mechanic.
3. Do not fill gaps from model memory, unofficial blogs, or issue comments unless those are the project's designated source of truth.

A skill that restates training knowledge without citations is not a technical reference.

What Counts As Official Documentation¶

Treat these as first-class when they are published by the project or standards body:

• Product documentation sites and API references
• Language or protocol specifications (PEPs, RFCs, OpenAPI, Agent Skills, MCP)
• Man pages and CLI --help that the project documents as canonical
• Versioned llms.txt or docs indexes published by the project

Do not treat as official unless the project points to them:

• Third-party tutorials and comparison posts
• Unreviewed GitHub discussions
• Copied snippets from other skills in this repository (those may be stale)

Locating Documentation¶

Work from the project's own indexes before searching the web at large.

Record the page you used. Later skill edits should be able to re-open the same URL.

When To Read Source¶

Open source after the official page is located, and only for the unresolved mechanic:

• Behavior the docs describe as undefined, experimental, or "see implementation"
• Deprecation or replacement not yet reflected on the landing page
• Exact default values, error types, or CLI flags missing from the reference
• Provider or plugin wiring that the docs summarize but do not specify

Prefer a tagged release that matches the skill's version floor over an unreleased default branch.

Read the implementation of the documented symbol, not an adjacent example app, unless the project documents that example as canonical.

Locating Source¶

Cite a permalink (tag or commit) when the line number matters. Default-branch links rot.

Citation On The Page¶

This repository renders the same Markdown as HTML and as MCP resources. Link quality is part of the research contract. Follow the same rules as Zensical documentation authoring:

• Never leave a bare URL in prose or list items.
• Use in-place Markdown links with meaningful labels.
• Group related official links in an info admonition so the HTML page remains scannable.
• If a claim is supported only by source, say so next to the link.

!!! info "Primary sources"
    - [FastAPI lifespan events](https://fastapi.tiangolo.com/advanced/events/)
    - [Starlette lifespan](https://www.starlette.io/lifespan/)

When the docs are insufficient, add a second group for source:

!!! note "Implementation fallback"
    - [`FastAPI.router.lifespan_context` in FastAPI](https://github.com/fastapi/fastapi/blob/master/fastapi/applications.py)

Completeness¶

A research pass is complete when:

1. The official page for the feature is identified (or documented as absent).
2. Any source fallback names the file or symbol that settles the mechanic.
3. The skill page being edited links those sources; it does not paraphrase them without a path back.
4. Version constraints that change the advice are stated next to the claim.

If neither docs nor source can be located, do not invent the mechanic. Leave the gap explicit.

Common Documentation And Source Roots¶

Use these as starting indexes for domains this library already covers. They are entry points, not a substitute for the feature-level page.