diagram

스타14

포크4

업데이트2026년 6월 4일 17:07

Create or update a diagram. Picks mermaid vs drawio per rules/diagrams.md, writes the source file, previews via MCP. Use when the user says 'diagram', '/diagram', or asks for a flowchart/architecture/sequence/state diagram.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

domengabrovsek

domengabrovsek/claude

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Step 1 - Pick the format

why-not-mechanizable: skill workflow guidance; each step requires understanding the surrounding context (repo, task shape, prior state).

Read rules/diagrams.md if uncertain. Default to mermaid unless one of these triggers fires - then use drawio:

Custom shapes, icons, or cloud provider symbols requested (review-time: see section note)
Precise grid / column layout (network topology, rack diagrams) (review-time: see section note)
More than 2 swimlanes, or nested swimlanes (review-time: see section note)
Multi-layer architecture (stacked data/control planes) (review-time: see section note)
Color or styling carries semantic weight that mermaid cannot express (review-time: see section note)
The user explicitly says "drawio" or "complex" (review-time: see section note)

If the diagram is borderline, ask the user before committing to drawio.

Step 2 - Locate the doc

Identify the doc this diagram belongs to. If docs/ does not exist, ask the user where to put it. (review-time: see section note)
Slug the topic from $ARGUMENTS or the parent doc's filename. (review-time: see section note)

Step 3 - Mermaid path

Write the mermaid source inline in the target doc using ```mermaid fenced blocks (one block per diagram). (review-time: see section note)
Match diagram type to purpose: flowchart / sequenceDiagram / stateDiagram-v2 / erDiagram / classDiagram / gitGraph / journey. (review-time: see section note)
Keep node labels short. Long descriptions go in adjacent prose. (review-time: see section note)
Verify with mcp__drawio__open_drawio_mermaid if you want a quick render check (optional). (review-time: see section note)
Commit the doc. (review-time: see section note)

Step 4 - Drawio path

Generate drawio XML for the diagram. Use mcp__drawio__open_drawio_xml reference (in the tool description) for shape catalogue, edge routing, swimlanes, containers. (review-time: see section note)
Write the source to docs/diagrams/<slug>.drawio. (review-time: see section note)
Call mcp__drawio__open_drawio_xml with the XML content - opens in the browser editor for the user to review and export PNG. (review-time: see section note)
Instruct the user: File > Export As > PNG > save to docs/diagrams/<slug>.png. They commit both files. (review-time: see section note)

In the consuming doc, embed: (review-time: see section note)

![<topic>](diagrams/<slug>.png)
*Source: [`<slug>.drawio`](diagrams/<slug>.drawio)*

Step 5 - Drift / update

If updating an existing diagram:

For mermaid: edit the inline block, keep the same diagram type unless the change requires a different one. (review-time: see section note)
For drawio: edit the .drawio source, re-open via MCP, re-export PNG, replace both files. Same commit. (review-time: see section note)

Anti-patterns

Do not generate ASCII art instead of a real diagram. (review-time: see section note)
Do not write more than one mermaid block per doc unless the doc is explicitly an architecture overview. (review-time: see section note)
Do not commit a .drawio file without its .png (GitHub reviewers need the preview). (review-time: see section note)
Do not ship a .png without its .drawio source (next maintainer needs to edit it). (review-time: see section note)
Do not invent layout coordinates manually for drawio - rely on its auto-layout. Set node ids, labels, edges, lanes; let drawio route. (review-time: see section note)

이 저장소의 다른 Skills

같은 저장소

prune

domengabrovsek/claude

Code review focused exclusively on over-engineering. Finds what to delete: reinvented standard library, unneeded dependencies, speculative abstractions, dead flexibility. One line per finding: location, what to cut, what replaces it. Use when the user says "review for over-engineering", "is this over-engineered", or invokes /prune. Complements correctness-focused review; this one only hunts complexity.

2026-07-0714

build

domengabrovsek/claude

Implement code incrementally with quality gates. Use when the user says 'build', 'implement', or when starting the implementation phase of an approved plan.

2026-07-0214

grill-with-docs

domengabrovsek/claude

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.

2026-07-0214

debug

domengabrovsek/claude

Structured production-incident investigation. Forces evidence-first hypothesis ranking before any code change. Use when given an error message, Sentry alert, failing log, or 'investigate <X>' request.

2026-06-1114

sentry-issue

domengabrovsek/claude

Fetch and digest Sentry issue data (issue summary, tags, stack trace, breadcrumbs, latest event) by short ID, numeric issue ID, or sentry.io URL. Org-agnostic - works for any Sentry org the local token can access. Use when the user mentions a Sentry issue or short ID (e.g. MY-PROJECT-4X2), pastes a sentry.io issue URL, or asks to investigate/debug a Sentry error.

2026-06-1114

document

domengabrovsek/claude

Create or refresh technical engineering docs in the current repo's /docs/ tree. Diataxis layout, mermaid diagrams, ADR support, drift audit. Use when the user says 'write docs', 'document this', 'audit the docs', or '/document'.

2026-06-0414

name	diagram
description	Create or update a diagram. Picks mermaid vs drawio per rules/diagrams.md, writes the source file, previews via MCP. Use when the user says 'diagram', '/diagram', or asks for a flowchart/architecture/sequence/state diagram.

Create or update the diagram for: $ARGUMENTS

Step 1 - Pick the format

why-not-mechanizable: skill workflow guidance; each step requires understanding the surrounding context (repo, task shape, prior state).

Read rules/diagrams.md if uncertain. Default to mermaid unless one of these triggers fires - then use drawio:

Custom shapes, icons, or cloud provider symbols requested (review-time: see section note)
Precise grid / column layout (network topology, rack diagrams) (review-time: see section note)
More than 2 swimlanes, or nested swimlanes (review-time: see section note)
Multi-layer architecture (stacked data/control planes) (review-time: see section note)
Color or styling carries semantic weight that mermaid cannot express (review-time: see section note)
The user explicitly says "drawio" or "complex" (review-time: see section note)

If the diagram is borderline, ask the user before committing to drawio.

Step 2 - Locate the doc

Identify the doc this diagram belongs to. If docs/ does not exist, ask the user where to put it. (review-time: see section note)
Slug the topic from $ARGUMENTS or the parent doc's filename. (review-time: see section note)

Step 3 - Mermaid path

Write the mermaid source inline in the target doc using ```mermaid fenced blocks (one block per diagram). (review-time: see section note)
Match diagram type to purpose: flowchart / sequenceDiagram / stateDiagram-v2 / erDiagram / classDiagram / gitGraph / journey. (review-time: see section note)
Keep node labels short. Long descriptions go in adjacent prose. (review-time: see section note)
Verify with mcp__drawio__open_drawio_mermaid if you want a quick render check (optional). (review-time: see section note)
Commit the doc. (review-time: see section note)

