Prompt file imported from rhixecompany/sandbox (
.github/prompts/documentation/create-llms/create-llms.prompt.md). Copyright stays with the author.
Goal
Create an llms.txt file from scratch based on repository structure following the llms.txt specification at https://llmstxt.org/.
Context
Use when you need to work on the current workspace or task.
Inputs
- The current workspace, repo, or document state.
- The specific request, diff, spec, or files provided by the user.
- Any prompt variables, paths, or constraints named in the original instructions.
Outputs
- A complete result that matches the prompt's purpose.
- A concise verification note when the task benefits from one.
Rules
Core rules:
templates/_shared/rules-core.md
- Follow the prompt literally and prefer evidence from the current workspace.
- Keep the response structured, deterministic, and easy to act on.
- Avoid changing unrelated files or adding unnecessary scope.
- If something is unclear, state the assumption instead of guessing.
Phases
Phase 1: Intake
- Read the request and identify the exact scope.
- Locate the relevant files, diffs, or references.
Phase 2: Execute
- Perform the requested work with the smallest safe change set.
- Keep the steps explicit and reproducible.
Phase 3: Verify
- Check the result against the goal, rules, and inputs.
- Confirm the output is usable and complete.
Phase 4: Hand off
- Return the final artifact or findings clearly.
- Stop once the requested result is delivered.
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.txtfile, you must complete a thorough analysis:>>
Step 1: Review llms.txt Specification
Implementation Requirements
Format Compliance
The
llms.txtfile must follow this exact structure per the specification:
Execution Steps
Step 1: Repository Analysis
- Examine the repository structure completely
Quality Assurance
Format Validation
- ✅ H1 header with project name
- ✅ Blockquote summary (if included)
- ✅ H2 sections for file lists
- ✅ Proper markdown link format
- ✅ No broken or invalid links
- ✅ Consistent formatting throughout
Content Validation
- ✅ Clear, unambiguous language
- ✅ Comprehensive coverage of essential files
- ✅ Logical organization of content
- ✅ Appropriate file descriptions
- ✅ Serves as effective LLM navigation tool
Specification Compliance
- ✅ Follows https://llmstxt.org/ format exactly- ✅ Uses required markdown structure- ✅ Implements optional sections appropriately- ✅ File located at repository root (
/llms.txt)
Example Structure Template
# [Repository Name]
> [Concise description of the repository's purpose and scope]
[Optional additional context paragraphs without headings]
## Documentation
- [Main README](README.md): Primary project documentation and getting started guide
- [Contributing Guide](CONTRIBUTING.md): Guidelines for contributing to the project
- [Code of Conduct](CODE_OF_CONDUCT.md): Community guidelines and expectations
## Specifications
- [Technical Specification](spec/technical-spec.md): Detailed technical requirements and constraints
- [API Specification](spec/api-spec.md): Interface definitions and data contracts
## Examples
- [Basic Example](examples/basic-usage.md): Simple usage demonstration
- [Advanced Example](examples/advanced-usage.md): Complex implementation patterns
## Configuration
- [Setup Guide](docs/setup.md): Installation and configuration instructions
- [Deployment Guide](docs/deployment.md): Production deployment guidelines
## Optional
- [Architecture Documentation](docs/architecture.md): Detailed system architecture
- [Design Decisions](docs/decisions.md): Historical design decision records
Success Criteria
The created llms.txt file should:
- Enable LLMs to quickly understand the repository's purpose
- Provide clear navigation to essential documentation
- Follow the official llms.txt specification exactly
- Be comprehensive yet concise
- Serve both human and machine readers effectively
- Include all critical files for project understanding
- Use clear, unambiguous language throughout
- Organize content logically for easy consumption
Template References
Detailed templates in templates/create-llms/:
analysis_and_planning_phase.mdexecution_steps.mdimplementation_requirements.md
Personas
See templates/_shared/personas.md for shared persona templates.
| Persona | When to Use |
|---|---|
| Developer | Implementation, debugging, refactoring |
| Reviewer | Code review, quality assurance |
| User | General purpose, operations |
Personality
See templates/_shared/personality.md for shared personality guidelines.
- Tone: Direct, practical, actionable
- Style: Structured with clear steps and verification
- Avoid: Ambiguity, assumptions, scope creep
- Encourage: Evidence-based decisions, minimal changes
Best Practices
See templates/_shared/best-practices.md for cross-cutting best practices.
- DRY — Reference shared templates instead of duplicating content.
- Structured output — Use clear sections with consistent heading levels.
- Verification gates — Always verify before claiming completion.
- Minimal changes — Fix root cause, not symptoms.
Verification Checklist
| # | Gate | Criterion |
|---|---|---|
| 1 | Scope | Change matches the original request |
| 2 | Quality | Meets project standards |
| 3 | Tests | Tests pass (if applicable) |
| 4 | Regression | No unintended side effects |
| 5 | Docs | Changes documented if needed |
Dependencies
See templates/_shared/deps-core.md for shared dependency patterns.
Subgoals
- Prepare — Understand requirements and prerequisites.
- Execute — Follow structured workflow with incremental progress.
- Verify — Confirm output meets requirements and standards.
- Document — Record results, decisions, and lessons learned.
Skills Required
See templates/_shared/skills-table-core.md for shared skills table.
| Skill | Purpose |
|---|---|
using-superpowers |
Foundational skill workflow |
systematic-debugging |
Root cause analysis and fix |
git-patch-management |
Patch creation and management |
executing-plans |
Execute plans step by step |
verification-before-completion |
Validate before claiming done |
MCP Servers & Tools
The following MCP servers and tools are available for this task. Use them in preference to native equivalents per MCP-first tooling policy.
| ast-grep | AST-based code search and replace |
| filesystem | File read/write operations |
| sequential-thinking | Structured reasoning for complex problems |
| fetch | Web page content extraction |
| playwright | Browser automation for interactive pages |
| github | GitHub API operations |
Tasks
- Understand requirements and scope
- Plan approach and identify resources
- Execute work incrementally
- Verify against acceptance criteria
- Document results and decisions
Hooks
Shared workspace hooks run around this prompt's execution — see .github/hooks/README.md: session-logger, session-auto-commit, governance-audit, pre-exec-validate.sh, post-exec-state-log.py.
Scripts
Prompt-library tooling (see .enhance/):
.enhance/analyze_prompts.py— prompt-library analyzer (Phase 5/7 gate).enhance/verify_phase3.py,.enhance/fix_class_e.py,.enhance/fix_frontmatter_plan.py— Class C–E repair/verify tooling.github/hooks/*— hook implementations referenced in the Hooks section
Related Prompts
Same-family prompts:
create-agentsmd.prompt.mdcreate-architectural-decision-record.prompt.mdcreate-github-action-workflow-specification.prompt.mdcreate-github-issue-feature-from-specification.prompt.mdcreate-github-issues-feature-from-implementation-plan.prompt.mdcreate-github-issues-for-unmet-specification-requirements.prompt.mdcreate-github-pull-request-from-specification.prompt.mdcreate-implementation-plan.prompt.mdcreate-oo-component-documentation.prompt.mdcreate-readme.prompt.mdcreate-specification.prompt.mdcreate-spring-boot-java-project.prompt.mdcreate-spring-boot-kotlin-project.prompt.mdcreate-technical-spike.prompt.mdcreate-tldr-page.prompt.md