/architecture-diagram
Generate polished dark-themed architecture diagrams as standalone HTML files with inline SVG, semantic system grouping, and readable connection flows.
$ npx -y skills add CoWork-OS/CoWork-OS --skill architecture-diagram --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/architecture-diagram
Context preview
The summary Claude sees to decide when to auto-load this skill.
Generate polished dark-themed architecture diagrams as standalone HTML files with inline SVG, semantic system grouping, and readable connection flows.
SKILL.md
architecture-diagram.SKILL.mdname: architecture-diagram
description: "Generate polished dark-themed architecture diagrams as standalone HTML files with inline SVG, semantic system grouping, and readable connection flows."
Architecture Diagram
Purpose
Turn an architecture description or inspected codebase into a self-contained HTML diagram with inline SVG that opens directly in any modern browser.
Routing
- Use when: Use when the user asks to create a technical architecture diagram, infrastructure map, deployment topology, security/data-flow visual, or a polished system diagram artifact they can open in a browser.
- Do not use when: Do not use for text-only summaries, requests that require Mermaid or another explicit diagram format, or non-technical visual design tasks such as UI mockups and marketing graphics.
- Outputs: A standalone HTML architecture diagram plus supporting plan and summary artifacts.
- Success criteria: The final HTML is readable, self-contained, faithful to the described or inspected system, and free of obvious layout collisions.
Trigger Examples
Positive
- Create an architecture diagram for this SaaS stack and give me an HTML file.
- Turn this codebase into a polished cloud architecture diagram.
- Make a system topology diagram showing services, databases, queues, and auth.
- Use the architecture-diagram skill for this request.
Negative
- Summarize this architecture in bullets only.
- Draw this as Mermaid so I can paste it into Markdown.
- Design a landing page hero illustration for our product.
- Create a wireframe for the settings screen.
Parameters
| Name | Type | Required | Description | |---|---|---|---| | system_name | string | No | Short system or project name for the header | | diagram_brief | string | No | Structured architecture description | | diagram_type | select | No | Diagram emphasis: auto, system-overview, cloud-infrastructure, deployment, data-flow, security, network-topology, microservices | | output_path | string | No | Workspace-relative or absolute HTML output path |
Workflow Notes
- Start from `assets/template.html`. Do not freehand the outer page shell unless the request explicitly needs a very different composition.
- Read `references/full-guidance.md` before major layout work. It contains the spacing, legend placement, component taxonomy, and arrow-order rules that keep the diagrams readable.
- If the request is based on a local codebase, inspect the code first and derive components conservatively. Missing certainty is better than invented systems.
- Prefer a slightly taller or wider SVG over cramped placement. Expanding the `viewBox` is cheap; unreadable overlaps are not.
- When updating an existing diagram, preserve the established visual language unless the user asks for a redesign.
- In the final assistant response, include a standalone `::html{...}` directive that points at the generated HTML file so the main conversation view can render the diagram inline.
Reference Map
- `references/full-guidance.md`: design system, layout heuristics, and output checklist
- `assets/template.html`: starter HTML/SVG template to customize
- `LICENSE.txt`: upstream MIT license carried with the bundled port
Runtime Prompt
- Runtime prompt is defined directly in `../architecture-diagram.json`.
Read more
name: architecture-diagram description: "Generate polished dark-themed architecture diagrams as standalone HTML files with inline SVG, semantic system grouping, and readable connection flows."
Architecture Diagram
Purpose
Turn an architecture description or inspected codebase into a self-contained HTML diagram with inline SVG that opens directly in any modern browser.
Routing
- Use when: Use when the user asks to create a technical architecture diagram, infrastructure map, deployment topology, security/data-flow visual, or a polished system diagram artifact they can open in a browser.
- Do not use when: Do not use for text-only summaries, requests that require Mermaid or another explicit diagram format, or non-technical visual design tasks such as UI mockups and marketing graphics.
- Outputs: A standalone HTML architecture diagram plus supporting plan and summary artifacts.
- Success criteria: The final HTML is readable, self-contained, faithful to the described or inspected system, and free of obvious layout collisions.
Trigger Examples
Positive
- Create an architecture diagram for this SaaS stack and give me an HTML file.
- Turn this codebase into a polished cloud architecture diagram.
- Make a system topology diagram showing services, databases, queues, and auth.
- Use the architecture-diagram skill for this request.
Negative
- Summarize this architecture in bullets only.
- Draw this as Mermaid so I can paste it into Markdown.
- Design a landing page hero illustration for our product.
- Create a wireframe for the settings screen.
Parameters
| Name | Type | Required | Description | |---|---|---|---| | system_name | string | No | Short system or project name for the header | | diagram_brief | string | No | Structured architecture description | | diagram_type | select | No | Diagram emphasis: auto, system-overview, cloud-infrastructure, deployment, data-flow, security, network-topology, microservices | | output_path | string | No | Workspace-relative or absolute HTML output path |
Workflow Notes
- Start from `assets/template.html`. Do not freehand the outer page shell unless the request explicitly needs a very different composition.
- Read `references/full-guidance.md` before major layout work. It contains the spacing, legend placement, component taxonomy, and arrow-order rules that keep the diagrams readable.
- If the request is based on a local codebase, inspect the code first and derive components conservatively. Missing certainty is better than invented systems.
- Prefer a slightly taller or wider SVG over cramped placement. Expanding the `viewBox` is cheap; unreadable overlaps are not.
- When updating an existing diagram, preserve the established visual language unless the user asks for a redesign.
- In the final assistant response, include a standalone `::html{...}` directive that points at the generated HTML file so the main conversation view can render the diagram inline.
Reference Map
- `references/full-guidance.md`: design system, layout heuristics, and output checklist
- `assets/template.html`: starter HTML/SVG template to customize
- `LICENSE.txt`: upstream MIT license carried with the bundled port
Runtime Prompt
- Runtime prompt is defined directly in `../architecture-diagram.json`.
Local-first personal agentic OS and everything app for coding, knowledge work, web design, automations, and artifacts.
Repo: CoWork-OS/CoWork-OS
Other skills on cowork-os.
- /attack-path-analysis
Use when Codex is already in the attack-path-analysis phase of a security scan or the user explicitly asks to trace a security finding from source to sink and calibrate severity. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.
Open skill - /deep-security-scan
Use when the user asks for a deep, exhaustive, multi-pass, or variance-reducing repository-wide Codex Security scan. Run repeated independent repository-wide discovery passes with worker-specific threat models, semantically merge candidates, synthesize one canonical validation
Open skill - /finding-discovery
Use when Codex is already in the finding-discovery phase of a security scan or the user explicitly asks to discover candidate security findings in a repository or code change. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.
Open skill - /fix-finding
Use when the user explicitly asks to fix and verify a validated or plausible security finding. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.
Open skill - /security-diff-scan
Use when the user asks for a security review of a pull request, commit, branch diff, working-tree patch, or other Git-backed change set.
Open skill - /security-scan
Use when the user asks for a repository-wide or scoped-path security scan.
Open skill