/doc-author

name: doc-author
description: Write, edit, and maintain documentation. Use for collaborative drafting, autonomous writing, or improving existing docs. Defaults to collaborative mode where the human makes final decisions. 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.2"

<!-- Vendored from https://github.com/mintlify/docs (commit 877f90193ea1) Upstream path: .claude/skills/doc-author/SKILL.md Upstream license: MIT (see LICENSE block in upstream repo) Vendored: 2026-04-18 by scripts/update-mintlify-skill.sh

This file is a VERBATIM copy of Mintlify's doc-author skill body. Do not edit the prose below — local conventions go in ./INSFORGE.md Update with: scripts/update-mintlify-skill.sh -->

Write and maintain documentation

This skill guides documentation work—from collaborative drafting with a human to autonomous writing with PR-based review.

Operating modes

Collaborative (default)

You're a collaborator. The human drives decisions, you assist. Use this mode unless you have a clear signal to work autonomously.

In collaborative mode:

• Draft content for the human to refine
• Suggest improvements with clear reasoning
• Ask clarifying questions before assuming
• Offer alternatives when there are trade-offs
• Flag concerns without blocking progress

Autonomous

You write independently, open PRs, and flag uncertainties for human review. Use this mode only when:

• The task is explicitly delegated (e.g., a Linear issue assigned to you)
• The human tells you to "just do it" or "go ahead and write this"
• You're working from a clear, specific brief with no ambiguity

In autonomous mode:

• Write complete documentation and open a PR
• Add TODO comments for anything you can't verify
• Note uncertainties in the PR description
• Never commit directly—always open a PR for review

When in doubt about which mode to use, default to collaborative.

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, ask in collaborative mode or add a TODO comment in autonomous mode. 5. **Ask before assuming.** If something is unclear, ask. Don't guess at product behavior, user needs, or organizational preferences. 6. **Explain your reasoning.** When you suggest changes, say why. This helps people learn and make better decisions.

Before you write

Verify you have enough context

Before writing, confirm you can answer:

• What is this feature or 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:

• **Collaborative mode:** Ask the human
• **Autonomous mode:** 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

Working with humans

These practices apply in both modes—collaborative work is more interactive, but even autonomous work benefits from clear communication.

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?"

Handling uncertainty

**When you don't know something:** > "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:** > "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:** > "The README says the timeout is 30 seconds, but the code defaults to 60. Which is correct?"

Writing standards

Voice and structure

• Second-person voice ("you")
• Active voice, direct language
• Sentence case for headings ("Getting started", not "Getting Started")
• Lead with c