Generated pages
This injects one page per module into the site’s routes. Each page gets a sidebar tree and prev/next links that mirror the package layout.
starlightPydocs({ packages: [{ name: 'mypkg', search: ['../src'] }],});This generates one page per module at /api/mypkg/, a sidebar tree that mirrors the
package layout, and symbols.json, objects.inv and llms.txt.
Generated pages
This injects one page per module into the site’s routes. Each page gets a sidebar tree and prev/next links that mirror the package layout.
Autodoc component
<Autodoc name="mypkg.Report" /> renders a single class or function into a
hand-written MDX page.
Symbol search
Search the API surface by object path. This works alongside the site’s existing prose search.
Docstring sections
Google, numpy or sphinx style: parameters, returns, raises, examples, admonitions and deprecations. Your site’s own Markdown pipeline renders them.
No Python at build time
Point the plugin at a dump your CI published and the site builds without an interpreter.
Linked signatures
Names in an annotation link to their definition. The link points to your own pages, or, through a Sphinx inventory, to another project’s documentation.
Inherited members
Merged from resolvable base classes and labelled with the class they came from.
Inventory and llms.txt
objects.inv and llms.txt per package, so other documentation sites and language
models can consume yours.
starlight-pydocs is the Starlight counterpart of
mkdocstrings-python. It keeps mkdocstrings’
conventions where they make sense. Heading anchors are dotted object paths. __all__
selects the documented surface. ::: name becomes <Autodoc name="…" />.
Read the migration guide
These docs are published as plain Markdown alongside the HTML.
/llms.txt indexes the site.
/llms-full.txt contains every guide in one file.
Each documented package publishes its own API surface the same way, for example
/api/demopkg/llms.txt. Point an agent at
these files instead of asking it to crawl the rendered pages.