菜单
Generate a spec-compliant llms.txt file for any project by analyzing its codebase, docs, and public URLs. Use when creating an llms.txt, making a project LLM-discoverable, or when the user mentions "llms.txt" in the context of generating or scaffolding one.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | create-llms-txt |
| description | Generate a spec-compliant llms.txt file for any project by analyzing its codebase, docs, and public URLs. Use when creating an llms.txt, making a project LLM-discoverable, or when the user mentions "llms.txt" in the context of generating or scaffolding one. |
| allowed-tools | Read, Grep, Glob, Bash(git *), Edit, Write, WebFetch |
| user-invocable | true |
| metadata | {"title":"Create llms.txt","category":"ai","order":1} |
Generate a high-quality, spec-compliant llms.txt that gives LLMs maximum understanding of a project with minimum tokens.
The file uses markdown with this exact section order:
[name](url): description links## Optional (special) links that can be skipped for shorter contextNo other heading levels allowed. Every list entry must be a markdown hyperlink. Descriptions after : are optional.
# Project Name
> One-paragraph summary covering what it is, who it's for, and key capabilities.
## Docs
- [README](url): Installation, usage, examples
- [API Reference](url): Endpoint documentation
## Optional
- [CONTRIBUTING](url): How to contribute
Read these files (skip missing ones):
README.md name, summary, featuresAGENTS.md architecture, key directoriespackage.json / Cargo.toml / pyproject.toml / go.mod name, description, repo URLCHANGELOG.md exists? link itCONTRIBUTING.md exists? link in OptionalLICENSE exists? link in OptionalDetermine the repo base URL from git remote or manifest. All links must be absolute URLs pointing to the main branch (e.g. https://github.com/{owner}/{repo}/blob/main/{path}).
Scan for files that help an LLM understand the project:
main.go, src/lib.rs, src/index.ts, app.py, etc.)Justfile, Makefile, docker-compose.yml, pyproject.toml)skills/*/SKILL.md)Limit to 6-10 key files. Prefer files that explain what the project does over internal implementation.
One paragraph, 2-3 sentences max. Cover:
Do NOT pad with generic filler. Every word should help an LLM decide whether this project is relevant to a query.
Use these H2 sections (omit empty ones):
| Section | Contents |
|---|---|
## Docs | README, AGENTS.md, API docs, guides |
## API / Key Files | Entry points, public API, config, schemas |
## Skills | Agent skills if skills/ directory exists |
## Optional | CONTRIBUTING, LICENSE, changelog, secondary docs |
Each : description should be 3-10 words explaining what the LLM will find there. Skip the description only if the link name is already self-explanatory.
Bad: - [README](url): The README file
Good: - [README](url): Installation, usage, and examples
Before writing the file, check:
## Optional is last if presentllms.txt from a URL. Relative paths break. Always use absolute URLs.skills/configure-ai/SKILL.md not skills/configure-ai/.## Optional heading is semantic. It tells LLMs they can drop these links when context is tight. Put truly skippable content there; not your API docs.git remote get-url origin and normalize to HTTPS. Strip .git suffix. Use blob/main/ for file links.Write or rewrite text in ASD-STE100 Simplified Technical English (STE): the approved-word dictionary discipline, controlled verb forms, sentence and paragraph limits, procedural vs descriptive rules, and safety-instruction structure. Use when the user asks for Simplified Technical English, STE, ASD-STE100, controlled language, or aerospace-style technical writing, or when authoring procedures, maintenance instructions, or safety warnings that must be unambiguous. Do NOT use for general documentation cleanup (use clean-docs), README structure (use write-readme), or ordinary prose style.
House doctrine for designing LLM agent systems: safety enforced by the harness and tools rather than model goodwill, tools that execute and return results, minimal loop code, interface-first component seams, typed config, deterministic evals over LLM judges, and POC scope discipline. Use when designing or reviewing any agent, tool-use loop, eval harness, or agent-backed CLI, in any framework. Do NOT use for Pydantic AI framework mechanics (use building-pydantic-ai-agents), generic design principles (use review-design), or Go agent-loop implementation details (use agent).
Operate the detect-secrets pre-commit hook correctly: update the baseline with the right flags, break the "baseline file was updated, please git add" commit loop, allowlist false positives, and audit real findings. Use when a commit fails on detect-secrets, the .secrets.baseline keeps changing, or a false positive blocks a push. Do NOT use for storing or injecting secrets via 1Password (use manage-secrets) or repo-wide leak scanning with gitleaks and trufflehog (use audit-security).
Run a project's own eval suite end to end without babysitting: locate the harness, launch it in the background, monitor to completion, parse the report into a normalized summary (pass rate, latency percentiles, tokens, cost), and diff against the previous run with per-case regressions explained. Use when asked to "run the evals", re-run after a change, or score a new dataset in any repo with an eval harness. Do NOT use for the GAP benchmark suite (use run-evals), SAIGE provider-boundary checks (use verify), or designing new eval sets (that is authoring work, not a run).
Playbook of known failure modes in this dotfiles stack: pipx "bad interpreter" after Python rebuilds, gpg commit-signing failures, direnv/nix shellHook running bash instead of zsh, Powerlevel10k instant-prompt warnings, and Neovim plugin errors from removed Lua APIs. Use when a shell startup error, git signing failure, broken CLI shim, or nvim stack trace appears on this machine. Do NOT use for generic runtime debugging in projects (use diagnose-runtime), chezmoi naming and templating conventions (use dotfiles), or authoring pinned installers (use setup-devenv-with-chezmoi).
Clean and modernize documentation in place. Enforce no em dashes, readable structure, proper Markdown formatting, accurate commands, current examples, resolved internal links, and user-focused guidance. Use when the user invokes /clean-docs, asks to clean docs, make docs up to date, improve README/AGENTS prose, remove AI-looking punctuation, or make docs easier for users to act on.