Product Architecture Diagrams
Turn PRDs, module lists, or messy meeting notes into layered product architecture diagrams you can present or export as HTML/SVG, Mermaid, or Figma-ready views.
Overview
product-architecture-diagrams is an agent skill most often used in Validate (also Build docs/pm, Launch distribution) that turns product inputs into classified, presentation-ready architecture diagrams.
Install
npx skills add https://github.com/shangbianai/product-architecture-diagrams --skill product-architecture-diagramsWhat is this skill?
- Classifies diagram type via references/diagram-types.md before drawing
- Applies methodology checklist for labels, relationships, and abstraction
- Defaults to colorful layered HTML/SVG charts with PNG/JPG export
- Produces Mermaid drafts, FigJam/Figma-ready layouts, and image-gen prompts
- Supports business-facing and engineering-facing architecture views from the same inputs
Adoption & trust: 1 installs on skills.sh; 3 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You have PRD fragments and module names but no shared visual model investors, partners, or engineers can align on.
Who is it for?
Founders scoping SaaS or platform products who need fast layered diagrams from unstructured notes or screenshots.
Skip if: Deep infra-as-code topology with live cloud inventory, or teams that only need ASCII one-liners with no visual artifact.
When should I use this skill?
Codex or your agent needs screenshot-like layered architecture charts, Mermaid drafts, FigJam/Figma-ready diagrams, or image prompts from product descriptions, PRDs, notes, screenshots, or module lists.
What do I get? / Deliverables
You receive correctly typed, labeled architecture diagrams with export paths (HTML/SVG, Mermaid, design-tool ready) matched to your audience.
- Classified architecture diagram (HTML/SVG with export)
- Optional Mermaid source
- FigJam/Figma-ready structure or image-generation prompt
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Validate scope is canonical because diagramming clarifies boundaries and capabilities before heavy Build work—when PRDs and stakeholder alignment matter most. Scope subphase fits defining product/system structure, capability maps, and abstraction level before implementation commitments.
Where it fits
Turn a rough module list into a capability map before you estimate the first build milestone.
Refresh application/data views after sprint planning changes service boundaries.
Check in Mermaid architecture drafts beside the PRD for agent onboarding.
Export PNG layered charts for a launch deck or partner briefing.
How it compares
Product-architecture generator with methodology—not a generic whiteboard MCP or automatic Terraform graph.
Common Questions / FAQ
Who is product-architecture-diagrams for?
Solo and indie builders preparing scope visuals for cofounders, clients, or agents before and during implementation.
When should I use product-architecture-diagrams?
At Validate scope when locking capabilities, during Build pm/docs when updating system charts, or at Launch distribution when you need investor- or partner-facing platform diagrams from existing PRD text.
Is product-architecture-diagrams safe to install?
Review the Security Audits panel on this page; the skill may read PRDs and generate files locally—avoid piping production secrets into prompts.
SKILL.md
READMESKILL.md - Product Architecture Diagrams
# Product Architecture Diagrams ## Purpose Turn unclear product/system material into a clear, presentation-ready product architecture diagram with the right level of abstraction, diagram type, labels, relationships, and visual style. Default to a colorful, layered, screenshot-like HTML/SVG architecture chart when the user wants a product architecture diagram they can use directly. Keep the methodology strong, but make the artifact visually useful. ## Core Workflow 1. Clarify the diagram job silently when possible: audience, purpose, product scope, known modules, technical depth, output format, and whether the user wants a business-facing or engineering-facing view. 2. Classify the requested diagram using [diagram-types.md](references/diagram-types.md). If the user provides screenshots, infer the nearest type from the layout. 3. Apply the methodology checklist in [methodology.md](references/methodology.md): business intent, user/experience layers, capability decomposition, architecture domains, platform support, data flow, governance/operations. 4. Choose an output style from [templates.md](references/templates.md): layered platform, domain relationship, swimlane, capability matrix, C4-style, value-flow, AI/data, or hybrid. 5. Produce the artifact directly. Prefer **HTML/SVG with PNG/JPG export** for screenshot-like architecture charts; use Mermaid only for quick logical drafts or when the user explicitly requests Mermaid; use Figma/FigJam tools when the user explicitly asks for Figma or an editable board. 6. If producing HTML, follow [html-export.md](references/html-export.md): include `保存为 PNG` and `保存为 JPG` buttons, export the chart area, and verify the buttons when tooling is available. 7. Include a brief reading guide: what each layer/domain means, what is upstream/downstream, what is support vs core capability, and what assumptions were made. ## Diagram Selection Use these defaults: - **Business/product explanation**: business architecture or value-flow map. - **PRD/module planning**: capability map plus layered product platform diagram. - **Engineering alignment**: layered application/technology/data diagram or C4 context/container view. - **Executive communication**: 3-5 architecture domains with sparse relationships. - **Screenshot-like layered boxes**: default to a colorful HTML layered product architecture diagram with presentation, gateway, application, business capability, support platform, model/data platform, technology platform, and monitoring/governance side rail. - **Unclear request**: provide one recommended diagram and optionally a second alternative if the material supports two valid views. ## Output Rules - Use Chinese labels when the user's material is Chinese. - Keep labels short: usually 2-8 Chinese characters or 1-4 English words. - Separate **core business capability**, **support capability**, **technical support**, **data capability**, **operations/governance**, and **external actors**. - For visual deliverables, use top-down horizontal layers, large colored layer bands, dashed architecture boundaries, and compact module boxes. This should resemble a presentation architecture screenshot, not a generic graph. - Show relationships with verbs on edges when useful: `细化`, `实现`, `支撑`, `协作`, `监控`, `消费`, `沉淀`. - Avoid mixing abstraction levels in one row. If unavoidable, group with clear boundari