@eventmodelers/cli 1.0.89 → 1.0.91

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

@@ -31,11 +31,11 @@ From `$ARGUMENTS` and the conversation, extract:
 
 ### 1a — Discover existing timelines
 
-Before doing anything else, fetch all chapters (timelines) on the board.
+Before doing anything else, fetch all chapters (timelines) on the board — only ids and titles are needed to list/pick one, so use `projection: "line"` (without it every chapter's full grid comes back).
 
 **Prefer MCP:**
 ```
-mcp__eventmodelers__get_nodes { "boardId": "<BOARD_ID>", "type": "CHAPTER" }
+mcp__eventmodelers__get_nodes { "boardId": "<BOARD_ID>", "type": "CHAPTER", "projection": "line" }
 ```
 
 **Fallback (no MCP):** see `references/api-fallback.md` — "Fetch all chapters".
@@ -55,17 +55,17 @@ mcp__eventmodelers__get_nodes { "boardId": "<BOARD_ID>", "type": "CHAPTER" }
 
 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.
+If `timelineId` is provided, first resolve it to a UUID if a name was given instead (ids and titles only — `projection: "line"`).
 
 **Prefer MCP:**
 ```
-mcp__eventmodelers__get_nodes { "boardId": "<BOARD_ID>", "type": "CHAPTER" }
+mcp__eventmodelers__get_nodes { "boardId": "<BOARD_ID>", "type": "CHAPTER", "projection": "line" }
 ```
 
 **Fallback (no MCP):** see `references/api-fallback.md` — "Fetch all chapters".
 
 - 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 it looks like a name, find the CHAPTER node whose `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 — `projection: "cells"` returns just `{rows, columns, cells}`, not the whole chapter node.
@@ -77,21 +77,21 @@ mcp__eventmodelers__get_node { "boardId": "<BOARD_ID>", "nodeId": "<CHAPTER_ID>"
 
 **Fallback (no MCP):** see `references/api-fallback.md` — "Fetch the chapter's grid state".
 
-From the result (`{rows, columns, cells}` via MCP's `projection: "cells"`, or `meta.timelineData` via the REST fallback):
+From the result (`{rows, columns, cells}` — both MCP and the REST fallback use `projection=cells`):
 - `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.
+Then load the existing EVENT nodes of this chapter — only `id` and `title` are needed (the column comes from `cells`), so use `projection: "line"`.
 
 **Prefer MCP:**
 ```
-mcp__eventmodelers__get_nodes { "boardId": "<BOARD_ID>", "type": "EVENT" }
+mcp__eventmodelers__get_nodes { "boardId": "<BOARD_ID>", "type": "EVENT", "chapterId": "<CHAPTER_ID>", "projection": "line" }
 ```
 
 **Fallback (no MCP):** see `references/api-fallback.md` — "Fetch all EVENT nodes".
 
-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`.
+For each EVENT node, find its cell in `cells` where `nodeId === event.id`. That cell's `colId` gives the `columnId`. Order events by their column's position in `columns`.
 
 Set `CHAPTER_ID = <resolved uuid>`.
 
@@ -176,7 +176,7 @@ mcp__eventmodelers__get_node { "boardId": "<BOARD_ID>", "nodeId": "<CHAPTER_ID>"
 
 **Fallback (no MCP):** see `references/api-fallback.md` — "Fetch the chapter's grid state".
 
-From the result (`rows`/`columns`/`cells` directly via MCP, or under `meta.timelineData` via the REST fallback):
+From the result (`rows`/`columns`/`cells` directly, via MCP or the REST fallback's `?projection=cells`):
 - Read `rows` to find and save `swimlaneRowId` (the row whose `type === "swimlane"`).
 - Identify **empty columns**: columns where no cell has a `nodeId` set.
 

package/stacks/modeling-kit/templates/.claude/skills/timeline/references/api-fallback.md

@@ -5,21 +5,21 @@ Only needed when MCP is not connected. Every call below has an MCP equivalent in
 ## Fetch all chapters (Steps 1a, 1b)
 
 ```bash
-curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes?type=CHAPTER"
+curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes?type=CHAPTER&projection=line"
 ```
 
 ## Fetch the chapter's grid state (Steps 1b, 3c)
 
 ```bash
-curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/$CHAPTER_ID"
+curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes/$CHAPTER_ID?projection=cells"
 ```
 
-Read `meta.timelineData` for `{rows, columns, cells}`.
+Returns `{rows, columns, cells}` directly (not wrapped in `meta.timelineData`).
 
 ## Fetch all EVENT nodes (Step 1b)
 
 ```bash
-curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes?type=EVENT"
+curl -s "$BASE_URL/api/org/$ORG_ID/boards/$BOARD_ID/nodes?type=EVENT&chapterId=$CHAPTER_ID&projection=line"
 ```
 
 ## Create a new chapter (Step 1c)

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

@@ -1,6 +1,6 @@
 ---
 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 comments on relevant nodes. Findings about a relationship between elements or a cluster of elements are always additionally drawn on the canvas (arrows, group loops) — comments carry every textual question, drawings carry every visual/structural hint.
+description: Business analyst exploration of an event model board. Reads all slices, analyzes them from a business perspective, and posts questions/observations as comments on relevant nodes. Findings about a relationship between two elements are additionally drawn on the canvas as an arrow — comments carry every textual question, arrows carry the relational hints.
 ---
 
 # WDYT — What Do You Think?
@@ -38,6 +38,8 @@ mcp__eventmodelers__get_slice_data {
 }
 ```
 
+This deliberately stays the **full graph (no `projection`)**: a business review needs elements, specs *and* existing comments together — `fields` drops specs and comments, `specs` drops elements, `outline` drops both fields and specs — and the full graph is also what carries the element geometry Step 4 draws from. Stitching two projections together would still miss the comments (existing questions you must not re-ask).
+
 `format` matters here because this skill reads the entire model before it writes anything. `"textual"` is a compact markdown dump and `"toon"` a token-efficient tabular encoding — both carry the same graph as `"json"` in a fraction of the tokens. Use `"json"` only when you need to read exact `x`/`y`/`width`/`height` values for the drawings in Step 4.2.
 
 Each response contains screens, commands, events, read models, specs, scenarios, actors, automations, and the edges between them.
@@ -117,16 +119,16 @@ Never raise a candidate off the count alone — reason about the specific events
 - **The right chair** — only if it holds up: "Is this screen answering one question for the user, or several different ones bundled together?"
 - **The shelf** — only if it holds up: "This step has a lot more cases than the ones around it — is that because it's really doing more, or because it's covering something that should be its own step?"
 
-Each of these four is inherently about a relationship or cluster of elements, so whichever you do raise always gets a drawing per Step 4.2 in addition to its comment — a group loop around the elements involved, or an arrow if the concern is specifically about one edge among several.
+Whichever of these four you raise, its comment goes on the element at the centre of it; add an arrow per Step 4.2 only if the concern is specifically about one edge among several.
 
 ---
 
-## Step 4 — Comments carry every textual question; drawings carry every visual/structural hint
+## Step 4 — Comments carry every textual question; arrows carry relational hints
 
 The two channels have a strict division of labor, always applied the same way — never swap them:
 
 - **Every textual question is a comment.** If the finding is "what happens / who does this / what do we expect" about a single element, it is worded and lives only in a comment. Never draw a text callout on the canvas to carry a question — that content belongs in 4.1, full stop.
-- **Every visual/structural hint is a drawing.** If the finding is inherently about *where things are relative to each other* — a relationship between two elements, or a cluster of elements sharing one concern — it is always additionally drawn on the canvas (4.2), not left as text alone. This isn't a selective "top 3" step; it's determined by the shape of the finding itself: relational or clustered → draw it, every time.
+- **Every relational hint is an arrow.** If the finding is inherently about a relationship between two elements, it is always additionally drawn on the canvas as an arrow (4.2), not left as text alone. This isn't a selective "top 3" step; it's determined by the shape of the finding itself: relational → draw the arrow, every time. A concern spanning a cluster of elements is a comment on the element at its centre — there is no drawing for clusters.
 
 ### 4.1 Comments (every textual question, always)
 
@@ -142,13 +144,13 @@ Post them together, not one at a time: `handle-comment` sends every comment of a
 
 Only post questions that are **genuinely unclear or missing** — don't post observations that are clearly intentional design decisions.
 
-### 4.2 Drawings (every relational or clustered finding, always)
+### 4.2 Arrows (every relational finding, always)
 
 **Prefer MCP:** `mcp__eventmodelers__create_drawing` — one call per drawing, no auth headers needed.
 
 **Fallback (no MCP):** `POST /api/org/{orgId}/boards/{boardId}/drawing/draw` (auth headers same as every other call — `x-token`, `x-user-id: wdyt`). Same fields as the tool args below.
 
-There are two kinds — no text-callout kind; a drawing never carries the question itself, only the shape of the concern:
+There is one kind — no text callout, no group outline; an arrow never carries the question itself, only the relationship:
 
 - **Arrow** (`kind: "path"`, `arrowEnd: true`) — the concern is about a missing or unclear relationship *between two elements* (e.g. "does this event actually reach this automation?"). Draw a straight line from one element's position to the other's. `path` is `M 0 0 L <dx> <dy>` in the box's own local coordinates; `x`/`y`/`width`/`height` describe that box in canvas space (so `width`/`height` = the delta between the two elements' positions).
 ```
@@ -165,25 +167,10 @@ mcp__eventmodelers__create_drawing {
   }]
 }
 ```
