@eventmodelers/cli 0.0.39 → 1.0.1

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-storyboarding-events/SKILL.md

@@ -9,7 +9,9 @@ allowed-tools:
 
 # Storyboarding Events
 
-> **Before doing anything else**, invoke the `connect` skill to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Then invoke the `learn-eventmodelers-api` skill to load the full API reference. Do not proceed until both skills have been loaded.
+> **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until it has completed. Consult `learn-eventmodelers-api` only if you need to look up a specific endpoint or field this file doesn't cover — don't load it eagerly.
+
+Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect` skill) — the curl blocks below are the fallback for sessions without MCP connected.
 
 ## Interview Phase (Optional)
 
@@ -297,18 +299,27 @@ Solution: Every event includes timestamp
 
 ## Board Integration
 
-Before starting the analysis, read existing SCREEN nodes from the board to avoid designing screens that already exist:
+Before starting the analysis, read existing screen nodes from the board to avoid designing screens that already exist. Screens created by this skill default to HTML_SCREEN, but older boards may still have plain SCREEN (sketch) nodes — check both types:
+
+**Prefer MCP:**
+```
+mcp__eventmodelers__get_nodes { "boardId": "$BOARD_ID", "type": "HTML_SCREEN" }
+mcp__eventmodelers__get_nodes { "boardId": "$BOARD_ID", "type": "SCREEN" }
+```
 
+**Fallback (no MCP):**
 ```bash