Step 4 - Drawio path

Generate drawio XML for the diagram. Use mcp__drawio__open_drawio_xml reference (in the tool description) for shape catalogue, edge routing, swimlanes, containers. (review-time: see section note)
Write the source to docs/diagrams/<slug>.drawio. (review-time: see section note)
Call mcp__drawio__open_drawio_xml with the XML content - opens in the browser editor for the user to review and export PNG. (review-time: see section note)
Instruct the user: File > Export As > PNG > save to docs/diagrams/<slug>.png. They commit both files. (review-time: see section note)

In the consuming doc, embed: (review-time: see section note)

![<topic>](diagrams/<slug>.png)
*Source: [`<slug>.drawio`](diagrams/<slug>.drawio)*

Step 5 - Drift / update

If updating an existing diagram:

For mermaid: edit the inline block, keep the same diagram type unless the change requires a different one. (review-time: see section note)
For drawio: edit the .drawio source, re-open via MCP, re-export PNG, replace both files. Same commit. (review-time: see section note)

Anti-patterns

Do not generate ASCII art instead of a real diagram. (review-time: see section note)
Do not write more than one mermaid block per doc unless the doc is explicitly an architecture overview. (review-time: see section note)
Do not commit a .drawio file without its .png (GitHub reviewers need the preview). (review-time: see section note)
Do not ship a .png without its .drawio source (next maintainer needs to edit it). (review-time: see section note)
Do not invent layout coordinates manually for drawio - rely on its auto-layout. Set node ids, labels, edges, lanes; let drawio route. (review-time: see section note)