-Get element positions from the slice data already loaded in Step 2. If a position is missing, fetch the nodes you need in **one** call — `mcp__eventmodelers__get_nodes { "boardId": "$BOARD_ID", "nodeIds": [<the ids>] }` — not `get_node` per element.
-- **Group loop** (`kind: "rect"`, drawn around a computed bounding box) — the concern spans a *cluster* of elements together (e.g. "this whole flow assumes nothing ever fails"). There's no dedicated group endpoint — union the elements' own `x`/`y`/`width`/`height` (plus some padding) yourself and draw one `rect` around that box:
-```
-mcp__eventmodelers__create_drawing {
-  "boardId": "$BOARD_ID",
-  "drawings": [{
-    "kind": "rect",
-    "x": <minX - pad>,
-    "y": <minY - pad>,
-    "width": <maxX - minX + 2*pad>,
-    "height": <maxY - minY + 2*pad>
-  }]
-}
-```
-This is a visual grouping only — unrelated to the `MODEL_CONTEXT` node type; never touch a `modelContext` field to satisfy this.
-
-Every arrow/group loop is paired with a comment on the relevant node(s) from 4.1 — the drawing makes the concern visible at a glance on the canvas itself, the comment carries the actual worded question. Post both; neither replaces the other.
+Get element positions from the slice data already loaded in Step 2. If a position is missing, fetch the nodes you need in **one** call — `mcp__eventmodelers__get_nodes { "boardId": "$BOARD_ID", "nodeIds": [<the ids>] }` — not `get_node` per element. Keep this read full (no `projection`): positions (`node.position`, width/height) are exactly what `line` leaves out; scoping by `nodeIds` is what keeps it cheap.
+Every arrow is paired with a comment on the relevant node(s) from 4.1 — the arrow makes the concern visible at a glance on the canvas itself, the comment carries the actual worded question. Post both; neither replaces the other.
 
