---
name: miro-architecture-board
description: Use when creating, redesigning, or maintaining an architecture, roadmap, implementation map, or system overview board in Miro.
---

<!-- markdownlint-disable -->

# Miro Architecture Board

Use this skill for architecture boards that need to explain a repository,
system, service, roadmap, operating model, or governance process.

## Board Contract

- Miro is the visual workspace, not the source of truth.
- Keep the canonical facts in repository docs, JSON blueprints, ADRs, specs,
  tests, and command output.
- The board should make the repo easier to discuss: where to start, what
  exists, what flows where, what is verified, and what decision remains.

## Recommended Frame Set

1. `0. Start Here` — reading order, board purpose, current status, authority
   rule.
2. `1. Workflow` — service blueprint or visible process flow.
3. `2. System Context` — actors, sources, core system, outputs.
4. `3. Authority` — source-of-truth boundaries and decision owners.
5. `4. Calculation/Data Flow` — how inputs become outputs.
6. `5. Governance Flow` — how gaps become decisions and records.
7. `6. Product Surfaces` — CLI, docs, dashboards, workbooks, future UI.
8. `7. Verification And Decisions` — tables for checks, risks, open decisions.
9. Optional appendix frames — compact diagrams, references, snapshots.

## Creation Workflow

1. Inspect the repository first. Prefer existing docs and source structure over
   invented architecture.
2. Draft a JSON or Markdown board blueprint before writing to Miro when the
   board is non-trivial.
3. Create frames and sparse cards with `layout_create`.
4. Add tables with `table_create` and `table_sync_rows` only in table frames.
5. Add compact diagrams only where connectors improve comprehension.
6. Verify the board and update the local blueprint/playbook with the rendered
   board URL and item counts.

## Content Rules

- A frame answers one question.
- A card states one concept, responsibility, risk, status, or decision.
- A table carries evidence, status, owner, or decision records.
- A diagram carries a small relationship set that must be visually followed.
- Long context belongs in a Miro doc or repo Markdown, not in shape bodies.

## Completion Criteria

- The board has a clear start frame.
- Workflows are visible and readable.
- Tables and diagrams are not overlapping dense card frames.
- The local repo has enough blueprint/documentation to recreate or audit the
  board.
- Verification results are reported to the user.