+curl -s -H "x-token: $TOKEN" -H "x-board-id: $BOARD_ID" \
+  "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes?type=HTML_SCREEN"
 curl -s -H "x-token: $TOKEN" -H "x-board-id: $BOARD_ID" \
   "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes?type=SCREEN"
 ```
 
-After completing the screen analysis, use the `handle-comment` skill to post a QUESTION comment on any SCREEN node where data fields are unclear or missing sources are identified.
+After completing the screen analysis, use the `handle-comment` skill to post a QUESTION comment on any screen node where data fields are unclear or missing sources are identified.
 
-## Mandatory Field Definitions on SCREEN Nodes
+## Mandatory Field Definitions on Screen Nodes
 
-> **CRITICAL: Every SCREEN node MUST include `meta.fields` with a `mapping` on every field.** A screen without fields cannot show data lineage — it becomes impossible to verify that all displayed data has a source event or command.
+> **CRITICAL: Every screen node MUST include `meta.fields` with a `mapping` on every field.** A screen without fields cannot show data lineage — it becomes impossible to verify that all displayed data has a source event or command. This applies regardless of which content type the screen renders as (HTML_SCREEN by default, or SCREEN when a sketch was explicitly requested).
 
 There are two types of screens, and each type has a different `mapping` source:
 
@@ -337,15 +348,15 @@ A **view screen** displays data read from a Read Model. Its fields map to the re
 
 ```json
 {
-  "type": "SCREEN",
+  "type": "HTML_SCREEN",
   "title": "Reserve a Bike",
   "fields": [
-    {"name": "bikeId",      "type": "String", "example": "bike-17",               "mapping": "ReserveBike.bikeId"},
-    {"name": "stationId",   "type": "String", "example": "stn-03",                "mapping": "ReserveBike.stationId"},
-    {"name": "startTime",   "type": "Date",   "example": "2026-06-01T09:00:00Z",  "mapping": "ReserveBike.startTime"},
-    {"name": "endTime",     "type": "Date",   "example": "2026-06-01T17:00:00Z",  "mapping": "ReserveBike.endTime"},
-    {"name": "bikeCategory","type": "String", "example": "City Bike",             "mapping": "AvailableBikeView.category"},
-    {"name": "dailyRate",   "type": "Number", "example": "0.10",                  "mapping": "AvailableBikeView.ratePerMinute"}
+    {"name": "bikeId",      "type": "String",   "example": "bike-17",               "mapping": "ReserveBike.bikeId"},
+    {"name": "stationId",   "type": "String",   "example": "stn-03",                "mapping": "ReserveBike.stationId"},
+    {"name": "startTime",   "type": "DateTime", "example": "2026-06-01T09:00:00Z",  "mapping": "ReserveBike.startTime"},
+    {"name": "endTime",     "type": "DateTime", "example": "2026-06-01T17:00:00Z",  "mapping": "ReserveBike.endTime"},
+    {"name": "bikeCategory","type": "String",   "example": "City Bike",             "mapping": "AvailableBikeView.category"},
+    {"name": "dailyRate",   "type": "Decimal",  "example": "0.10",                  "mapping": "AvailableBikeView.ratePerMinute"}
   ]
 }
 ```
@@ -354,15 +365,15 @@ A **view screen** displays data read from a Read Model. Its fields map to the re
 
 ```json
 {
-  "type": "SCREEN",
+  "type": "HTML_SCREEN",
   "title": "Reservation Confirmed",
   "fields": [
-    {"name": "reservationId",  "type": "String", "example": "res-001",               "mapping": "ActiveReservationView.reservationId"},
-    {"name": "bikeName",       "type": "String", "example": "City Bike — Gazelle",   "mapping": "ActiveReservationView.bikeName"},
-    {"name": "stationName",    "type": "String", "example": "Central Park East",     "mapping": "ActiveReservationView.stationName"},
-    {"name": "startTime",      "type": "Date",   "example": "2026-06-01T09:00:00Z",  "mapping": "ActiveReservationView.startTime"},
-    {"name": "expiresAt",      "type": "Date",   "example": "2026-06-01T09:30:00Z",  "mapping": "ActiveReservationView.expiresAt"},
-    {"name": "estimatedCost",  "type": "Number", "example": "48.00",                 "mapping": "derived:durationHours × AvailableBikeView.ratePerMinute × 60"}
+    {"name": "reservationId",  "type": "String",   "example": "res-001",               "mapping": "ActiveReservationView.reservationId"},
+    {"name": "bikeName",       "type": "String",   "example": "City Bike — Gazelle",   "mapping": "ActiveReservationView.bikeName"},
+    {"name": "stationName",    "type": "String",   "example": "Central Park East",     "mapping": "ActiveReservationView.stationName"},
+    {"name": "startTime",      "type": "DateTime", "example": "2026-06-01T09:00:00Z",  "mapping": "ActiveReservationView.startTime"},
+    {"name": "expiresAt",      "type": "DateTime", "example": "2026-06-01T09:30:00Z",  "mapping": "ActiveReservationView.expiresAt"},
+    {"name": "estimatedCost",  "type": "Decimal",  "example": "48.00",                 "mapping": "derived:durationHours × AvailableBikeView.ratePerMinute × 60"}
   ]
 }
 ```
@@ -383,14 +394,22 @@ Every field must also set `"cardinality"` — use `"Single"` unless the field ge
 
 A screen that only has a title and no fields is an empty placeholder — place the fields before moving on.
 
-## Mandatory Sketch Rendering
+## Mandatory Screen Rendering
 
-Every SCREEN node requires a wireframe sketch. The correct order for every screen is:
+Every screen node requires rendered content. **HTML_SCREEN (via the `html-screen` rendering path below) is the default for every screen** — render a real HTML/CSS mockup, not a wireframe sketch. Only use the sketch path (plain SCREEN node, grid elements) when the user's request explicitly asked for a "sketch", "wireframe", or "low-fidelity mockup". The correct order for every screen is:
 
 **Step A — Compute the cell ID.** Screens go in the **actor lane** of their target column.
 
 1. Determine the target column (same column as the event/command, OR one column to the right of the read model).
-2. Fetch the chapter to find the actor row ID:
+2. Fetch the chapter to find the actor row ID.
+
+   **Prefer MCP:**
+   ```
+   mcp__eventmodelers__get_node { "boardId": "$BOARD_ID", "nodeId": "$CHAPTER_ID" }
+   # → meta.timelineData.rows — find the row where type === "actor"
+   ```
+
+   **Fallback (no MCP):**
    ```bash
    curl -s -H "x-token: $TOKEN" -H "x-board-id: $BOARD_ID" \
      "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/$CHAPTER_ID"