-A finding about a single element with no relational or cluster dimension gets a comment only — don't manufacture an arrow or loop for it just to add a drawing.
+A finding about a single element, or about a cluster, gets a comment only — don't manufacture an arrow for it just to add a drawing.
 
 ---
 

package/stacks/modeling-kit/templates/kit/AGENTS.md

@@ -14,10 +14,11 @@ ones in a compressed, reusable form; only add if not already covered here.
 - `/update-slice-status` rejects moving a slice into a status it's already in — this is a concurrency guard so two agents can't both claim the same slice. Treat this as `ALREADY_IN_STATUS`, not a task failure: drop the prompt, move on to the next task, and do not retry the same update.
 - macOS/BSD `date` silently ignores GNU-only format specifiers like `%N`/`%3N` (sub-second precision) instead of erroring — it prints the literal characters, producing a malformed timestamp that only fails downstream. Don't shell out to `date` for sub-second precision; use `$(( $(date +%s) * 1000 ))` for whole-second-in-ms, or a runtime call (`Date.now()`, `process.hrtime()`) instead.
 - Before retrying a failed shell command a second time, diagnose why it failed (e.g. a GNU/BSD flag mismatch) rather than re-running it unchanged — repeating the same command produces the same failure and just burns retries.
-- A cell address (`B2`, `AE6`) is always read, never computed: `get_board_outline`, `get_nodes` and `get_node` each report a node's `cellName`. An address inferred from a column letter plus a node's place in a list is a guess, and a guess that happens to name an occupied cell is accepted silently by every cell-addressed tool.
+- An existing element is addressed by its `nodeId`, never by a cell. A cell address (`B2`, `AE6`) is only needed to place something into a cell, and it is always read, never computed: `get_board_outline` is the only read that reports a node's `cellName` (`get_nodes`/`get_node` don't). An address inferred from a column letter plus a node's place in a list is a guess, and a guess that happens to name an occupied cell is accepted silently by every cell-addressed tool.
 - Orientation and working set are two different reads, in that order: `get_board_outline` (or `get_nodes` with `projection: "line"`) answers *where is the work*, and only then does one full-`meta` `get_nodes`, scoped by `chapterId`/`nodeIds`, cover the nodes actually being touched. Opening with an unscoped full-`meta` read pulls every field body and rendered HTML page on the board to answer the cheapest question of the turn.
