@eventmodelers/cli 1.0.162 → 2.0.1

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

@@ -17,20 +17,19 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
 
 0. Do not read the entire code base. Focus on the tasks in this description.
 1. Read `.build-kit/.slices/current_context.json` to find the active context name, then read `.build-kit/.slices/<contextName>/index.json`. Every item in status "planned" is a task.
-2. Read the progress log at `progress.txt` **if it exists** (check Codebase Patterns section first) — it is absent until the first slice is built, which is not an error; create it when you write your first entry
+2. Read `.build-kit/AGENTS.md` **if it exists** — the project's accumulated learnings, generated from what earlier builds recorded. If the slice's `slice.json` has a `lastAttempt`, an earlier attempt at it failed: read its `reason`, `lastReply`, `branch` and `changed`, and do not repeat what failed.
 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:**
+5. Your slice is the one the task request names (the run loop picked the highest priority slice with status "Planned"); it becomes your PRD. The run loop has already claimed it — its status is "InProgress" in index.json and on the board. Build that slice and do not call `update-slice-status`: the run loop owns the slice's status on the board.
+   **IMPORTANT: Only work on the slice named in the task request. Never switch to another slice, whatever its status. If the task request names no slice and 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. 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.
 7. Define the slice type and load the matching skill:
    - Write slice (has commands, no processors) → `build-state-change`
    - Read slice (has readModel / information flow) → `build-state-view`
    - Translation slice (`sliceType === "TRANSLATION"`) → read `description` and `notes` from slice.json for hints; default to `build-automation` if nothing else is specified
    - Automation slice (processors-array is not empty) → `build-automation`
-8. Write a short progress one liner after each step to progress.txt
+8. Record each learning the moment you have it (see **Recording Learnings**), not at the end.
 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
@@ -43,48 +42,27 @@ You work within **exactly ONE context at a time** — the one named in `.build-k
     If the tests for the slice are not yet named predictably, run `./mvnw test -q` and check for failures.
 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). For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to set is `Handover`, not `Done` — see the `ui-contract` skill, Step 4.
-17. Append your progress to `progress.txt` after each step in the iteration.
-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.
+16. Record the outcome with `npx @eventmodelers/cli slice-status Done` — not by editing index.json, and do not call `update-slice-status`: the run loop pushes the status to the board when your turn ends. For STATE_VIEW/STATE_CHANGE slices when `handover` is enabled the status to record is `Handover`, not `Done` — see the `ui-contract` skill, Step 4. A slice you could not finish needs no status: leave it as it is and the run loop discards the attempt.
+17. Record any reusable learning you have not recorded yet (see **Recording Learnings**).
+18. If an entry in `.build-kit/AGENTS.md` turned out wrong or obsolete, retract it (see **Recording Learnings**).
 19. Finish the iteration.
 
 ## Escalating Ambiguity
 
-**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
-## Progress Report Format
+## Recording Learnings
 
-APPEND to progress.txt (never replace, always append):
+`.build-kit/AGENTS.md` is generated from the learnings recorded so far — read it at the start of every session, never edit it by hand. Record a learning the moment you have it:
 
 ```
-## [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")
----
+npx @eventmodelers/cli learn "<one terse line>" --topic "<topic>"
 ```
 
-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 event sourcing aggregate patterns for all state changes
-- Example: Always use @CommandHandler on the aggregate for write slices
-- Example: Export query result types from the slice package
-```
-
-Only add patterns that are **general and reusable**, not story-specific details.
+- Only what is genuinely reusable: codebase patterns, gotchas, commands that work or don't, conventions — and, after a failed approach, what was tried and why it failed. Not slice-specific details, and nothing the code or git log already says.
+- One learning per call, one line each. A learning that is already in `.build-kit/AGENTS.md` is skipped for you.
+- `--scope system` for what is true of the modeled domain (a business rule, a naming convention of the model); `repo` (the default) for the codebase and its tooling. `--tag <tag>` labels it (repeatable).
+- One in `.build-kit/AGENTS.md` that turned out wrong or obsolete: `npx @eventmodelers/cli learnings --ids` lists each with its id, `npx @eventmodelers/cli learn --retract <id>` removes it.
 
 ## Update AGENTS.md Files
 
@@ -110,7 +88,7 @@ Before committing, check if any edited files have learnings worth preserving in
 - Slice specific implementation details
 - Story-specific implementation details
 - Temporary debugging notes
