Documentation Skill

Core Philosophy

"Docs that stay in sync with code and intent."

Write documentation that is accurate, scannable, and updated when behavior changes. Prefer living docs over one-off writeups.

Protocol

1. Identify Type

2. Conventions

• README: Quick start, prerequisites, install, run, test, contribute. Keep under ~200 lines; link to detailed docs.
• API docs: Method/path, request/response shape, errors, examples. Prefer OpenAPI when the project uses it.
• ADR: Context, decision, consequences. One file per decision; number and date in filename.
• Inline: Explain why, not what. Docstrings for public functions/classes; avoid noise on trivial code.
• Runbook: Steps, checks, rollback, contacts. Assume someone unfamiliar can follow.

3. Commands

No mandatory commands. Use project structure: if docs/ or CONTRIBUTING.md exists, follow existing layout and style.

4. MCP (Atlassian Confluence)

When documentation lives in Confluence or the user wants to sync with Confluence, use the Atlassian MCP (after /setup) to fetch pages, search with CQL, and create/update content. Key tools:

• confluence_search - Search Confluence content using simple terms or CQL
• confluence_get_page - Get content of a specific page by ID or title+space
• confluence_create_page - Create a new page in a space (supports Markdown)
• confluence_update_page - Update an existing page
• confluence_get_page_children - Get child pages for navigation
• confluence_get_comments - Get comments on a page
• confluence_add_comment - Add a comment to a page

Ensure /setup has been run so Atlassian MCP is configured.

5. Output

When adding or updating docs, provide the content and say what was created/updated. If the project has a docs style guide, follow it.

Checklist

• Matches current behavior (no outdated steps or APIs).
• Scannable (headings, lists, code blocks where useful).
• Links to related docs or code when helpful.
• No duplicate info across README and other docs; cross-reference instead.