@@ -398,7 +417,59 @@ Every SCREEN node requires a wireframe sketch. The correct order for every scree
    ```
 3. `cellId = actorRow.id + "-" + columnId`
 
-**Step B — Create the SCREEN node with `cellId`** (`node:created`) — the node is immediately placed in the correct cell:
+**Step B (default) — Create the HTML_SCREEN node and render it in one atomic call.** Use `create_screen` with `contentType: "html"` — this creates the node, places it in `cellId`, and renders its pages together, so there is no window where the node exists without content:
+
+**Prefer MCP:**
+```
+mcp__eventmodelers__create_screen {
+  "boardId": "<BOARD_ID>",
+  "contentType": "html",
+  "nodeId": "<node-uuid>",
+  "chapterId": "<CHAPTER_ID>",
+  "cellId": "<actorRowId>-<columnId>",
+  "pages": ["<div>...</div>"],
+  "description": "<concise description of what this screen shows>"
+}
+```
+
+**Fallback (no MCP):**
+```bash
+curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/html-screen-nodes/<node-uuid>" \
+  -H "x-token: $TOKEN" -H "x-board-id: $BOARD_ID" -H "x-user-id: storyboarding-events" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "chapterId": "<CHAPTER_ID>",
+    "cellId": "<actorRowId>-<columnId>",
+    "pages": ["<div>...</div>"]
+  }'
+```
+
+Once the node is created, still set `meta.fields` on it (per "Mandatory Field Definitions" above) via `node:changed` — `create_screen`/the HTML endpoint owns page content, not the field-lineage metadata.
+
+Design the page(s) as real HTML/CSS, following the `html-screen` skill's guidance: write full-size markup (16px body text, generous padding — the canvas scales it down, don't shrink it yourself), one complete self-contained fragment per page (no `<html>`/`<head>`/`<body>` wrapper — the canvas adds those), no `<script>`/inline handlers (stripped server-side), and Bulma CSS classes (`title`, `button`, `is-primary`, `field`/`control`/`input`, etc. — remember heading size modifiers like `class="title is-1"`) since Bulma 0.9.4 is loaded by default. Every page MUST include real field labels matching the actual event/command fields this screen captures or displays, and at least one primary action (submit/confirm button) for command screens.
+
+> **CRITICAL: NEVER pass an empty `pages` array.** An empty pages array produces a blank placeholder and is always wrong. You MUST design and include actual page markup before calling the render API.
+
+**Step B (sketch path, explicit request only) — Create the SCREEN node with `cellId`** (`node:created`) — only when the user explicitly asked for a wireframe/sketch:
+
+**Prefer MCP:**
+```
+mcp__eventmodelers__submit_node_events {
+  "boardId": "<BOARD_ID>",
+  "events": [{
+    "id": "<event-uuid>",
+    "eventType": "node:created",
+    "nodeId": "<node-uuid>",
+    "boardId": "<BOARD_ID>",
+    "timestamp": 1234567890,
+    "chapterId": "<CHAPTER_ID>",
+    "cellId": "<actorRowId>-<columnId>",
+    "meta": {"type": "SCREEN", "title": "<Screen Title>", "fields": [...]}
+  }]
+}
+```
+
+**Fallback (no MCP):**
 ```bash
 curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/events" \
   -H "x-token: $TOKEN" -H "x-board-id: $BOARD_ID" -H "x-user-id: storyboarding-events" \
@@ -415,7 +486,7 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/events" \
   }]'
 ```
 
-**Step C — Render the wireframe sketch immediately** (`POST /images/$NODE_ID/sketch`).
+**Step C (sketch path only) — Render the wireframe sketch immediately** (`POST /images/$NODE_ID/sketch`).
 
 > **Do NOT call `drop` after using `cellId` in `node:created`.** The drop endpoint adds a second cell reference without removing the first, causing the node to appear in two columns simultaneously. `node:created + cellId` is the single placement step — render the sketch right after.
 
@@ -423,6 +494,22 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/events" \
 
 Call the sketch API between node creation and cell placement, with a fully designed elements array:
 
+**Prefer MCP:**
+```
+mcp__eventmodelers__render_screen {
+  "boardId": "$BOARD_ID",
+  "nodeId": "$NODE_ID",
+  "description": "<concise description of what this screen shows>",
+  "elements": [
+    {"type":"rectangle","gridX":0,"gridY":0,"gridWidth":50,"gridHeight":40,"fill":"white"},
+    {"type":"rectangle","gridX":0,"gridY":0,"gridWidth":50,"gridHeight":3,"fill":"violet"},
+    {"type":"headline","gridX":2,"gridY":1,"text":"Screen Title","fontSize":16,"fill":"white","gridWidth":46},
+    ...more elements...
+  ]
+}
+```
+
+**Fallback (no MCP):**
 ```bash
 curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/images/$NODE_ID/sketch" \
   -H "x-token: $TOKEN" -H "x-board-id: $BOARD_ID" -H "x-user-id: storyboarding-events" \
@@ -459,7 +546,7 @@ Every sketch MUST include at minimum:
 - Field labels that match the actual event/command fields this screen captures or displays
 - At least one primary action (submit button, confirm button, etc.) for command screens
 