-- Information already in progress.txt
+- Information already recorded as a learning in `.build-kit/AGENTS.md`
 - Task specific learnings
 
 Only update AGENTS.md if you have **genuinely reusable knowledge** that would help future work
@@ -154,9 +132,9 @@ If ALL slices in the current context are Done, reply with:
 - If no `.eventmodelers/config.json` exists anywhere (project root or an ancestor directory, or `~/.eventmodelers/config.json` — the one inside `.build-kit/` is only an optional override, so its absence means nothing), 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
+- Record learnings as you go with `learn`
+- Read `.build-kit/AGENTS.md` before starting
 
 ## When an iteration completes
 
-Use all the key learnings from the progress.txt and update the `.build-kit/AGENTS.md` file with those learnings.
+Make sure every reusable learning is recorded with `learn`; `.build-kit/AGENTS.md` is generated from them — never edit it by hand.

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

@@ -4,17 +4,11 @@ You are an autonomous agent reacting to slice status change events on an Eventmo
 
 ## 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.
+1. Read `AGENT.md` and, if it exists, `.build-kit/AGENTS.md` to load accumulated knowledge before doing anything else.
+2. The task request at the end of this prompt names your task: its id and the slice change that queued it (`sliceId`, `sliceTitle`, `sliceStatus`, …). It is the oldest one waiting — the run loop picked it for you.
+3. Execute the task — see the Execution section below.
+4. Record any reusable learning with `npx @eventmodelers/cli learn "<one terse line>" --topic <topic>` (see **Recording Learnings**).
+5. Reply normally. The run loop completes the task when your turn ends and hands you the next one in a fresh turn — you never read or write a queue file.
 
 ## Execution
 
@@ -48,11 +42,11 @@ Inspect the `sliceStatus` in the payload:
 
 This is the build trigger. Setting `InProgress` and building are one atomic step:
 
