Agent setup prompts
leadtype init scaffolds the common case — a greenfield app with a local
docs/ folder. But docs often live elsewhere: another repository pulled in
via collections, an existing site with its
own structure, or a Fumadocs app. For those, hand a coding agent one of the
prompts below. The agent reads your actual layout and wires Leadtype to fit,
instead of dropping in a fixed file tree.
When to use which:
- Local docs, fresh app → run
leadtype init --framework <fw>. Fastest, no agent needed. - Local docs, existing app with custom structure → the Wire into an app prompt.
- Docs in another repo / multi-repo → the External docs prompt (
initdoes not fit — it scaffolds a local folder). - Shipping docs inside an npm package → the Bundle for a package prompt.
Wire Leadtype into an app
You are integrating Leadtype into this app so one MDX source renders for humans and is also exposed to agents (llms.txt, markdown mirrors, search, JSON-LD).
Inspect first:
- The framework (check
package.json): Next, Astro, Nuxt, SvelteKit, TanStack Start, or a Fumadocs app. - Where docs MDX lives, or where it should live.
- Whether a
docs.config.tsorleadtype.config.tsalready exists.
Implement:
- Create
docs/docs.config.tswithdefineDocsConfig({ product, navigation }). Put realproduct.taglineandllms.sections(an## Overviewmarkdown block and aBest Starting Pointslinks block) sollms.txtis useful. Usenavigationfor structure, not frontmattergroup. - Create a source loader that calls
createDocsSource({ contentDir, nav: docsConfig.navigation, baseUrl })fromleadtype. - Add the docs route and a markdown route using the matching adapter:
leadtype/next,leadtype/astro,leadtype/nuxt, orleadtype/sveltekit. The markdown route handlesAccept: text/markdown, AI user-agents, and.mdURLs via the generatedagent-readability.jsonmanifest (load it withnormalizeAgentReadabilityManifest). - Render JSON-LD in the docs page head with
createDocsJsonLdfromleadtype/llm/readability. - Add a
docs:generatescript:leadtype generate --src . --out <public-or-static> --base-url <url>. Usepublic/for Next/Astro/Nuxt,static/for SvelteKit. Run it inprebuild/predevso the manifest always exists.
Match the patterns in the Use the source primitive recipe for this framework. Do not invent leadtype exports — use only documented ones.
Validation:
- Run
docs:generate, then start the app. curl http://localhost:<port>/llms.txtlists.mdURLs that resolve.curl -H "Accept: text/markdown" http://localhost:<port>/docs/<page>returnsContent-Type: text/markdown.- The docs HTML head contains one
application/ld+jsonscript.
External / multi-repo docs
You are setting up Leadtype in a docs UI repository whose content is authored in a different repository. Do not scaffold a local
docs/folder and do not runleadtype init— the source is remote.Inspect first:
- The docs source repository URL and the ref (branch, tag, or commit) it should pin to.
- Whether multiple content areas exist (e.g.
docsandchangelog). - The UI framework in this repo.
Implement:
- Create
leadtype.config.tsat the repo root usingdefineDocsConfigwith acollectionsmap. Each collection usesdefineCollection({ repository, ref, cacheDir, dir, prefix }). Pinrefto a reviewed revision; share onecacheDirclone across collections of the same repo. - Give each collection its own
navigation(andschemaif the source uses custom frontmatter). - Add a generate script that syncs the remote source first:
leadtype generate --src . --out <public-or-static> --base-url <url> --sync. Use--refreshto fast-forward the pinned cache and--offlineto prove the cache is sufficient (air-gapped CI). - Wire the docs route, markdown route, and JSON-LD exactly as for local docs — the runtime side is identical once artifacts exist.
Reference Collections and Sync docs across repositories for the config fields and the cross-repo pin-update workflow.
Validation:
- First run clones the source into
cacheDir(gitignore it). leadtype generate --offlinesucceeds against the cache without network.- Generated
llms.txtand markdown mirrors resolve, scoped under each collection'sprefix.
Bundle docs for a package
You are configuring this npm package to ship agent-readable docs inside its tarball, so coding agents read version-matched docs from
node_modules.Inspect first:
- Where the package's docs MDX lives.
- The
package.jsonfilesarray and any existing prepack/build scripts.
Implement:
- Ensure a
docs.config.ts(orleadtype.config.ts) describesproductandnavigation. - Add a script that runs bundle mode:
leadtype generate --bundle --src . --out .. This writesAGENTS.mdat the package root anddocs/*.mdwith relative links that still work after install. It skips website-only artifacts (llms.txt, search, sitemap, robots). - Run it in
prepack/prepublishOnlyso the bundle is fresh on publish. - Add
AGENTS.mdanddocsto thefilesarray so they ship in the tarball. If they are gitignored build outputs, that is fine —filesstill includes them at pack time.
Reference Bundle docs into a package.
Validation:
AGENTS.mdexists at the package root and links to./docs/*.mdfiles that exist.npm pack --dry-runlistsAGENTS.mdanddocs/.