@eventmodelers/cli 1.0.45 → 1.0.47

package/shared/skills/request-feedback/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: request-feedback
-description: Post a QUESTION comment on a slice and mark it Blocked when the slice's requirements are genuinely ambiguous, contradictory, or missing something a decision depends on. This is an escalation path, not a routine step — reach for it only when you cannot proceed without guessing.
+description: Post a comment on a slice and mark it Blocked when the slice's requirements are genuinely ambiguous, contradictory, or missing something a decision depends on. This is an escalation path, not a routine step — reach for it only when you cannot proceed without guessing.
 ---
 
 # Request Feedback
@@ -57,7 +57,7 @@ From `$ARGUMENTS` or the calling skill's context, extract:
 |-------|---------------|---------|
 | `sliceName` or `sliceId` | the slice being worked on | **required** — one of the two |
 | `question` | the specific ambiguity or missing piece, phrased as a question | **required** |
-| `author` | author identifier string | `agent` |
+| `author` | author identifier string | `agent-$CLAUDE_CODE_SESSION_ID` (falls back to `agent` if that env var is unset) |
 
 ## Step 2 — Resolve the slice's node id
 
@@ -81,12 +81,14 @@ Find the slice whose `title` matches `sliceName` (case-insensitive), or whose `i
 If no match is found, stop and list the available slice titles so the caller can pick one. Save the
 matched slice's `id` as `SLICE_NODE_ID` and its current `status` as `CURRENT_STATUS`.
 
-## Step 3 — Post the QUESTION comment
+## Step 3 — Post the comment
+
+There is no separate `QUESTION` type at the API level — post a normal `COMMENT` worded as a question.
 
 Prefer MCP:
 
 ```
-mcp__eventmodelers__add_comment { "boardId": "<BOARD_ID>", "nodeId": "<SLICE_NODE_ID>", "text": "<question>", "type": "QUESTION", "author": "<author>" }
+mcp__eventmodelers__add_comment { "boardId": "<BOARD_ID>", "nodeId": "<SLICE_NODE_ID>", "text": "<question>", "type": "COMMENT", "author": "<author>" }
 ```
 
 **Fallback (no MCP):**
@@ -95,7 +97,7 @@ mcp__eventmodelers__add_comment { "boardId": "<BOARD_ID>", "nodeId": "<SLICE_NOD
 curl -s -X POST "<BASE_URL>/api/org/<ORG_ID>/boards/<BOARD_ID>/nodes/<SLICE_NODE_ID>/comments" \
   -H "Authorization: Bearer <TOKEN>" \
   -H "Content-Type: application/json" \
-  -d '{"text":"<question>","type":"QUESTION","author":"<author>"}'
+  -d '{"text":"<question>","type":"COMMENT","author":"<author>"}'
 ```
 
 Response: `201 {"id":"<commentId>"}`. Save it as `COMMENT_ID` — the calling skill may want to reference

package/stacks/axon/templates/build-kit/CLAUDE.md

@@ -58,7 +58,7 @@ When asked to build a slice, always follow this flow:
    - **State-view** — `projections` or `queries` array is non-empty → invoke `/build-state-view`
    - **State-change** — default (has `commands` / `events`) → invoke `/build-state-change`
 3. Invoke the matching skill and follow its instructions completely. Do not deviate.
-4. **Verify against slice.json**: After the skill completes, check that every command field, event field, and specification in slice.json appears in the implementation. No invented fields — if it is not in slice.json, it must not be in the code.
+4. **Verify against slice.json**: After the skill completes, check that every command field, event field, and specification in slice.json appears in the implementation. No invented fields — if it is not in slice.json, it must not be in the code. This applies even when the slice was previously `Done` and reappears as `Planned` — never dismiss a mismatch as "already implemented" or harmless drift; diff slice.json against the code field by field and update the code to match every change.
 5. Run quality checks (`./mvnw compile -q`, then the slice tests only).
 6. If checks pass, commit with `feat: [Slice Name]` and set slice status to `Done`.
 

package/stacks/blank/templates/build-kit/CLAUDE.md

@@ -48,7 +48,7 @@ When asked to build a slice, always follow this flow:
    - **State-view** — `projections` or `queries` array is non-empty → invoke `/build-state-view`
    - **State-change** — default (has `commands` / `events`) → invoke `/build-state-change`
 3. Invoke the matching skill and follow its instructions completely. Do not deviate.