-A screen node without a wireframe sketch is an empty placeholder. It must not be left unrendered.
+A screen node without rendered content (HTML pages by default, or a wireframe sketch on the explicit-request path) is an empty placeholder. It must not be left unrendered.
 
 ## Timeline Placement Rules
 
@@ -497,7 +584,7 @@ Human roles get SCREEN nodes. System actors and processors get AUTOMATION nodes.
 ❌ Wrong:   Member "My Loans" AND Librarian "Confirm Checkout" both in col 11
 ```
 
-If a second role also needs a screen related to the same event, insert a new column immediately after and place the second screen there. Use `POST /timelines/:tl/columns` with `{"index": N}` to insert at the correct position.
+If a second role also needs a screen related to the same event, insert a new column immediately after and place the second screen there. Prefer `mcp__eventmodelers__add_column { "boardId": "$BOARD_ID", "timelineId": "$CHAPTER_ID", "index": N }`; fallback (no MCP) is `POST /timelines/:tl/columns` with `{"index": N}` to insert at the correct position.
 
 ---
 
@@ -593,7 +680,7 @@ Failure produces: [Event]
 
 ## Quality Checklist
 
-- [ ] **Every screen has a rendered wireframe sketch** (sketch API returned HTTP 204 — no exceptions)
+- [ ] **Every screen has rendered content** — HTML pages by default (`create_screen`/`render_screen` with `contentType: "html"` returned success), or a wireframe sketch only when explicitly requested — no exceptions
 - [ ] **No column contains more than one SCREEN node** across all actor lanes
 - [ ] Every screen's wireframe shows real field labels matching the event/command fields
 - [ ] Every displayed field has a source event

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-translating-external-events/SKILL.md

@@ -9,7 +9,7 @@ allowed-tools:
 
 # Translating External Events
 
-> **Before doing anything else**, invoke the `connect` skill to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Then invoke the `learn-eventmodelers-api` skill to load the full API reference. Do not proceed until both skills have been loaded.
+> **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until it has completed. Consult `learn-eventmodelers-api` only if you need to look up a specific endpoint or field this file doesn't cover — don't load it eagerly.
 
 ## Interview Phase (Optional)
 

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-validating-event-models/SKILL.md

@@ -8,7 +8,9 @@ allowed-tools:
 
 # Validating Event Models
 
-> **Before doing anything else**, invoke the `connect` skill to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Then invoke the `learn-eventmodelers-api` skill to load the full API reference. Do not proceed until both skills have been loaded.
+> **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until it has completed. Consult `learn-eventmodelers-api` only if you need to look up a specific endpoint or field this file doesn't cover — don't load it eagerly.
+
+Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect` skill) — the curl blocks below are the fallback for sessions without MCP connected.
 
 For validation you treat the Event Model as read only. The only thing you are allowed to change is comments.
 For critical questions, add comments to elements.
@@ -21,7 +23,17 @@ The source can be also determined by looking at the defined Scenarios. Are all S
 
 ## Board Context
 
-Before starting, read the current board state to validate what is actually on the board:
+Before starting, read the current board state to validate what is actually on the board.
+
+Prefer MCP — call `mcp__eventmodelers__get_nodes` once per type (no header wiring needed, auth resolves from the connected session):
+
+```
+mcp__eventmodelers__get_nodes { "boardId": "$BOARD_ID", "type": "EVENT" }
+mcp__eventmodelers__get_nodes { "boardId": "$BOARD_ID", "type": "COMMAND" }
+mcp__eventmodelers__get_nodes { "boardId": "$BOARD_ID", "type": "READMODEL" }
+```
+
+**Fallback (no MCP):**
 
 ```bash
 curl -s -H "x-token: $TOKEN" -H "x-board-id: $BOARD_ID" \
@@ -32,7 +44,7 @@ curl -s -H "x-token: $TOKEN" -H "x-board-id: $BOARD_ID" \
   "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes?type=READMODEL"
 ```
 
