home / skills / openclaw / skills / miro-workshop-assistant

miro-workshop-assistant skill

/skills/simoneferrario/miro-workshop-assistant

This skill converts workshop notes into a structured Miro diagram with frames, stickies, and connectors, ensuring idempotency and safe undo.

npx playbooks add skill openclaw/skills --skill miro-workshop-assistant

Review the files below or copy the command above to add this skill to your agents.

Files (6)
SKILL.md
6.8 KB
---
name: workshop-miro
description: Workshop photos/notes -> an editable Miro diagram (real FRAMES as containers + stickies + connectors) with idempotent dedupe, rollback, undo and change commands, using the local script miro-push.mjs and env vars.
---

# Workshop → Miro (Top Mode vNext)

## Goal
Produce a workshop output on Miro that is:
- readable as a diagram (not “scattered post-its”)
- easy to edit (real containers)
- idempotent (no duplicates)
- correctable (undo / delete / update)

## Security (mandatory)
- Never print MIRO_ACCESS_TOKEN
- Use only env vars: MIRO_ACCESS_TOKEN and MIRO_BOARD_ID
- Never use browser cookies/session tokens

## Key rule: a container = a FRAME (not a shape)
A “workshop container” must be a FRAME when:
- there is a large rectangle/square with a clear title (e.g., “Easy vision”, “Milestone”, “VMS”, “Data Hub”, “Vico Insider”)
- or there is a swimlane/column with a title
- or a box is clearly grouping multiple elements (stickies or sub-boxes)

Do NOT create a frame if:
- it’s just blank space without a title
- it’s only a decorative border without grouping meaning

## HARD REQUIREMENT (do not violate)
- You MUST create frames[] when the board contains categories/areas.
- You MUST assign a non-null frameId to each sticky (except explicit "outside notes").
- If frames[] is empty OR if >10% stickies have frameId=null:
  - DO NOT run the push command.
  - Regenerate the structure (max 2 attempts).

## Quality Gate — Container sanity check (mandatory)
If the image contains >=2 titled containers:
- frames.length MUST be >= 2
- at least 95% of stickies MUST have a non-null frameId
If not satisfied:
- DO NOT push
- Regenerate structure (max 2 attempts)

## Mandatory planning (do not print)
Before generating JSON and before running DIRECT PUSH:
1) Identify candidate FRAMES:
   - any large rectangle with a title
   - any area labeled on the side or centered above/below
2) Assign every sticky to a candidate frame.
3) If a sticky is ambiguous, add a warning and assign it to the closest/most plausible frame.
4) Only after that, generate the final JSON.

## Quality Gate (mandatory)
Before executing `node ... apply`:
- At least 1 frame must exist.
- At least 90% of stickies must have a non-null frameId.
- No frame should be “giant” if the image clearly contains multiple distinct areas.
- If the gate fails, DO NOT push: regenerate the structure (max 2 attempts).

## Dedup / Idempotency (mandatory)
- Every push must include a STABLE `meta.sessionKey` for the same diagram/topic (e.g., "easy-vision-workshop").
- Every push must include a unique `meta.runId` (timestamp).
- If the sessionKey is the same:
  - first remove the previous run (automatic undo)
  - then apply the new one
This prevents duplicates and repeated runs.

## Operating modes
### A) DIRECT PUSH (default if the user asks)
1) Generate a Miro-ready JSON (schema below) including:
   - meta.sessionKey (stable)
   - meta.runId (unique)
2) Save the JSON to:
   - `...\workshop-miro\_out\miro-ready-YYYYMMDD-HHMMSS.json`
3) Execute:
   - `node ...\miro-push.mjs apply <PATH_JSON>`
4) Reply with:
   - frames created: N
   - stickies created: N
   - connectors created: N
   - sessionKey + runId
   - warnings (if any)

### B) CORRECTIONS (when the user wants changes)
- UNDO (per session): `node ...\miro-push.mjs undo <sessionKey>`
- If the user says “redo it better / wrong category / move things”:
  - regenerate a corrected JSON with the same sessionKey
  - run APPLY again (it replaces the previous run)

> Note: fine-grained edits (delete/update a single sticky) are a next step if the script supports them.
> Otherwise, recommended: full regeneration with the same sessionKey (cleaner and usually faster).

## Smart layout rules
- Inside each frame:
  - left: inputs/sources
  - center: processing / API / platforms
  - right: outputs/UI/external integrations
- Spacing guideline: x += 420, y += 260
- If there is a long arrow crossing the whole diagram:
  - prefer 2 shorter connectors via an intermediate node (e.g., sticky “API” or “Integration”) if it improves readability

## Connector / relationship rules
Create a connector when:
- you see an arrow/line on the whiteboard
- or the text implies a flow: "API", "sensoren", "data", "->", "integration"
- connector label: use the word that describes the flow (e.g., “API”, “Sensoren”, “Data”, “Milestone”)

Default connector shape: "elbowed" (more readable for architecture diagrams).

