Engineering

Documentation Studio

Technical documentation lifecycle for API docs, guides, runbooks, and knowledge bases

5 stages9 hats6 review agentsPersistence: gitDelivery: pull-request

Stage Pipeline

Stage Details

AuditAuto review

Assess existing documentation, identify gaps, and prioritize what to write or update

Hats

Auditor

Inventory existing documentation, assess its currency and accuracy, and catalog what exists. Systematic coverage matters — every public-facing API, workflow, and concept should be accounted for.

Gap Analyst

Analyze the auditor's inventory to identify documentation gaps, prioritize them by user impact, and produce a ranked backlog of documentation work. Connect gaps to real user pain — support tickets, onboarding friction, common mistakes.

Review Agents

Coverage

The agent **MUST** verify the audit identified all documentation gaps and priorities are correctly ranked.

OutlineAsk review

Structure the documentation with clear information architecture

Hats

Architect

Design the information architecture — how content is organized, navigated, and discovered. Structure documentation around user tasks and workflows, not around system internals. Apply progressive disclosure so readers find what they need at the right level of detail.

Outline Reviewer

Validate the architect's outline from the reader's perspective. Walk through common user journeys and verify the structure supports them. Check for orphaned sections, circular references, and gaps in the learning path.

Review Agents

Structure

The agent **MUST** verify the information architecture supports how users actually look for information.

Requires: audit-report from Audit
DraftAsk review

Write the documentation content following the approved outline

Hats

Technical Reviewer

Verify the technical accuracy of the writer's draft. Test code examples, validate API signatures, confirm configuration values, and check procedures against the running system. Every claim should be traceable to the source of truth.

Writer

Write clear, accurate documentation following the approved outline. Leadd with the user's goal, explain why before how, and include concrete examples for every abstract concept. Code samples must be runnable, not pseudocode.

Review Agents

Accuracy

The agent **MUST** verify all technical content is factually correct against the current codebase.

Clarity

The agent **MUST** verify the documentation is understandable by its target audience.

Requires: document-outline from Outline
ReviewAsk review

Review documentation for accuracy, clarity, and completeness

Hats

Editor

Review documentation for clarity, consistency, and readability. Ensure terminology is consistent with the project glossary. Check that the writing serves the reader — concise where possible, detailed where necessary. Fix ambiguous instructions, passive voice that obscures the actor, and unclear antecedents.

Subject Matter Expert

Validate that the documentation accurately represents the system's behavior, design intent, and operational reality. Catch subtle inaccuracies that a technical reviewer might miss — wrong mental models, misleading simplifications, and missing edge cases that users will hit in production.

Review Agents

Completeness

The agent **MUST** verify the documentation fully addresses the gaps identified in the audit.

Requires: draft-documentation from Draft
PublishAuto review

Format, validate links, and publish the documentation

Hats

Publisher

Incorporate review findings, finalize formatting for the target platform, validate all links, and ensure metadata is complete. The publisher bridges "reviewed draft" to "live documentation" — addressing findings, confirming rendering, and verifying that the documentation is discoverable.

Review Agents

Formatting

The agent **MUST** verify the published documentation renders correctly and is navigable.

Accuracy

from Draft stage

Requires: draft-documentation from Draft, review-report from Review

Documentation Studio

Use this studio for any technical documentation effort — API references, user guides, operational runbooks, architecture decision records, onboarding docs, or knowledge base articles. The lifecycle moves from assessing existing documentation gaps through structured outlining, drafting, review, and publication.

Best suited when documentation is the primary deliverable rather than a side-effect of code work. For inline code documentation or README updates that accompany a code change, the default software studio is more appropriate.