Documentation Studio
Technical documentation lifecycle for API docs, guides, runbooks, and knowledge bases
Stage Pipeline
Stage Details
Assess existing documentation, identify gaps, and prioritize what to write or update
Hats
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.
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.
Structure the documentation with clear information architecture
Hats
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.
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.
Write the documentation content following the approved outline
Hats
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.
Write clear, accurate documentation following the approved outline. Lead 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 documentation for accuracy, clarity, and completeness
Hats
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.
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.
Format, validate links, and publish the documentation
Hats
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.
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.