-After validation, use the `handle-comment` skill to post findings on the relevant nodes — `TASK` for critical violations that must be fixed, `QUESTION` for warnings and recommendations.
+After validation, use the `handle-comment` skill to post findings on the relevant nodes — `TASK` for critical violations that must be fixed, `QUESTION` for warnings and recommendations. (That skill already handles the `add_comment` MCP-vs-curl choice internally — no separate rewrite needed here.)
 
 ## Purpose
 Ensures event-sourced models are complete, correct, and follow pure event sourcing principles (minimal per-command state).

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-validating-event-models-checklist/SKILL.md

@@ -8,7 +8,9 @@ allowed-tools:
 
 # Event Model Validation Checklist Skill
 
-> **Before doing anything else**, invoke the `connect` skill to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Then invoke the `learn-eventmodelers-api` skill to load the full API reference. Do not proceed until both skills have been loaded.
+> **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until it has completed. Consult `learn-eventmodelers-api` only if you need to look up a specific endpoint or field this file doesn't cover — don't load it eagerly.
+
+Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect` skill) — the curl blocks below are the fallback for sessions without MCP connected.
 
 **Purpose**: Validate any event-sourced CQRS event model against 16 architectural checks across 7 phases. Identifies anti-patterns and confirms compliance with event sourcing principles.
 
@@ -35,6 +37,15 @@ allowed-tools:
 
 Read the current board state before running the checklist:
 
+**Prefer MCP:** call `get_nodes` once per type, or pull the fuller graph in one shot with `get_slice_data` if you need events/commands/readmodels/screens/specs/actors together:
+
+```
+mcp__eventmodelers__get_nodes { "boardId": "<BOARD_ID>", "type": "EVENT" }
+mcp__eventmodelers__get_nodes { "boardId": "<BOARD_ID>", "type": "COMMAND" }
+mcp__eventmodelers__get_nodes { "boardId": "<BOARD_ID>", "type": "READMODEL" }
+```
+
+**Fallback (no MCP):**
 ```bash
 curl -s -H "x-token: $TOKEN" -H "x-board-id: $BOARD_ID" \
   "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes?type=EVENT"
@@ -44,7 +55,7 @@ curl -s -H "x-token: $TOKEN" -H "x-board-id: $BOARD_ID" \
   "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes?type=READMODEL"
 ```
 
-Use the board nodes as the model input. After the checklist, use `handle-comment` to post `TASK` comments on nodes that fail checks.
+Use the board nodes as the model input. After the checklist, use `handle-comment` to post `TASK` comments on nodes that fail checks (that skill covers the MCP `add_comment`/curl choice for comment-posting itself).
 
 ## Validation Phases (Domain-Agnostic)
 

package/stacks/modeling-kit/templates/.claude/skills/examples/SKILL.md

@@ -5,7 +5,9 @@ description: Find an element on an eventmodelers board by ID, name, or cell name
 
 # Examples
 
-> **Before doing anything else**, invoke the `connect` skill to resolve `TOKEN`, `BOARD_ID`, and `BASE_URL`. Do not proceed until the connect skill has completed.
+> **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, and `BASE_URL`. Do not proceed until the connect skill has completed.
+
+Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect` skill) — the curl blocks below are the fallback for sessions without MCP connected.
 
 You are adding or improving example data on an eventmodelers element. You find the element, read all linked elements for context, then generate realistic and consistent example values for every field that is missing one or has a weak example.
 
@@ -23,7 +25,27 @@ From `$ARGUMENTS`, extract:
 
 ---
 
