--- title: "Documentation Generation Docs Architect: review, role & definition · Undominated.ai" canonical: https://undominated.ai/agents/wshobson-docs-architect/ description: "Builds a structured architecture manual from an existing codebase, covering design rationale, component interactions, operational behavior and paths into the source." --- # Documentation Generation Docs Architect: review, role & definition · Undominated.ai > Builds a structured architecture manual from an existing codebase, covering design rationale, component interactions, operational behavior and paths into the source. [← Explore all agents](/agents/) DOCUMENTATION / wshobson # Documentation Generation Docs Architect Builds a structured architecture manual from an existing codebase, covering design rationale, component interactions, operational behavior and paths into the source. Use this definition ↓Original source ↗ SOURCE REVIEW Reviewed 2026-09-21 Evidence 4 linked sources Publisher wshobson Licence MIT ↗ Revision 4236bb91f839 Read what was—and wasn’t—checked ↓ “Creates comprehensive technical documentation from existing codebases. Analyzes architecture, design patterns, and implementation details to produce long-form technical manuals and ebooks. Use PROACTIVELY for system” wshobson · upstream description ↗ Our analysis follows below. 01 / THE REASONING ## Why this made the selection. - Output contract is specific: Markdown, heading hierarchy, code blocks, tables, links as file_path:line_number, 10-section skeleton. - Discovery→structure→write process starts from code structure rather than inventing architecture. ### A good fit for - Onboarding manuals and architecture deep-dives from an existing repo. - Documenting design rationale when ADRs are missing. ### Weigh up before choosing - The source favors extensive manuals; choose a bounded audience and scope to avoid documentation that is costly to maintain. - It does not declare tools or restrict output paths; repository access and allowed file changes depend on the host. - Requested security, performance and historical sections need evidence beyond plausible prose. Diagrams are described as deliverables, not supplied renderers. 02 / THE REVIEW RECORD ## What we actually inspected. Source review has boundaries. A clear record is more useful than a “safe” badge. ### Material inspected - plugins/documentation-generation/agents/docs-architect.md (complete frontmatter and body) - LICENSE (applicable redistribution terms) - README.md (host and installation guidance) - Host configuration documentation; immutable source and licence hashes ### Our findings - Best practices include current state plus evolutionary history, troubleshooting, and audience-specific reading paths. - Does not forbid writing docs that assert unverified performance/security characteristics—those sections are requested. - Unlike ecc-doc-updater, this is long-form manuals, not CODEMAPS paths. - No instruction to refuse inventing line numbers if files were not read. - Not a reviewer: it creates documentation, so stale-confident prose is a failure mode. ### Not established by this review - The agent has not been executed or benchmarked. - Tool availability, host/model compatibility and task outcomes were not runtime-tested. The review applies to the material and revision named here. A newer upstream release can change its behavior. 03 / PUT IT TO WORK ## Use the role in your project. Upstream setup instructions ↗ - Download the original docs-architect.md together with its LICENSE and attribution; inspect its instructions, model choice and tools. - For project use, place the definition in .claude/agents/docs-architect.md; the documented personal scope is ~/.claude/agents/. - Ask Claude Code to delegate a bounded task to the agent by its frontmatter name. Existing agent directories are watched; restart if you created a new agents directory after the session began. - Configure any referenced tools, sibling files or plugin dependencies separately. A standalone definition does not install its complete upstream plugin. ### Before you start - Repository access and a target audience. - Prefer hosts that actually expose file read tools so citations can be real. ### Compatibility Claude Code subagents ### Host-mediated repository and tool access - Declared: none; model sonnet. Instructed: read the codebase and generate Markdown manuals. Not enforced: write path allowlist (e.g. docs/ only). ### Cost model Definition can be reused under its stated licence. Host subscriptions, model usage or connected services may incur charges. THE COMPLETE REVIEWED DEFINITION ## Read it before you reuse it. Original source bytes, with attribution. Review the host-specific setup notes above. Copy definition ↗ [Download definition + licence ↗](/resources/agents/wshobson-docs-architect/bundle.zip)[Raw Markdown ↗](/resources/agents/wshobson-docs-architect/definition.md) --- name: documentation-generation-docs-architect description: Creates comprehensive technical documentation from existing codebases. Analyzes architecture, design patterns, and implementation details to produce long-form technical manuals and ebooks. Use PROACTIVELY for system documentation, architecture guides, or technical deep-dives. model: sonnet --- You are a technical documentation architect specializing in creating comprehensive, long-form documentation that captures both the what and the why of complex systems. ## Core Competencies 1. **Codebase Analysis**: Deep understanding of code structure, patterns, and architectural decisions 2. **Technical Writing**: Clear, precise explanations suitable for various technical audiences 3. **System Thinking**: Ability to see and document the big picture while explaining details 4. **Documentation Architecture**: Organizing complex information into digestible, navigable structures 5. **Visual Communication**: Creating and describing architectural diagrams and flowcharts ## Documentation Process 1. **Discovery Phase** - Analyze codebase structure and dependencies - Identify key components and their relationships - Extract design patterns and architectural decisions - Map data flows and integration points 2. **Structuring Phase** - Create logical chapter/section hierarchy - Design progressive disclosure of complexity - Plan diagrams and visual aids - Establish consistent terminology 3. **Writing Phase** - Start with executive summary and overview - Progress from high-level architecture to implementation details - Include rationale for design decisions - Add code examples with thorough explanations ## Output Characteristics - **Length**: Comprehensive documents (10-100+ pages) - **Depth**: From bird's-eye view to implementation specifics - **Style**: Technical but accessible, with progressive complexity - **Format**: Structured with chapters, sections, and cross-references - **Visuals**: Architectural diagrams, sequence diagrams, and flowcharts (described in detail) ## Key Sections to Include 1. **Executive Summary**: One-page overview for stakeholders 2. **Architecture Overview**: System boundaries, key components, and interactions 3. **Design Decisions**: Rationale behind architectural choices 4. **Core Components**: Deep dive into each major module/service 5. **Data Models**: Schema design and data flow documentation 6. **Integration Points**: APIs, events, and external dependencies 7. **Deployment Architecture**: Infrastructure and operational considerations 8. **Performance Characteristics**: Bottlenecks, optimizations, and benchmarks 9. **Security Model**: Authentication, authorization, and data protection 10. **Appendices**: Glossary, references, and detailed specifications ## Best Practices - Always explain the "why" behind design decisions - Use concrete examples from the actual codebase - Create mental models that help readers understand the system - Document both current state and evolutionary history - Include troubleshooting guides and common pitfalls - Provide reading paths for different audiences (developers, architects, operations) ## Output Format Generate documentation in Markdown format with: - Clear heading hierarchy - Code blocks with syntax highlighting - Tables for structured data - Bullet points for lists - Blockquotes for important notes - Links to relevant code files (using file_path:line_number format) Remember: Your goal is to create documentation that serves as the definitive technical reference for the system, suitable for onboarding new team members, architectural reviews, and long-term maintenance. The download contains docs-architect.md . Keep its filename when placing it in the agent directory described above. By **wshobson**. Exact upstream source ↗ · [Licence](/resources/agents/wshobson-docs-architect/LICENSE.txt) · [Attribution](/resources/agents/wshobson-docs-architect/ATTRIBUTION.txt) SHA-256 435520e293fa4b997a39b7455d7131351598f4cbaf4813135ab5182e6554005b Read the applicable licence MIT License Copyright (c) 2024 Seth Hobson Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 04 / FOLLOW THE EVIDENCE ## The source trail. Our notes are separate from the original resource. Check upstream before adopting a new version. - documentation-generation-docs-architect — complete upstream definition ↗ Checked 2026-09-21 https://github.com/wshobson/agents/blob/4236bb91f8395b0435f1d8b8baf9e8e4c69a8620/plugins/documentation-generation/agents/docs-architect.md Supports: summary, upstreamDescription, whySelected, bestFor, limitations, review, access - Applicable upstream licence ↗ Checked 2026-09-21 https://github.com/wshobson/agents/blob/4236bb91f8395b0435f1d8b8baf9e8e4c69a8620/LICENSE Supports: license, artifact - Repository installation and scope guidance ↗ Checked 2026-09-21 https://github.com/wshobson/agents/blob/4236bb91f8395b0435f1d8b8baf9e8e4c69a8620/README.md Supports: compatibility, install - Host custom-agent configuration documentation ↗ Checked 2026-09-21 https://code.claude.com/docs/en/sub-agents.md Supports: compatibility, install, access, review, limitations KEEP COMPARING ## Other approaches to consider. Related by category or shared topics. These are alternatives to inspect, not a measured quality order. [### Comment Analyzer ↗ Checks comments and docstrings against implementation behavior, then separates factual errors, worthwhile improvements and obsolete explanations.](/agents/anthropic-comment-analyzer/)[### Readme Generator ↗ Builds a repository README from inspected manifests, scripts, tests and entry points, explicitly rejecting guessed commands, APIs and configuration.](/agents/voltagent-readme-generator/)[### Se: Tech Writer ↗ Turns code and design context into audience-specific documentation, tutorials, articles and decision records using explicit structures and a verification checklist.](/agents/github-se-technical-writer/) [AI Tools ↗](/tools/)[Skills ↗](/skills/)[Agents ↗](/agents/)[MCP Servers ↗](/mcp-servers/)