@eventmodelers/cli 0.0.1

package/stacks/node/templates/.claude/skills/load-slice/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: load-slice
+description: Load all slices from the board via the slicedata API and persist them to the .build-kit/.slices/ directory hierarchy (index.json with full definitions, per-slice folders). Returns data for a specific slice by ID or title.
+---
+
+# Load Slice
+
+> **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 |
+|-------|---------------|---------|
+| `sliceId` | UUID of the slice (SLICE_BORDER node ID) | optional — prefer over title |
+| `sliceTitle` | slice title (case-insensitive match) | optional — used if sliceId missing |
+
+If neither is provided, load and persist all slices without filtering.
+
+---
+
+## Step 2 — Fetch all slices from the slicedata API
+
+```bash
+curl -s \
+  -H "x-token: <TOKEN>" \
+  -H "x-board-id: <BOARD_ID>" \
+  -H "x-user-id: load-slice-skill" \
+  "<BASE_URL>/api/org/<ORG_ID>/boards/<BOARD_ID>/slicedata/slices"
+```
+
+Response shape: `{ "slices": [ { "id": "...", "title": "...", "status": "...", "contextName": "...", "contextId": "...", "comments": ["..."], ... } ] }`
+
+Save the full array as `ALL_SLICES`.
+
+---
+
+## Step 3 — Persist slices to .build-kit/.slices/ directory
+
+Apply the following logic for every slice in `ALL_SLICES`.
+
+### Derive paths
+
+- `contextSlug` = slugify `slice.contextName` if present, otherwise `"default"` — lowercase, spaces to hyphens, non-alphanumeric removed (e.g. `"My Ctx"` → `"my-ctx"`)
+- `sliceFolder` = `slice.title` lowercased, with all spaces removed and the prefix `"slice:"` stripped  
+  e.g. `"Beta Enable User for Beta Test"` → `"betaenableuserforbetatest"`
+- `baseFolder` = `.build-kit/.slices/<contextSlug>/`
+- `sliceDir`   = `.build-kit/.slices/<contextSlug>/<sliceFolder>/`
+
+### Write files
+
+```bash
+mkdir -p ".build-kit/.slices/<contextSlug>/<sliceFolder>"
+```
+
+**`.build-kit/.slices/current_context.json`** — always overwrite:
+
+```json
+{ "name": "Beta" }
+```
+
+**`.build-kit/.slices/<contextSlug>/context.json`** — write once per context:
+
+```json
+{ "name": "Beta" }
+```
+
+**`.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`** — the full slice object with the `index` field removed.
+
+### Maintain `.build-kit/.slices/<contextSlug>/index.json`
+
+Read the file if it exists, otherwise start with `{ "slices": [] }`.
+
+Each entry in `index.json` contains the index metadata **plus** the complete slice definition fetched from the API:
+
+```json
+{
+  "slices": [
+    {
+      "id": "d0dbc70c-f244-4048-886b-1d11e461f466",
+      "slice": "Beta Enable User for Beta Test",
+      "index": 0,
+      "contextName": "Beta",
+      "contextSlug": "beta",
+      "folder": "betaenableuserforbetatest",
+      "status": "Created",
+      "definition": {
+        "id": "d0dbc70c-f244-4048-886b-1d11e461f466",
+        "title": "Beta Enable User for Beta Test",
+        "status": "Created",
+        "contextName": "Beta",
+        "contextId": "..."
+      }
+    }
+  ]
+}
+```
+
+The `definition` field holds the full object returned by the API for that slice (all fields as-is).
+
+**Merge rules:**
+- If an entry with the same `id` already exists: update all fields and refresh `definition`; preserve any existing `assigned` field.
+- If not found: append the new entry.
+
+Write the updated object back to `.build-kit/.slices/<contextSlug>/index.json`.
+
+---
+
+## Step 4 — Return the requested slice
+
+If `sliceId` was given: find the entry in `ALL_SLICES` where `id === sliceId`.  
+If `sliceTitle` was given: find the entry where `title` matches case-insensitively.  
+If neither: return all slices.
+
+If a specific slice was requested but not found, stop and list the available titles.
+
+---
+
+## Step 5 — Output
+
+```
+Slices loaded: <count> total
+Persisted to: .build-kit/.slices/<contextSlug>/
+
+Requested slice:
+  Title:  <title>
+  ID:     <id>
+  Status: <status>
+  Folder: .build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json
+```
+
+Or if no filter was given:
+
+```
+All slices (<count>) — context: <contextSlug>:
+  - <title> [<status>] → .build-kit/.slices/<contextSlug>/<sliceFolder>/
+  - ...
+```
+
+Make the matched slice's `id`, `title`, `status`, and local folder path available to subsequent steps in the same session.