-## Step 2 — Resolve the element
+## Step 2 — Resolve and generate examples (prefer MCP)
+
+`add_field_examples` is a whole-algorithm convenience tool: it resolves the node, loads linked neighbours for cross-element consistency, fills any empty field examples, and writes the result back — collapsing the entire "find node → find linked nodes → build examples → submit_node_events" flow (Steps 2–5 below) into one call. Call it with whichever identifier matches `target`:
+
+- `target` is a UUID → pass `nodeId`
+- `target` is a name → pass `name`
+- `target` is a cell name (e.g. `B3`) → pass `cellName` + `timelineId` (the chapter id — if multiple chapters exist on the board, resolve which one first using 2c-fallback's chapter lookup, or `mcp__eventmodelers__get_nodes { "boardId": "$BOARD_ID", "type": "CHAPTER" }`, and ask the user if ambiguous)
+
+```
+mcp__eventmodelers__add_field_examples { "boardId": "$BOARD_ID", "nodeId": "<target, if a UUID>" }
+```
+```
+mcp__eventmodelers__add_field_examples { "boardId": "$BOARD_ID", "name": "<target, if a name>" }
+```
+```
+mcp__eventmodelers__add_field_examples { "boardId": "$BOARD_ID", "cellName": "<target, if a cell name>", "timelineId": "$CHAPTER_ID" }
+```
+
+If this succeeds, skip straight to Step 6 (report back), describing the fields the tool reports as changed. Use the manual fallback flow below (Steps 2–5) only if MCP isn't connected.
+
+### Fallback (no MCP) — Step 2: Resolve the element
 
 Try the resolution strategies in order until one succeeds.
 
@@ -70,7 +92,7 @@ From `meta.timelineData`, decode the cell name into a `cellId`:
 - Find the matching column in `columns` and the matching row in `rows`.
 - Compute: **`CELL_ID = row.id + "-" + column.id`** (cell IDs are always `<rowId>-<columnId>`).
 
-3. **Always fetch the cell live** to get the current node list — do not rely on the `nodeId` in the chapter's cell data, as it may be stale:
+3. **Always fetch the cell live** to get the current node list — do not rely on the `nodeId` in the chapter's cell data, as it may be stale. No MCP equivalent: `get_nodes` only filters by `type`, not `cellId`:
 
 ```bash
 curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes?cellId=$CELL_ID" \
@@ -85,7 +107,7 @@ Save the resolved node as `TARGET_NODE` (full JSON including `id`, `meta`, `edge
 
 ---
 
-## Step 3 — Load linked elements for context
+### Fallback (no MCP) — Step 3: Load linked elements for context
 
 Collect nearby elements to understand the domain context and generate consistent examples. **Never fetch all board nodes.** Only fetch specific nodes you already have IDs for.
 
@@ -116,7 +138,7 @@ For each neighbour element collected above (COMMAND, EVENT, READMODEL), extract
 
 ---
 
-## Step 4 — Generate improved examples
+### Fallback (no MCP) — Step 4: Generate improved examples
 
 For each field in `TARGET_NODE.meta.fields`:
 
@@ -143,9 +165,25 @@ Build the updated `fields` array: same structure as the original, only the `exam
 
 ---
 
-## Step 5 — Write the update
+### Fallback (no MCP) — Step 5: Write the update
+
+**Prefer MCP** (only reachable if you did the resolve/generate steps manually but still have MCP available): same event body, passed as a tool arg instead of `-d`:
+```
+mcp__eventmodelers__submit_node_events {
+  "boardId": "$BOARD_ID",
+  "events": [{
+    "id": "<uuid>",
+    "eventType": "node:changed",
+    "nodeId": "<TARGET_NODE.id>",
+    "boardId": "$BOARD_ID",
+    "timestamp": <epoch-ms>,
+    "changedAttributes": ["meta.fields"],
+    "meta": { "fields": "<updated-fields-array>" }
+  }]
+}
+```
 
-Build the payload with Python to avoid shell JSON-escaping issues, then POST it:
+**Fallback (no MCP at all)** — build the payload with Python to avoid shell JSON-escaping issues, then POST it:
 
 ```bash
 python3 - <<EOF > /tmp/examples_payload.json

package/stacks/modeling-kit/templates/.claude/skills/handle-comment/SKILL.md

@@ -5,7 +5,9 @@ description: Place, resolve, or delete a comment on an eventmodelers board node.
 
 # Handle Comment
 
-> **Before doing anything else**, invoke the `connect` skill to resolve `TOKEN`, `BOARD_ID`, and `BASE_URL`. Do not proceed until the connect skill has completed.
+> **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, and `BASE_URL`. Do not proceed until the connect skill has completed.
+
+Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect` skill) — the curl blocks below are the fallback for sessions without MCP connected.
 
 ---
 
@@ -29,6 +31,13 @@ Route to the matching section below based on `action`.
 
 ## Action: place
 
+**Prefer MCP** — one call, `type` (`COMMENT`/`TASK`/`QUESTION`) passed straight through:
+
+```
+mcp__eventmodelers__add_comment { "boardId": "$BOARD_ID", "nodeId": "$NODE_ID", "text": "<text>", "type": "<COMMENT|TASK|QUESTION>", "author": "<author>" }
+```
+
+**Fallback (no MCP):**
 ```bash
 curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/$NODE_ID/comments" \
   -H "Authorization: Bearer $TOKEN" \
@@ -53,6 +62,12 @@ Type: <type> | Author: <author>
 
 **Step A — Resolve comment ID** (skip if `commentId` was provided directly):
 
+**Prefer MCP:**
+```
+mcp__eventmodelers__get_node_comments { "boardId": "$BOARD_ID", "nodeId": "$NODE_ID" }
+```
+
+**Fallback (no MCP):**
 ```bash
 curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/$NODE_ID/comments" \
   -H "Authorization: Bearer $TOKEN"
@@ -62,6 +77,12 @@ Find the comment whose `text` contains the `text` argument (case-insensitive). I
 
 **Step B — Resolve:**
 
+**Prefer MCP:**
+```
+mcp__eventmodelers__update_comment { "boardId": "$BOARD_ID", "nodeId": "$NODE_ID", "commentId": "$COMMENT_ID", "action": "resolve" }
+```
+
+**Fallback (no MCP):**
 ```bash
 curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/$NODE_ID/comments/$COMMENT_ID/resolve" \
   -H "Authorization: Bearer $TOKEN"
@@ -86,6 +107,12 @@ Wait for an explicit "yes". On any other response, stop: "Deletion cancelled."
 
 **Step C — Delete:**
 
+**Prefer MCP:**
+```
+mcp__eventmodelers__update_comment { "boardId": "$BOARD_ID", "nodeId": "$NODE_ID", "commentId": "$COMMENT_ID", "action": "delete" }
+```
+
+**Fallback (no MCP):**
 ```bash
 curl -s -X DELETE "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/$NODE_ID/comments/$COMMENT_ID" \
   -H "Authorization: Bearer $TOKEN"

package/stacks/modeling-kit/templates/.claude/skills/html-screen/SKILL.md

@@ -1,15 +1,17 @@
 ---
 name: html-screen
-description: Design and render a single real HTML/CSS screen (one or more pages) onto an HTML_SCREEN node — use only when the user explicitly asks for an HTML screen; sketches (storyboard-screen) remain the default for ordinary screen requests
+description: Design and render a single real HTML/CSS screen (one or more pages) onto an HTML_SCREEN node — this is the default skill for any "design a screen" / "storyboard this" request; wireframe sketches (storyboard-screen) are used only when the user explicitly asks for one
 ---
 
 # HTML Screen Designer
 
-> **Before doing anything else**, invoke the `connect` skill to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until the connect skill has completed.
+> **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until the connect skill has completed.
 
-> **EXPLICIT USE ONLY**: Do not reach for this skill on an ordinary "design a screen" / "storyboard this" request — that default remains `storyboard-screen`, which renders a wireframe sketch onto a SCREEN node. Use this skill **only** when the user explicitly asks for an "HTML screen", a "real webpage", a "coded/HTML mockup", or names the HTML_SCREEN node type directly.
+Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect` skill) — the curl blocks below are the fallback for sessions without MCP connected.
 
