diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json
index e81412d7a..6be711d34 100644
--- a/.claude-plugin/marketplace.json
+++ b/.claude-plugin/marketplace.json
@@ -1,40 +1,106 @@
{
- "name": "mintlify-workflows",
- "owner": {
- "name": "Mintlify",
- "email": "support@mintlify.com",
- "url": "https://mintlify.com"
+ "name": "mintlify-workflows",
+ "owner": {
+ "name": "Mintlify",
+ "email": "support@mintlify.com",
+ "url": "https://mintlify.com"
+ },
+ "metadata": {
+ "description": "Ready-to-use Claude Code plugins for documentation workflows. Write, review, and consume docs using Mintlify best practices.",
+ "version": "1.1.0"
+ },
+ "plugins": [
+ {
+ "name": "doc-reader",
+ "source": "./",
+ "description": "Efficiently consume and navigate documentation sites. Use llms.txt, MCP search, and smart loading strategies to find information without overwhelming context.",
+ "version": "0.1.0",
+ "author": {
+ "name": "Ethan Palm"
+ },
+ "license": "MIT",
+ "keywords": ["documentation", "docs", "llms.txt", "mcp", "research", "reading"],
+ "category": "documentation",
+ "strict": false,
+ "skills": [
+ "./.claude/skills/doc-reader/"
+ ],
+ "mcpServers": {
+ "Mintlify": {
+ "type": "http",
+ "url": "https://mintlify.com/docs/mcp"
+ }
+ }
},
- "metadata": {
- "description": "Ready-to-use Claude Code templates for documentation workflows using Mintlify components and technical writing best practices.",
- "version": "1.0.0"
+ {
+ "name": "doc-helper",
+ "source": "./",
+ "description": "Collaborative documentation assistance. Draft, edit, and improve docs with AI help while you make final decisions.",
+ "version": "0.1.0",
+ "author": {
+ "name": "Ethan Palm"
+ },
+ "license": "MIT",
+ "keywords": ["documentation", "docs", "writing", "editing", "collaboration"],
+ "category": "documentation",
+ "strict": false,
+ "skills": [
+ "./.claude/skills/doc-helper/"
+ ],
+ "mcpServers": {
+ "Mintlify": {
+ "type": "http",
+ "url": "https://mintlify.com/docs/mcp"
+ }
+ }
+ },
+ {
+ "name": "doc-author",
+ "source": "./",
+ "description": "Autonomous documentation writing with guardrails. AI writes docs and opens PRs, with verification checks and clear escalation triggers.",
+ "version": "0.1.0",
+ "author": {
+ "name": "Ethan Palm"
+ },
+ "license": "MIT",
+ "keywords": ["documentation", "docs", "writing", "autonomous", "pr"],
+ "category": "documentation",
+ "strict": false,
+ "skills": [
+ "./.claude/skills/doc-author/"
+ ],
+ "mcpServers": {
+ "Mintlify": {
+ "type": "http",
+ "url": "https://mintlify.com/docs/mcp"
+ }
+ }
},
- "plugins": [
- {
- "name": "doc-reviewer",
- "source": "./",
- "description": "Workflow for reviewing documentation updates",
- "version": "1.0.0",
- "author": {
- "name": "Denzell Ford"
- },
- "license": "MIT",
- "keywords": ["documentation", "docs", "mintlify", "review", "lint"],
- "category": "documentation",
- "strict": false,
- "commands": [
- "./.claude/commands/review-docs.md",
- "./.claude/commands/lint-docs.md"
- ],
- "agents": [
- "./.claude/agents/document-reviewer.md"
- ],
- "mcpServers": {
- "Mintlify": {
- "type": "http",
- "url": "https://mintlify.com/docs/mcp"
- }
+ {
+ "name": "doc-reviewer",
+ "source": "./",
+ "description": "Review and lint documentation updates. Catch style issues, verify accuracy, and maintain consistency.",
+ "version": "1.0.0",
+ "author": {
+ "name": "Denzell Ford"
+ },
+ "license": "MIT",
+ "keywords": ["documentation", "docs", "mintlify", "review", "lint"],
+ "category": "documentation",
+ "strict": false,
+ "commands": [
+ "./.claude/commands/review-docs.md",
+ "./.claude/commands/lint-docs.md"
+ ],
+ "agents": [
+ "./.claude/agents/document-reviewer.md"
+ ],
+ "mcpServers": {
+ "Mintlify": {
+ "type": "http",
+ "url": "https://mintlify.com/docs/mcp"
}
}
- ]
- }
\ No newline at end of file
+ }
+ ]
+}
\ No newline at end of file
diff --git a/.claude/skills/doc-author/SKILL.md b/.claude/skills/doc-author/SKILL.md
new file mode 100644
index 000000000..601c63002
--- /dev/null
+++ b/.claude/skills/doc-author/SKILL.md
@@ -0,0 +1,299 @@
+---
+name: doc-author
+description: Write and maintain documentation autonomously. Use when assigned to create, update, or improve documentation without direct human oversight. Always opens PRs for review. Built by Mintlify.
+license: MIT
+compatibility: Requires git access and ability to create pull requests. Works with any markdown or MDX documentation. Optimized for Mintlify-powered documentation sites.
+metadata:
+ author: Mintlify
+ url: https://mintlify.com
+ version: "0.1"
+---
+
+# Write documentation autonomously
+
+This skill guides autonomous documentation work. You write docs, open PRs, and flag uncertainties, but a human reviews before merge.
+
+## Core principles
+
+1. **Only document what you can verify.** If you can't confirm something from the codebase or explicit user input, don't write it. Leave a TODO instead.
+2. **Write just enough.** Help users succeed and get back to their work. More docs isn't better docs.
+3. **Match existing patterns.** Read surrounding content before writing. Consistency beats personal preference.
+4. **Flag uncertainty.** When unsure, add a TODO comment and note it in your PR description.
+
+## Before you write
+
+### Verify you have enough context
+
+Before writing, confirm you can answer:
+- What is this feature/concept?
+- Who needs this documentation?
+- What should they be able to do after reading?
+
+If you can't answer these from the codebase or user input, stop and escalate.
+
+### Check for existing content
+
+Search the docs for related content before creating new pages. You may need to:
+- Update an existing page instead of creating a new one
+- Add a section to an existing page
+- Link to existing content rather than duplicating
+
+### Read surrounding content
+
+Before writing, read 2-3 similar pages to understand:
+- Voice and tone patterns
+- Structure and formatting conventions
+- Level of detail provided
+- Component usage patterns
+
+## Writing standards
+
+### Voice and structure
+
+- Second-person voice ("you")
+- Active voice, direct language
+- Sentence case for headings ("Getting started", not "Getting Started")
+- Lead with context when helpful—explain what before how
+- Prerequisites at the start of procedural content
+
+### What to avoid
+
+**Never use:**
+- Marketing language ("powerful", "seamless", "robust", "cutting-edge")
+- Filler phrases ("it's important to note", "in order to")
+- Excessive conjunctions ("moreover", "furthermore", "additionally")
+- Editorializing ("obviously", "simply", "just", "easily")
+- Emoji in documentation
+
+**Watch for AI-typical patterns:**
+- Overly formal or stilted phrasing
+- Unnecessary repetition of concepts
+- Generic introductions that don't add value
+- Concluding summaries that repeat what was just said
+
+### Code examples
+
+- Keep examples simple and practical
+- Use realistic but generic values (not "foo", "bar", "example")
+- Test that code actually works before including it
+- One clear example is better than multiple variations
+
+## For Mintlify-powered docs
+
+If you're working with a Mintlify-powered documentation site, follow these conventions:
+
+### File format
+
+MDX files with YAML frontmatter:
+
+```mdx
+---
+title: "Clear, descriptive title"
+description: "Concise summary for SEO and navigation."
+keywords: ["relevant", "search", "terms"]
+---
+
+Content starts here.
+```
+
+Every page requires title, description, and keywords in frontmatter.
+
+### File naming
+
+- Use kebab-case: `getting-started.mdx`, `api-reference.mdx`
+- Be descriptive but concise
+- Match existing naming patterns in the directory
+
+### Components
+
+Use Mintlify components appropriately:
+
+**Callouts** for important information:
+```mdx
+Helpful context
+Something potentially destructive
+A useful suggestion or best practice
+Information related to the task at hand
+```
+
+**Steps** for sequential procedures:
+```mdx
+
+
+ Instructions for step one.
+
+
+ Instructions for step two.
+
+
+```
+
+**Code blocks** always need language tags:
+```javascript
+const example = "always specify language";
+```
+
+### Internal links
+
+Use root-relative paths: `/content/components/accordions`, not `../components/accordions` or full URLs.
+
+## Verification guardrails
+
+### What you can document
+
+✓ Behavior you can verify in the codebase
+✓ Information explicitly provided by the user
+✓ Patterns consistent with existing documentation
+✓ Standard usage based on documented APIs
+
+### What requires a TODO
+
+? Implementation details you can't verify
+? Edge cases you haven't tested
+? Configuration options you're unsure about
+? Behavior that might vary by environment
+
+Format TODOs clearly:
+```mdx
+{/* TODO: Verify the default timeout value - couldn't find in codebase */}
+```
+
+### What requires escalation
+
+Stop and escalate when you encounter:
+
+**Content uncertainty:**
+- You don't understand the feature well enough to document it accurately
+- Existing docs contradict what you see in the codebase
+- The feature seems incomplete or broken
+
+**Scope concerns:**
+- Changes affect multiple pages or navigation structure
+- Content requires product or design input
+- Documentation involves security-sensitive information
+- Content relates to pricing, billing, or legal terms
+- You need to deprecate or significantly change existing content
+
+**Technical blockers:**
+- You can't find the source code for what you're documenting
+- The API or interface has changed significantly
+- You need access to systems or environments you don't have
+
+## Workflow
+
+### 1. Understand the task
+
+Read the issue or request carefully. Identify:
+- What specifically needs to be documented
+- What pages are affected
+- What the user should accomplish after reading
+
+### 2. Research
+
+- Search existing docs for related content
+- Read the relevant source code
+- Check for patterns in similar documentation
+
+### 3. Plan your changes
+
+Before writing, outline:
+- Which files you'll modify or create
+- What sections you'll add
+- What existing content needs updates
+
+### 4. Write
+
+- Start with the most important information
+- Keep sections focused and scannable
+- Use components appropriately
+- Add TODOs for anything uncertain
+
+### 5. Self-review
+
+Before creating a PR, verify:
+
+- [ ] All code blocks have language tags
+- [ ] Frontmatter includes title, description, keywords (if using MDX)
+- [ ] Internal links are correct
+- [ ] No marketing language or filler phrases
+- [ ] Content matches style of surrounding pages
+- [ ] TODOs are clearly marked for uncertain content
+- [ ] New pages are added to navigation (if applicable)
+
+### 6. Create PR
+
+Always open a pull request. Never commit directly.
+
+PR description should include:
+- What changed and why
+- Any TODOs or uncertainties that need human review
+- Files affected
+- How to test/verify the changes
+
+## Examples
+
+### Good page introduction
+
+```mdx
+---
+title: "Webhooks"
+description: "Receive real-time notifications when events occur in your account."
+keywords: ["webhooks", "events", "notifications"]
+---
+
+Webhooks let your application receive automatic notifications when specific events happen,
+like when a user signs up or a payment succeeds. Instead of polling for changes,
+your server receives an HTTP POST request with event details.
+```
+
+### Poor page introduction (avoid)
+
+```mdx
+---
+title: "Webhooks"
+description: "Learn about our powerful webhook system."
+keywords: ["webhooks"]
+---
+
+Welcome to our comprehensive guide on webhooks! Webhooks are an incredibly powerful
+feature that seamlessly integrates with your application. In this article, we'll
+explore everything you need to know about leveraging webhooks effectively.
+```
+
+### Good procedural content
+
+```mdx
+## Create a webhook endpoint
+
+Before registering a webhook, you need an endpoint to receive events.
+
+
+
+ Add a POST route to your server that accepts JSON payloads:
+
+ ```javascript
+ app.post('/webhooks', (req, res) => {
+ const event = req.body;
+ // Process the event
+ res.status(200).send('OK');
+ });
+ ```
+
+
+ Your endpoint must be reachable from the internet. During development,
+ use a tool like ngrok to expose your local server.
+
+
+```
+
+### Appropriate TODO usage
+
+```mdx
+## Rate limits
+
+Webhook deliveries are rate-limited to prevent overwhelming your server.
+
+{/* TODO: Verify exact rate limit - code suggests 100/min but couldn't confirm */}
+
+If a delivery fails, we retry with exponential backoff up to 5 times over 24 hours.
+```
diff --git a/.claude/skills/doc-helper/SKILL.md b/.claude/skills/doc-helper/SKILL.md
new file mode 100644
index 000000000..a519c7c4b
--- /dev/null
+++ b/.claude/skills/doc-helper/SKILL.md
@@ -0,0 +1,251 @@
+---
+name: doc-helper
+description: Assist humans with writing and improving documentation. Use when collaborating on docs, drafting content for review, or helping someone improve their writing. The human makes final decisions.
+license: MIT
+compatibility: Works with any markdown or MDX documentation. Optimized for Mintlify-powered documentation sites.
+metadata:
+ author: Mintlify
+ url: https://mintlify.com
+ version: "0.1"
+---
+
+# Help write documentation
+
+This skill guides collaborative documentation work. You help humans write better docs—drafting, editing, suggesting improvements—but they make final decisions.
+
+## Your role
+
+You're a collaborator, not an autonomous author. Your job is to:
+- Draft content the human can refine
+- Suggest improvements with clear reasoning
+- Ask clarifying questions before assuming
+- Offer alternatives when there are trade-offs
+- Flag concerns without blocking progress
+
+## Core principles
+
+1. **Ask before assuming.** If something is unclear, ask. Don't guess at product behavior, user needs, or organizational preferences.
+2. **Explain your reasoning.** When you suggest changes, say why. This helps people learn and make better decisions.
+3. **Offer options for judgment calls.** When there's no single right answer, present alternatives with trade-offs.
+4. **Match their voice.** Adapt to the existing writing style rather than imposing your own.
+
+## Working with the human
+
+### When to ask questions
+
+Ask before writing when:
+- You don't understand the feature being documented
+- The audience isn't clear
+- You're unsure what level of detail is appropriate
+- There are multiple valid approaches
+
+Good questions:
+- "Who's the primary audience for this page—developers integrating the API or admins configuring the product?"
+- "Should this be a separate page or a new section on the existing [page name]?"
+- "What should people be able to accomplish after they read the documentation?"
+- "The codebase shows two ways to do this. Which should we document, or both?"
+
+### When to offer alternatives
+
+Present options when:
+- There are different valid structures
+- Tone could go multiple directions
+- Detail level is a judgment call
+
+Example:
+> "I can write this as either:
+> A. A quick reference with just the essential steps
+> B. A detailed guide with context and troubleshooting
+>
+> A is faster to scan but assumes more knowledge. B helps beginners but takes longer to read. Which fits your users better?"
+
+### When to flag concerns
+
+Speak up when you notice:
+- Content that might be inaccurate
+- Patterns that differ from the rest of the docs
+- Missing information that users would need
+- Overly complex explanations
+
+Be direct but not blocking:
+> "This explanation assumes the reader knows what webhooks are. Want me to add a one-sentence intro, or is this page only for users who already understand the basics?"
+
+## Writing standards
+
+### Voice and structure
+
+- Second-person voice ("you")
+- Active voice, direct language
+- Sentence case for headings ("Getting started", not "Getting Started")
+- Lead with context when helpful—explain what before how
+- Prerequisites at the start of procedural content
+
+### What to avoid
+
+**Never use:**
+- Marketing language ("powerful", "seamless", "robust", "cutting-edge")
+- Filler phrases ("it's important to note", "in order to")
+- Excessive conjunctions ("moreover", "furthermore")
+- Editorializing ("obviously", "simply", "just", "easily")
+- Emoji in documentation
+
+**Watch for AI-typical patterns:**
+- Overly formal phrasing
+- Unnecessary repetition
+- Generic introductions
+- Concluding summaries that repeat the content
+
+### Code examples
+
+- Keep examples simple and practical
+- Use realistic values (not "foo", "bar")
+- Test that code works
+- One clear example beats multiple variations
+
+## For Mintlify-powered docs
+
+If you're working with a Mintlify-powered documentation site, follow these conventions:
+
+### File format
+
+MDX files with YAML frontmatter:
+
+```mdx
+---
+title: "Clear, descriptive title"
+description: "Concise summary for SEO and navigation."
+keywords: ["relevant", "search", "terms"]
+---
+
+Content starts here.
+```
+
+### Components
+
+Use Mintlify components appropriately:
+
+**Callouts** for important information:
+```mdx
+Helpful context
+Something potentially destructive
+A useful suggestion or best practice
+Information related to the task at hand
+```
+
+**Steps** for sequential procedures:
+```mdx
+
+
+ Instructions for step one.
+
+
+ Instructions for step two.
+
+
+```
+
+**Code blocks** always need language tags:
+```python
+example = "always specify language"
+```
+
+### File naming
+
+- Use kebab-case: `getting-started.mdx`
+- Match existing patterns in the directory
+
+### Internal links
+
+Use root-relative paths: `/content/components/accordions`
+
+## Common tasks
+
+### Drafting new content
+
+When asked to draft:
+1. Ask clarifying questions if the scope isn't clear
+2. Read existing related pages to match style
+3. Write a draft, noting any assumptions
+4. Highlight areas where you're uncertain
+
+Present drafts as starting points:
+> "Here's a draft based on what I found in the codebase. I've marked two spots where I wasn't sure about the exact behavior—can you verify those?"
+
+### Editing existing content
+
+When asked to improve content:
+1. Read the full page for context
+2. Identify specific issues (not just "make it better")
+3. Explain what you'd change and why
+4. Offer to make changes or let the human decide
+
+Be specific:
+> "I'd suggest three changes:
+> 1. Move the prerequisites to the top—right now users don't see them until they're mid-process
+> 2. Shorten the intro paragraph—it repeats information from the description
+> 3. Add a code example after step 3—currently it's abstract without showing the actual syntax"
+
+### Reviewing documentation
+
+When asked to review:
+- Check for accuracy against the codebase
+- Look for missing information users would need
+- Note inconsistencies with other docs
+- Flag unclear or ambiguous sections
+
+Structure feedback clearly:
+> **Accuracy issues:**
+> - Line 23: The parameter is `timeout`, not `timeoutMs`
+>
+> **Missing information:**
+> - No mention of what happens on failure
+>
+> **Style suggestions:**
+> - The intro could be shorter
+> - Consider using Steps component for the procedure
+
+### Helping with structure
+
+When asked how to organize content:
+1. Understand what the content covers
+2. Identify the user's goal when reading
+3. Suggest a structure with reasoning
+4. Be open to alternatives
+
+Example:
+> "For a setup guide, I'd suggest:
+> 1. One-sentence overview of what they're setting up
+> 2. Prerequisites (what they need before starting)
+> 3. Steps (the actual procedure)
+> 4. Verification (how to confirm it worked)
+> 5. Troubleshooting (common issues)
+>
+> Does that structure work, or do you have a different flow in mind?"
+
+## Handling uncertainty
+
+### When you don't know something
+
+Be honest:
+> "I can't tell from the codebase what the default value is. Do you know, or should we check with the team?"
+
+### When the human seems wrong
+
+Push back respectfully:
+> "The existing docs use sentence case for headings, but you've written this in title case. Should I match the existing pattern, or are you intentionally changing the convention?"
+
+### When there's conflicting information
+
+Surface the conflict:
+> "The README says the timeout is 30 seconds, but the code defaults to 60. Which is correct?"
+
+## Quality checks
+
+Before presenting work, verify:
+
+- [ ] All code blocks have language tags
+- [ ] Frontmatter is complete (if using MDX)
+- [ ] Internal links are correct
+- [ ] Style matches surrounding content
+- [ ] No marketing language or filler phrases
+- [ ] Noted any areas of uncertainty
diff --git a/.claude/skills/doc-reader/SKILL.md b/.claude/skills/doc-reader/SKILL.md
new file mode 100644
index 000000000..c29f2ff61
--- /dev/null
+++ b/.claude/skills/doc-reader/SKILL.md
@@ -0,0 +1,211 @@
+---
+name: doc-reader
+description: Efficiently consume and navigate external documentation sites. Use when researching APIs, libraries, or tools; when the user mentions docs, documentation, or references a docs URL; or when you need to understand how something works before implementing it.
+license: MIT
+compatibility: Requires internet access. Works best with Mintlify-powered documentation sites which provide MCP servers and llms.txt files.
+metadata:
+ author: Mintlify
+ url: https://mintlify.com
+ version: "0.1"
+---
+
+# Read documentation effectively
+
+This skill helps you efficiently consume documentation without overwhelming your context window or missing important information.
+
+## Quick reference: choose your approach
+
+| Situation | Approach |
+|-----------|----------|
+| First visit to a doc site | Check for llms.txt, then MCP |
+| Know exactly what you're looking for | MCP search or grep llms-full.txt |
+| Exploring/browsing | View HTML page in browser |
+| Need comprehensive understanding | Load llms-full.txt (check length first) |
+| Multiple doc sites in one task | Set up MCPs for each |
+
+## Step 1: Discover what's available
+
+When you encounter a documentation site, check for AI-friendly resources.
+
+### Check for llms.txt
+
+Every well-structured doc site should have an llms.txt file at the root:
+
+```
+https://docs.example.com/llms.txt
+```
+
+This file contains:
+- A description of what the documentation covers
+- Links to each page in the docs
+
+Sites may also have llms-full.txt files at the root which contain all the content on the documentation site as a single .md file.
+
+### Check for skill.md
+
+Some documentation sites provide a skill.md file that teaches you how to work with the product that is documented. Check for it at the root:
+
+```
+https://docs.example.com/skill.md
+```
+
+If found, install it:
+```bash
+npx skills add docs.example.com/skill.md
+```
+
+For example: `npx skills add mintlify.com/docs/skill.md`
+
+### Check for MCP server
+
+Mintlify-powered documentation sites provide MCP servers for semantic search. The MCP endpoint follows this pattern:
+
+```
+https://docs.example.com/mcp
+```
+
+If you don't have the MCP connected, set it up before proceeding.
+
+## Step 2: Set up MCP if available
+
+MCP (Model Context Protocol) servers let you search documentation semantically rather than relying on keyword matching or loading entire files.
+
+### Connecting to the MCP
+
+The setup process varies by platform. For Claude Code:
+
+```json
+{
+ "mcpServers": {
+ "example-docs": {
+ "type": "http",
+ "url": "https://docs.example.com/mcp"
+ }
+ }
+}
+```
+
+Once connected, you'll have access to the search tool for semantic search across the documentation. The tool follows the naming pattern `Search{DocsTitle}` (for example, `SearchMintlify`).
+
+### Managing multiple MCPs
+
+When working with multiple documentation sources:
+
+1. Give each MCP a descriptive name based on the product/library
+2. Use the appropriate MCP for each query rather than searching all of them
+
+## Step 3: Choose your consumption strategy
+
+### Strategy A: MCP search (preferred for targeted questions)
+
+Use when:
+- You have a specific question or topic
+- You're looking for a particular API, function, or concept
+- You want semantically relevant results, not just keyword matches
+
+```
+Use the MCP search tool with a natural language query describing what you need.
+```
+
+### Strategy B: Grep llms-full.txt (for keyword-specific searches)
+
+Use when:
+- You need to find exact matches (function names, error codes, specific terms)
+- MCP isn't available
+- You want to see all occurrences of a term
+
+Grep for your terms:
+```bash
+curl -s "https://docs.example.com/llms-full.txt" | grep -C 3 "your-search-term"
+```
+
+### Strategy C: Load full content (for comprehensive understanding)
+
+Use when:
+- You need complete context about a library/API
+- The llms-full.txt is small enough (< 15k tokens recommended)
+- You're doing extensive work that will reference many parts of the docs
+
+**Always check length first.** Before loading a full file:
+```bash
+curl -sI "https://docs.example.com/llms-full.txt" | grep -i content-length
+```
+
+If the file is too large, consider:
+- Loading specific files identified from llms.txt instead
+- Using MCP search for specific topics
+- Loading in chunks as needed
+
+### Strategy D: View HTML page (for exploration and navigation)
+
+Use when:
+- You need to understand the documentation structure
+- The user needs to navigate or click through the docs
+- You want to see diagrams, interactive examples, or formatted content
+- You're helping the user find something and they need to continue browsing
+
+Fetch and render the HTML page, or direct the user to open it in their browser. HTML pages provide:
+- Navigation menus showing doc structure
+- Interactive code examples
+- Visual diagrams and illustrations
+- Links to related topics
+
+## Common patterns
+
+### Pattern: Research before implementation
+
+1. Fetch llms.txt to understand documentation scope
+2. Set up MCP if available
+3. Use MCP search for your specific implementation questions
+4. Load relevant sections as needed
+5. Keep MCP connected for follow-up questions during implementation
+
+### Pattern: Debugging with docs
+
+1. Search for the exact error message or code using grep
+2. If no results, use MCP search with a description of the problem
+3. Load the relevant section for full context on the solution
+
+### Pattern: Learning a new library
+
+1. View the HTML landing page to understand structure
+2. Load llms-full.txt if small enough, or use section-specific files
+3. Set up MCP for ongoing reference during development
+
+### Pattern: Quick reference lookup
+
+1. MCP search with the function/method name
+2. Or grep llms-full.txt for exact matches
+
+## Tips for efficiency
+
+1. **Prefer MCP for Mintlify sites**: Semantic search is more efficient than loading and parsing raw text.
+
+2. **Cache strategically**: If you'll reference the same docs repeatedly, loading llms-full.txt once may be more efficient than multiple MCP searches.
+
+3. **Use section files**: If llms.txt links to section-specific files (like `api/llms.txt`), load only what you need.
+
+4. **Parallel MCP searches**: When working with multiple doc sources, search them in parallel rather than sequentially.
+
+## Handling edge cases
+
+### No llms.txt available
+
+Fall back to:
+1. Check if there's an MCP endpoint anyway
+2. Use WebFetch to read specific documentation pages
+3. Search the web for the documentation
+
+### Very large documentation sets
+
+For docs over 15k tokens:
+1. Use MCP search instead of loading the full file
+2. Load section-specific files as needed
+3. Ask the user which areas are most relevant
+
+### Outdated or conflicting information
+
+If you find documentation that seems outdated:
+1. Check for version indicators in the docs
+2. Note the discrepancy to the user
+3. Suggest checking the changelog or release notes