@eventmodelers/cli 1.0.18 → 1.0.20

package/README.md

@@ -94,8 +94,9 @@ Use skills in Claude Code with `/skill-name`:
 | `/update-slice-status` | Update slice status on the board |
 | `/load-slice` | Persist board slices to disk (backend stacks) |
 | `/build-state-change`, `/build-state-view`, `/build-automation`, `/build-webhook` | Implement a slice's command/view/automation/webhook (backend stacks) |
+| `/request-feedback` | Post a QUESTION comment and mark a slice `Blocked` when it's genuinely ambiguous (backend stacks) |
 
-Which skills install depends on the chosen stack — see `stacks/<name>/templates/.claude/skills/`. `/connect`, `/learn-eventmodelers-api`, and `/update-slice-status` have no stack-specific content and install into every stack from `shared/skills/` instead.
+Which skills install depends on the chosen stack — see `stacks/<name>/templates/.claude/skills/`. `/connect`, `/learn-eventmodelers-api`, `/update-slice-status`, and `/request-feedback` have no stack-specific content and install into every stack from `shared/skills/` instead.
 
 ## Everyday commands
 
@@ -346,7 +347,7 @@ npx @eventmodelers/cli uninstall --modeling-kit      # remove .agent-modeling-ki
 
 ### Adding a stack
 
-Each stack lives under `stacks/<name>/templates/` with `.claude/` (skills), `root/` (spread into the project root), and either `build-kit/` (backend stacks) or `kit/` (modeling-only) for the agent runner. Files identical across all backend stacks live once in `shared/build-kit/` and get layered in automatically — only put stack-specific overrides under `stacks/<name>/templates/build-kit/`. Skills with no stack-specific content (`connect`, `learn-eventmodelers-api`, `update-slice-status`) work the same way via `shared/skills/` — a new stack gets them for free without copying anything; add a skill there only once it needs a stack-specific fork.
+Each stack lives under `stacks/<name>/templates/` with `.claude/` (skills), `root/` (spread into the project root), and either `build-kit/` (backend stacks) or `kit/` (modeling-only) for the agent runner. Files identical across all backend stacks live once in `shared/build-kit/` and get layered in automatically — only put stack-specific overrides under `stacks/<name>/templates/build-kit/`. Skills with no stack-specific content (`connect`, `learn-eventmodelers-api`, `update-slice-status`, `request-feedback`) work the same way via `shared/skills/` — a new stack gets them for free without copying anything; add a skill there only once it needs a stack-specific fork.
 
 Once your `init --build-kit` scaffold (see above) works against a real backend, promote it to a first-class stack:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "1.0.18",
