Insight Diagram - Project Diagram Generation Skill

/architecture-diagram

Diagram Categories and List

Structural Diagrams — Static

Behavioral Diagrams — Dynamic

Example References

examples/

Example File List

examples/architecture.html

examples/class.html

examples/object.html

examples/component.html

examples/deployment.html

examples/flowchart.html

examples/usecase.html

examples/activity.html

examples/sequence.html

examples/communication.html

examples/dfd.html

examples/interaction-overview.html

examples/swimlane.html

Reference Rules

1. Read Before Generation: Before calling

   /architecture-diagram

   , use the Read tool to read the example file of the corresponding type, and extract:
   • SVG layout strategy (node spacing, grouping method, arrow direction)
   • Node style hierarchy (core node accent highlight, normal node solid border, optional node dashed border)
   • Annotation style (phase labels, Legend, card summary)
   • Information density (number of fields/properties displayed per node)
2. Structure Alignment: The generated diagram should maintain the same structural hierarchy as the example:
   • Top of page: Title + Subtitle + Diagram type description
   • Middle body: SVG diagram area (with light border container)
   • Bottom: Information summary card + Footer
3. Replace Content Instead of Copying: The business data (NovaShield risk control system) in the examples is a fictional reference case. When generating, replace it with the actual architecture information of the target project. Only reference the layout and style, do not copy business content.
4. Types Without Corresponding Examples: For the 5 diagram types without example files (package, composite-structure, profile, state-machine, timing), refer to the closest existing examples (e.g., package diagram refers to component diagram, state machine diagram refers to activity diagram) and follow the same visual language.

Execution Process

Step 1: Analyze the Codebase

1. Read the

   CLAUDE.md

   file in the project root directory (if exists) to get an overview of the project
2. Read

   CLAUDE.md

   files in each subdirectory (if exists) to get module details
3. Use Glob to scan the source code file structure (

   **/*.go

   ,

   **/*.py

   ,

   **/*.ts

   , etc.)
4. Read entry files (

   main.go

   ,

   app.py

   ,

   index.ts

   , etc.) to identify top-level components
5. Use Grep to search for key patterns: interface definitions, function signatures, dependency injection, configuration items

• Component List: Services, modules, external dependencies
• Relationship Diagram: Who calls whom, who depends on whom, data flow direction
• Core Types: Structs/classes, interfaces, enums
• Processes: Main business processes, exception handling processes
• Deployment: Processes, middleware, external services

Step 2: Select Diagrams

• System Architecture Diagram (architecture)
• Class Diagram (class)
• Object Diagram (object)
• Component Diagram (component)

• Deployment Diagram (deployment)
• Package Diagram (package)
• Composite Structure Diagram (composite-structure)
• Profile Diagram (profile)

• Flowchart (flowchart)
• Use Case Diagram (usecase)
• Activity Diagram (activity)
• State Machine Diagram (state-machine)

• Sequence Diagram (sequence)
• Communication Diagram (communication)
• Interaction Overview Diagram (interaction-overview)
• Swimlane Diagram (swimlane)
• Generate All (all)

Step 3: Generate One by One

1. Read Example First: Use the Read tool to read

   examples/<identifier>.html

   (e.g.,

   examples/architecture.html

   ) to extract layout patterns, node styles, and annotation methods
2. Based on the architecture information extracted in Step 1, organize the elements and relationships that should be displayed in the diagram
3. Call the

   /architecture-diagram

   skill, passing in the diagram type, title, content description, output path, must specify the light style
4. Save the output file to

   docs/<identifier>.html

   (e.g.,

   docs/architecture.html

   )
5. Briefly report the completion status

• Style: Must use the light Claude style (warm white background #FAF9F6, terracotta/sage/plum/rose color scheme, Inter font, white card container), consistent with the Anthropic Claude brand visual
• Anti-Overlap: All SVG elements (nodes, arrows, labels) must not overlap with each other. Specific practices:
  • Calculate the bounding box of each element to ensure no overlap
  • Draw arrows below nodes (draw arrows first then nodes in SVG)
  • Leave sufficient spacing between nodes (minimum 40px vertically, minimum 30px horizontally)
  • Text does not exceed the boundary of the node it belongs to; truncate or wrap long text
  • Place connection line labels at the offset of the line midpoint to avoid covering lines or nodes
  • If there are too many elements causing crowding, split into multiple sub-diagrams or reduce element size

Step 4: Report

• List of generated files
• Brief description of each diagram

Content Guidelines for Each Diagram

System Architecture Diagram (architecture) — Non-UML, Most Commonly Used

• Display top-level system components and their connection relationships
• Distinguish internal modules from external dependencies
• Mark core data flow directions

Class Diagram (class)

• Core types are class nodes (name + fields + methods)
• Inheritance, composition, dependency relationships
• Separation of interfaces and implementations
• Limit to 10-15 core types

Object Diagram (object)

• Select a typical runtime scenario
• Display object instances and their attribute values
• Link relationships between objects

Component Diagram (component)

• Each component is a node
• Arrows indicate dependency/call direction
• Mark interface names

Deployment Diagram (deployment)

• Physical nodes (servers, containers, Serverless)
• Middleware (message queues, caches, databases)
• External services (third-party APIs)
• Mark communication protocols

Package Diagram (package)

• Group by module/namespace
• Dependency relationships between packages
• Reflect layered architecture

Composite Structure Diagram (composite-structure)

• Internal structure of classes/components
• Parts and Connectors
• Ports and interfaces

Profile Diagram (profile)

• Custom Stereotypes
• Tagged Values extending metamodel definitions
• Domain-specific modeling constraints

Flowchart (flowchart) — Non-UML, Most Commonly Used

• Main process + key branches
• Failure/exception paths
• Clear start and end nodes

Use Case Diagram (usecase)

• Actors (people/external systems)
• Use case ellipses
• include/extend relationships

Activity Diagram (activity)

• Phases/steps are activity nodes
• Parallel branches use fork/join
• Decision points use diamonds

State Machine Diagram (state-machine)

• Key states of objects
• Events triggering state transitions
• Actions/guard conditions
• Initial and final states

Sequence Diagram (sequence)

• Actors are vertical lifelines
• Horizontal arrows are message calls
• Mark key return values
• Focus on 2-5 core interaction scenarios

Communication Diagram (communication)

• Components are nodes, messages are connections
• Mark message serial numbers
• Emphasize collaboration relationships rather than timing

Timing Diagram (timing)

• Time axis expands horizontally
• Time constraints for state changes
• Duration annotations

Interaction Overview Diagram (interaction-overview)

• Control flow nodes embed interaction fragments
• Display conditional branches and loops
• Macro overview of each interaction scenario

Swimlane Diagram (swimlane) — Variant of Activity Diagram

• Divide swimlanes by component/role
• Process steps are within corresponding swimlanes
• Cross-swimlane arrows indicate interactions