+- Pick each read by what the step needs, cheapest first: `get_nodes` `projection: "line"` when ids/titles/types/attribute names suffice (never carries `sliceStatus`, meta or field types), `get_node` `projection: "cells"`/`"edges"` for a grid or one node's wiring, `get_slice_data` `projection: "outline"`/`"fields"`/`"specs"` (outline/specs only in json/yaml/toon) over the full graph. Full reads only when a later step reads field types, examples, descriptions, positions, HTML or comments. Table: `learn-eventmodelers-api` → *Which read to use*.
 - Both reads are once per turn. A chapter's outline and grid don't move unless something writes to them, so re-read only after a structural write. Three `get_board_outline` calls in one turn means the first two were thrown away.
 - Mint ids once per turn, in one shell: `for i in $(seq <n>); do uuidgen; done` — one per new node, plus one per event, since every event needs its own fresh `id` (required; not the node id). Nothing in it depends on anything being read, so splitting it across several calls buys round trips for nothing. Never mint a per-event `boardId` or `timestamp` — both are server-derived and ignored if sent.
 - A subagent is a fresh session: it gets `token=`/`org=`/`baseUrl=`/`board=` inline as already-resolved values (which satisfies `connect` at its Step 0 — tell it not to invoke `/connect`) plus the board state already read for it, inline. Handed bare node ids instead, it has exactly one way to recover the rest — re-reading the whole board, once per agent.
 - Dispatch executor agents with `model:` set to the session header's `subagent_model` (default `sonnet`). The judging happened before the dispatch, on this session's model; what's left is execution against a written brief. Keep an agent on the session model only where its piece re-derives modeling structure (a chain's shape, a slice boundary).
-- Only slices in status `Created` may be modified. `get_nodes` returns `sliceStatus` per node and `get_board_outline` per column, so the board read at `/connect` Step 5 already answers it — absent means the element is in no slice (writable), not locked. Never spend a `list_slices`/`get_slice_data` call just to check whether you may write.
+- Only slices in status `Created` may be modified. `get_board_outline` returns `sliceStatus` per column (`get_nodes` does not carry it), so the outline read at `/connect` Step 5 already answers it — absent means the column is in no slice (writable), not locked. Never spend a `list_slices`/`get_slice_data` call just to check whether you may write.

package/stacks/modeling-kit/templates/kit/CLAUDE-STANDALONE.md

@@ -43,9 +43,11 @@ Steps:
 
 1. **Get the whole picture, not just the changed nodes — in two reads, not twenty.** The
    whole `changed:` list goes into **one**
-   `mcp__eventmodelers__get_nodes { boardId, nodeIds: [...] }` (or the REST equivalent), and
-   the area around it into **one** `get_board_outline` per chapter those nodes land in; `projection: "line"`
-   is enough for both whenever you only need names, types and slice statuses. That pair is your
+   `mcp__eventmodelers__get_nodes { boardId, nodeIds: [...], projection: "line" }` (REST:
+   `POST .../nodes/query` with `"projection": "line"`), and
+   the area around it into **one** `get_board_outline` per chapter those nodes land in — the outline is the
+   only read that carries slice statuses; `line` gives ids, names, types and attribute names, nothing more (cell names come from the outline).
+   Drop `projection` only if you need field types, examples or descriptions of those nodes. That pair is your
    orientation — and you pay for a chapter's half of it **once per session**: the `SESSION_START` warm-up
    deliberately read no chapter at all, so the first turn that touches one fetches its outline and keeps it,
    and every later turn works from that copy, re-reading only where this turn's `changed:` list says it moved
@@ -124,7 +126,7 @@ Steps:
    - `board_id`, plus the exact target ids (`node_id`/`cellName`/`timelineId`/slice) it owns
      — never "the node that changed";
    - **the board state you already read, inline.** For each target: its id, title and type,
