llms-md-updater
Skill4 starsChanged 10 months agoMITView on GitHub
Update llms.md documentation for LLM consumption based on codebase changes. Use when adding providers, changing APIs, updating types, or when the LLM reference guide drifts from implementation.
In this repository6 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- changelog-generatorSkill
- code-reviewSkill
- implementation-reviewSkill
- readme-updaterSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
24 rules. About 0 are common, 24 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈24
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
After adding new providers (e.g., "just added Groq provider")
- Distinctive: line 15
When core APIs or types change
- Distinctive: line 16
After modifying factory functions (llm, embedding, image)
- Distinctive: line 17
When capability matrices change
- Distinctive: line 18
Before releases to ensure LLM docs match code
- Distinctive: line 64
Update Provider Capability Matrix if providers added/changed
- Distinctive: line 65
Add new provider-specific sections if needed
- Distinctive: line 66
Update type definitions and interfaces
- Distinctive: line 68
Update environment variable references
- Distinctive: line 69
Verify all imports paths are correct
- Distinctive: line 102
When updating llms.md content:
- Distinctive: line 105
Complete imports: Always show full import statements
- Distinctive: line 107
Provider parity: Document all providers consistently
- Distinctive: line 108
Capability matrix accuracy: Keep the matrix current with actual capabilities
- Distinctive: line 113
Always check these sections are current:
- Distinctive: line 116
Provider Functions: - All providers listed with correct import paths
- Distinctive: line 121
StreamEventType: - All event types listed
- Distinctive: line 123
Environment Variables: - All API key env vars listed
- Distinctive: line 132
Check image factory function for new methods
- Distinctive: line 134
Update Image Generation section with streaming API
- Distinctive: line 135
Add streaming example for image generation
- Distinctive: line 136
Update capability matrix if needed
- Distinctive: line 143
Keep examples simple and self-contained
- Distinctive: line 144
Don't remove working examples, only update outdated ones
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
LLMs.md Updater
Analyze codebase changes and update the llms.md reference guide to keep it accurate for AI model consumption.
When to Use
- After adding new providers (e.g., "just added Groq provider")
- When core APIs or types change
- After modifying factory functions (llm, embedding, image)
- When capability matrices change
- Before releases to ensure LLM docs match code
- User says "update llms.md", "sync llm docs", "llms.md is stale"
Instructions
Step 1: Determine Change Scope
Identify what has changed since llms.md was last accurate:
# Find when llms.md was last modified
git log -1 --format="%h %s" -- llms.md
# Get commits since llms.md update
git log $(git log -1 --format="%h" -- llms.md)..HEAD --oneline --no-merges
# See what files changed (focus on src/)
git diff --name-only $(git log -1 --format="%h" -- llms.md)..HEAD -- src/Step 2: Spawn Analysis Sub-Agents
Deploy parallel sub-agents to analyze different aspects:
| Sub-Agent | Task |
| Provider Scanner | Check src/providers/ for new or modified providers, capabilities |
| Type Analyzer | Review src/types/ for interface changes, new types, modified signatures |
| API Surface Scanner | Check src/index.ts and core exports for new/changed public APIs |
| Example Validator | Verify code examples in llms.md against current implementation |
Prompt each sub-agent with:
"Analyze [scope] and report findings relevant to llms.md accuracy. Focus on exported functions, types, provider options, and usage patterns that an LLM would need to understand."
Step 3: Synthesize Findings
Aggregate sub-agent reports into:
- Outdated sections - Content that no longer matches implementation
- Missing documentation - New providers/APIs/types not documented
- Capability changes - Updated provider capability matrix
- Broken examples - Code samples that need updating
- New patterns - Usage patterns that should be documented
Step 4: Apply Updates
- Update Provider Capability Matrix if providers added/changed
- Add new provider-specific sections if needed
- Update type definitions and interfaces
- Fix/add code examples
- Update environment variable references
- Verify all imports paths are correct
Output Format
# LLMs.md Update Report
## Analysis Summary
[One paragraph overview of changes needed]
## Sections Updated
| Section | Change Type | Description |
|---------|-------------|-------------|
| Provider Capability Matrix | Updated | Added Groq and Cerebras |
| Anthropic Options | Updated | New beta flags available |
| Quick Start | Fixed | Import path changed |
## Providers Modified
- [x] New: Groq provider added
- [x] New: Cerebras provider added
- [ ] Updated: OpenAI new API mode
## Code Examples Validated
- [x] Basic LLM usage
- [x] Streaming example
- [ ] Tool calling (needs fix - new signature)
## Changes Applied
[Summary of edits made to llms.md]Content Guidelines
When updating llms.md content:
- Optimize for LLM comprehension: Clear, unambiguous examples that can be copied
- Complete imports: Always show full import statements
- Type annotations: Include TypeScript types in examples
- Provider parity: Document all providers consistently
- Capability matrix accuracy: Keep the matrix current with actual capabilities
- Environment variables: List all supported env vars
Sections to Verify
Always check these sections are current:
- Quick Start - Basic usage still works
- Provider Functions - All providers listed with correct import paths
- LLMOptions interface - Matches src/types/llm.ts
- Turn object - Matches current Turn interface
- Message types - Current message classes documented
- Tool interface - Tool definition is accurate
- StreamEventType - All event types listed
- Provider Capability Matrix - Accurate for all providers
- Environment Variables - All API key env vars listed
- Provider-Specific Options - Params types are current
Example
Input: User says "update llms.md, I just added streaming to the image modality"
Action:
- Scan src/types/image.ts for streaming changes
- Check image factory function for new methods
- Review any new stream event types
- Update Image Generation section with streaming API
- Add streaming example for image generation
- Update capability matrix if needed
Output: Updated llms.md with image streaming documentation + report of changes made
Notes
- Preserve the existing document structure and style
- Keep examples simple and self-contained
- Don't remove working examples, only update outdated ones
- Cross-reference with src/index.ts exports for public API surface
- Provider-specific params come from src/providers/{provider}/types.ts
- Capability flags come from src/providers/{provider}/llm.ts
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

