diagram-generation

AI Community

Repo stars 19,426
Author repo opik

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Generate self-contained HTML architecture diagrams. Use when creating visual diagrams for PRs, task plans, or architectural expl…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “When to Use”, “Output”, “How to Generate”, “Required Sections (pick what applies)”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name diagram-generation directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “When to Use / Output / How to Generate” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Diagram Generation

Generate self-contained HTML diagrams that visualize code changes, data flows, and architecture decisions.

When to Use

Visualizing PR changes for code review
Explaining architectural decisions
Documenting data/request flows
Illustrating before/after comparisons

Output

Self-contained HTML file at {MAIN_REPO_ROOT}/diagrams/opik-{TICKET_NUMBER}-diagram.html — always resolved against the main repo root (via git rev-parse --git-common-dir), even when the session runs inside a worktree, so the file outlives the worktree
Includes "Copy as image" button for sharing in Slack, Jira, PR descriptions
Dark GitHub theme, semantic color coding, responsive layout

How to Generate

Follow the style guide in style-guide.md and use the HTML template in template.md.

Required Sections (pick what applies)

Request / Data Flow — how data moves through layers
Why This Approach — problem vs solution comparison
Files Changed by Layer — grid of affected files grouped by component
Key Design Decisions — numbered guards, trade-offs, or constraints

Section Selection

Bug fix: Focus on before/after flow, root cause, safety guards
New feature: Focus on data flow, architecture, files changed
Refactor: Focus on before/after architecture, files changed
Cross-component: Show all layers with connecting flows

Reference Files

style-guide.md — Semantic colors, box themes, section labels, flow patterns, architecture trees
template.md — Base HTML structure, copy-as-image script, section recipes

Common Gotchas

SRI hash on CDN scripts: The html2canvas <script> tag must include integrity and crossorigin attributes — see template.md for the current hash
Absolute paths for Playwright screenshots: Playwright saves relative to its own CWD, not the repo root — always use absolute paths when calling browser_take_screenshot
Max 4 sections: More than 4 sections makes diagrams too tall for screenshots and hard to scan visually
No raw diff content: Diagrams show high-level summaries (component names, file names, flow descriptions) — never embed verbatim diff hunks or Jira comments
toBlob can return null: The Canvas toBlob call in the copy-as-image script needs a null check — see template.md

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: AI
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @comet-ml · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Write / modify
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview diagram-generation.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# Diagram Generation

Generate self-contained HTML diagrams that visualize code changes, data flows, and architecture decisions.

## When to Use

- Visualizing PR changes for code review
- Explaining architectural decisions
- Documenting data/request flows
- Illustrating before/after comparisons

## Output

- Self-contained HTML file at `{MAIN_REPO_ROOT}/diagrams/opik-{TICKET_NUMBER}-diagram.html` — always resolved against the main repo root (via `git rev-parse --git-common-dir`), even when the session runs inside a worktree, so the file outlives the worktree
- Includes "Copy as image" button for sharing in Slack, Jira, PR descriptions
- Dark GitHub theme, semantic color coding, responsive layout

## How to Generate

Follow the style guide in `style-guide.md` and use the HTML template in `template.md`.

### Required Sections (pick what applies)

1. **Request / Data Flow** — how data moves through layers
2. **Why This Approach** — problem vs solution comparison
3. **Files Changed by Layer** — grid of affected files grouped by component
4. **Key Design Decisions** — numbered guards, trade-offs, or constraints

### Section Selection

- **Bug fix**: Focus on before/after flow, root cause, safety guards
- **New feature**: Focus on data flow, architecture, files changed
- **Refactor**: Focus on before/after architecture, files changed
- **Cross-component**: Show all layers with connecting flows

## Reference Files

- [style-guide.md](style-guide.md) — Semantic colors, box themes, section labels, flow patterns, architecture trees
- [template.md](template.md) — Base HTML structure, copy-as-image script, section recipes

## Common Gotchas

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> When to Use → Output → How to Generate → Required Sections (pick what applies) → Section Selection → Reference Files
terms    -> Request / Data Flow · Why This Approach · Files Changed by Layer · Key Design Decisions · Bug fix · New feature · Refactor · Cross-component
files/cmd -> {MAINREPOROOT}/diagrams/opik-{TICKETNUMBER}-diagram.html · git rev-parse --git-common-dir · style-guide.md · template.md · <script> · integrity · crossorigin · browsertakescreenshot
body sha256 -> 30b25aeb4e88