+  "version": "1.0.20",
   "description": "Eventmodelers CLI — real-time Claude agent + skills for Claude Code, for any stack (Node, Supabase, Axon, Cratis, or modeling-only)",
   "type": "module",
   "bin": {

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

@@ -0,0 +1,155 @@
+---
+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.
+---
+
+# Request Feedback
+
+> **Before doing anything else**, invoke the `connect` skill — if not already connected — to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL`. Do not proceed until the connect skill has completed.
+
+Prefer `mcp__eventmodelers__*` tools when available (registered by the `connect` skill) — the curl blocks below are the fallback for sessions without MCP connected.
+
+---
+
+## When to use this skill — the exception, not the rule
+
+Building a slice is normally unambiguous: `slice.json` names every command field, event field, and
+GWT scenario, and the matching build skill (`build-state-change`, `build-state-view`,
+`build-automation`, ...) tells you exactly how to turn that into code. **Read `slice.json` fully, and
+read the build skill's own instructions and reference docs, before ever concluding something is
+missing.** Most slices need none of this.
+
+Only invoke `request-feedback` when, after that reading, a decision the implementation depends on
+still cannot be made without guessing — for example:
+
+- A business rule mentioned in `description`/`comments`/`notes` isn't backed by any field, event, or
+  `specifications[]` scenario, so there's no way to encode it.
+- Two fields, or a field and an `idAttribute` flag, contradict each other about what the slice is
+  supposed to do.
+- A `specifications[]` scenario references a prior event or state that no command/event in this slice
+  (or its declared dependencies) actually produces.
+- The slice depends on another slice, screen, or read model that doesn't exist yet and it's unclear
+  whether one should be created, or the dependency was meant to point elsewhere.
+
+**Do not use this skill for:**
+- Implementation-detail choices the build skill's own instructions already answer (e.g. package
+  naming, file layout, which annotation to use) — those aren't ambiguity in the slice, they're just
+  reading the skill more carefully.
+- Style or naming preferences with no functional consequence — pick the reasonable option and move on.
+- "This would be nice to confirm" — if you *can* proceed correctly from what `slice.json` says, proceed.
+
+When in doubt, prefer finishing the slice over escalating. Escalating on every minor uncertainty
+defeats the purpose — it should be rare enough that a `Blocked` slice reliably means "a human needs to
+look at this," not "the agent didn't feel like deciding."
+
+**When this skill does apply: do not guess and build anyway.** Post the question and stop work on this
+slice for this run — do not implement your best interpretation first. A wrong guess encoded into
+working, tested, committed code is harder to catch and undo than an unbuilt slice waiting for an
+answer.
+
+---
+
+## Step 1 — Parse arguments
+
+From `$ARGUMENTS` or the calling skill's context, extract:
+
+| Field | How to find it | Default |
+|-------|---------------|---------|
+| `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` |
+
+## Step 2 — Resolve the slice's node id
+
+Prefer MCP:
+
+```
+mcp__eventmodelers__list_slices { "boardId": "<BOARD_ID>" }
+```
+
+**Fallback (no MCP):**
+
+```bash
+curl -s \
+  -H "x-token: <TOKEN>" \
+  -H "x-board-id: <BOARD_ID>" \
+  -H "x-user-id: request-feedback-skill" \
+  "<BASE_URL>/api/org/<ORG_ID>/boards/<BOARD_ID>/slicedata/slices"
+```
+
+Find the slice whose `title` matches `sliceName` (case-insensitive), or whose `id` matches `sliceId`.
+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
+
+Prefer MCP:
+
+```
+mcp__eventmodelers__add_comment { "boardId": "<BOARD_ID>", "nodeId": "<SLICE_NODE_ID>", "text": "<question>", "type": "QUESTION", "author": "<author>" }
+```
+
+**Fallback (no MCP):**
+
+```bash
+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>"}'
+```
+
+Response: `201 {"id":"<commentId>"}`. Save it as `COMMENT_ID` — the calling skill may want to reference
+it later once the question is answered.
+
+Write `<question>` so a human reading it cold understands the gap without re-reading the slice
+themselves: name the slice, name the specific field/rule/scenario in question, and say what's missing
+or contradictory — not just "please clarify this slice."
+
+## Step 4 — Mark the slice Blocked
+
+Prefer MCP:
+
+```
+mcp__eventmodelers__update_slice_status { "boardId": "<BOARD_ID>", "sliceId": "<SLICE_NODE_ID>", "newStatus": "Blocked" }
+```
+
+Also mark the slice 'blocked' locally in the index.json if possible.
+
+**Fallback (no MCP)** — send a `node:changed` event to update the `sliceStatus` field in the
+SLICE_BORDER node's meta directly:
+
+```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: request-feedback-skill" \
+  -d '[{
+    "id": "<new-random-uuid>",
+    "eventType": "node:changed",
+    "nodeId": "<SLICE_NODE_ID>",
+    "boardId": "<BOARD_ID>",
+    "timestamp": <Date.now()>,
+    "changedAttributes": ["sliceStatus"],
+    "meta": {
+      "sliceStatus": "Blocked"
+    }
+  }]'
+```
+
+If `CURRENT_STATUS` was already `Blocked`, this step is a no-op — don't treat that as an error, and
+don't retry. It just means someone (possibly this same agent, on an earlier prompt) already flagged it.
+
+## Step 5 — Stop and report
+
+Do not continue implementing the slice after this. Report back to whoever invoked this skill:
+
+```
+Requested feedback on slice "<sliceName>" (<SLICE_NODE_ID>)
+Question posted: "<question>"
+Status: <CURRENT_STATUS> → Blocked
+```
+
+Then stop work on this slice for this run. If the caller has other, unrelated slices queued, it may
+move on to those — but this specific slice stays untouched until the question is answered and the
+slice is moved out of `Blocked`.

package/stacks/axon/templates/.claude/skills/build-automation/SKILL.md

@@ -415,8 +415,6 @@ than fabricating an assertion.
 
 ## References
 
-- [Stateless Automation Example](references/automation-test-example.md) — Complete Java test example
-- [Automation with Read Model Example](references/automation-with-read-model-test-example.md) — Multi-command test
 - [Feature Flag Patterns](references/feature-flag-patterns.md) — `@ConditionalOnProperty` and alternatives
 
 ---

package/stacks/axon/templates/.claude/skills/build-automation-workflow/SKILL.md

@@ -7,8 +7,7 @@ description: >
   (long-running, durable, multi-step processes) instead of plain @EventHandler automations.
   Determines WHICH slices need a Workflow, then implements them using the AF5 Workflow engine.
   Use when: (1) given a set of automation slice.json definitions, decide which ones should be
-  Workflows; (2) user asks to "convert automation to workf
-  low", "implement as workflow",
+  Workflows; (2) user asks to "convert automation to workflow", "implement as workflow",
   or "use Axon Workflow for this slice"; (3) a slice has multi-step logic, needs to wait for
   external input/approval, requires compensation/rollback, or spans significant time.
   NOTE: AF5 Workflows are in Preview — APIs may change; not intended for production use yet.

package/stacks/axon/templates/.claude/skills/build-state-change/SKILL.md

@@ -121,8 +121,16 @@ public static final String {TAG_CONSTANT} = "idField";
 ## Step 3: Decision-model entity
 
 Package-private, mutable field(s) — **not** an immutable `State` record with free-standing
-`decide()`/`evolve()` static methods. One boolean/value field per fact the command handler's rule
-check needs, nothing else.
+`decide()`/`evolve()` static methods.
+
+**Derive the field(s) from this slice's `specifications[]` (Step 0), not from the event's shape.**
+Each GWT scenario's `given`/`then` pair states the one decision the command handler must make and the
+prior fact that decision depends on — that fact is the field. Re-read the scenarios before naming
+fields: a "given no prior activity" / "given already {X}" pair means one boolean flag for {X}; a
+scenario that discriminates on a value (not just presence/absence) means a value field holding that
+value, not a boolean. Add exactly one field per fact a scenario actually branches on — an event can
+carry several fields, but the entity only needs the ones a `specifications[]` scenario checks. Do not
+add a field just because the corresponding event happens to carry that data.
 
 ```java
 package {basePackage}.slices.{context}.{slicename};
