Create Claude slash command for llms.txt generation #5
Conversation
Create new slash command to generate llms.txt files following the llmstxt.org specification. Command intelligently detects project type and places file in appropriate location (public/, static/, or root). Features: - Auto-detects web framework and documentation structure - Generates proper markdown format (H1, blockquote, sections) - Organizes documentation links by priority - Handles updates to existing files - Follows llms.txt standard for helping LLMs navigate sites Similar to generate-AGENTS-file but focused on external site navigation rather than internal project context.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| 3. Check for `docs/` directory if this appears to be a documentation site | ||
| 4. Default to repository root if none found | ||
|
|
||
| The file should be placed where it will be accessible at the URL path `/llms.txt` when the site is deployed. |
There was a problem hiding this comment.
Bug: Documentation Site Priority Conflict
The location detection priority conflicts with the documentation site guidance. The sequential checks prioritize public/ and static/ unconditionally, but the examples section shows docs/ should be used for documentation sites. This creates ambiguity: if a documentation site has both public/ and docs/ directories, the algorithm would incorrectly choose public/. The docs/ check needs clearer prioritization logic for documentation-focused projects.
Pull Request Review: Generate llms.txt CommandThank you for creating this PR! I've reviewed the new StrengthsExcellent LLM-to-LLM Prompt Structure:
Comprehensive Coverage:
Good Documentation:
Areas for Improvement1. Formatting Violations (per Lines 125-127 use bold formatting unnecessarily. According to the project's prompt engineering guidelines:
Current: 1. **Prioritize ruthlessly**: Most important links first
2. **Be concise**: Brief descriptions, not full explanations
3. **Use relative paths**: For internal documentation (easier to maintain)Should be: 1. Prioritize ruthlessly: Most important links first
2. Be concise: Brief descriptions, not full explanations
3. Use relative paths: For internal documentation (easier to maintain)The same issue appears in lines 89-95 and 213-239. Bold formatting doesn't help LLM comprehension and increases token usage. 2. Semantic Tag Naming Consistency The workflow uses numbered steps within sections that could be semantic. For example, in Current structure: <analyze-project>
1. Detect project type:
- Check package.json...
2. Identify key documentation:
- Look for README.md...
3. Identify important links:
- GitHub repository URL...
</analyze-project>Consider (more semantic): <analyze-project>
<detect-project-type>
- Check package.json for web frameworks (Next.js, React, Vue, etc.)
- Check pyproject.toml, requirements.txt for Python frameworks (Django, Flask, FastAPI)
- Check for static site generators (Hugo, Jekyll, Gatsby, etc.)
- Check for documentation tools (MkDocs, Docusaurus, VitePress, etc.)
</detect-project-type>
<identify-documentation>
- Look for README.md
- Look for docs/ or documentation/ directory
- Look for CONTRIBUTING.md, ARCHITECTURE.md, API.md
- Check .cursor/rules/ for coding standards
- Check .claude/agents/ for specialized agents
- Check for API documentation (OpenAPI/Swagger files)
</identify-documentation>
<identify-links>
- GitHub repository URL (from package.json, git remote)
- Documentation site URL (from package.json, README)
- API reference locations
- Getting started guides
</identify-links>
</analyze-project>This follows the guideline: "Use semantic names, not numbers: 3. Minor: Example Code Block Could Show More Variety The example structure (lines 58-86) shows a single pattern. Per the prompt engineering guidelines on pattern reinforcement:
While one comprehensive example is fine for a template, consider showing 2-3 examples of actual llms.txt files for different project types (e.g., one for a Next.js app, one for a Python library, one for documentation site). This would help LLMs better understand the variations. Code Quality
RecommendationApprove with minor changes. The command is well-structured and follows most project standards. The formatting issues are easy to fix and don't affect functionality. The semantic tag suggestion would improve LLM parsing but isn't critical. Suggested Changes
The command provides real value and follows the project's philosophy of creating LLM-friendly navigation. Great addition to the toolkit! Files reviewed: |
Create new slash command to generate llms.txt files following the llmstxt.org specification. Command intelligently detects project type and places file in appropriate location (public/, static/, or root).
Features:
Similar to generate-AGENTS-file but focused on external site navigation rather than internal project context.
Note
Introduces a new command spec to generate/update llms.txt with auto placement, structured markdown links, optimization, and update workflow.
generate-llms-txtspecification in.claude/commands/generate-llms-txt.md.llms.txt(public/,static/,docs/, or root).llms-full.txtguidance (deferred by default).Written by Cursor Bugbot for commit 0eff191. This will update automatically on new commits. Configure here.