package/stacks/node/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. Callers trying to claim a `Planned` slice for building should treat this as a signal to pick a different slice, not to stop.
+
+---
+
+## 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/node/templates/build-kit/README.md

@@ -0,0 +1,86 @@
+# .build-kit
+
+Ralph's runtime directory. Contains the agent loop, realtime subscription, prompts, and Claude skills.
+
+## Quick start
+
+```bash
+# Claude (default)
+node .build-kit/ralph-claude.js
+
+# Local Ollama model — run `ollama serve` first
+OLLAMA_MODEL=qwen3:8b node .build-kit/ralph-ollama.js
+
+# Custom project directory (defaults to the parent of .build-kit)
+node .build-kit/ralph-claude.js /path/to/project
+```
+
+## Files
+
+**Entry points** (top level):
+
+| File | Purpose |
+|------|---------|
+| `ralph-claude.js` | Runs the full loop using Claude Code as the executor |
+| `ralph-ollama.js` | Runs the full loop using a local Ollama model |
+| `ralph.sh` | Shell-based loop — alternative to the JS entry points |
+| `realtime-agent.js` | Standalone realtime agent — only needed to run it in a separate terminal |
+
+**Internals** (`lib/`):
+
+| File | Purpose |
+|------|---------|
+| `lib/ralph.js` | Shared library — realtime agent + loop logic; imported by the entry points |
+| `lib/ollama-agent.js` | Ollama executor — called by `ralph-ollama.js`, can also run manually |
+| `lib/agent.sh` | Thin shell wrapper around `claude` — called by `ralph.sh` |
+| `lib/prompt.md` | Phase 1 prompt: tells Claude how to load a slice from the board |
+| `lib/backend-prompt.md` | Phase 2 prompt: tells Claude how to build a planned slice |
+| `lib/AGENT.md` | Agent instructions included in Claude's context |
+
+## How it works
+
+**Phase 1** — triggered when `tasks.json` has entries:
+- The realtime agent writes a task to `tasks.json` each time a `slice:changed` event arrives from the board
+- The loop picks it up and runs Claude (or Ollama) with `prompt.md`
+- Claude loads the slice data and updates `.slices/`
+
+**Phase 2** — triggered when any file in `.slices/` contains `"status": "Planned"`:
+- The loop runs Claude with `backend-prompt.md`
+- Claude implements the slice in the project
+- Phase 2 is Claude-only; Ollama mode skips it (ollama-agent handles its own queue)
+
+Both phases run in a continuous loop with a 3-second idle sleep. The realtime agent runs concurrently in the same process.
+
+## Running the realtime agent separately
+
+If you want the board subscription in one terminal and the Claude loop in another:
+
+```bash
+# Terminal 1 — realtime agent only
+node .build-kit/realtime-agent.js
+
+# Terminal 2 — loop only (poll tasks.json without the realtime subscription)
+.build-kit/ralph.sh
+```
+
+## Ollama configuration
+
+```bash
+OLLAMA_MODEL=qwen3:8b          # model to use (default: qwen3:8b)
+OLLAMA_URL=http://host:11434   # Ollama server URL (default: http://localhost:11434)
+```
+
+## Config
+
+Credentials are stored in `.build-kit/.eventmodelers/config.json` (written by `ralph-li install`):
+
+```json
+{
+  "organizationId": "...",
+  "boardId": "...",
+  "token": "...",
+  "baseUrl": "https://api.eventmodelers.ai"
+}
+```
+
+Claude skills live in `.build-kit/.claude/skills/` and are available inside any Claude Code session started from `.build-kit/`.

