Code to Mindmap

Use when (1) user pastes source code and wants to visualize it as a mind map, node graph, or tree diagram. (2) user says "show this as a mindmap", "draw the architecture", "make a flowchart of this code", or "visualize the structure". (3) user wants to understand an unfamiliar codebase by seeing its structure visually.

Core Position

This skill solves the specific problem of: code structure is hard to grasp from raw text — a visual map reveals relationships, hierarchy, and architecture at a glance.

This skill IS NOT:

• A code documentation tool — it produces visual diagrams, not written docs
• A UML class diagram tool — use PlantUML for detailed class relationships
• A code formatter — it does not change source code

This skill IS activated ONLY when: source code + visualization intent are both present.

Modes

/code-to-mindmap

Default mode. Parses source code and outputs a Mermaid-compatible mindmap or graph.

When to use: User provides code and wants a visual structure diagram.

/code-to-mindmap/hierarchy

Outputs a tree showing file/folder hierarchy without analyzing imports.

When to use: User wants to see project structure, not code relationships.

Execution Steps

Step 1 — Parse the Code Structure

1. Receive source code (single file, snippet, or multi-file content)
2. Detect language and framework:
   • Python: parse def, class, import, async def
   • JavaScript/TypeScript: parse function, const, class, import, export
   • Go: parse func, type, struct, package
   • General: detect class definitions, function definitions, module-level declarations
3. Identify:
   • Entry points (main, app, index)
   • Class/struct names and their methods
   • Top-level functions
   • Cross-file dependencies (import/require statements)
4. Build a hierarchical tree: modules → classes → methods → nested logic

Step 2 — Select Diagram Type

Step 3 — Generate Diagram

Output as Mermaid mindmap or graph LR format:

mindmap
  root((Code))
    ClassName
      method_one
      method_two
        nested_helper
    another_class
      handler

For large codebases (>20 nodes), summarize: show top-level structure only, note that deeper nodes exist.

Step 4 — Validate

• All detected classes/functions appear as nodes
• Root/entry point is clearly marked as the center
• No fabricated nodes (only from actual code)
• Mermaid syntax is valid and renderable

Mandatory Rules

Do not

• Do not make up method names, class names, or relationships not in the code
• Do not render >30 nodes in a single diagram (split into sub-diagrams)
• Do not replace source code comments with diagram comments
• Do not activate for pseudo-code or algorithm descriptions without actual code

Do

• Use the language's actual syntax to detect structure
• Label nodes with function signatures for disambiguation (e.g., calculate_sum(nums: list) -> int)
• Mark external library calls differently from project-internal calls
• Preserve the root entry point as the diagram center

Quality Bar

A good output:

• Every class and function in the provided code appears as a labeled node
• Relationships (calls, imports, inheritance) are represented as edges
• The diagram is valid Mermaid and renders correctly
• Entry points are visually distinct (center or top)

A bad output:

• Adds classes or methods not in the source code
• Renders >30 nodes making the diagram unreadable
• Misrepresents call direction (A calls B shown as B calls A)
• Output is not valid Mermaid syntax

Good vs. Bad Examples

References

• references/ — Mermaid mindmap syntax guide, language-specific parsing patterns, code architecture patterns
• scripts/render.py — Render Mermaid diagram to PNG/SVG