-4. **Verify against slice.json**: After the skill completes, check that every command field, event field, and specification in slice.json appears in the implementation. No invented fields — if it is not in slice.json, it must not be in the code.
+4. **Verify against slice.json**: After the skill completes, check that every command field, event field, and specification in slice.json appears in the implementation. No invented fields — if it is not in slice.json, it must not be in the code. This applies even when the slice was previously `Done` and reappears as `Planned` — never dismiss a mismatch as "already implemented" or harmless drift; diff slice.json against the code field by field and update the code to match every change.
 5. Run quality checks (TODO: this stack's build + test commands), then the slice tests only.
 6. If checks pass, commit with `feat: [Slice Name]` and set slice status to `Done`.
 

package/stacks/blank/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` (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 `.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.

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

@@ -1,139 +1,135 @@
-# 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` (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 `.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.
+# Agent Task Instructions
 
-## Escalating Ambiguity
+You are an autonomous agent reacting to slice status change events on an Eventmodelers board.
 
-**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.
+## Your Loop
 
-## Progress Report Format
+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.
 
-APPEND to progress.txt (never replace, always append):
+## Execution
+
+Each task has a single `payload` of type `SliceChangedPayload`:
 
 ```
-## [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")
----
+{
+  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
+}
 ```
 
-The learnings section is critical - it helps future iterations avoid repeating mistakes and understand the codebase better.
+### Step 1 — Load credentials
 
-## Consolidate Patterns
+Run `/connect` to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL` from `.eventmodelers/config.json`.
 
-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).
+### Step 2 — Load the slice
 
-```
-## Codebase Patterns
-- TODO: an example of a your stack-specific reusable pattern once you have one
-```
+Run `/load-slice sliceId=<payload.sliceId>` to fetch full slice details (title, status, raw node record).
 
-Only add patterns that are **general and reusable**, not story-specific details.
+### Step 3 — Act on the change
 
-## Update AGENTS.md Files
+Inspect the `sliceStatus` in the payload:
 
-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.
+#### `Planned` — build the slice
 
-**Do NOT add:**
+This is the build trigger. Setting `InProgress` and building are one atomic step:
 
-- Slice specific implementation details
-- Story-specific implementation details
-- Temporary debugging notes
-- Information already in progress.txt
-- Task-specific learnings
+1. Immediately call `/update-slice-status` to set the slice to `InProgress` on the board.
 
-Only update AGENTS.md if you have **genuinely reusable knowledge** that would help future work
+   **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.
 
-## Quality Requirements
+2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).
 
-- 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
+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`
 
-## Skills
+4. Invoke the matching skill and follow its instructions **completely**. Do NOT implement the slice manually.
 
-Use the provided skills in the skills folder as guidance.
-Update skill definitions if you find an improvement you can make.
+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.
 
-## Specifications
+6. Run quality checks (TODO: your stack's build + test commands — slice-scoped tests only, not the full suite).
 
-For every specification added to the Slice, you need to implement one executable Specification in Code.
+7. If checks pass, commit all changes with message: `feat: [Slice Name]`.
 
-A Slice is not complete if specifications are missing or can't be executed.
+8. Call `/update-slice-status` to set the slice to `Done` on the board.
 
-## Stop Condition
+#### `InProgress`
+Another agent is already building this slice. Log it and skip — do not build.
 
-**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.
+#### `Done`
+Summarize what was completed and update `progress.txt`.
 
-If the slice was completed and committed successfully, reply with:
-<promise>DONE</promise>
+#### `Blocked`
+Log the blocker in `progress.txt`.
 
-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.)
+#### `Review`
+Fetch slice details and prepare a review summary in `progress.txt`.
 
-If ALL slices in the current context are Done, reply with:
-<promise>COMPLETE</promise>
+#### Any other status (`Created`, etc.)
+Load the slice and log the state transition in `progress.txt`. No build action.
 
-## Important
+Use the skills available in `.claude/skills/` to interact with the board.
+
+## Updating tasks.json
 
-- 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
+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 `[]`.
 
-## When an iteration completes
+## Escalating Ambiguity
+
+**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.
+
+## 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
 
-Use all the key learnings from the progress.txt and update the `.build-kit/AGENTS.md` file with those learnings.
+- 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.

package/stacks/cratis-csharp/templates/build-kit/CLAUDE.md

@@ -16,6 +16,15 @@ then stop work on this slice for this run. This is an escalation path, not a rou
 `slice.json` and the matching build skill's own instructions fully first; most slices are fully
 specified and need none of this.
 
+## No such thing as harmless drift
+
+`slice.json` is always the desired state — the code follows what it defines, never the other way
+around. If code for a slice already exists — most often because it was previously `Done` and got moved
+back to `Planned` — never conclude "already implemented" and move on. A slice does not return to
+`Planned` without a reason: diff the current `slice.json` against the existing implementation field by
+field (events, commands, params, specifications, routes) and update the code to match every difference
+you find. Only mark it `Done` once there is no gap left.
+
 ## Structure (learn from `SomeModule/SomeFeature/`)
 
 ```