package/stacks/node/templates/build-kit/lib/AGENT.md

@@ -0,0 +1,47 @@
+# Agent Learnings
+
+Patterns and gotchas discovered during task processing. Update this file whenever you encounter something reusable.
+
+## tasks.json
+
+- Tasks are objects with `id`, `createdAt`, and `payload` (a `SliceChangedPayload`).
+- After completing a task, remove it from the array entirely — do not add a status field.
+- Write `[]` to `tasks.json` if the last task is completed.
+
+## SliceChangedPayload fields
+
+```
+event           always "slice:changed"
+organizationId  org UUID or null
+boardId         board UUID
+sliceId         SLICE_BORDER node UUID — use this with /load-slice
+sliceTitle      human-readable slice name (may be null)
+sliceStatus     e.g. "Created", "InProgress", "Done", "Blocked" (may be null)
+timestamp       unix ms when the change was emitted
+```
+
+## Slice files
+
+The realtime agent writes one file per slice on startup and after each `slice:changed` event:
+
+```
+.slices/<context>/<sliceName>.json
+```
+
+- `<context>` is the slice's context value, or `default` if none.
+- `<sliceName>` is the slice title lowercased with spaces and the `"slice:"` prefix removed (e.g. `"slice: Enable User"` → `enableuser`).
+
+These files are always up to date — read them directly before invoking any skill.
+
+## Skill Usage
+
+- Always run `/connect` first to load credentials from `.eventmodelers/config.json` before calling any other skill.
+- `/load-slice sliceId=<uuid>` re-fetches all slices from the API, refreshes the slice files, and returns the requested slice. Use it when you need a guaranteed-fresh view of a specific slice.
+- Read `.slices/<context>/<sliceName>.json` directly when you already know the context and name and the file is recent enough.
+
+## Board API
+
+- The `boardId` and `organizationId` from each payload provide full context — pass them to skills.
+- Node events use `node:created`, `node:changed`, `node:deleted` — always POST to `/api/org/:orgId/boards/:boardId/nodes/events`.
+- Slice metadata (title, status) lives on the SLICE_BORDER node under `meta.sliceStatus` and `meta.title`.
+- `/update-slice-status` rejects moving a slice into a status it's already in — this is a concurrency guard, not a bug. It means another agent already claimed the slice. Treat it as `ALREADY_IN_STATUS`, skip that slice, and move on to the next `Planned` one instead of erroring out.

package/stacks/node/templates/build-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.5:9b}"
+# node "$(dirname "$0")/ollama-agent.js" "$MODEL"

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

