@eventmodelers/cli 1.0.104 → 1.0.105

package/package.json

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

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-orchestrating-event-modeling/SKILL.md

@@ -53,6 +53,11 @@ These rules govern how every element is placed on the board. Enforce them throug
 ### Never stack read models at the end
 Placing all read models in new columns at the very end of the timeline severs the visual connection to the events they're derived from. The board must show a coherent left-to-right narrative where each slice is self-contained.
 
+### Place in narrative order, never type by type
+The steps below decide *what* exists (events, commands, read models, screens); they do not decide the *order of placement calls*. When you write elements to the board — in one `place_element` call or several — order them **left to right by the story**, one slice at a time: the screen, command and event of a state change, then the read model (and its view screen) that the event feeds, then the next state change. A read model's column goes right after its source event's column, so placing the next command after it is simply the next column.
+
+Never emit "all events, then all commands, then all read models" (or any other by-type batch). It forces every read model into a column inserted afterwards, shifts everything already placed, and produces the board shape this skill forbids: a row of commands across the timeline with the read models bunched in their own block. If your element list is grouped by `elementType`, re-sort it by column before the call.
+
 ### One read model per component, not one read model per screen
 A read model does not necessarily serve a whole screen — **one component in a screen resembles one read model.** Storyboarding (Step 3) only produces a plain screen per screen state; it does not decide components. That decision, and the work of breaking a multi-component screen apart into copies, happens in Step 5 (Identifying Outputs), because a component is defined by its read model.
 

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

@@ -54,7 +54,7 @@ mcp__eventmodelers__place_element {
 }
 ```
 
-Pass `fields` whenever the element's attributes are already known — they are written by this same call, so don't follow a placement with a `submit_node_events` just to set them. Placing **more than one** element is more entries in the same `elements` array, applied in order so each entry sees the columns the previous one added — one call for a whole slice's or column run's worth instead of one per element.
+Pass `fields` whenever the element's attributes are already known — they are written by this same call, so don't follow a placement with a `submit_node_events` just to set them. Placing **more than one** element is more entries in the same `elements` array, applied in order so each entry sees the columns the previous one added — one call for a whole slice's or column run's worth instead of one per element. **Order the array by narrative, left to right, one slice after another** (screen → command → event → the read model/view screen that event feeds → next slice) — never grouped by `elementType` (all commands, then all read models): by-type order makes every read model land in an inserted column after the fact and breaks the visual story.
 
 This tool finds or creates an empty cell in the correct lane and places the node in one call — it collapses the "resolve timeline → fetch columns → determine lane → check occupancy → create node" sequence (Steps 2–3, 4, 6, 7b below) into a single round trip. A `columnIndex` past the timeline's current column count is handled automatically (columns are added to reach it) — no need to pre-check the column count or catch an out-of-range error yourself. If `timelineId` is unknown, resolve it first via Step 2's MCP call. Pass `compact: true` for a smaller `{nodeId, cellName, columnIndex}` response (plus `connectedCount` if auto-connect wired an edge) when you don't need the full `lane`/`elementType`/`title`/`autoConnected` detail back. Go straight to Step 8 once it returns.
 

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

@@ -148,6 +148,10 @@ mention it in the `DONE` comment, and leave it for a self-directed turn (or for
 5. **Invoke the matched skill — never substitute direct tool calls for it.** Execute the prompt using the skill matched in the Skill Selection table below, passing the resolved `TIMELINE_ID`, `NODE_ID`, and `CELL_ID` from step 3 as that skill's `timelineId`/node-reference/`cellName` arguments (not the raw `timeline_id`/`node_id` fields, and not a cell reference parsed from the prompt text). For a skill like `/place-element` that accepts a `cellName`, pass the resolved `CELL_ID` as `cellName` whenever it's present — skip parsing the prompt text for a cell reference entirely in that case.
 
    `mcp__eventmodelers__*` tools (and the REST fallback) are building blocks a skill calls *internally* once you've invoked it — they are not a substitute for invoking the skill. Being able to see `mcp__eventmodelers__get_node`/`create_slice`/etc. in your tool list does not mean you should reach for them directly to satisfy a prompt that matches a row in the Skill Selection table: e.g. "add the next slice" always goes through `/eventmodeling-slicing-event-models` (falling through to `/add-next-slice` when nothing existing is left to slice) or `/place-element`, even though technically a couple of raw MCP calls could produce something on the board. The skill is what encodes the actual domain reasoning (which node type follows which, naming, field derivation, dependency notes) — a raw tool call skips all of that and produces a shallower result even when it "works." Only call MCP/REST directly when no row in the table matches the prompt's intent at all.
+   **A prompt that names a skill (`/<skill-name> …`) is not a hint — invoke exactly that skill, via the Skill tool, as the first thing after step 4**, before any `mcp__eventmodelers__*` call. `Read`ing its `SKILL.md` is not invoking it. The named skill then drives the work, including invoking the step skills it delegates to (an orchestrating skill that stops after placing commands/events has not run); where it says to interview or ask the user, apply the Questioning rule below instead.
+
+   **Placement order — applies to every `place_element` / `submit_node_events` / `create_screen` write, with or without a skill:** order elements by the story, left to right, one slice after another (screen → command → event → the read model and view screen that event feeds → next slice). Never write "all commands, then all read models" (or any by-`elementType` batch): it forces every read model into a column inserted afterwards and leaves a row of commands with the read models bunched elsewhere. If your element list is grouped by type, re-sort it by column before the call.
+
    **Questioning rule**: you are running autonomously — no human is available to answer questions. (A `CHAT` turn never reaches this rule: there someone *is* waiting, and you ask back in the chat — see "Chat turns".) If you need clarification, do not pause or ask interactively — post a comment (`/handle-comment` with `action=place`, `type=COMMENT`) on the most relevant node. Then:
    - If a reasonable default interpretation exists, continue with it.
    - If it doesn't — the prompt is ambiguous enough that any guess risks doing the wrong thing — stop instead of guessing. Skip straight to step 6 and mark the prompt `DONE` with a comment explaining what's unclear and pointing to the comment you just posted. Never leave a prompt neither progressed nor closed.
@@ -279,6 +283,7 @@ nothing to sanitize either, since a board change is not user text.
 | Write the specs for a COMMAND or READMODEL — GWT scenarios, or a storyline for a view | `/eventmodeling-elaborating-scenarios` |
 | Make an existing timeline element's (COMMAND/READMODEL/AUTOMATION) slice explicit | `/eventmodeling-slicing-event-models` |
 | Add the next slice when nothing existing is left to slice | `/add-next-slice` |
+| Model a whole process, domain or chapter end to end from requirements (events → commands/screens → read models → scenarios → slices) | `/eventmodeling-orchestrating-event-modeling` |
 | Update the status of a slice (e.g. done, in-progress) | `/update-slice-status` |
 | Update the status of the current prompt (e.g. in-progress, done) | `/update-prompt-status` |