ClaudeSuperPower
SubmitLog in

miro-code-explain-on-board

Skill

Use when the user wants to explain or visualize a codebase on a Miro board — produces a minimal, notation-correct set of architecture / structure / behavior diagrams (flowchart, UML class, UML sequence, ERD) plus a short companion document, grounded in real repo artifacts.

0Documents

Install

git clone https://github.com/miroapp/miro-ai.git ~/.claude/skills/miro-code-explain-on-board

What is miro-code-explain-on-board?

Use when the user wants to explain or visualize a codebase on a Miro board — produces a minimal, notation-correct set of architecture / structure / behavior diagrams (flowchart, UML class, UML sequence, ERD) plus a short companion document, grounded in real repo artifacts.

What this can do

Capabilities declared in this component's own frontmatter — not inferred.

Inherit all session tools

Declares no tool restrictions — inherits every session tool

~68 tokens of context used while enabled, before you invoke anything

Documentation

README · ~5 min read

Explain a Codebase on a Miro Board

You are a senior software engineer and visual architect. Produce high-quality, readable visual explanations of a codebase for engineering + product audiences on a Miro board.

Drive the workflow with the Miro MCP diagramming tools. Diagrams are created from Mermaid syntax via diagram_get_mermaid_instructions → diagram_create_mermaid (iterate with diagram_update_mermaid). The companion document is created with doc_create.

Artifact-first: cite repo symbols (files / modules / types) only when known. Do NOT invent. If something cannot be grounded, mark it UNKNOWN/VERIFY in notes rather than guessing.

0. Inputs

  1. Board URL. If missing, ask. Required to place artifacts. To target a specific frame, the URL may include ?moveToWidget=<frame_id> — diagrams then land inside that frame with frame-relative coordinates.
  2. What to explain. A repo, subsystem, or specific question. If unclear, ask for scope before analyzing.

Core diagramming principles

Apply these throughout. The full ruleset (R1–R9 notation/edge rules, H1–H4 budgets) lives in references/diagramming-principles.md — read it before drafting. The essentials:

  • Separate views, one question per diagram (R1/R2). Never mix abstraction levels in one diagram: system context, runtime architecture, module decomposition, static structure, runtime behavior, algorithms, UX flow are distinct. Split when dense.

Reviews

Log in to leave a review.

No reviews yet — be the first.

Explore related

Other things in this space — across every part of the ecosystem, not just skills.

Skillssimilar to this one

All skills →

obsidian-skills

Agent skills for Obsidian. Teach your agent to use Obsidian CLI and open formats including Markdown, Bases, JSON Canvas.

43.6K stars

plugin-structure

This skill should be used when the user asks to "create a plugin", "scaffold a plugin", "understand plugin structure", "organize plugin components", "set up plugin.json", "use ${CLAUDE_PLUGIN_ROOT}", "add commands/agents/skills/hooks", "configure auto-discovery", or needs guidance on plugin director

32.8K stars

command-development

This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs gu

32.8K stars