-**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line in `progress.txt` and as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
+**Default: make a reasonable assumption and build the slice.** If a detail is unclear or missing (an example value, a field type, a status mapping, a referenced event that isn't modeled yet, ...), pick the most sensible interpretation from `slice.json`, its specifications and the surrounding model, build it, and record each assumption in one line as a code comment. Ambiguity alone is never a reason to stop. **Only if the slice literally cannot be built** — nothing runnable can be produced even with sensible assumptions — invoke `/request-feedback` with the specific question; it posts the question as a comment on the slice and marks it `Blocked`. That must be the absolute exception; a `Blocked` slice should mean "impossible without a human", never "the agent preferred to ask".
 
 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.
+   **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. Say so in your reply, drop this task without building, and continue the loop (the next task will naturally cover the next slice). Do not retry.
 
 2. Run `/load-slice sliceId=<payload.sliceId>` to fetch the full slice, then read the slice definition from `.build-kit/.slices/<contextSlug>/<sliceFolder>/slice.json`. The runner keeps a `slice.json` fresh from a summary endpoint, so a file holding only `id`, `title`, `status` and `sliceType` is that stub, not an empty slice — never conclude a slice has no elements from it. Only if the full fetch itself returns no commands/events/read models/fields is the slice actually empty.
 
@@ -78,48 +72,31 @@ This is the build trigger. Setting `InProgress` and building are one atomic step
 Another agent is already building this slice. Log it and skip — do not build.
 
 #### `Done`
-Summarize what was completed and update `progress.txt`.
+Summarize what was completed in your reply.
 
 #### `Blocked`
-Log the blocker in `progress.txt`.
+State the blocker in your reply.
 
 #### `Review`
-Fetch slice details and prepare a review summary in `progress.txt`.
+Fetch slice details and prepare a review summary in your reply.
 
 #### Any other status (`Created`, etc.)
-Load the slice and log the state transition in `progress.txt`. No build action.
+Load the slice and note the state transition in your reply. No build action.
 
 Use the skills available in `.claude/skills/` to interact with the board.
 
-## Updating tasks.json
+## Recording Learnings
 
-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 `[]`.
+`.build-kit/AGENTS.md` is generated from the learnings recorded so far — read it at the start of every session, never edit it by hand. Record a learning the moment you have it:
 
-## 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]
----
+npx @eventmodelers/cli learn "<one terse line>" --topic "<topic>"
 ```
 
-## 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.
+- Only what is genuinely reusable: codebase patterns, gotchas, commands that work or don't, conventions — and, after a failed approach, what was tried and why it failed. Not slice-specific details, and nothing the code or git log already says.
+- One learning per call, one line each. A learning that is already in `.build-kit/AGENTS.md` is skipped for you.
+- `--scope system` for what is true of the modeled domain (a business rule, a naming convention of the model); `repo` (the default) for the codebase and its tooling. `--tag <tag>` labels it (repeatable).
+- One in `.build-kit/AGENTS.md` that turned out wrong or obsolete: `npx @eventmodelers/cli learnings --ids` lists each with its id, `npx @eventmodelers/cli learn --retract <id>` removes it.
 
 ## Important
 

package/shared/bridge/spec-kitty/bridge-spec-kitty-specify/SKILL.md

@@ -1,125 +0,0 @@
----
-name: bridge-spec-kitty-specify
-description: "Adapter: generate a Spec Kitty mission spec.md (and auto-evaluate its quality checklist) from an Eventmodelers board's exported event model, instead of running the /spec-kitty.specify interview. Use when the user says \"use the event model as the spec\", \"sync the board to spec-kitty\", \"generate the spec from the event model\", or when a .slices/ export exists and a Spec Kitty mission needs to start or refresh from it."
----
-
-# bridge-spec-kitty-specify
-
-Replaces the human interview in `/spec-kitty.specify` with a direct read of an
-Eventmodelers board export. The event model is the source of truth; `spec.md`
-becomes a **generated, read-only artifact** derived from it. Everything
-downstream of specify (`/spec-kitty.plan`, `/spec-kitty.tasks`,
-implement/review/merge) is untouched — this skill only produces the two
-artifacts that phase gate expects: `spec.md` and `checklists/requirements.md`.
-
-Do not use this to hand-author or hand-edit `spec.md` — if the event model is
-wrong, fix it on the board and re-run this skill. A `spec.md` produced here
-that gets manually edited afterward will be silently overwritten on the next
-sync; there is no merge/diff in this version (see Limitations).
-
-## Inputs
-
-The Eventmodelers `listen` server (`npx @eventmodelers/cli listen`) writes the
-board export locally. Read it directly — do not call the board API:
-
-- `.slices/current_context.json` → `{ "name": "<context>" }` — which context
-  to ingest if the user didn't name one.
-- `.slices/<context>/index.json` → `{ "slices": [{ id, slice, index, context,
-  folder, status, group }] }` — the ordered slice list.
-- `.slices/<context>/context.json` → context-level name/package info.
-- `.slices/<context>/<folder>/slice.json` → full slice detail per the
-  [event-modeling-spec](https://github.com/dilgerma/event-modeling-spec)
-  contract: `commands[]`, `events[]`, `readModels[]` (projections/queries),
-  `screens[]`, `automations[]`/`processors[]`, `specifications[]` (given/when/
-  then), plus free-text `description`/`notes`.
-
-If `.slices/` doesn't exist yet, stop and tell the user to run
-`npx @eventmodelers/cli listen` (or `init-modeling` first if the kit isn't
-installed) and push the board export before retrying.
-
-## Flow
-
-1. **Resolve the mission.** If an existing `kitty-specs/<slug>/meta.json`
-   already points at this context (check `purpose_tldr`/a stored context
-   reference), re-sync into it. Otherwise create a new mission dir the same
-   way `/spec-kitty.specify` does: kebab-case name + 8-char ULID suffix,
-   `mission_type: software-dev` (this adapter does not introduce a new
-   mission type — see project memory on why). Write `meta.json` matching the
-   shape in an existing mission (`mission_id`, `mission_slug`, `purpose_tldr`,
-   `purpose_context`, `target_branch`, etc.).
-2. **Load every slice** referenced in `index.json` by reading each
-   `<folder>/slice.json`. Do not skip slices with empty `specifications` —
-   surface them as gaps in the checklist instead (step 4).
-3. **Compose `spec.md`** using the standard Spec Kitty template sections,
-   sourced only from what the model actually states — never invent detail
-   the board doesn't have:
-   - **Purpose** ← `context.json` name/description, or ask the user for a
-     one-paragraph purpose if the board has none.
-   - **Primary User Story** ← walk the slices in `index.json` order (this is
-     already the chronological/timeline order from the board) and narrate
-     the SCREEN → COMMAND → EVENT → READMODEL flow across them.
-   - **Acceptance Scenarios** ← one bullet per `specifications[]` entry,
-     copied straight from its given/when/then — do not paraphrase away
-     precision the model already captured.
-   - **Edge Cases** ← `specifications[]` entries that describe rejection/
-     negative/boundary behavior (reject, invalid, already-exists, etc.).
-   - **Domain Language** ← distinct nouns from event/command/read-model field
-     names and titles, deduped.
-   - **Functional Requirements (FR-###)** ← one row per COMMAND (state-change
-     slice) and per AUTOMATION slice; wording from the command/automation
-     name + `description`.
-   - **Non-Functional Requirements / Constraints** ← only from explicit
-     `notes`/`description` content tagged as timing/authorization/volume
-     constraints. If the model states none, leave the table empty — do not
-     fabricate NFRs to fill it.
-   - **Key Entities** ← distinct read-model/event payload shapes.
-   - **Interfaces to Other Teams** ← any `TRANSLATION`-type slice or external
-     system mentioned in a slice's `description`.
-4. **Evaluate `checklists/requirements.md`** against the ingested model
-   instead of a human review pass. Check an item only if the model
-   demonstrably satisfies it:
-   - "No [NEEDS CLARIFICATION] markers remain" → fails if any slice has an
-     empty `specifications[]` or a `description` containing `TODO`/`TBD`.
-   - "Requirements are testable and unambiguous" → fails if an FR/NFR row has
-     no backing `specifications[]` entry.
-   - "Non-functional requirements include measurable thresholds" → fails
-     (leave unchecked, don't skip the row) if the NFR table is empty but the
-     model contains AUTOMATION slices implying a timing constraint the board
-     never made explicit.
-   - Leave any check unchecked with a `## Notes` explanation when the event
-     model genuinely doesn't provide enough to verify it — this checklist
-     gates `/spec-kitty.plan`, so a false pass defeats the point of the gate.
-5. **Hand off.** Once `spec.md` + `checklists/requirements.md` are written,
-   tell the user the mission is ready for `/spec-kitty.plan` as normal — do
-   not run plan/tasks yourself from this skill.
-
-## Re-sync behavior
-
-Re-running this skill against the same mission regenerates `spec.md` and
-`checklists/requirements.md` wholesale from the current `.slices/` state.
-There is no field-level diff against the previous generation — if the spec
-needs to reflect board changes, re-run this skill rather than hand-patching
-`spec.md`.
-
-## Guardrail
-
-If a required section can't be populated from the event model (e.g. no
-Purpose anywhere on the board), ask the user rather than inventing one — an
-invented Purpose defeats the reason this adapter exists (the event model,
-not the LLM, is the source of truth for product intent).
-
-## Limitations (by design, v1)
-
-- Does not itself generate `tasks/WP##-*.md` from slices — see the companion
-  `bridge-spec-kitty-tasks` skill, which enforces a 1:1
-  slice-to-WP mapping when `wps.yaml` is written during
-  `/spec-kitty.tasks-outline`.
-- Does not introduce a new Spec Kitty mission type. Spec Kitty 3.2.5's
-  built-in mission types are loaded from a flat directory inside the
-  installed package (`doctrine/missions/mission_types/*.yaml`) via
-  `MissionTypeRepository.default()`, and org-pack extension for the
-  `mission_types` kind is unwired in this version (fragments only add
-  governance-graph metadata, not an executable type). A real native mission
-  type would require patching the installed `spec-kitty-cli` package itself.
-  This adapter avoids that entirely — it stays inside `mission_type:
-  software-dev` and only replaces the specify phase's *inputs*.

