generate-llms-txt

Generate llms.txt and optionally llms-full.txt following the llms.txt standard so that LLMs can quickly understand the project.

The output directory is $ARGUMENTS if provided, otherwise default to the project root (.).

Steps

1. Check for existing files: If <output-dir>/llms.txt or <output-dir>/llms-full.txt already exist, read them in full so any hand-written sections can be preserved and updated rather than replaced.

2. Gather project information (read in this order, each layer fills gaps left by the previous):

   a. Build manifests — read package.json, build.gradle.kts, settings.gradle.kts, Cargo.toml, go.mod, pyproject.toml, or whatever build/manifest file exists. Extract the project name, description, language, and dependencies.

   b. README — read README.md (or README, README.rst, README.txt) for the project overview, features, and usage.

   c. Existing documentation — glob docs/**/*.md, doc/**/*.md, and any other common doc directories. Read each file to understand module descriptions and API summaries.

   d. Source code — glob source files (src/**/*, lib/**/*, cmd/**/*, app/**/*, etc.) and read them to identify the public API surface (exported functions, classes, interfaces, types). Only use source code to supplement where existing documentation is lacking.

3. Build the llms.txt structure following this format:

   # ProjectName
   
   > One-line project description.
   
   Brief 2–4 sentence overview of what the project does, who it is for, and what problem it solves.
   
   ## Docs
   
   - [SectionOrModule](relative/path/to/doc.md): One-line description of what this covers
   
   ## API
   
   - [SymbolName](relative/path/to/source.ext): One-line summary of what it does
   
   ## Optional
   
   - [Contributing](CONTRIBUTING.md)
   - [Changelog](CHANGELOG.md)
   - [License](LICENSE)
   

   Rules for this structure:

   • The # ProjectName heading and > blockquote description are required.
   • The ## Docs section lists documentation files with relative links and one-line descriptions.
   • The ## API section lists key public symbols with relative links to their source files. Include only the most important entry points — not every function.
   • The ## Optional section lists supplementary files (CONTRIBUTING, CHANGELOG, LICENSE, etc.) only if they exist.
   • Omit any section that has no entries.
   • Use relative links throughout.

4. Decide whether to generate llms-full.txt: Count the number of source files and estimate the expanded content size. Apply these thresholds:

   • ≤ 50 source files AND estimated expanded content ≤ 100 KB → generate llms-full.txt.
   • Otherwise → skip llms-full.txt and note in the report that the project is too large.

5. Build llms-full.txt (if generating): Use the same structure as llms.txt, but replace every link with the actual content inlined directly below the heading. For documentation files, include the full Markdown content. For API symbols, include the signature and doc comment (not the full implementation).

6. Preserve hand-written content: Any section in an existing llms.txt or llms-full.txt that is not derivable from the project (e.g., custom descriptions, usage notes, special instructions for LLMs) must be carried over verbatim.

7. Write the files: Write llms.txt (and llms-full.txt if applicable) to the output directory.

8. Report: List every file written or updated. If llms-full.txt was skipped, explain why (file count or estimated size). Flag any areas where project documentation was too thin to produce a useful summary.

Formatting rules

• Use # for the project name, ## for sections, and Markdown list items for entries.
• Keep descriptions precise and concise — one sentence per entry.
• Use relative paths for all links.
• Do not include sections with zero entries.
• In llms-full.txt, use --- horizontal rules to separate inlined content blocks.

Important

• Never invent features, capabilities, or descriptions that are not present in the source code or documentation. If something is unclear, omit it rather than guess.
• Do not overwrite an existing file wholesale if it contains hand-written sections — merge instead.
• Do not add a "Generated by AI" notice or any similar disclaimer.
• If the project has no source files and no README, create a minimal llms.txt with just the project name and a placeholder description, and tell the user.