-> **MANDATORY RENDER + VERIFY**: The render call in Step 4 and the verification in Step 5 are **not optional**. This skill exists solely to produce rendered pages. An HTML_SCREEN node with no non-empty page is an empty placeholder that adds no value to the model. If the render call is skipped or fails, or verification reports `valid: false`, the task is incomplete — retry or report the error.
+> **DEFAULT SCREEN SKILL**: Reach for this skill on any ordinary "design a screen" / "storyboard this" request — it is the default, rendering a real HTML/CSS mockup onto an HTML_SCREEN node. Use `storyboard-screen` (a low-fidelity wireframe sketch onto a plain SCREEN node) **only** when the user explicitly asks for a "sketch", a "wireframe", a "low-fidelity mockup", or names the SCREEN node type directly.
+
+> **MANDATORY RENDER**: The render call in Step 4 is **not optional**. This skill exists solely to produce rendered pages. An HTML_SCREEN node with no non-empty page is an empty placeholder that adds no value to the model. If the render call is skipped or fails, the task is incomplete — retry or report the error.
 
 Design one or more HTML/CSS pages and render them onto an HTML_SCREEN node — creating the node if it doesn't exist yet, or updating it in place if it does. Use this to build a realistic, styled mockup (forms, tables, real page layout) rather than a wireframe sketch. Each page is a separate, standalone piece of markup — e.g. a multi-step form is one page per step, not one blob with hidden sections.
 