package/shared/bridge/spec-kitty/bridge-spec-kitty-tasks/SKILL.md

@@ -1,95 +0,0 @@
----
-name: bridge-spec-kitty-tasks
-description: "Adapter: enforce a 1:1 mapping between Eventmodelers board slices and Spec Kitty work packages when writing wps.yaml. Use when the user says \"one slice should become one task/WP\", \"generate tasks from the event model\", or right after bridge-spec-kitty-specify, in place of freeform subtask-grouping judgment in /spec-kitty.tasks-outline."
----
-
-# bridge-spec-kitty-tasks
-
-Companion to `bridge-spec-kitty-specify`. That skill turns the event model into
-`spec.md`; this one enforces that each **slice** on the board becomes exactly
-**one work package** — never split across WPs, never merged with another
-slice — when Spec Kitty's task-planning pipeline builds `wps.yaml`.
-
-This replaces only step 3–6 of `/spec-kitty.tasks-outline` (deriving
-subtasks and rolling them into WPs). `/spec-kitty.tasks-packages` and
-`/spec-kitty.tasks-finalize` run completely unmodified afterward — they only
-ever consume `wps.yaml`, and don't care where its groupings came from.
-
-## Why a hard 1:1 boundary
-
-Spec Kitty's default `tasks-outline` groups subtasks into WPs by
-judgment (target 3–7 subtasks, merge small ones, split large ones). That's
-the right default when subtask boundaries come from an LLM reading prose. It
-is the *wrong* default here: the event model already drew the real
-boundaries (each SLICE_BORDER is a reviewable, independently buildable unit
-the board's `Planned → InProgress → Done` slice lifecycle already governs).
-Re-grouping at the WP layer would create a second, competing notion of "unit
-of work" that drifts from the board over time. So this skill trades away
-`tasks-outline`'s sizing flexibility on purpose: WP boundary = slice
-boundary, full stop.
-
-## Inputs
-
-Same event-model export as `bridge-spec-kitty-specify`:
-`.slices/<context>/index.json` (slice list, board/timeline order) and each
-`.slices/<context>/<folder>/slice.json` (commands, events, readModels,
-automations, `specifications`). Also read, from `feature_dir`:
-`spec.md` (for FR/NFR ids — already generated by `bridge-spec-kitty-specify`) and
-`plan.md` (for the tech-stack/file-layout context needed to fill
-`owned_files`, since the event model doesn't know the codebase's directory
-structure).
-
-## Flow
-
-1. **One WP per slice, in board order.** Assign `WP01`, `WP02`, ... following
-   `index.json`'s order (already the board's chronological/timeline order).
-   Do not reorder for "phase grouping" the way default `tasks-outline` does —
-   the board order already encodes the intended build sequence.
-2. **Subtasks come from inside the slice, not across slices.** For each
-   slice, break its own commands/read-models/screens/automations into T-ids
-   (one per command handler, one per read-model endpoint, one per
-   screen/automation, one for its tests) — all nested under that slice's one
-   WP. Every subtask must trace to exactly one slice; never let a subtask
-   span two slices.
-3. **Dependencies from event flow, not guesswork.** WP *B* depends on WP *A*
-   iff slice B's commands/queries/automations consume an event that slice
-   A's commands/automations produce. Derive this by diffing each slice's
-   emitted event names against every other slice's consumed event names —
-   this is mechanical, not judgment-based, so don't also apply
-   `tasks-outline`'s "Phase 2 typically depends on Phase 1" heuristic on top
-   of it.
-4. **`requirement_refs` from the spec's own FR/NFR table.** Match each
-   slice's command/read-model/automation names against `spec.md`'s FR/NFR
-   rows (written by `bridge-spec-kitty-specify` from these same slices) and cite
-   whichever ids trace to this slice. A slice with no matching row means
-   `bridge-spec-kitty-specify` needs a re-run, not a fabricated ref here.
-5. **Write `wps.yaml`** using the exact schema `/spec-kitty.tasks-outline`
-   expects (`id`, `title`, `dependencies`, `owned_files`, `requirement_refs`,
-   `plan_concern_refs` or `cross_cutting: true`, `subtasks`, `prompt_file:
-   null`) — so `tasks-packages`/`finalize-tasks` need no awareness that this
-   skill (rather than default `tasks-outline`) produced it.
-6. **Hand off.** Tell the user to continue with `/spec-kitty.tasks-packages`
-   then `/spec-kitty.tasks-finalize` (or `spec-kitty next`) exactly as normal.
-
-## Guardrail: don't fix boundary problems here
-
-If a slice's own scope would blow past Spec Kitty's WP sizing ceiling (>10
-subtasks / >700 lines), **do not silently split it into two WPs** — that
-breaks the 1:1 invariant this skill exists to enforce, and produces the
-exact spec/code drift it's meant to prevent. Instead, flag it to the user:
-the slice is too coarse on the board itself, so split the SLICE_BORDER
-there and re-run both `bridge-spec-kitty-specify` and this skill. The event model
-stays the single place slice boundaries get decided.
-
-The same holds in the other direction: never merge two small slices into
-one WP for tidiness, even if `tasks-outline`'s default guidance would.
-
-## Limitations (v1)
-
-- `owned_files`/file-layout ownership still comes from `plan.md`, which is
-  still produced by the normal, LLM-authored `/spec-kitty.plan` — the event
-  model has no notion of source-file structure, so this isn't something to
-  push onto it.
-- Re-running this skill after the board changes regenerates `wps.yaml`
-  wholesale from the current slice set, same as `bridge-spec-kitty-specify`'s
-  re-sync behavior — no field-level diff against a prior run.

