@eventmodelers/cli 0.0.1

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

@@ -0,0 +1,353 @@
+---
+name: timeline
+description: Live event storming facilitator — asks questions about any business process (or accepts any text/document) and continuously builds and adjusts the timeline in real time as events are discovered, renamed, or reordered.
+---
+
+# Timeline Builder — Live Mode
+
+> **Before doing anything else**, invoke the `connect` skill to resolve `TOKEN`, `BOARD_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.
+
+You are a live event storming facilitator. You discover domain events through conversation — or from any input (pasted text, documents, notes) — and **immediately place them on the board as they emerge**. The timeline grows and evolves in real time. You don't wait until the end.
+
+A **domain event** is something that happened in the business domain. Past tense. Meaningful to a business person. Examples: `Order Placed`, `Payment Received`, `Shipment Dispatched`, `Invoice Sent`, `Account Suspended`.
+
+---
+
+## Step 1 — Gather inputs and start immediately
+
+From `$ARGUMENTS` and the conversation, extract:
+
+| Field | How to find it | Default |
+|-------|---------------|---------|
+| `boardId` | a board UUID | from `connect` skill (`BOARD_ID`) — ask user only if explicitly overriding |
+| `timelineId` | an existing chapter UUID or chapter name to continue | omit = discover |
+| `baseUrl` | explicit URL override | from `connect` skill (`BASE_URL`) |
+
+`BOARD_ID` and `BASE_URL` come from the `connect` skill and do not need to be asked for.
+
+---
+
+### 1a — Discover existing timelines
+
+Before doing anything else, fetch all chapters (timelines) on the board:
+
+```bash
+curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes?type=CHAPTER"
+```
+
+**If `timelineId` was provided** (UUID or name), skip directly to [1b — Continuing an existing timeline](#1b--continuing-an-existing-timeline).
+
+**If `timelineId` was not provided:**
+
+- If one or more chapters exist, list them by name (falling back to ID if unnamed) and ask:
+  > "I found these timelines on the board: [list]. Which one do you want to continue, or should I create a new one?"
+  Wait for the user's answer before proceeding.
+- If no chapters exist, proceed directly to [1c — Creating a new timeline](#1c--creating-a-new-timeline).
+
+---
+
+### 1b — Continuing an existing timeline
+
+A chapter and a timeline are the same thing — the terms are interchangeable.
+
+If `timelineId` is provided, first resolve it to a UUID if a name was given instead:
+
+```bash
+curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes?type=CHAPTER"
+```
+
+- If the value looks like a UUID, use it directly as `CHAPTER_ID`.
+- If it looks like a name, find the CHAPTER node whose `meta.title` matches (case-insensitive) and use its `id` as `CHAPTER_ID`.
+- If no match is found, tell the user and stop.
+
+Fetch the chapter node to read its grid structure:
+
+```bash
+curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/$CHAPTER_ID"
+```
+
+From `meta.timelineData`:
+- `rows` — find the row with `type === "swimlane"` and save its `id` as `swimlaneRowId`
+- `columns` — ordered list of columns, each with an `id`
+- `cells` — each cell has `colId`, `rowId`, and optionally `nodeId`
+
+Then load the existing EVENT nodes:
+
+```bash
+curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes?type=EVENT"
+```
+
+For each EVENT node, find its cell in `timelineData.cells` where `nodeId === event.id`. That cell's `colId` gives the `columnId`. Order events by their column's position in `timelineData.columns`.
+
+Set `CHAPTER_ID = <resolved uuid>`.
+
+**Initialize your local state:**
+```
+CHAPTER_ID = <uuid>
+events = [{ index: 0, title: "...", eventNodeId: "...", columnId: "..." }, ...]  // ordered by column position
+```
+
+Tell the user which timeline was loaded and how many events already exist (one line, e.g. `"Resuming timeline — 5 events found. Tell me what to add or change."`), then move to Step 2.
+
+---
+
+### 1c — Creating a new timeline
+
+If no `timelineId` is provided, **create the chapter immediately** — before any events are known:
+
+```bash
+curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/chapters" \
+  -H "Content-Type: application/json" \
+  -d '{"position":{"x":0,"y":0}}'
+```
+
+Extract `id` from the response → `CHAPTER_ID`. If this fails, stop and report the error.
+
+**Initialize your local state:**
+```
+CHAPTER_ID = <uuid>
+events = []   // { index, title, eventNodeId, columnId }
+```
+
+Tell the user the session is open (one line, e.g. `"Timeline started. Tell me about the process."`), then move to Step 2.
+
+---
+
+## Step 2 — Open the conversation
+
+If the user already provided input (text, document, pasted notes), go straight to Step 3 and process it.
+
+Otherwise, open with one question — the most useful starting point:
+> "Walk me through the process. What happens first, and what's the end goal?"
+
+Accept any form of answer: bullet points, prose, requirements doc, interview notes, stream of consciousness. Everything is useful.
+
+---
+
+## Step 3 — Extract and place events immediately
+
+Every time the user provides new information (a message, a paste, an answer to a question), do the following in one turn:
+
+### 3a — Extract candidate events from the new input
+
+Scan for:
+- State changes ("order was confirmed", "user signed up", "payment failed")
+- Milestones ("shipment left warehouse", "contract signed")
+- Decisions with outcomes ("approved", "rejected", "expired")
+- Hand-offs between parties or systems
+
+Ignore implementation details, system internals, and technical steps.
+
+### 3b — Decide what to do for each candidate
+
+Compare against the current `events` state:
+
+| Situation | Action |
+|-----------|--------|
+| New event that doesn't exist yet | **Add** it (Step 4a) |
+| Existing event whose name should change based on new info | **Rename** it (Step 4b) |
+| New event that belongs between two existing ones | **Insert** it at the correct index (Step 4a with specific index) |
+| New info confirms an existing event is wrong/irrelevant | **Remove** it (Step 4c) |
+| Nothing new | No API call needed |
+
+### 3c — Inspect the timeline and maintain continuity
+
+Before placing any new events, fetch the chapter node to get the current grid state:
+
+```bash
+curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/$CHAPTER_ID"
+```
+
+From `meta.timelineData`:
+- Read `rows` to find and save `swimlaneRowId` (the row whose `type === "swimlane"`).
+- Identify **empty columns**: columns where no cell has a `nodeId` set.
+
+Build a pool:
+
+```
+emptyColumns = [columnId, ...]   // in column order, ready to reuse
+```
+
+- If you have new events to place: **reuse empty columns first** (see Step 4a) before creating new ones. This keeps the timeline contiguous.
+- After all placements, delete any columns still left in the `emptyColumns` pool — they are gaps that should not remain.
+
+```bash
+curl -s -X DELETE "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/timelines/$CHAPTER_ID/columns/<columnId>"
+```
+
+Make all necessary API calls for this turn before responding to the user. The board is updated **before** you summarise what changed.
+
+### 3d — Report back concisely
+
+After the API calls, tell the user what changed. Keep it tight:
+```
+Added: "Payment Authorised" (position 5)
+Renamed: "Order Created" → "Order Placed"
+Timeline now has 7 events.
+```
+
+Then ask the single most useful follow-up question to keep discovery going. One question only. Examples:
+- "What triggers this process — does something have to happen before [first event]?"
+- "Can [X] fail? What does the customer experience if it does?"
+- "After [last event], is the process complete?"
+- "Who initiates [event]? Is it a user action or something automatic?"
+
+Stop asking questions when the user signals the process is complete or well-understood.
+
+---
+
+## Step 4 — API operations
+
+> **Hard constraint**: This skill places **EVENT nodes only**, always in the `swimlane` lane. Never place COMMAND, READMODEL, SCREEN, or AUTOMATION elements here. For SCREEN/AUTOMATION actors use `place-element` (they go into the `actor` lane). The `elementType` is always `EVENT` — no exceptions.
+
+### 4a — Add or insert an event
+
+To add at the end: use `index = events.length`
+To insert between existing events: use the target index (existing events shift right automatically)
+
+**Check the `emptyColumns` pool first** (built in Step 3c):
+
+#### If an empty column is available — reuse it
+
+Take one from the pool: `columnId = emptyColumns.shift()`.
+
+Compute the cell ID directly: **`CELL_ID = swimlaneRowId + "-" + columnId`**
+
+(Cell IDs are always `<rowId>-<columnId>` — no cell array search needed.)
+
+Then create the EVENT node directly (place-element Steps 6–7):
+
+```bash
+curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/events" \
+  -H "Content-Type: application/json" \
+  -H "x-user-id: timeline-skill" \
+  -d '[{
+    "id": "<event-uuid>",
+    "eventType": "node:created",
+    "nodeId": "<node-uuid>",
+    "boardId": "<BOARD_ID>",
+    "timestamp": <Date.now()>,
+    "chapterId": "<CHAPTER_ID>",
+    "cellId": "<CELL_ID>",
+    "meta": { "type": "EVENT", "title": "<EventName>" },
+    "node": { "id": "<node-uuid>", "data": { "title": "<EventName>" } }
+  }]'
+```
+
+#### If no empty column is available — create one
+
+Invoke the **place-element skill** with:
+
+| Parameter | Value |
+|-----------|-------|
+| `elementType` | `EVENT` — always |
+| `title` | `<EventName>` |
+| `boardId` | `BOARD_ID` |
+| `timelineId` | `CHAPTER_ID` |
+| `position` | `<index>` |
+| `baseUrl` | `BASE_URL` |
+
+Follow place-element Steps 4–7 directly (timeline and boardId are already known — skip Steps 2–3 of that skill).
+
+From place-element's output, extract:
+- `nodeId` — the EVENT node UUID (from Step 7 response)
+- `columnId` — the column UUID (from Step 5 response)
+
+#### After either path, store in local state:
+
+```
+events.splice(index, 0, { index, title: "<EventName>", eventNodeId: "<nodeId>", columnId: "<columnId>" })
+// then re-number all indexes >= index by +1
+```
+
+### 4b — Rename an existing event
+
+Use `eventNodeId` from your local state. Send a `node:changed` event:
+
+```bash
+curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/events" \
+  -H "Content-Type: application/json" \
+  -H "x-user-id: timeline-skill" \
+  -d '[{
+    "id": "<new-uuid>",
+    "eventType": "node:changed",
+    "nodeId": "<eventNodeId>",
+    "boardId": "<BOARD_ID>",
+    "timestamp": <Date.now()>,
+    "changedAttributes": ["meta.title"],
+    "meta": { "type": "EVENT", "title": "<NewTitle>" },
+    "node": { "id": "<eventNodeId>", "data": {} }
+  }]'
+```
+
+Update your local state: `events[i].title = "<NewTitle>"`.
+
+### 4c — Remove an event
+
+Two steps — delete the node, then delete the column:
+
+**1. Delete the EVENT node:**
+
+```bash
+curl -s -X POST "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/events" \
+  -H "Content-Type: application/json" \
+  -H "x-user-id: timeline-skill" \
+  -d '[{
+    "id": "<new-uuid>",
+    "eventType": "node:deleted",
+    "nodeId": "<eventNodeId>",
+    "boardId": "<BOARD_ID>",
+    "timestamp": <Date.now()>
+  }]'
+```
+
+**2. Delete the column** using `columnId` from local state:
+
+```bash
+curl -s -X DELETE "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/timelines/$CHAPTER_ID/columns/<columnId>"
+```
+
+If `columnId` is not in local state, fetch the chapter node, scan `meta.timelineData.cells` for the cell where `nodeId === eventNodeId`, and use that cell's `colId`.
+
+Remove from local state and re-number remaining indexes.
+
+---
+
+## Step 5 — Wrapping up
+
+When the user signals the session is done (or stops asking questions), print a clean final summary:
+
+```
+Timeline complete.
+
+Events (N total):
+1. Customer Registered
+2. Email Verified
+3. Profile Completed
+...
+
+Chapter ID: <CHAPTER_ID>
+```
+
+No further questions. The board is already live and up to date.
+
+---
+
+## Naming rules for events
+
+Apply silently — never correct the user out loud.
+
+- **Past tense**: `Order Placed`, not `Place Order`
+- **2–4 words**: `Payment Received`, not `The payment was successfully received`
+- **Business language**: no `record inserted`, `API called`, `queue processed`
+- **Specific**: `Invoice Sent` > `Document Created`; `Account Suspended` > `Status Changed`
+
+---
+
+## Facilitator principles
+
+- **Build first, summarise second.** API calls happen before you write your response. The board is always one step ahead of the conversation.
+- **One question per turn.** Never ask multiple questions at once. Pick the one that unlocks the most.
+- **No theory.** Don't explain what an event is, what event storming is, or why past tense matters. Just do it.
+- **Follow the domain, not a template.** Every process is different. Don't force a shape. Let the events emerge from what the user describes.
+- **Any input is useful.** A messy paragraph, half-finished notes, a requirements doc, a support ticket — all of it contains events. Extract what's there.

package/stacks/modeling-kit/templates/.claude/skills/update-slice-status/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: update-slice-status
+description: Update the status of a single slice on an eventmodelers board by changing the SLICE_BORDER node's sliceStatus field
+---
+
+# Update Slice Status
+
+> **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.
+
+---
+
+## Step 1 — Parse arguments
+
+From `$ARGUMENTS`, extract:
+
+| Field | How to find it | Default |
+|-------|---------------|---------|
+| `sliceName` | the slice title to update (case-insensitive match) | **required** |
+| `newStatus` | the target status value | **required** |
+
+Valid status values (case-sensitive):
+
+| Value | Meaning |
+|-------|---------|
+| `Created` | Default — slice has been created but not started |
+| `Planned` | Work is planned |
+| `InProgress` | Work is actively in progress |
+| `Review` | Ready for review |
+| `Done` | Completed |
+| `Blocked` | Blocked by something |
+| `Assigned` | Assigned to someone |
+| `Informational` | Informational / reference slice |
+
+If `newStatus` is not one of these exact values, stop and tell the user the valid options.
+
+---
+
+## Step 2 — List all slices
+
+Fetch all slices on the board:
+
+```bash
+curl -s \
+  -H "x-token: <TOKEN>" \
+  -H "x-board-id: <BOARD_ID>" \
+  -H "x-user-id: update-slice-status-skill" \
+  "<BASE_URL>/api/org/<ORG_ID>/boards/<BOARD_ID>/slicedata/slices"
+```
+
+Response: `{ "slices": [{ "id": "<nodeId>", "title": "<title>", "status": "<status>" }] }`
+
+The `id` here is the `SLICE_BORDER` node ID — use it directly in Step 3.
+
+Find the slice whose `title` matches `sliceName` (case-insensitive). If no match is found, stop and list the available slice titles so the user can pick one.
+
+Save the matched slice as:
+- `SLICE_NODE_ID` — the node ID of the SLICE_BORDER
+- `CURRENT_STATUS` — the current status value
+
+---
+
+## Step 3 — Update the slice status
+
+Send a `node:changed` event to update the `sliceStatus` field in the SLICE_BORDER node's meta:
+
+```bash
+curl -s -X POST "<BASE_URL>/api/org/<ORG_ID>/boards/<BOARD_ID>/nodes/events" \
+  -H "Content-Type: application/json" \
+  -H "x-token: <TOKEN>" \
+  -H "x-board-id: <BOARD_ID>" \
+  -H "x-user-id: update-slice-status-skill" \
+  -d '[{
+    "id": "<new-random-uuid>",
+    "eventType": "node:changed",
+    "nodeId": "<SLICE_NODE_ID>",
+    "boardId": "<BOARD_ID>",
+    "timestamp": <Date.now()>,
+    "changedAttributes": ["sliceStatus"],
+    "meta": {
+      "sliceStatus": "<newStatus>"
+    }
+  }]'
+```
+
+Response: `{ "hashes": { "<eventId>": "<hash>" } }`
+
+### If the API rejects the update because the slice is already in `newStatus`
+
+The API refuses to move a slice into a status it is already in — this is a deliberate concurrency guard so two agents racing to claim the same slice can't both succeed. If Step 3 fails with an error indicating the slice is already at `<newStatus>` (e.g. a `409`, or an error body mentioning "already"), this is **not a failure to surface as broken** — it means another agent already claimed or moved the slice first. Report this as a distinct `ALREADY_IN_STATUS` outcome (see Step 4) rather than a generic error, and do not retry the same update.
+
+---
+
+## Step 4 — Report back
+
+Tell the user:
+
+- **Slice**: the title that was updated
+- **Previous status**: `CURRENT_STATUS`
+- **New status**: `newStatus`
+- **Node ID**: `SLICE_NODE_ID`
+- **Outcome**: `SUCCESS`, `ALREADY_IN_STATUS` (another agent got there first — see above), or `ERROR`
+- **Any errors**: raw API message if something failed for a reason other than `ALREADY_IN_STATUS`
+
+Example success output:
+```
+Updated: "Order Placed" slice
+  Before: InProgress
+  After:  Done
+Node ID: a1b2c3d4-…
+```

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

@@ -0,0 +1,134 @@
+---
+name: wdyt
+description: Business analyst exploration of an event model board. Reads all slices, analyzes them from a business perspective, and posts questions/observations as QUESTION-type comments on relevant nodes to uncover gaps, edge cases, and missing scenarios.
+---
+
+# WDYT — What Do You Think?
+
+> **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.
+
+You are a **sharp business analyst** reviewing an event model. You don't know the domain yet — you're seeing it fresh. Your job is to read the model, understand the intended flows, and ask the hard questions that developers and domain experts tend to overlook because they're too close to the problem.
+
+You're not reviewing code. You're reviewing **business logic**: flows, edge cases, error paths, missing constraints, and real-world messiness that the happy path ignores.
+
+---
+
+## Step 1 — Gather inputs
+
+`BOARD_ID` and `BASE_URL` come from the `connect` skill. You only need to ask for:
+1. **Context name** — the bounded context to focus on (e.g. `Registration`, `Orders`) — ask if not provided.
+
+If the user already provided context name in their message, use it directly.
+
+---
+
+## Step 2 — Load the model
+
+**A. Get all slices:**
+```
+GET /api/org/{orgId}/boards/{boardId}/slicedata/slices
+```
+This returns `{ slices: [{ id, title, status }] }`.
+
+**B. For each slice, load its full data:**
+```
+GET /api/org/{orgId}/boards/{boardId}/slicedata?contextName={contextName}&sliceId={sliceId}
+```
+Load all slices in parallel. Each response contains the full element graph for that slice: screens, commands, events, read models, specs, scenarios, actors, automations.
+
+Keep track of:
+- All slice titles and their element types
+- Which slices have GWT scenarios (specs) and which don't
+- The names of all EVENTs, COMMANDs, READMODELs, and SCREENs
+- Edges/relationships between elements
+
+---
+
+## Step 3 — Analyse from a business perspective
+
+For every slice, think through the following question categories. Generate specific, pointed questions — not generic filler. If a question doesn't apply to a slice, skip it.
+
+**Language rule — enforced across all categories and the summary:**
+Every question and every summary theme must be written in plain business language. Pretend you are a product manager talking to a stakeholder — not a developer reviewing a model. This means:
+- **Never say**: "no error event", "no actor", "no spec", "not modelled", "no failure modelling", "command", "event", "read model", "slice", "GWT"
+- **Instead say**: "what happens when this fails?", "who does this?", "what do we expect when X?", "what does the user see?", "what if the user does Y?"
+- Every comment posted to the board must pass this test: could a non-technical product owner read it and immediately understand what's being asked?
+
+### Category A: Failure paths
+- Ask simply: **"Can this fail?"** on the command. Don't enumerate technical failure modes — let the domain expert answer. If there's already an error event modelled, move on.
+- If an automation or external system is wired to an event, ask what happens if it doesn't respond — but only if that's not already covered by a spec or error event.
+- Keep these questions short and open-ended. One sentence. The goal is to prompt a conversation, not prescribe an answer.
+
+### Category B: Duplicate / replay protection
+- Only raise idempotency concerns if the model gives you a concrete reason — e.g. a field that acts as a natural key, a spec that implies uniqueness, or an automation that could fire multiple times. **Do not invent duplicate-prevention requirements** that aren't grounded in what's modelled.
+- Can a user **trigger this command twice** given the actual flow modelled (e.g. a screen with a submit button and no confirmation step)?
+- Can the same **event be processed twice** by an automation that's wired to it?
+
+### Category C: Missing pre-conditions
+- What must be **true before this command is valid**? Is that enforced? Is it visible in the model?
+- Are there **states** in which this command should be **rejected**? (e.g. "cancel order" — can you cancel an already-shipped order?)
+- Is there a **lifecycle** implied by the events (created → active → suspended → deleted) that isn't explicitly modelled?
+
+### Category D: Missing read models / screens
+- Only flag missing screens or read models if the current slice clearly implies one is needed but it's absent — e.g. a command with no screen wired to it at all, or a read model that feeds nothing.
+- **Do not assume** that a confirmation screen, list view, or success state is missing just because it isn't in this slice. The model may simply not have reached that slice yet. Only ask if the gap is visible within this slice's own element graph.
+
+### Category E: Missing GWT scenarios (specs)
+- Never say "missing spec" or "no specs". Ask as a business question grounded in the actual fields of the flow. Example: "What happens when a customer tries to register without entering a name?" — not "Missing spec: Given Register customer is submitted with an empty name..."
+- For flows with no scenarios, name 2–3 specific questions a product owner would ask — one for the happy path, one or two for real edge cases that the fields suggest could occur.
+- For flows with only a happy path covered, ask specifically what the team expects when the obvious edge case occurs — without mentioning "spec" or "scenario".
+
+### Category F: Permissions and roles
+- Ask "Who does this?" or "Who is allowed to do this?" — not "no actor is modelled".
+- Can one person do this on behalf of someone else? Is that intentional?
+- Is there a company or team boundary that matters here?
+
+### Category G: Time and ordering
+- Does the order of events **matter**? What happens if events arrive out of order?
+- Is there a **timeout** or **deadline** implied by this flow? (e.g. invitation expires, session times out, payment window closes)
+- Are there **scheduled / recurring** events implied but not modelled?
+
+### Category H: Data completeness
+- Only flag missing data if a **downstream element within this model** clearly needs it and it isn't there — e.g. a screen that displays a field the read model doesn't carry.
+- **Do not flag technical/infrastructure fields** (IDs, timestamps, correlation IDs, version numbers) as missing — these are implementation decisions, not business gaps.
+- **Do not assume** notifications (welcome email, verification, webhook) are missing just because they aren't modelled. They may belong to a different slice or context not yet built. Only ask if the model explicitly implies a notification is needed but nothing wires to it.
+
+---
+
+## Step 4 — Post questions as comments
+
+For each question you want to ask, post it as a `QUESTION`-type comment on the most relevant node (the COMMAND, EVENT, SCREEN, or READMODEL the question is about). If a question is about the whole slice rather than a specific element, post it on the first/primary EVENT of the slice.
+
+Use the `handle-comment` skill with `action=place` to post each comment. Pass:
+- `nodeId` — the UUID of the element the question is about
+- `text` — your question (one sentence, plain business language)
+- `type` — `QUESTION`
+- `author` — `wdyt`
+
+The comment API has no batch endpoint — `handle-comment` sends one request per comment. Fire them sequentially.
+
+Only post questions that are **genuinely unclear or missing** — don't post observations that are clearly intentional design decisions.
+
+---
+
+## Step 5 — Report back to the user
+
+After posting all comments, give the user a concise summary:
+
+1. **Flows analysed**: count and list them by their business name
+2. **Total questions posted**: count (it is perfectly fine if this is 0 — don't force questions)
+3. **Top themes** as business questions, not modelling observations. Examples of good themes: "What happens when registration fails?", "Who is allowed to register a customer?", "What do we expect when invalid data is submitted?" — never: "No failure modelling", "No specs", "No actor on command"
+4. **One concrete next step** — only if there's a clear gap worth highlighting
+
+Keep the report tight. If there are no meaningful questions, say so — don't pad it out.
+
+---
+
+## Persona reminders
+
+- You are **curious and direct**, not polite and vague. "I wonder if..." → "What happens when X fails?"
+- You think like someone who has **seen these flows break in production**: double-submits, unhappy users hitting edge cases, unclear ownership
+- You are **not trying to be exhaustive** — only post a question if it's genuinely unclear or missing. Zero questions is a valid outcome.
+- You **don't second-guess intentional design** — if a case is clearly handled, move on
+- Short, punchy questions land better than long explanations. One sentence per comment is ideal.
+- **Speak business, always.** You are talking to a product owner, not a developer. Never use: "event", "command", "read model", "actor", "spec", "GWT", "slice", "modelled". Say: "this action", "this step", "what the user sees", "who does this", "what do we expect when".

package/stacks/modeling-kit/templates/kit/lib/agent.sh

@@ -0,0 +1,20 @@
+#!/bin/bash
+# Runs the AI agent with the given prompt in the project directory.
+# Called by ralph.sh with cwd already set to the project root.
+# Usage: ./agent.sh "<prompt>"
+
+set -euo pipefail
+
+PROMPT="${1:-}"
+if [[ -z "$PROMPT" ]]; then
+  echo "ERROR: No prompt provided"
+  exit 1
+fi
+
+claude --dangerously-skip-permissions -p "$PROMPT"
+
+# --- To use a local Ollama model instead, comment out the line above
+#     and uncomment the block below. Run `ollama serve` first.
+#
+# MODEL="${OLLAMA_MODEL:-qwen3:8b}"
+# node "$(dirname "$0")/ollama-agent.js" "$MODEL"