@@ -312,6 +320,8 @@ in all three places:
 - `META-INF/additional-spring-configuration-metadata.json` — add a `{"name": "...", "type":
   "java.lang.Boolean", "description": "..."}` entry
 
+See [references/feature-flag-patterns.md](references/feature-flag-patterns.md) for the full pattern.
+
 This flag is irrelevant to the Step 7 test below — that test never boots Spring, so
 `@ConditionalOnProperty` never runs.
 

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

@@ -42,6 +42,13 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 **CRITICAL: You MUST always use the provided skills to build slices. NEVER implement a slice manually.**
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT invent, assume, or guess any field or logic not present in the slice definition.**
 
+**If, at any point below, 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 the
+`request-feedback` skill with the specific question; it posts the question as a comment on the slice
+and marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path,
+not a routine step — read `slice.json` and the matching build skill's own instructions fully first;
+most slices are fully specified and need none of this.
+
 When asked to build a slice, always follow this flow:
 
 1. Read the slice definition from `.build-kit/.slices/<context>/<slicename>/slice.json`.

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

@@ -48,6 +48,17 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 18. 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.
 19. Finish the iteration.
 
+## 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, always append):

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

@@ -48,6 +48,8 @@ Inspect the `sliceStatus` in the payload:
 
 This is the build trigger. Setting `InProgress` and building are one atomic step:
 
+**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` (superseding the `InProgress` set in step 1), then drop this task without finishing the build. This is an escalation path, not a routine step — most slices are fully specified.
+
 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.

package/stacks/axon/templates/root/pom.xml

@@ -4,7 +4,7 @@
     <modelVersion>4.0.0</modelVersion>
     <groupId>io.axoniq.quickstart</groupId>
     <artifactId>quickstart</artifactId>
-    <name>Axoniq Platform Quickstart</name>
+    <name>Axoniq Quickstart</name>
     <version>0.0.1-SNAPSHOT</version>
 
     <properties>
@@ -20,6 +20,8 @@
             <artifactId>spring-boot-starter-webflux</artifactId>
         </dependency>
 
+
+
         <!-- Read model persistence: Spring Data JPA + PostgreSQL, default for all projections -->
         <dependency>
             <groupId>org.springframework.boot</groupId>
@@ -43,6 +45,14 @@
             <artifactId>axoniq-platform-spring-boot-starter</artifactId>
         </dependency>
 
+        <!-- Auto-starts docker-compose.yml services (e.g. postgres) on app run -->
+        <dependency>
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-docker-compose</artifactId>
+            <scope>runtime</scope>
+            <optional>true</optional>
+        </dependency>
+
         <!-- Testing -->
         <dependency>
             <groupId>org.springframework.boot</groupId>

package/stacks/axon/templates/root/src/main/resources/application.properties

@@ -1 +1,8 @@
-spring.application.name=Platform QuickStart
+spring.application.name=Platform QuickStart
+
+spring.datasource.url=jdbc:postgresql://localhost:5432/quickstart
+spring.datasource.username=quickstart
+spring.datasource.password=quickstart
+
+spring.docker.compose.enabled=true
+spring.docker.compose.file=docker-compose.yml

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

@@ -32,6 +32,13 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 **CRITICAL: You MUST always use the provided skills to build slices. NEVER implement a slice manually.**
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT invent, assume, or guess any field or logic not present in the slice definition.**
 
+**If, at any point below, 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 the
+`request-feedback` skill with the specific question; it posts the question as a comment on the slice
+and marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path,
+not a routine step — read `slice.json` and the matching build skill's own instructions fully first;
+most slices are fully specified and need none of this.
+
 When asked to build a slice, always follow this flow:
 
 1. Read the slice definition from `.build-kit/.slices/<context>/<slicename>/slice.json`.

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

@@ -91,6 +91,17 @@ Use the skills available in `.claude/skills/` to interact with the board.
 
 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 `[]`.
 
+## 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):

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

@@ -38,6 +38,17 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 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.
 
+## 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 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.
+
 ## Progress Report Format
 
 APPEND to progress.txt (never replace, always append):

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

@@ -9,6 +9,13 @@ and follow the conventions distilled in
 `.build-kit/.claude/skills/_shared/cratis-conventions.md`. **The shipped example slice
 under `SomeModule/SomeFeature/` is the concrete pattern to copy** — match its structure exactly.
 
+**If a 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 the `request-feedback` skill with
+the specific question; it posts the question as a comment on the slice and marks it `Blocked`, and you
+then stop work on this slice for this run. This is an escalation path, not a routine step — read
+`slice.json` and the matching build skill's own instructions fully first; most slices are fully
+specified and need none of this.
+
 ## Structure (learn from `SomeModule/SomeFeature/`)
 
 ```

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