-     its cell (column/row), its `meta.fields` as you loaded them, its `sliceStatus`, and the
+     its cell (column/row), its `meta.fields` as you loaded them, its column's `sliceStatus` (from the outline), and the
      neighbours that bear on the work (the event a read model follows, the chain a field has
      to travel, the persona and values other elements already use). All of it is sitting in
      your step-1 read. An agent handed bare ids has exactly one way to recover it — fetch the

package/stacks/modeling-kit/templates/kit/CLAUDE.md

@@ -51,7 +51,8 @@ On that turn, and only that turn:
    and stop there. Do **not** read any chapter's contents on this turn: a board of a dozen chapters
    read up front is a minute and a dollar spent before anyone has asked for anything, and most of
    what comes back is never used. A chapter is read on the first turn that has business in it (one
-   `get_board_outline`, or `get_nodes` with `projection: "line"`) and **kept** from then on — that
+   `get_board_outline` — the only read that carries slice statuses; `get_nodes` with `projection: "line"`
+   gives just ids, names, types and attribute names) and **kept** from then on — that
    growing set of read chapters is this session's board picture: columns, elements, slice statuses.
    Later turns answer from it instead of re-reading, and refresh only the part a change invalidated.
 
@@ -81,8 +82,8 @@ At the start of every session, read `.agent-modeling-kit/AGENTS.md` if it exists
 `Assigned`, `InProgress`, `Review`, `Blocked`, `Done`, `Informational` — means someone is working
 on that slice: read it for context, but never change, move, rename or delete its elements, and
 never add scenarios, fields or examples to them. An element in no slice at all is not locked.
-`get_nodes` returns `sliceStatus` per node and `get_board_outline` per column, so the board read
-`/connect` Step 5 already makes answers this — no `list_slices`/`get_slice_data` call needed.
+`get_board_outline` returns `sliceStatus` per column (`get_nodes` does not carry it), so the
+outline read `/connect` Step 5 already makes answers this — no `list_slices`/`get_slice_data` call needed.
 If only part of what you were asked to do is locked, do the rest and name what you skipped and
 why; if all of it is, change nothing and post a `COMMENT` on that slice saying which status
 blocked it.
@@ -98,6 +99,10 @@ came back and answer later questions from it instead of re-fetching a chapter yo
 carries the full discipline — the two tiers, the one-call `submit_node_events` rule for writes, and the per-turn
 pool for the ids a `node:created` needs (one for the node, one for the event itself). Whatever you hand a subagent comes out of that same read,
 never out of a second one it pays for itself (step 2).
+**Pick every read by what the step needs, cheapest first**: `get_nodes` `projection: "line"` for ids/titles/types/
+attribute names, `get_node` `projection: "cells"` for a grid and `"edges"` for one node's wiring, and
+`get_slice_data` `projection: "outline"` / `"fields"` / `"specs"` instead of the full graph unless the step needs
+elements, specs and comments together. The decision table is in `learn-eventmodelers-api` → *Which read to use*.
 
 **Every prompt gets exactly two `/update-prompt-status` calls per turn — never zero, never one.** `IN_PROGRESS` before you start the work (step 4), `DONE` after you finish it (step 6). This holds even for a prompt that turns out to be trivial or a no-op — the board UI has no other way to know the agent picked it up and finished it.
 