package/shared/build-kit/lib/agent.sh

@@ -1,20 +0,0 @@
-#!/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/shared/build-kit/ralph.sh

@@ -1,111 +0,0 @@
-#!/bin/bash
-# Ralph agent loop — two independent loops, each triggered by their own condition
-#
-# onTask:        tasks.json has entries  → load slice from board, update .build-kit/.slices/
-# onPlannedSlice: .build-kit/.slices/ has a "Planned" slice → build it
-#
-# The loops are NOT causally linked — either can trigger on its own.
-#
-# Usage: ./ralph.sh [iterations] [project_dir]
-#   iterations  — number of loop cycles to run; 0 or omitted means run forever
-#   project_dir — path to the project root; defaults to the parent of .build-kit
-
-set -euo pipefail
-
-KIT_DIR="$(cd "$(dirname "$0")" && pwd)"
-ITERATIONS="${1:-0}"
-PROJECT_DIR="${2:-"$KIT_DIR/.."}"
-TASKS_FILE="$KIT_DIR/tasks.json"
-PROMPT_FILE="$KIT_DIR/lib/prompt.md"
-BACKEND_PROMPT_FILE="$KIT_DIR/lib/backend-prompt.md"
-AGENT_SCRIPT="$KIT_DIR/lib/agent.sh"
-
-HAS_CREDENTIALS=true
-if [[ "${RALPH_LOCAL:-}" == "1" ]]; then
-  echo "[ralph] --local — platform sync disabled." >&2
-  HAS_CREDENTIALS=false
-elif [[ ! -f "$KIT_DIR/.eventmodelers/config.json" ]]; then
-  echo "[ralph] Note: no .eventmodelers/config.json found — platform sync disabled." >&2
-  echo "        To enable board sync, follow: https://app.eventmodelers.ai/documentation#build" >&2
-  echo "        Code generation from local slice definitions will still run." >&2
-  HAS_CREDENTIALS=false
-fi
-
-echo "Ralph — kit: $KIT_DIR  project: $PROJECT_DIR"
-
-# Returns 0 if tasks.json has at least one task
-has_pending_tasks() {
-  [[ -f "$TASKS_FILE" ]] || return 1
-  local content
-  content=$(cat "$TASKS_FILE")
-  [[ "$content" != "[]" && -n "$content" ]]
-}
-
-# Status this loop picks work up from — `run --status-trigger <status>` (RALPH_STATUS_TRIGGER), default Planned
-PICKUP_STATUS="${RALPH_STATUS_TRIGGER:-Planned}"
-
-# Returns 0 if any JSON under .build-kit/.slices/ contains a slice in the pickup status
-has_planned_slices() {
-  grep -rqi "\"status\"[[:space:]]*:[[:space:]]*\"$PICKUP_STATUS\"" "$KIT_DIR/.slices/" --include='index.json' 2>/dev/null
-}
-
-# Returns the title of the first "Planned" slice, or empty string
-get_planned_slice_title() {
-  for index_file in "$KIT_DIR/.slices/"*/index.json; do
-    [[ -f "$index_file" ]] || continue
-    local title
-    title=$(node -e "
-      try {
-        const d = JSON.parse(require('fs').readFileSync(process.argv[1], 'utf-8'));
-        const s = (d.slices||[]).find(s => (s.status||'').toLowerCase() === process.argv[2].toLowerCase());
-        if (s) process.stdout.write(s.slice || s.id || '');
-      } catch(e) {}
-    " "$index_file" "$PICKUP_STATUS" 2>/dev/null)
-    if [[ -n "$title" ]]; then
-      echo "$title"
-      return
-    fi
-  done
-}
-
-# prompt.md and backend-prompt.md are instruction manuals with no request in them — handed one
-# alone, the agent may read it as background and ask what to do. Every turn ends with the concrete
-# request, the same one lib/ralph.js's taskRequest() appends.
-task_request() {
-  printf '\n\n---\n\nYour task now: %s, following the instructions above. Start immediately.\n' "$1"
-}
-
-# Runs agent.sh with the given prompt; retries on non-zero exit
-run_agent() {
-  local label="$1"
-  local prompt="$2"
-  while true; do
-    echo "[$(date -u +%H:%M:%S)] $label"
-    (cd "$PROJECT_DIR" && bash "$AGENT_SCRIPT" "$prompt") 2>&1 && return 0
-    echo "[$(date -u +%H:%M:%S)] Agent error — retrying in 60s..."
-    sleep 60
-  done
-}
-
-cycle=0
-while [[ "$ITERATIONS" -eq 0 || "$cycle" -lt "$ITERATIONS" ]]; do
-  ran_something=false
-
-  if [[ "$HAS_CREDENTIALS" == true ]] && has_pending_tasks; then
-    run_agent "onTask: loading slice from board..." "$(cat "$PROMPT_FILE"; task_request 'process the pending tasks in tasks.json')"
-    ran_something=true
-  fi
-
-  if has_planned_slices; then
-    slice_title=$(get_planned_slice_title)
-    run_agent "onPlannedSlice: building \"$slice_title\"..." "$(cat "$BACKEND_PROMPT_FILE"; task_request "build the $PICKUP_STATUS slice \"$slice_title\"")"
-    echo "[$(date -u +%H:%M:%S)] Slice \"$slice_title\" build complete — waiting for next slice"
-    ran_something=true
-  fi
-
-  if [[ "$ran_something" == false ]]; then
-    sleep 3
-  fi
-
-  (( cycle++ )) || true
-done