@@ -73,6 +73,17 @@ implementing.
 until the backend compiles**. Always: Backend → `dotnet build` → Specs → Frontend → Composition.
 Never implement a slice's frontend before its backend builds.
 
+## 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):

package/stacks/cratis-csharp/templates/build-kit/lib/prompt.md

@@ -48,6 +48,8 @@ Inspect the `sliceStatus` in the payload:
 
 This is the build trigger. Setting `InProgress` and building are one atomic step:
 
+**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` (superseding the `InProgress` set in step 1), then drop this task without finishing the build. This is an escalation path, not a routine step — most slices are fully specified.
+
 1. Immediately call `/update-slice-status` to set the slice to `InProgress` on the board.
 
 2. Read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json` (written by `/load-slice`).

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

@@ -35,6 +35,13 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 **CRITICAL: You MUST always use the provided skills to build slices. NEVER implement a slice manually.**
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT invent, assume, or guess any field or logic not present in the slice definition.**
 
+**If, at any point below, 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 the
+`request-feedback` skill with the specific question; it posts the question as a comment on the slice
+and marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path,
+not a routine step — read `slice.json` and the matching build skill's own instructions fully first;
+most slices are fully specified and need none of this.
+
 When asked to build a slice, always follow this flow:
 
 1. Read the slice definition from `.build-kit/.slices/<context>/<slicename>/slice.json`.

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

@@ -42,6 +42,17 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 18. 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.
 19. Finish the iteration.
 
+## 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, always append):

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

@@ -48,6 +48,8 @@ Inspect the `sliceStatus` in the payload:
 
 This is the build trigger. Setting `InProgress` and building are one atomic step:
 
+**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` (superseding the `InProgress` set in step 1), then drop this task without finishing the build. This is an escalation path, not a routine step — most slices are fully specified.
+
 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.

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

@@ -35,6 +35,13 @@ When starting to work on a slice, invoke the `update-slice-status` skill with `I
 **CRITICAL: You MUST always use the provided skills to build slices. NEVER implement a slice manually.**
 **ALL fields, event names, command names, and business rules MUST come exclusively from slice.json. Do NOT invent, assume, or guess any field or logic not present in the slice definition.**
 
+**If, at any point below, 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 the
+`request-feedback` skill with the specific question; it posts the question as a comment on the slice
+and marks it `Blocked`, and you then stop work on this slice for this run. This is an escalation path,
+not a routine step — read `slice.json` and the matching build skill's own instructions fully first;
+most slices are fully specified and need none of this.
+
 When asked to build a slice, always follow this flow:
 
 1. Read the slice definition from `.build-kit/.slices/<context>/<slicename>/slice.json`.

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

@@ -42,6 +42,17 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
  18. 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.
 19. Finish the iteration.
 
+## 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, always append):

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

@@ -48,6 +48,8 @@ Inspect the `sliceStatus` in the payload:
 
 This is the build trigger. Setting `InProgress` and building are one atomic step:
 
+**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` (superseding the `InProgress` set in step 1), then drop this task without finishing the build. This is an escalation path, not a routine step — most slices are fully specified.
+
 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.