@@ -124,7 +129,7 @@ mention it in the `DONE` comment, and leave it for a self-directed turn (or for
 
    This also applies **inside** a turn: when the skill you invoke in step 5 internally calls a second skill (e.g. `/add-next-slice` calling `/html-screen` to fill in the new screen), that second skill's own "invoke `connect` first" preamble is already satisfied by the connect you ran this turn — don't run it again just because the sub-skill's instructions say to.
 
-   And it applies **downwards**, to any subagent you dispatch. A subagent is a fresh session that inherits none of this one's state, so hand it `token=`, `org=`, `baseUrl=` and `board=` inline as already-resolved values and tell it explicitly not to invoke `/connect`: all four inline satisfy that skill outright at its Step 0. Three agents that each resolve and verify the same credentials pay for the connect you already did, three more times over.
+   And it applies **downwards**, to any subagent you dispatch. A subagent is a fresh session that inherits none of this one's state, so hand it `token=`, `org=`, `baseUrl=` and `board=` inline as already-resolved values (the token exactly as the header gave it, `token=$EVENTMODELERS_TOKEN` — the reference, never its value; the subagent inherits the same environment) and tell it explicitly not to invoke `/connect`: all four inline satisfy that skill outright at its Step 0. Three agents that each resolve and verify the same credentials pay for the connect you already did, three more times over.
 
    The same "don't reload what's already loaded" logic applies to `/learn-eventmodelers-api`: it's a lookup reference, not a mandatory preamble. Every skill already documents the exact API calls it needs inline — only invoke `/learn-eventmodelers-api` on demand, for a specific endpoint/field/type a skill's own instructions don't cover, and only once per session even then.
 3. **Resolve `BOARD_ID`** from this turn's `board_id` field; if absent, fall back to `boardId` in `.eventmodelers/config.json`.

package/stacks/react/templates/build-kit/lib/backend-prompt.md

@@ -1,135 +1,139 @@
-# Agent Task Instructions
+# Ralph Agent Instructions
+
+You are an autonomous coding agent working on a software project. You apply your skills to build software slices. You only work on one slice at a time.
+
+The structure defined in the Project-Skills is relevant.
+
+## Context Boundary (READ FIRST — NON-NEGOTIABLE)
+
+You work within **exactly ONE context at a time** — the one named in `.build-kit/.slices/current_context.json`.
+
+- **ONLY** look for and build slices inside `.build-kit/.slices/<currentContext>/`.
+- **NEVER** read, scan, or build slices from any other context directory, even if it has "Planned" slices, and even if the current context has no work left.
+- A "Planned" slice in a *different* context is **NOT yours to build**. Ignore it completely.
+- If the current context has no "Planned" slice, you are **done for this iteration** — reply `<promise>NO_TASKS</promise>` and stop. Do not go looking elsewhere. The context is only ever changed on the board, never by you.
+
+## Your Task
+
+0. Do not read the entire code base. Focus on the tasks in this description.
+1. Read `.build-kit/.slices/current_context.json` to find the active context name, then read `.build-kit/.slices/<contextName>/index.json`. Every item in status "planned" is a task.
+2. Read the progress log at `progress.txt` **if it exists** (check Codebase Patterns section first) — it is absent until the first slice is built, which is not an error; create it when you write your first entry
+3. Make sure you are on the right branch "feature/<slicename>", if unsure, start from main.
+5. Pick the **highest priority** slice where status is **exactly** "Planned" (case insensitive). This becomes your PRD. Set the status "InProgress" in the index.json **and** update the slice status on the eventmodelers board using the `update-slice-status` skill (or MCP if available).
+   **IMPORTANT: Only work on slices with status "Planned" in the CURRENT context. Never pick up a slice that is "InProgress", "Done", "Blocked", "Created", or any other status — even if it looks incomplete. If no slice has status "Planned" in the current context, reply with:**
+   <promise>NO_TASKS</promise> and stop immediately. Do not work on other slices and do not switch to another context.
+   **Claim conflict**: the board rejects the status update if the slice is already in the target status — this is expected: another agent claimed it first, racing you for the same slice. This is NOT an error. Do not stop, do not retry the same slice. Re-read `index.json` (or re-fetch via `load-slice`), pick the next-highest-priority slice still "Planned", and try claiming that one instead. Repeat until a claim succeeds or no "Planned" slice remains, in which case reply `<promise>NO_TASKS</promise>`.
+6. Pick the slice definition from `.build-kit/.slices/<contextName>/<folder>/slice.json` as defined in the prd. Never work on more than one slice per iteration.
+7. A slice can define additional prompts as codegen/backendPrompt. Any additional prompts defined in backend are hints for the implementation of the slice and have to be taken into account. If you use the additional prompt, add a line in progress.txt
+7. Determine the slice type and invoke the matching skill as defined in the **Building a Slice** section of `.build-kit/CLAUDE.md`. Do NOT implement manually.
+8. Write a short progress one liner after each step to progress.txt
+9. Analyze and Implement that single slice, making use of the skills in the skills directory plus your previously collected knowledge. Make a TODO list for what needs to be done, and adjust the implementation according to the JSON definition. Carefully inspect events, fields and compare against the implemented slice. JSON is the desired state. ATTENTION: a "planned" task can also be just added specifications. So always look at the slice itself, but also the specifications. If specifications were added in json which are not on code, you need to add them in code.
+10. The slice in the json is always true, the code follows what is defined in the json
+11. Slice is only 'Done' if business logic is implemented as defined in the JSON, APIs are implemented, all scenarios in JSON are implemented in code and it fulfills the slice.json. There must be no specification in json that has no equivalent in code.
+12. Make sure to write the ui-prompt.md as defined if defined in the skill
+13. Run quality checks — TODO: your stack's build command, TODO: your stack's test command (slice-scoped only; do not run all tests).
+14. If checks pass, commit ALL changes with message: `feat: [Slice Name]` and merge back to main as FF merge (update first)
+15. Update the PRD to set `status: Done` for the completed story in index.json **and** update the slice status on the eventmodelers board using the `update-slice-status` skill (or MCP if available).
+16. Append your progress to `progress.txt` after each step in the iteration.
+17. Append your new learnings to `.build-kit/AGENTS.md` in a compressed form, reusable for future iterations. Only add learnings if they are not already there.
+18. Finish the iteration.
 
-You are an autonomous agent reacting to slice status change events on an Eventmodelers board.
-
-## Your Loop
+## Escalating Ambiguity
 
-1. Read `AGENT.md` to load accumulated learnings before doing anything else.
-2. Read `.build-kit/tasks.json`.
-3. If `tasks.json` is empty or missing, reply with:
-   <promise>IDLE</promise>
-   and stop.
-4. Pick the **oldest task** (earliest `createdAt`).
-5. Execute the task — see the Execution section below.
-6. After execution, remove that task from the array and write `.build-kit/tasks.json` back.
-7. Append a progress entry to `progress.txt` (create if missing).
-8. Update `AGENT.md` with any new reusable learnings discovered this iteration.
-9. Reply normally so the next iteration can pick up the next task.
+**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
+in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
+specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
+board (overriding the `InProgress` set in step 5), then stop this iteration without finishing the
+build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
+implement the slice. This is an escalation path, not a routine step — read the slice.json and the
+matching build skill's own instructions fully first; most slices are fully specified and need none of
+this.
 
-## Execution
+## Progress Report Format
 
-Each task has a single `payload` of type `SliceChangedPayload`:
+APPEND to progress.txt (never replace, always append):
 
 ```
-{
-  event:          "slice:changed"
-  organizationId: string | null
-  boardId:        string
-  sliceId:        string   ← SLICE_BORDER node UUID
-  sliceTitle:     string | null
-  sliceStatus:    string | null   ← e.g. "InProgress", "Done", "Blocked"
-  timestamp:      number
-}
+## [Date/Time] - [Slice]
+
+- What was implemented
+- Files changed
+- **Learnings for future iterations:**
+  - Patterns discovered (e.g., "this codebase uses X for Y")
+  - Gotchas encountered (e.g., "don't forget to update Z when changing W")
+  - Useful context (e.g., "the evaluation panel is in component X")
+---
 ```
 
-### Step 1 — Load credentials
-
-Run `/connect` to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL` from `.eventmodelers/config.json`.
-
-### Step 2 — Load the slice
-
-Run `/load-slice sliceId=<payload.sliceId>` to fetch full slice details (title, status, raw node record).
-
-### Step 3 — Act on the change
-
-Inspect the `sliceStatus` in the payload:
-
-#### `Planned` — build the slice
-
-This is the build trigger. Setting `InProgress` and building are one atomic step:
-
-1. Immediately call `/update-slice-status` to set the slice to `InProgress` on the board.
-
-   **Claim conflict**: if this call reports the slice is already in `InProgress` (or any status other than `Planned`), another agent already claimed it first — this is expected, not an error. Log it in `progress.txt`, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
-
-2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).
+The learnings section is critical - it helps future iterations avoid repeating mistakes and understand the codebase better.
 
-3. Determine the **slice type** from the slice.json:
-   - **Translation** — `sliceType === "TRANSLATION"` → read `description` and `notes` from slice.json for hints; default to `/build-automation` if nothing else is specified
-   - **Automation** — `processors` array is non-empty → invoke `/build-automation`
-   - **State-view** — `projections` or `queries` array is non-empty → invoke `/build-state-view`
-   - **State-change** — default (has `commands` / `events`) → invoke `/build-state-change`
+## Consolidate Patterns
 
-4. Invoke the matching skill and follow its instructions **completely**. Do NOT implement the slice manually.
+If you discover a **reusable pattern** that future iterations should know, add it to the `## Codebase Patterns` section at the TOP of progress.txt (create it if it doesn't exist).
 
-5. **Verify against slice.json**: cross-check the implementation — every command field, event field, and specification in slice.json must appear in the code. No invented fields — if it is not in slice.json, it must not be in the code.
-
-6. Run quality checks (TODO: your stack's build + test commands — slice-scoped tests only, not the full suite).
-
-7. If checks pass, commit all changes with message: `feat: [Slice Name]`.
+```
+## Codebase Patterns
+- TODO: an example of a your stack-specific reusable pattern once you have one
+```
 
-8. Call `/update-slice-status` to set the slice to `Done` on the board.
+Only add patterns that are **general and reusable**, not story-specific details.
 
-#### `InProgress`
-Another agent is already building this slice. Log it and skip — do not build.
+## Update AGENTS.md Files
 
-#### `Done`
-Summarize what was completed and update `progress.txt`.
+Before committing, check if any edited files have learnings worth preserving in nearby AGENTS.md files — API patterns/conventions, gotchas, dependencies between files, testing approaches, configuration/environment requirements.
 
-#### `Blocked`
-Log the blocker in `progress.txt`.
+**Do NOT add:**
 
-#### `Review`
-Fetch slice details and prepare a review summary in `progress.txt`.
+- Slice specific implementation details
+- Story-specific implementation details
+- Temporary debugging notes
+- Information already in progress.txt
+- Task-specific learnings
 
-#### Any other status (`Created`, etc.)
-Load the slice and log the state transition in `progress.txt`. No build action.
+Only update AGENTS.md if you have **genuinely reusable knowledge** that would help future work
 
-Use the skills available in `.claude/skills/` to interact with the board.
+## Quality Requirements
 
-## Updating tasks.json
+- ALL commits must pass this project's quality checks (typecheck/compile, lint, test)
+- TODO: your stack's build command
+- TODO: your stack's test command
+- Do NOT commit broken code
+- Keep changes focused and minimal
+- Follow existing code patterns
 
-After completing a task, remove it from the array and write the updated array back to `.build-kit/tasks.json`. If the array is now empty, write `[]`.
+## Skills
 
-## Escalating Ambiguity
+Use the provided skills in the skills folder as guidance.
+Update skill definitions if you find an improvement you can make.
 
-**If the slice's requirements are genuinely ambiguous, contradictory, or missing a decision you need
-in order to proceed — do not guess, and do not build anyway.** Invoke `/request-feedback` with the
-specific question; it posts the question as a comment on the slice and marks it `Blocked` on the
-board (overriding the `InProgress` set earlier), then stop this iteration without finishing the
-build — reply `<promise>DONE</promise>` as if the iteration's work was to raise the question, not to
-implement the slice. This is an escalation path, not a routine step — read the slice.json and the
-matching build skill's own instructions fully first; most slices are fully specified and need none of
-this.
+## Specifications
 
-## Progress Report Format
+For every specification added to the Slice, you need to implement one executable Specification in Code.
 
-APPEND to `progress.txt` (never replace):
-```
-## [ISO timestamp] — Task [task.id]
+A Slice is not complete if specifications are missing or can't be executed.
 
-Slice: [sliceTitle] ([sliceId])
-Status change: [sliceStatus]
+## Stop Condition
 
-Action taken:
-- [what was done in response to the slice change]
+**After completing ONE slice, always stop — regardless of whether more slices are Planned.** The ralph loop will invoke you again for the next slice. Never chain multiple slices in one iteration.
 
-Learnings:
-- [any patterns, gotchas, or reusable knowledge discovered]
----
-```
+If the slice was completed and committed successfully, reply with:
+<promise>DONE</promise>
 
-## Stop Condition
+If no slice has status "Planned" in the current context, reply with:
+<promise>NO_TASKS</promise>
+(Do NOT switch to another context to find work — stop here.)
 
-If `.build-kit/tasks.json` is empty (`[]`) or does not exist, reply with:
-<promise>IDLE</promise>
+If ALL slices in the current context are Done, reply with:
+<promise>COMPLETE</promise>
 
-## Updating AGENT.md
+## Important
 
-After completing a task, add any **reusable** learnings to `AGENT.md` — patterns, gotchas, API quirks, or skill behaviour that future iterations should know. Only add things that are general and applicable beyond this single task. Do not duplicate what is already there.
+- If `.build-kit/.eventmodelers/config.json` is absent, skip all platform communication (MCP calls, `update-slice-status`, board sync) and continue working locally.
+- Work on ONE slice per iteration
+- Commit frequently
+- update progress.txt frequently
+- Read the Codebase Patterns section in progress.txt before starting
 
-## Important
+## When an iteration completes
 
-- Process **one task per iteration**.
-- Read `AGENT.md` first — it contains patterns from previous iterations.
-- Always start with `/connect` if credentials are not yet loaded.
+Use all the key learnings from the progress.txt and update the `.build-kit/AGENTS.md` file with those learnings.