Update Llms
Keep root llms.txt accurate so coding agents and AI crawlers find the right specs and doc entry points.
Overview
update-llms is an agent skill most often used in Launch (also Build docs, Operate iterate) that refreshes root llms.txt to match repo docs per the llmstxt.org specification.
Install
npx skills add https://github.com/github/awesome-copilot --skill update-llmsWhat is this skill?
- Updates existing root llms.txt per https://llmstxt.org/ specification
- Repository structure analysis compares documented paths to current tree
- Planning phase reviews prior file and spec compliance before editing
- Tracks new, moved, or removed docs that LLMs should cite
- Balances LLM-optimized structure with human-readable maintenance
- Two-phase workflow: review current file plus llmstxt.org spec, then repository structure analysis before edits
Adoption & trust: 8.5k installs on skills.sh; 34.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your repo changed but llms.txt still points agents at wrong or missing spec paths.
Who is it for?
Open-source or product repos where Claude Code, Cursor, or crawlers should load the correct specs first try.
Skip if: Repos with no documentation to index, or teams that want marketing landing copy instead of structured LLM guidance.
When should I use this skill?
Documentation, specifications, or repository layout changed and root llms.txt must stay accurate for LLMs.
What do I get? / Deliverables
An accurate, spec-compliant llms.txt that lists current high-signal doc locations for LLM consumption.
- Updated llms.txt compliant with llmstxt.org
- Inventory of included doc paths versus current tree
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
llms.txt is the canonical AI-facing map of your repo—most valuable when you want discoverability at Launch and kept honest as the product evolves. GEO subphase covers machine-readable visibility (llms.txt spec at llmstxt.org), complementary to human SEO.
Where it fits
After adding an API spec folder, regenerate llms.txt so agents load openapi paths first.
Before Product Hunt launch, publish llms.txt so AI search snippets reference your real architecture doc.
When you archive old /docs pages, update llms.txt so support agents stop citing 404s.
How it compares
Repo-root LLM map per llms.txt—not generic README polishing or full static-site SEO audits.
Common Questions / FAQ
Who is update-llms for?
Solo maintainers and indie SaaS builders who want coding agents and AI systems to discover their canonical docs via llms.txt.
When should I use update-llms?
At Launch (geo) before public release; in Build (docs) after adding specs; in Operate (iterate) whenever directories or ADRs move.
Is update-llms safe to install?
Review the Security Audits panel on this page; the skill edits a root file and reads the repo—confirm diffs before merge.
SKILL.md
READMESKILL.md - Update Llms
# Update LLMs.txt File Update the existing `llms.txt` file in the root of the repository to reflect changes in documentation, specifications, or repository structure. This file provides high-level guidance to large language models (LLMs) on where to find relevant content for understanding the repository's purpose and specifications. ## Primary Directive Update the existing `llms.txt` file to maintain accuracy and compliance with the llms.txt specification while reflecting current repository structure and content. The file must remain optimized for LLM consumption while staying human-readable. ## Analysis and Planning Phase Before updating the `llms.txt` file, you must complete a thorough analysis: ### Step 1: Review Current File and Specification - Read the existing `llms.txt` file to understand current structure - Review the official specification at https://llmstxt.org/ to ensure continued compliance - Identify areas that may need updates based on repository changes ### Step 2: Repository Structure Analysis - Examine the current repository structure using appropriate tools - Compare current structure with what's documented in existing `llms.txt` - Identify new directories, files, or documentation that should be included - Note any removed or relocated files that need to be updated ### Step 3: Content Discovery and Change Detection - Identify new README files and their locations - Find new documentation files (`.md` files in `/docs/`, `/spec/`, etc.) - Locate new specification files and their purposes - Discover new configuration files and their relevance - Find new example files and code samples - Identify any changes to existing documentation structure ### Step 4: Create Update Plan Based on your analysis, create a structured plan that includes: - Changes needed to maintain accuracy - New files to be added to the llms.txt - Outdated references to be removed or updated - Organizational improvements to maintain clarity ## Implementation Requirements ### Format Compliance The updated `llms.txt` file must maintain this exact structure per the specification: 1. **H1 Header**: Single line with repository/project name (required) 2. **Blockquote Summary**: Brief description in blockquote format (optional but recommended) 3. **Additional Details**: Zero or more markdown sections without headings for context 4. **File List Sections**: Zero or more H2 sections containing markdown lists of links ### Content Requirements #### Required Elements - **Project Name**: Clear, descriptive title as H1 - **Summary**: Concise blockquote explaining the repository's purpose - **Key Files**: Essential files organized by category (H2 sections) #### File Link Format Each file link must follow: `[descriptive-name](relative-url): optional description` #### Section Organization Organize files into logical H2 sections such as: - **Documentation**: Core documentation files - **Specifications**: Technical specifications and requirements - **Examples**: Sample code and usage examples - **Configuration**: Setup and configuration files - **Optional**: Secondary files (special meaning - can be skipped for shorter context) ### Content Guidelines #### Language and Style - Use concise, clear, unambiguous language - Avoid jargon without explanation - Write for both human and LLM readers - Be specific and informative in descriptions #### File Selection Criteria Include files that: - Explain the repository's purpose and scope - Provide essential technical documentation - Show usage examples and patterns - Define interfaces and specifications - Contain configuration and setup instructions Exclude files that: - Are purely implementation details - Contain redundant information - Are build artifacts or generated content - Are not relevant to understandin