@@ -30,7 +32,15 @@ If neither `nodeId` nor (`chapterId` + `cellName`) can be resolved, ask the user
 
 ## Step 2 — If updating an existing screen, load its current pages first
 
-If `nodeId` refers to a screen that already has pages (i.e. this is an adjustment/tweak, or "add a page" to an existing screen — not a brand-new screen), **do not design from scratch**. Load the node and inspect `meta.pages`:
+If `nodeId` refers to a screen that already has pages (i.e. this is an adjustment/tweak, or "add a page" to an existing screen — not a brand-new screen), **do not design from scratch**. Load the node and inspect `meta.pages`.
+
+**Prefer MCP:**
+
+```
+mcp__eventmodelers__get_node { "boardId": "<BOARD_ID>", "nodeId": "<NODE_ID>" }
+```
+
+**Fallback (no MCP):**
 
 ```bash
 curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/$NODE_ID" \
@@ -60,6 +70,18 @@ Guidelines:
 
 **Updating an existing node** (`nodeId` was given) — always sends the **complete** pages array, not just the changed/new entry:
 
+**Prefer MCP:**
+
+```
+mcp__eventmodelers__render_screen {
+  "boardId": "<BOARD_ID>",
+  "nodeId": "<NODE_ID>",
+  "pages": ["<div>...</div>", "<div>...</div>"]
+}
+```
+
+**Fallback (no MCP):**
+
 ```bash
 curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/html-screens/$NODE_ID" \
   -H "x-token: $TOKEN" \
@@ -71,6 +93,21 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/html-screens/$NODE_I
 
 **Creating a new node** (no `nodeId` — one is generated and placed into `chapterId`/`cellName`):
 
+**Prefer MCP:**
+
+```
+mcp__eventmodelers__create_screen {
+  "boardId": "<BOARD_ID>",
+  "contentType": "html",
+  "nodeId": "<generated-uuid>",
+  "chapterId": "<CHAPTER_ID>",
+  "cellName": "<CELL_NAME>",
+  "pages": ["<div>...</div>"]
+}
+```
+
+**Fallback (no MCP):**
+
 ```bash
 NODE_ID=$(uuidgen)
 curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/html-screen-nodes/$NODE_ID" \
@@ -81,23 +118,12 @@ curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/html-screen-nodes/$N
   -d '{"chapterId": "'"$CHAPTER_ID"'", "cellName": "'"$CELL_NAME"'", "pages": ["<div>...</div>"]}'
 ```
 
-Expect `204 No Content` on success from either call.
-
-## Step 5 — Verify the screen
-
-Confirm the node exists, is type HTML_SCREEN, and has at least one non-empty page:
-
-```bash
-curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/html-screens/$NODE_ID/verify" \
-  -H "x-token: $TOKEN"
-```
-
-If `valid` is `false`, read the `error` field and retry the failing step once before reporting failure.
+Expect `204 No Content` on success from either curl call.
 
-## Step 6 — Report back
+## Step 5 — Report back
 
 Tell the user:
 - The node ID that was created or updated
 - How many pages the screen now has
-- Whether the render succeeded (HTTP 204) and verification passed (`valid: true`)
+- Whether the render succeeded (HTTP 204)
 - Any errors