## Anti-overlap rules (clean arrows)
Goal: avoid connectors crossing over stickies/notes.

- Use default connector shape = "elbowed".
- Always keep a free “routing lane”:
  - Do not place stickies close to frame borders.
  - Minimum inner frame padding: 160px.
- If a connector would be long or would cross a cluster:
  - create one or more “router nodes” (gray sticky with "." or empty text) placed outside clusters
  - split the connection into segments: A -> R1 -> R2 -> B
- For connections between different frames:
  - use a router node near the right border of the source frame
  - and a router node near the left border of the target frame

## JSON Output (FRAME-based)
{
  "meta": {
    "title": "string",
    "source": "photo|notes",
    "language": "it|de|en",
    "createdAt": "ISO-8601",
    "sessionKey": "string (stable)",
    "runId": "string (unique)"
  },
  "frames": [
    { "id": "F1", "title": "string", "x": 0, "y": 0, "w": 1400, "h": 900 }
  ],
  "stickies": [
    {
      "id": "S1",
      "frameId": "F1|null",
      "text": "string",
      "color": "light_yellow|light_blue|light_green|light_pink|gray",
      "x": 0,
      "y": 0,
      "unclear": false
    }
  ],
  "connectors": [
    { "from": "S1", "to": "S2", "label": "string|null", "shape": "straight|elbowed|curved" }
  ],
  "warnings": [ "string" ]
}

## HARD Containment Detection (mandatory)
A "container" is a large rectangle that encloses other notes and has a title (e.g. "Product A", "Product B").

You MUST do this:
1) Create one FRAME per container rectangle (title = the container title).
2) Assign EVERY inner note to that frame via frameId.
3) Only outer notes (explicitly outside all containers) may have frameId=null.

Containment must be interpreted literally:
- If an element is visually inside the container boundaries, it belongs to that container.
- If unsure, assign to the nearest container and add a warning.

## Quality checklist (before pushing)
- sessionKey present and stable
- no giant “Workshop” frame unless the photo truly shows a single big box
- every sticky belongs to the correct frame (category)
- no duplicate stickies with identical text inside the same frame
- connectors only where they make sense (not between every pair)

Overview

This skill converts workshop photos or notes into an editable Miro diagram composed of real FRAMES as containers, stickies, and connectors. It guarantees idempotent pushes with dedupe, rollback/undo, and change commands by driving the local miro-push.mjs script using MIRO_ACCESS_TOKEN and MIRO_BOARD_ID environment variables. The output is human-editable, visually organized, and safe: sensitive tokens are never printed. The workflow supports direct pushes and correction cycles with stable session keys and unique runIds.

How this skill works

The skill analyzes the input (photo or notes), detects titled container rectangles and groups individual notes into FRAME objects, then generates a Miro-ready JSON containing frames[], stickies[], connectors[], meta.sessionKey and meta.runId. It runs containment and quality gates (frame counts, stickies assignment thresholds) and only executes node .../miro-push.mjs apply if all mandatory checks pass. Pushes are idempotent: the same sessionKey triggers an automatic undo of the previous run before applying the new one; undo and redo operations are exposed via the same local script.

When to use it

  • Turn whiteboard photos or handwritten notes into a clean, editable Miro diagram.
  • You need reproducible, idempotent imports for post-workshop editing and collaboration.
  • When you require real frames (containers) rather than loose shapes for grouping and navigation.
  • To automate rollback or regenerate corrected diagrams without creating duplicates.
  • When you want connector-driven flows preserved (arrows/flow relationships).

Best practices

  • Provide high-resolution photos or clearly transcribed notes so container detection is reliable.
  • Always supply a stable, descriptive sessionKey (e.g., "easy-vision-workshop") to enable safe dedupe and undo.
  • Review warnings before applying pushes; regenerate structure up to two times if containment or assignment thresholds fail.
  • Do not include sensitive tokens in prompts; rely solely on MIRO_ACCESS_TOKEN and MIRO_BOARD_ID from env vars and never print them.
  • Prefer full regeneration with the same sessionKey for corrections unless fine-grained edits are supported by the push script.

Example use cases

  • Convert a post-mortem whiteboard into organized Miro frames with stickies grouped by topic and connectors for causal flows.
  • Import a product discovery workshop photo into Miro, preserving swimlanes as frames and mapping features to processing/outputs layout.
  • Iteratively refine a stakeholder mapping: push, get feedback, regenerate with same sessionKey to replace the previous diagram.
  • Backup multiple workshop sessions with stable sessionKeys and timestamped runIds for auditability and rollback.

FAQ

What environment variables are required?

MIRO_ACCESS_TOKEN and MIRO_BOARD_ID must be set; the skill never prints tokens and avoids browser sessions or cookies.

What if the quality gates fail?

The skill will not push. It regenerates the structure (up to two attempts) and returns warnings; manual review is recommended before a subsequent push.

How does idempotency work?

Every JSON includes a stable meta.sessionKey and a unique meta.runId. Applying with the same sessionKey first removes the prior run, preventing duplicates; runId provides traceability.