agentleFS
ProviderProtocolProviderProtocol/ai/.claude/skills/llms-md-updater/SKILL.md

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.

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
  1. Distinctive:

    After adding new providers (e.g., "just added Groq provider")

    line 14
  2. Distinctive:

    When core APIs or types change

    line 15
  3. Distinctive:

    After modifying factory functions (llm, embedding, image)

    line 16
  4. Distinctive:

    When capability matrices change

    line 17
  5. Distinctive:

    Before releases to ensure LLM docs match code

    line 18
  6. Distinctive:

    Update Provider Capability Matrix if providers added/changed

    line 64
  7. Distinctive:

    Add new provider-specific sections if needed

    line 65
  8. Distinctive:

    Update type definitions and interfaces

    line 66
  9. Distinctive:

    Update environment variable references

    line 68
  10. Distinctive:

    Verify all imports paths are correct

    line 69
  11. Distinctive:

    When updating llms.md content:

    line 102
  12. Distinctive:

    Complete imports: Always show full import statements

    line 105
  13. Distinctive:

    Provider parity: Document all providers consistently

    line 107
  14. Distinctive:

    Capability matrix accuracy: Keep the matrix current with actual capabilities

    line 108
  15. Distinctive:

    Always check these sections are current:

    line 113
  16. Distinctive:

    Provider Functions: - All providers listed with correct import paths

    line 116
  17. Distinctive:

    StreamEventType: - All event types listed

    line 121
  18. Distinctive:

    Environment Variables: - All API key env vars listed

    line 123
  19. Distinctive:

    Check image factory function for new methods

    line 132
  20. Distinctive:

    Update Image Generation section with streaming API

    line 134
  21. Distinctive:

    Add streaming example for image generation

    line 135
  22. Distinctive:

    Update capability matrix if needed

    line 136
  23. Distinctive:

    Keep examples simple and self-contained

    line 143
  24. Distinctive:

    Don't remove working examples, only update outdated ones

    line 144

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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-AgentTask
Provider ScannerCheck src/providers/ for new or modified providers, capabilities
Type AnalyzerReview src/types/ for interface changes, new types, modified signatures
API Surface ScannerCheck src/index.ts and core exports for new/changed public APIs
Example ValidatorVerify 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:

  1. Outdated sections - Content that no longer matches implementation
  2. Missing documentation - New providers/APIs/types not documented
  3. Capability changes - Updated provider capability matrix
  4. Broken examples - Code samples that need updating
  5. New patterns - Usage patterns that should be documented

Step 4: Apply Updates

  1. Update Provider Capability Matrix if providers added/changed
  2. Add new provider-specific sections if needed
  3. Update type definitions and interfaces
  4. Fix/add code examples
  5. Update environment variable references
  6. 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:

  1. Quick Start - Basic usage still works
  2. Provider Functions - All providers listed with correct import paths
  3. LLMOptions interface - Matches src/types/llm.ts
  4. Turn object - Matches current Turn interface
  5. Message types - Current message classes documented
  6. Tool interface - Tool definition is accurate
  7. StreamEventType - All event types listed
  8. Provider Capability Matrix - Accurate for all providers
  9. Environment Variables - All API key env vars listed
  10. Provider-Specific Options - Params types are current

Example

Input: User says "update llms.md, I just added streaming to the image modality"

Action:

  1. Scan src/types/image.ts for streaming changes
  2. Check image factory function for new methods
  3. Review any new stream event types
  4. Update Image Generation section with streaming API
  5. Add streaming example for image generation
  6. 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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.