package/shared/build-kit/realtime-agent.js

@@ -1,20 +0,0 @@
-#!/usr/bin/env node
-// Standalone realtime agent — subscribes to board events and writes tasks.json.
-// The same logic runs embedded inside ralph-claude.js / ralph-local-ai.js, so you
-// only need this if you want to run the agent independently (e.g. separate terminal).
-// Usage: node realtime-agent.js [kit_dir]
-
-import { loadLocalConfig, fetchPlatformConfig, retryTransient, startRealtimeAgent } from './lib/ralph.js';
-import { redactConsole } from './lib/redact.js';
-import { dirname, resolve } from 'path';
-import { fileURLToPath } from 'url';
-
-const kitDir = process.argv[2] ? resolve(process.argv[2]) : dirname(fileURLToPath(import.meta.url));
-
-const local = loadLocalConfig(kitDir);
-redactConsole([local.token]);
-const cfg = await retryTransient('fetchPlatformConfig', () => fetchPlatformConfig(local));
-
-console.log(`[agent] Starting — org=${cfg.organizationId}${cfg.boardId ? `, board=${cfg.boardId}` : ''}, base=${cfg.baseUrl}`);
-
-await startRealtimeAgent(cfg, kitDir);

package/stacks/bridge/templates/bridge/lib/AGENT.md

