@eventmodelers/cli 1.0.117 → 1.0.118

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eventmodelers/cli",
-  "version": "1.0.117",
+  "version": "1.0.118",
   "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/analyze-code-base/SKILL.md

@@ -69,6 +69,8 @@ Every pass reads the code through the same four lenses; each produces *hypothese
 
    **With a URL, walk it via `discover-storyboard`** (URL already known — don't ask again; pass the flow as guidance and ask for screenshots). Its click path is the *proposed* order and its screens go into the chapter as evidence; confirm both against the API and persistence lenses. Submit forms only against a local or test system, or after the person agrees.
 
+If the code is a generic engine (templates, schemas, configurable entities), model one real case it handles, not the engine (see *Concrete Over Generic* in `eventmodeling-core-rules`).
+
 Where the lenses disagree (a route nobody calls, a table never written, a test for removed behaviour, a screen with no backend), that is a question for the person — not something to model.
 
 ---

package/stacks/modeling-kit/templates/.claude/skills/eventmodeling-core-rules/SKILL.md

@@ -165,6 +165,14 @@ Model the business process as it would work without any software first, then tra
 
 Question any step that exists only because of the system — a loading spinner, a cache refresh, a session check is not a business step and does not belong on the timeline. This is the discipline behind the Anti-Patterns below; the anti-patterns are what it looks like when this principle is skipped.
 
+## Concrete Over Generic
+
+Looking at the model, a reader must understand how the business works. Model one real flow with real examples and real data, not a generic model that covers every case. This applies to generic platforms too: model one real case the platform handles, not the platform's own structure.
+
+Example (a template-driven health record system):
+- ❌ `Commit Composition` with fields `content`, or `name`/`category`/`entries` — still says nothing about the business.
+- ✅ `Record Blood Pressure` → `Blood Pressure Recorded` with `systolic: 132`, `diastolic: 92`, `pulse: 113`, `composer: Dr. Marcus Johnson`.
+
 ## Anti-Patterns
 
 - **Data-loading commands**: `LoadOrders`/`FetchData` are queries, not business intent — model as a READMODEL, not a COMMAND.
@@ -209,5 +217,6 @@ Before treating a model as done, verify:
 - [ ] The timeline starts with a state-view or an automation reacting to an event — not a bare COMMAND
 - [ ] No two `state-change`/`state-change` slices are chained without a new trigger between them
 - [ ] No SCREEN is wired to more than one COMMAND (the bed — see Structural Shapes)
+- [ ] The model follows one real flow with real data, not a generic one (see Concrete Over Generic)
 
 This is the fast pass — the full, deeper check is `eventmodeling-validating-event-models-checklist`.