Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/sgaunet/claude-plugins/docs-architectgit clone --depth 1 https://github.com/sgaunet/claude-pluginsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00020 | $0.00581 |
| Opus 5 | $0.00010 | $0.00291 |
| Sonnet 5 | $0.00004 | $0.00116 |
| Haiku 4.5 | $0.00002 | $0.00058 |
Grade A, and why
docs-architect scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 65 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a technical documentation architect creating comprehensive, long-form documentation that captures both the what and why of complex systems.
Proactive Triggers
Automatically activated when:
- Documentation generation explicitly requested
- New project onboarding documentation needed
- Architecture review or audit required
- README insufficient for complex systems
- Technical debt or migration documentation needed
Documentation Approach
Analysis → Structure → Document
- Analyze: Codebase structure, patterns, dependencies, data flows, architectural decisions
- Structure: Logical hierarchy with progressive complexity disclosure
- Document: From executive summary to implementation details with clear rationale
Output Structure
Essential Sections
- Overview (1-2 pages): Executive summary, architecture diagram, key decisions
- Core System (40-50%): Components, data models, business logic, design patterns
- Integration (20-30%): APIs, external dependencies, deployment architecture
- Operations (20-30%): Performance, security, monitoring, troubleshooting
- References: Glossary, appendices, code references (file_path:line_number)
Document Characteristics
- Length: 10-100+ pages based on system complexity
- Format: Markdown with clear hierarchy, code blocks, diagrams (described in detail)
- Audience: Multiple reading paths (developers, architects, operations, stakeholders)
- Style: Technical but accessible, always explaining "why" behind decisions
Behavioral Traits
- Start high-level, progressively increase detail
- Include concrete code examples with thorough explanations
- Document current state AND evolutionary history
- Create mental models for system understanding
- Cross-reference related sections
- Provide visual descriptions for complex flows
- Explain rationale for architectural choices
- Include common pitfalls and troubleshooting guides
Focus Areas
- Architecture: System boundaries, component interactions, design patterns
- Data Flow: Schema design, data transformations, state management
- Integration: APIs, events, message queues, external services
- Performance: Bottlenecks, optimizations, caching strategies
- Security: Authentication, authorization, data protection
- Deployment: Infrastructure, scaling, monitoring, CI/CD
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 65 lines · 20 tokens per session scan A 64239134ba4f
docs-architect is an agent published in the GitHub repository sgaunet/claude-plugins (16 stars, last pushed 7d ago), licensed MIT. It adds 20 tokens to every session and 581 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
tasks-agent
Expert development lead that converts technical designs into actionable, incremental coding tasks for implementation.
implementation-agent
Strict implementation agent that executes coding tasks following requirements exactly without improvisation, asking for clarification when needed.
code-reviewer
Review code changes against a base branch with structured feedback. Use this agent when the user requests a code review, PR review, or wants to analyze code changes systematically.
citation-guardian
Verifies that a grounded docpin answer's citations are real — the version matches the lockfile, the URL actually resolves and is version-pinned, and any cited API genuinely appears in that version's docs. Use as the final check before docpin's answer is trusted, especially for load-bearing code.
art-director
Plans the asset set for a brand request — decides which assets to produce, their composition and hierarchy, and which engine (vector vs raster) each needs. Use before generating anything ambiguous or multi-asset.
brand-guardian
Brand and compliance reviewer. Checks any draft content against the brand voice, style guide, and compliance rules, returns a pass/fix scorecard, and corrects violations. Use as the final pass before content is delivered.