@@ -1,47 +0,0 @@
-# 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`).
-- Unlike build-kit, every status change is queued (not just non-`Planned`
-  ones) — see `queueAllStatuses` in `lib/ralph.js`.
-- 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
-sliceTitle      human-readable slice name (may be null)
-sliceStatus     e.g. "Created", "Planned", "InProgress", "Done" (may be null)
-timestamp       unix ms when the change was emitted
-```
-
-## Bridge target
-
-- The active target framework lives in `.bridge-kit/bridge.json`'s `target`
-  field, written at `init --bridge --target <name>` time. This file is
-  committed (unlike `.eventmodelers/config.json`, which is gitignored) since
-  it's project policy shared by every teammate and CI runner, not a
-  per-machine credential.
-- Skill naming convention: `bridge-<target>-specify` (kept in sync every
-  task) and `bridge-<target>-tasks` (invoked separately, by that framework's
-  own task-planning phase — not from this loop).
-
-## Executors
-
-- Claude (`ralph-claude.js`, this prompt) is the default. `bridge --local-ai`
-  swaps in a local model instead — same prompt, different executor.
-- `bridge --hook "<command>"` (or a `hookCommand` persisted in
-  `bridge.json`) bypasses this prompt entirely: `ralph-hook.js` runs an
-  arbitrary shell command per batch of changes instead of any AI agent — e.g.
-  commit + push `.slices/` and let a CI pipeline do the actual translation.
-  If you're reading this file, a hook wasn't configured for this run.