From aigent-skills
Generate polished HTML architecture documentation for any codebase. Use when the user asks to "document this codebase", "create architecture docs", "explain this project", "generate HTML docs", "create a deep dive", "help new engineers understand this", "write onboarding documentation", "document this for a junior", "create a getting started guide", "explain the architecture", "create developer docs", "review this codebase", "analyze the architecture", "what patterns does this project use", "how is this project structured", "explain this codebase in depth", "document the architecture", "create deep-dive documentation", "generate an HTML doc site for this repo", "add a section to the existing docs", "create presentation-friendly documentation", "write architecture guides", "generate noob docs", "explain a project for new team members", or wants durable reference material explaining how a project is designed.
How this skill is triggered — by the user, by Claude, or both
Slash command
/aigent-skills:docitThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Generate polished multi-page HTML documentation for any codebase. Adapts depth and
Generate polished multi-page HTML documentation for any codebase. Adapts depth and framing to the intended audience. Supports both fresh documentation passes and iterative extension of existing docs.
A multi-page HTML doc site (default) or single self-contained HTML page, covering:
Optional sections (off by default, enabled during clarification):
Ask the minimum questions needed before doing substantial work. Use sensible defaults so the user can say "just go" and get a reasonable result.
Audience — "Who will read these docs?"
Output location — "Where should I put the docs?"
docs/docit/ in the repo rootMode — "Is this a fresh documentation pass, or should I add to existing docs?"
Optional sections (offer as a list; all off by default):
Feature example (only ask if feature guide was selected):
If the user says "just go", skip the interview and use all defaults. If a feature guide is requested but no feature is specified, choose one after exploration.
Read the repo before writing anything. Run these in parallel:
package.json, go.mod, Cargo.toml,
pyproject.toml, pom.xml, build.gradle, mix.exs, composer.json, GemfileCLAUDE.md / AGENTS.md / CONTRIBUTING.md if present (first 100 lines)docs/, doc/, ADR/, or architecture/ directoriesgit log --stat --oneline -30 — coupling signals (which files change together)git log --all --oneline -20 — recent activity (what's being worked on)From this, determine:
Trigger when README is < ~20 lines or missing AND no docs directory exists:
"{project name}" architecture and "{project name}" designLabel all web-sourced findings with their source URL. Treat as Inferred. If web search yields nothing useful, note: "Analysis derived entirely from code structure."
See references/exploration-procedure.md for detailed file-reading strategies,
pattern recognition tables, and dependency categorization.
Launch 5 Explore agents in parallel. Adapt focus areas to the actual project — these categories are starting points, not rigid boxes.
If a feature guide was requested, instruct each agent to also note how their subsystem would be involved in implementing the chosen feature.
| Agent | Focus | What to find |
|---|---|---|
| 1. Entry & Boot | Main entry point, startup sequence | How the process starts; initialization order |
| 2. Transport / Input | HTTP handlers, CLI args, message queues, file watchers | Request/event lifecycle from outside world to internal processing |
| 3. Core Business Logic | Processing pipeline, domain models, key algorithms | The "heart" of the system — what it actually does |
| 4. Extension Points | Plugin system, middleware, hooks, event bus, module registration | How the system is extended without modifying core |
| 5. Shared Infrastructure | Types, config, logging, error handling, utilities | Cross-cutting concerns everything else depends on |
Each agent should report:
Tell each agent to be thorough and read full files where needed.
Identify the key abstractions that flow through the system.
If an LSP is available (test with a hover operation on any source file):
workspaceSymbol — map exported interfaces/types at module boundarieshover on key type names — full type signaturesdocumentSymbol on 3-5 critical files — complete symbol listgoToDefinition — trace type hierarchies for the 3-5 most important typesfindReferences — understand where key interfaces are implementedIf no LSP is available, use grep to find type/class/interface definitions.
Map:
Based on agent findings, read 10-20 critical files thoroughly:
Take notes on patterns, conventions, and design decisions.
Default: multi-page HTML doc site. Single self-contained page only if explicitly requested.
Write all output to the confirmed output directory.
| Page | Filename | Content |
|---|---|---|
| Landing | index.html | Project identity, elevator pitch, 10,000-foot view diagram |
| Architecture | architecture.html | Components, layers, dependency spine, key patterns, transferable principles |
| Components | components.html | Per-package/module deep dives, type relationships |
| Extensibility | extensibility.html | Plugin/extension model, registration flow, SDK interfaces |
| Surfaces | surfaces.html | API surfaces, integrations, delivery mechanisms, UI surfaces |
| Change Guide | changes.html | Decision flow for where different classes of changes belong |
Optional pages (generate only if selected in Phase 0):
| Page | Filename | When |
|---|---|---|
| Feature Guide | feature-guide.html | Feature implementation guide selected |
| Dev Commands | commands.html | Dev commands selected |
| Glossary | glossary.html | Glossary selected |
Include a shared styles.css in the same output directory.
Follow references/presentation-guidelines.md for detailed visual guidance. Defaults:
styles.css across all pages — no per-page styles except minor overridesPrefer embedded SVG so output stays self-contained and editable.
Every SVG must have an aria-label. Use a consistent shared visual style across all
diagrams (stroke weight, color palette, font family).
Good diagram candidates:
Every diagram must have a text explanation alongside it — diagrams are overviews, prose provides the detail.
Fact vs. Inference separation — clearly distinguish throughout all pages:
Language translation — if the codebase uses a language outside the assumed reader's background, map language-specific idioms to equivalents in a familiar language. Example: "This Elixir GenServer is analogous to a long-running service with an internal message queue in Java."
Neutral tone — describe architectural trade-offs factually (e.g., "event sourcing adds replay capability but increases write complexity") without judging whether a choice is good or bad.
Self-contained — the reader should not need external sources to understand the docs.
At the bottom of architecture.html, synthesize 3-7 general design principles derived
from this codebase. Each principle must be:
Present each as a callout card:
[Principle name] — [General statement of the principle] As seen here: [Specific component or pattern reference]
Aim for quality over quantity. Only include principles that are genuinely non-obvious.
If the startup sequence is non-trivial (initialization order matters, services are wired in specific steps), include on the architecture page:
On feature-guide.html, walk through implementing the chosen feature with no code —
only which files, classes, and methods to touch and why.
Structure:
For each file:
path/to/file.ext — modify | create
Why this file is involved: [1-2 sentences]
What needs to happen:
- ClassName.methodName() — [what should change and why, no code]
- AnotherClass — [new method or field to add and its purpose]
Before declaring documentation complete:
When the user asks to extend existing docs:
styles.css for new shared diagram styles rather than adding per-page stylesIf the existing documentation is inconsistent or poor quality, it is acceptable to refactor the structure while adding new content — but inform the user.
references/presentation-guidelines.md — Visual design and readability guidancereferences/exploration-procedure.md — Detailed discovery steps, file-reading
strategy, pattern recognition tables, dependency categorizationnpx claudepluginhub roaanv/aigent-skills --plugin aigent-skillsProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.