Create Llms
Generate a root-level llms.txt from your repo layout so coding agents and LLM crawlers can find the right docs and specs fast.
Overview
Create LLMs is an agent skill most often used in Launch (also Build and Validate) that generates a specification-compliant llms.txt at the repository root from your project structure.
Install
npx skills add https://github.com/github/awesome-copilot --skill create-llmsWhat is this skill?
- Authors llms.txt at the repository root aligned with the official llms.txt specification at llmstxt.org
- Runs a 3-step analysis: spec review, full repository structure scan, and content discovery (READMEs and key entry files)
- Catalogs important directories and high-value files so agents know where purpose and specs live
- Balances LLM-optimized structure with human-readable markdown headings and links
- Primary directive: one comprehensive entry point before agents deep-dive scattered docs
- 3-step analysis phase: specification review, repository structure analysis, and content discovery
- Output targets the repository root per the llms.txt specification at llmstxt.org
Adoption & trust: 8.7k installs on skills.sh; 34.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Agents and LLM crawlers cannot reliably find your repo’s purpose, specs, and entry docs when everything is buried across folders and long READMEs.
Who is it for?
Open-source or product repos going public where you want consistent agent navigation and AI-discovery hygiene after structure changes.
Skip if: Repos that already maintain an up-to-date llms.txt, or pure marketing sites with no meaningful code tree to catalog.
When should I use this skill?
You need a new llms.txt from scratch based on repository structure following https://llmstxt.org/.
What do I get? / Deliverables
You get a root llms.txt that points LLMs to the right high-signal paths so the next agent session or public indexing pass starts from a clear map instead of random file reads.
- llms.txt at the repository root compliant with llmstxt.org
- Structured inventory of key directories and entry files referenced in llms.txt
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Launch/geo is the canonical shelf because llms.txt is an AI-discovery artifact aimed at how LLMs index and route into your repository, not just human README reading. GEO subphase matches llmstxt.org’s purpose: generative-engine and agent-facing discoverability beyond classic SEO pages.
Where it fits
Publish or refresh llms.txt before promoting a repo so AI search and coding agents land on the right architecture notes.
After splitting packages or services, regenerate llms.txt so agent sessions know which folder holds APIs versus apps.
While deciding what is public in v1, draft llms.txt sections that mirror the bounded surface area you will ship.
When developer content and examples multiply, update llms.txt links so lifecycle docs stay the canonical agent entry.
How it compares
Use a structured llms.txt entry map instead of pasting entire READMEs or hoping agents guess monorepo layout from chat context alone.
Common Questions / FAQ
Who is create-llms for?
Solo and indie builders shipping repos who want coding agents and LLM-oriented crawlers to understand project layout without manual path dictation each session.
When should I use create-llms?
At launch/geo when you care about AI discoverability, during build/docs after adding modules or packages, and in validate/scope when you define which directories and specs are public entry points.
Is create-llms safe to install?
Treat it like any skill that reads your filesystem: review what it will write at the repo root and check the Security Audits panel on this Prism page before running it on sensitive trees.
SKILL.md
READMESKILL.md - Create Llms
# Create LLMs.txt File from Repository Structure Create a new `llms.txt` file from scratch in the root of the repository following the official llms.txt specification at https://llmstxt.org/. 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 Create a comprehensive `llms.txt` file that serves as an entry point for LLMs to understand and navigate the repository effectively. The file must comply with the llms.txt specification and be optimized for LLM consumption while remaining human-readable. ## Analysis and Planning Phase Before creating the `llms.txt` file, you must complete a thorough analysis: ### Step 1: Review llms.txt Specification - Review the official specification at https://llmstxt.org/ to ensure full compliance - Understand the required format structure and guidelines - Note the specific markdown structure requirements ### Step 2: Repository Structure Analysis - Examine the complete repository structure using appropriate tools - Identify the primary purpose and scope of the repository - Catalog all important directories and their purposes - List key files that would be valuable for LLM understanding ### Step 3: Content Discovery - Identify README files and their locations - Find documentation files (`.md` files in `/docs/`, `/spec/`, etc.) - Locate specification files and their purposes - Discover configuration files and their relevance - Find example files and code samples - Identify any existing documentation structure ### Step 4: Create Implementation Plan Based on your analysis, create a structured plan that includes: - Repository purpose and scope summary - Priority-ordered list of essential files for LLM understanding - Secondary files that provide additional context - Organizational structure for the llms.txt file ## Implementation Requirements ### Format Compliance The `llms.txt` file must follow 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 understanding the project ## Execution Steps ### Step 1: Repository Analysis 1. Examine the