@@ -0,0 +1,152 @@
+# 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 (e.g. "Rename organization" while you are in "Board Invitations") 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` (check Codebase Patterns section first)
+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 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, make use of the skills in the skills directory, but also your previsously collected
+   knowledge. Make a list TODO list for what needs to be done. Also make sure to 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 ( npm run build, npm run test ) - Attention - it´s enough to run the tests for the slice. Do not run all tests.
+14. even if the slice is fully implemented, run your test-analyzer skill and provide the code-slice.json file as defined in the skill
+15. If checks pass, commit ALL changes with message: `feat: [Slice Name]` and merge back to main as FF merge ( update
+    first )
+16. 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).
+17. Append your progress to `progress.txt` after each step in the iteration.
+18. append your new learnings to AGENTS.md in a compressed form, reusable for future iterations. Only add learnings if they are not already there.
+19. Finish the iteration.
+
+## Progress Report Format
+
+APPEND to progress.txt (never replace, always append):
+
+```
+## [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")
+---
+```
+
+The learnings section is critical - it helps future iterations avoid repeating mistakes and understand the codebase
+better.
+
+## Consolidate Patterns
+
+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). This section should consolidate the most important
+learnings:
+
+```
+## Codebase Patterns
+- Example: Use `sql<number>` template for aggregations
+- Example: Always use `IF NOT EXISTS` for migrations
+- Example: Export types from actions.ts for UI components
+```
+
+Only add patterns that are **general and reusable**, not story-specific details.
+
+## Update AGENTS.md Files
+
+Before committing, check if any edited files have learnings worth preserving in nearby AGENTS.md files:
+
+1. **Identify directories with edited files** - Look at which directories you modified
+3. **Add valuable learnings that apply to all tasks** to the Agents.md - If you discovered something future developers/agents should know:
+    - API patterns or conventions specific to that module
+    - Gotchas or non-obvious requirements
+    - Dependencies between files
+    - Testing approaches for that area
+    - Configuration or environment requirements
+
+**Examples of good AGENTS.md additions:**
+
+- "When modifying X, also update Y to keep them in sync"
+- "This module uses pattern Z for all API calls"
+- "Tests require the dev server running on PORT 3000"
+- "Field names must match the template exactly"
+
+**Do NOT add:**
+
+- Slice specific implementation details
+- Story-specific implementation details
+- Temporary debugging notes
+- Information already in progress.txt
+- Task speecific learnings like "- Timesheet approval requires: submitted=true, reverted=false, approved=false, declined=false"
+
+Only update AGENTS.md if you have **genuinely reusable knowledge** that would help future work
+
+## Quality Requirements
+
+- ALL commits must pass your project's quality checks (typecheck, lint, test)
+- run 'npm run build'
+- run 'npm run test'
+- Do NOT commit broken code
+- Keep changes focused and minimal
+- Follow existing code patterns
+
+## Skills
+
+Use the provided skills in the skills folder as guidance.
+Update skill definitions if you find an improvement you can make.
+
+## Specifications
+
+For every specification added to the Slice, you need to implement one use executable Specification in Code.
+
+A Slice is not complete if specifications are missing or can´t be executed.
+
+## Stop Condition
+
+**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.
+
+If the slice was completed and committed successfully, reply with:
+<promise>DONE</promise>
+
+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 ALL slices in the current context are Done, reply with:
+<promise>COMPLETE</promise>
+
+## Important
+
+- 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
+
+## When an iteration completes
+
+Use all the key learnings from the project.txt and update the Agends.md file with those learning.

package/stacks/node/templates/build-kit/lib/prompt.md

@@ -0,0 +1,122 @@
+# Agent Task Instructions
+
+You are an autonomous agent reacting to slice status change events on an Eventmodelers board.
+
+## Your Loop
+
+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.
+
+## Execution
+
+Each task has a single `payload` of type `SliceChangedPayload`:
+
+```
+{
+  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
+}
+```
+
+### 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`).
+
+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`
+
+4. Invoke the matching skill and follow its instructions **completely**. Do NOT implement the slice manually.
+
+5. Run quality checks (`npm run build`, then the slice tests only — not the full test suite).
+
+6. If checks pass, commit all changes with message: `feat: [Slice Name]`.
+
+7. Call `/update-slice-status` to set the slice to `Done` on the board.
+
+#### `InProgress`
+Another agent is already building this slice. Log it and skip — do not build.
+
+#### `Done`
+Summarize what was completed and update `progress.txt`.
+
+#### `Blocked`
+Log the blocker in `progress.txt`.
+
+#### `Review`
+Fetch slice details and prepare a review summary in `progress.txt`.
+
+#### Any other status (`Created`, etc.)
+Load the slice and log the state transition in `progress.txt`. No build action.
+
+Use the skills available in `.claude/skills/` to interact with the board.
+
+## Updating tasks.json
+
+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 `[]`.
+
+## Progress Report Format
+
+APPEND to `progress.txt` (never replace):
+```
+## [ISO timestamp] — Task [task.id]
+
+Slice: [sliceTitle] ([sliceId])
+Status change: [sliceStatus]
+
+Action taken:
+- [what was done in response to the slice change]
+
+Learnings:
+- [any patterns, gotchas, or reusable knowledge discovered]
+---
+```
+
+## Stop Condition
+
+If `.build-kit/tasks.json` is empty (`[]`) or does not exist, reply with:
+<promise>IDLE</promise>
+
+## Updating AGENT.md
+
+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.
+
+## Important
+
+- 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.