@phuc1403/musketeer 0.7.0 → 0.8.0

package/manifest.json

@@ -146,14 +146,14 @@
     },
     "dotnet": {
       "label": "dotnet",
-      "description": ".NET extras: tdd, knowledge-crunching + EF migration-guard & CONTEXT auto-load hooks. Muster also always merges 4 quality-gate MSBuild properties into root Directory.Build.props (any dotnet-selected project, set MUSKETEER_SKIP_DOTNET_PROPS=1 to skip) and scaffolds a generic src/tests Clean Architecture skeleton when the project is genuinely blank.",
+      "description": ".NET extras: tdd, knowledge-crunching + EF migration-guard & ubiquitous-language auto-load hooks. Muster also always merges 4 quality-gate MSBuild properties into root Directory.Build.props (any dotnet-selected project, set MUSKETEER_SKIP_DOTNET_PROPS=1 to skip) and scaffolds a generic src/tests Clean Architecture skeleton when the project is genuinely blank.",
       "locked": false,
       "deps": [],
       "files": [
         "skills/tdd/**",
         "skills/knowledge-crunching/**",
         "hooks/block-migration-edits.cjs",
-        "hooks/inject-context.cjs"
+        "hooks/inject-ubiquitous-language.cjs"
       ],
       "settings": [
         {
@@ -166,9 +166,9 @@
         {
           "event": "SessionStart",
           "matcher": "startup|resume|clear|compact",
-          "command": "node \"${CLAUDE_PROJECT_DIR}/.claude/hooks/inject-context.cjs\"",
+          "command": "node \"${CLAUDE_PROJECT_DIR}/.claude/hooks/inject-ubiquitous-language.cjs\"",
           "order": 1,
-          "statusMessage": "Loading domain CONTEXT"
+          "statusMessage": "Loading ubiquitous language"
         }
       ],
       "prereqs": []

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@phuc1403/musketeer",
-  "version": "0.7.0",
+  "version": "0.8.0",
   "description": "Distributable custom Claude Code harness — one declarative command scaffolds a curated company of musketeers (skills/agents/hooks) into any project's .claude/.",
   "type": "commonjs",
   "bin": {

package/template/.claude/hooks/inject-design-docs.cjs

@@ -1,12 +1,12 @@
 #!/usr/bin/env node
-// SessionStart hook: inject Sololingo's always-on design artifacts into every
+// SessionStart hook: inject the project's always-on design artifacts into every
 // session so the design-first docs reliably "lead the code" (CLAUDE.md), instead
 // of relying on me to remember to read them.
 //
-// Payload (~7K tokens, mostly the CONTEXT.md): the CML context map, the
+// Payload (~7K tokens, mostly the vocabularies): the CML context map, the
 // architecture-characteristics worksheet, the ADR index, and every bounded
-// context's CONTEXT.md (globbed recursively, so new BCs are picked up with no
-// config change). tasks.json / event-storm JSON under bounded-contexts are
+// context's ubiquitous-language.md (globbed recursively, so new BCs are picked
+// up with no config change). tasks.json / event-storm JSON under bounded-contexts are
 // deliberately excluded — task-tracking and raw walls, not design context.
 //
 // Fails open: any error emits nothing and exits 0, so it can never block a session.
@@ -15,8 +15,8 @@ const path = require("path");
 
 const root = process.env.CLAUDE_PROJECT_DIR || process.cwd();
 
-// Recursively collect CONTEXT.md under a directory (BC ubiquitous-language models).
-function findContextDocs(dir) {
+// Recursively collect ubiquitous-language.md under a directory (one per bounded context).
+function findUbiquitousLanguageDocs(dir) {
   const out = [];
   let entries;
   try {
@@ -27,8 +27,8 @@ function findContextDocs(dir) {
   for (const entry of entries) {
     const full = path.join(dir, entry.name);
     if (entry.isDirectory()) {
-      out.push(...findContextDocs(full));
-    } else if (entry.isFile() && entry.name === "CONTEXT.md") {
+      out.push(...findUbiquitousLanguageDocs(full));
+    } else if (entry.isFile() && entry.name === "ubiquitous-language.md") {
       out.push(full);
     }
   }
@@ -40,7 +40,7 @@ try {
     path.join(root, "docs", "context-map.cml"),
     path.join(root, "docs", "architecture-characteristics.md"),
     path.join(root, "docs", "adr", "README.md"),
-    ...findContextDocs(path.join(root, "docs", "bounded-contexts")),
+    ...findUbiquitousLanguageDocs(path.join(root, "docs", "bounded-contexts")),
   ];
 
   const sections = [];
@@ -60,16 +60,16 @@ try {
   }
 
   const additionalContext =
-    "Sololingo design artifacts — injected every session." +
+    "Design artifacts — injected every session. " +
     "Treat these as the source of truth for the domain model, context boundaries, architecture " +
     "characteristics, and recorded decisions; consult them before any domain, " +
     "architecture, or ADR work, and keep changes consistent with them.\n\n" +
-    "Each CONTEXT.md captures the decisions of the DOMAIN only — the ubiquitous " +
-    "language and model rules, kept vendor/decision-neutral. It bounds what the " +
+    "Each ubiquitous-language.md captures the decisions of the DOMAIN only — the " +
+    "vocabulary and model rules, kept vendor/decision-neutral. It bounds what the " +
     "domain model sees, not what infrastructure may do: the ACL/infrastructure can " +
     "legitimately key on more than the model names. (E.g. the domain only ever sees " +
     "a learner's Email, never the auth method; the ACL may also match the OIDC `sub`.) " +
-    "That layering is intended, not a contradiction of CONTEXT.md.\n\n" +
+    "That layering is intended, not a contradiction of the ubiquitous language.\n\n" +
     sections.join("\n\n");
 
   process.stdout.write(

package/template/.claude/hooks/inject-ubiquitous-language.cjs

@@ -0,0 +1,52 @@
+#!/usr/bin/env node
+// SessionStart hook (dotnet company): auto-load `docs/ubiquitous-language.md` —
+// the bounded context's vocabulary, produced by the knowledge-crunching skill —
+// into every session, so the domain's language and invariants "lead the code".
+//
+// If the doc is missing, ALERT the user (systemMessage) with the command that
+// creates it. Any other error fails open (emits nothing, exit 0) so it can never
+// block a session.
+const fs = require("fs");
+const path = require("path");
+
+const root = process.env.CLAUDE_PROJECT_DIR || process.cwd();
+const REL = "docs/ubiquitous-language.md";
+const file = path.join(root, "docs", "ubiquitous-language.md");
+
+try {
+  let content;
+  try {
+    content = fs.readFileSync(file, "utf-8");
+  } catch {
+    // Not found — surface a visible warning to the user, inject nothing.
+    process.stdout.write(
+      JSON.stringify({
+        systemMessage:
+          `musketeer: no ${REL} — the bounded context's ubiquitous language is missing. ` +
+          "Run the knowledge-crunching skill (/knowledge-crunching) to create it.",
+      })
+    );
+    process.exit(0);
+  }
+
+  const additionalContext =
+    `Ubiquitous language (${REL}) — injected every session. It is the vocabulary and ` +
+    "model rules of this bounded context, kept vendor- and decision-neutral. Treat it as " +
+    "canonical for domain naming, concepts, and invariants: name new code after it, and when a " +
+    `concept is renamed update ${REL} and the code in the same turn. It bounds what the DOMAIN ` +
+    "model sees, not what infrastructure may do (an ACL can legitimately key on more).\n\n" +
+    `===== ${REL} =====\n` +
+    content.trimEnd();
+
+  process.stdout.write(
+    JSON.stringify({
+      hookSpecificOutput: {
+        hookEventName: "SessionStart",
+        additionalContext,
+      },
+    })
+  );
+  process.exit(0);
+} catch {
+  process.exit(0); // fail open
+}

package/template/.claude/skills/context-map/SKILL.md

@@ -75,6 +75,6 @@ For deeper validation, open the file in VSCode with the Context Mapper extension
 
 ## Glossary
 
-Same `CONTEXT.md` convention as the EventStorming skills. Challenge BC names against the glossary before writing. If a relationship introduces a novel domain term, add a one-sentence definition in `CONTEXT.md` the same turn.
+Same `ubiquitous-language.md` convention as the EventStorming skills. Challenge BC names against the language doc before writing. If a relationship introduces a novel domain term, add a one-sentence definition in `docs/ubiquitous-language.md` the same turn.
 
 </supporting-info>

package/template/.claude/skills/knowledge-crunching/SKILL.md

@@ -1,130 +1,94 @@
 ---
 name: knowledge-crunching
 description: >-
-  Crunch domain knowledge with the user as domain expert, Eric Evans style: instead of drawing
-  diagrams, express the emerging model as test-driven domain-layer code in the project's own
-  language, verify understanding in a tight per-concept loop before writing anything, and record the
-  shared vocabulary in the bounded context's CONTEXT.md (its ## Language section). Use when the user invokes
-  /knowledge-crunching, describes a domain flow/feature to model, wants to collaboratively discover a
-  domain model, distill a ubiquitous language, reconcile experts' terminology, or build a DDD domain
-  prototype test-first while confirming each concept before coding.
+  Crunch domain knowledge with the user as domain expert into test-driven domain-layer code and a ubiquitous language (DDD). Use when the user invokes /knowledge-crunching, describes a domain flow or feature to model, wants to discover a domain model, distill a ubiquitous language, or reconcile experts' terminology.
 ---
 
 # Knowledge Crunching
 
-You are the developer/architect on a DDD team; the user is the **domain expert** (the client). You
-crunch their knowledge into a model the way Eric Evans did on the PCB project, with one change: **the
-emerging model is test-driven domain-layer code, not diagrams.**
+You are the developer/architect on a DDD team; the user is the **domain expert** (the client). You crunch their knowledge into a model through a tight modeling dialogue, with one commitment: **the emerging model is test-driven domain-layer code, not diagrams.**
 
-**This skill handles:** the collaborative modeling *dialogue* and the domain-layer model it produces
-— types, behavior, unit tests, and the language in `CONTEXT.md` — for a module that already exists,
-whether its domain layer is a bare scaffold or a live model. **Does NOT handle:** persistence,
-repositories, UI, API/transport, deployment, strategic context-mapping, or standing up a new module
-scaffold (a prerequisite, done first). Stay in the domain layer; if the user asks for the rest, note
-it's out of scope and offer to hand off afterward.
+**This skill handles:** the collaborative modeling *dialogue* and the domain-layer model it produces — types, behavior, unit tests, and the language in `docs/ubiquitous-language.md` — for a module that already exists, whether its domain layer is a bare scaffold or a live model. **Does NOT handle:** persistence, repositories, UI, API/transport, deployment, strategic context-mapping, or standing up a new module scaffold (a prerequisite, done first). Stay in the domain layer; if the user asks for the rest, note it's out of scope and offer to hand off afterward.
 
 ## The five stances (hold these the whole session)
 
-1. **Model in code, not diagrams.** Every model fragment is a small type or method — in the bounded
-   context's own language — you can show on screen. The running test, not a picture, is what makes the
-   model concrete to the expert. (Examples in this skill are language-neutral pseudocode; write yours
-   as real, runnable code and tests in the project's language and test framework.)
-2. **Verify before you build.** Never write code for an unconfirmed concept — propose, ask, and
-   **WAIT** for the answer (mechanics in Step 4). Their corrections *are* the model.
-3. **Speak the expert's words.** Use their nouns and verbs verbatim. Reconcile synonyms and
-   contradictions out loud ("ref-des and component instance — same thing?"). Code names == language names.
-4. **Distill, don't transcribe.** Exclude every fact the current problem doesn't need (Evans dropped
-   `Topology` for the probe simulation). Bring a concept back only when a feature actually pulls it in.
-5. **Don't accept the solution as stated.** Experts often describe a mechanical solution ("read a file,
-   sort it, write a report"). Dig past it for the domain concepts that yield the real leap.
+1. **Model in code, not diagrams.** Every model fragment is a small type or method — in the bounded context's own language — you can show on screen. The running test, not a picture, is what makes the model concrete to the expert.
+2. **Verify before you build.** Never write code for an unconfirmed concept — propose, ask, and **WAIT** for the answer.
+3. **Speak the expert's words.** Use their nouns and verbs verbatim. Reconcile synonyms and contradictions out loud ("customer and account holder — same thing?"). Code names == language names.
+4. **Distill, don't transcribe.** Exclude every fact the current problem doesn't need — the model is a distillation, not a transcription. Bring a concept back only when a feature actually pulls it in.
+5. **Don't accept the solution as stated.** A request usually arrives already framed as a mechanism ("export the table, sort it, email a summary"). That framing is not the domain. Dig past it for the concepts underneath — that is where the model is.
 
 ## Workflow
 
-### Step 1 — Open the session and name the flow
+### Step 1 — Read what already exists
+**First read any prior crunching output for that context** — `docs/ubiquitous-language.md` and the domain's code; in DDD, document = code. If the module is a bare scaffold with no language chosen yet, ask the user which language and test framework the context should be modeled in before proposing any code.
 
-**First read any prior crunching output for that context** — the root-level `CONTEXT.md` and read the domain's code; in DDD, document = code. While reading the code, **note the language, idioms, and test framework already in use** — you'll model in those. If the module is a bare scaffold with no language chosen yet, ask the user which language and test framework the context should be modeled in before proposing any code.
+If a model is already there, read it against the language and let each mismatch become a Step 4 loop turn — surface it, verify with the user, then change code and `docs/ubiquitous-language.md` together:
 
-### Step 2 — Find the first model elements (the "glimmer")
-Listen past the user's solution framing for the **domain nouns and verbs that keep recurring** — Name 2–4 candidate
-concepts back to the user and ask which ones are real. Do not scaffold types yet.
+- **Synonym drift** — code says `Learner`, experts now say `Student`. Reconcile and pick one, in both.
+- **Conflated concept** — one type doing two jobs the experts name separately → candidate split.
+- **Leaked invariant** — a rule enforced in a service/controller that an aggregate should own.
+- **Dead concept** — a type no scenario exercises anymore → remove it from the code and drop its entry.
+
+### Step 2 — Find the first model elements
+The opening description is usually a mechanism, not a model (stance 5). Listen past it for the **domain nouns and verbs that keep recurring**, and name 2–4 of them back as candidate concepts.
+
+For each, ask whether it is something the business actually names and treats as a distinct thing — as opposed to a word used in passing, or one you invented. You are testing your own guesses, so expect to be corrected. This is *not* "which word do you prefer?" — choosing between two words for one thing is stance 3, and it only arises once you have two.
+
+> **You:** I'm hearing `Car`, `Inspection`, and something like `Listing` for a car on the lot for sale. Is `Listing` a real thing you'd name, or just "the car is on the lot"?
+>
+> **Expert:** It's real, but we call it a `Unit`, and only once it's passed inspection. A car we haven't inspected isn't a unit.
+
+One answer, and you have a concept, its actual name, and the rule that brings it into existence. Do not scaffold types yet.
 
 ### Step 3 — Focus on ONE scenario
-Narrow to a single concrete scenario to make progress.
-Ask the user to pick or confirm the one scenario you'll model first. Everything else waits.
+Narrow to a single concrete scenario to make progress. Ask the user to pick or confirm the one you'll model first; everything else waits. If their explanation runs ahead of you, say so and pull back here.
 
 ### Step 4 — The per-concept tight loop (the heart of the skill)
 For each concept the chosen scenario pulls in, run this loop — **one concept at a time**:
 
-1. **Propose** one model fragment as minimal code in the project's language (a type, a method, a
-   relationship) + a one-line plain gloss of what it means.
-2. **Ask one sharp verifying question** that would expose a misunderstanding if your guess is wrong —
-   about cardinality, a synonym, behavior ownership, an exclusion, a simplification, or the goal of the
-   computation. (Catalog of question types + the PCB dialogue worked end-to-end:
-   `references/crunching-dialogue.md`.)
+1. **Propose** one model fragment as minimal code in the project's language (a type, a method, a relationship) + a one-line plain gloss of what it means.
+2. **Ask one sharp verifying question** that would expose a misunderstanding if your guess is wrong. Pick the type that fits the fragment you just proposed — a good question is falsifiable, concrete, and answerable in a sentence, never "does this look right?":
+
+   | Type | What it pins down | Template |
+   |---|---|---|
+   | **Cardinality** | how many relate to how many | "Does one X belong to exactly one Y, or many?" |
+   | **Synonym** | two words, one concept | "Are X and Y the same thing?" |
+   | **Ownership of behavior** | which object does the work | "What pushes the signal — X or Y?" |
+   | **Exclusion / relevance** | is this concept needed *now* | "Does X matter for this scenario?" |
+   | **Simplification** | how little can we model | "Is a simplified Z enough instead of full X?" |
+   | **Computation goal** | what the output must be | "What exactly do you need from this?" |
+   | **Definition of a unit** | what one increment is | "What counts as one X?" |
+   | **Lifetime / sameness** | shared vs per-instance data | "Is this the same for every instance, or per instance?" |
+
+   If you can't think of a question, you don't understand the fragment well enough to code it — go smaller. Prefer a question that could get a "no"; one that can only be answered "yes" teaches nothing. After a "no," restate the corrected understanding before moving on.
 3. **WAIT** for the answer. Do not write code, tests, or the next fragment until the user responds.
 4. **Fold in** the correction (rename, re-shape, drop, or add), then record the term (Step 6).
 
 Example of the loop's rhythm (compressed):
 
-> **You:** Here's my first guess — a `Net` carries a signal to every `Pin` attached to it.
-> ```
-> Net — connects many Pins
-> ```
-> Are you saying a `Pin` belongs to exactly one `ComponentInstance` and connects to exactly one `Net`?
+> **You:** Here's my first guess — an `Order` groups the `LineItem`s a customer buys in one go, so `Order` holds many `LineItem`s. Does a `LineItem` belong to exactly one `Order`, or can the same one sit on several?
 >
-> **Expert:** Yes — one pin, one component instance, one net.
+> **Expert:** One line item, one order. Always.
 >
 > **You:** Good — I'll make that a hard invariant. *(folds in, records the term, then moves to the next concept)*
 
-### Step 5 — TDD the confirmed behavior (one test at a time)
-Now make the confirmed fragment real — **domain only, no persistence, no UI**. The cardinal rule is
-**a genuine RED before any production code**:
-
-1. The fragment you sketched in Step 4 is a *drawing in the chat, not a file*. **Do not create the
-   production type yet.**
-2. **RED** — write ONE test for ONE behavior the fragment must exhibit, run the project's test command,
-   and show it **fail**. A compile error because the type/method doesn't exist yet counts as red — that
-   failing run is the point; never skip it by writing the type and its test together.
-3. **GREEN** — write the *minimal* code to pass that one test; run it; show green.
-4. **Repeat one behavior at a time** — test → code, test → code. Never write several tests at once or
-   write the whole type ahead of its tests. Batching tests ("horizontal slicing") yields tests of
-   *imagined*, not actual, behavior.
-5. Test **observable behavior through the public surface**, not getters or data shape. The test should
-   read like the scenario's rule (Evans: "a path of more than 2–3 hops is a long delay; each Net
-   crossing is one hop") and survive an internal refactor.
-6. **Never refactor while red.** Get to green first; tidy only with the bar green.
-
-Let the failing-then-passing test — not a written-out class — be the turning point that makes the model
-concrete to the expert.
+A loop turn is complete only when **all three** agree: the **expert** has answered the verifying question, the **code** reflects that answer, and **`docs/ubiquitous-language.md`** records the term. If any of the three lags, close the gap before proposing the next concept.
 
-### Step 6 — Record the language immediately
-The ubiquitous language lives in **one** place: the bounded context's `CONTEXT.md`, under
-`## Language`. There is no separate glossary file. The moment a term is confirmed, add an entry in the
-repo's format — `**Term**:` then a one-line definition in the expert's words (mention the `TypeName`
-that embodies it), then `_Avoid_:` rejected synonyms — grouped under a `###` subsection. Keep code and
-`CONTEXT.md` identical: rename in code, rename here in the same turn. Distilled-out concepts go under
-`## Deferred`, unresolved ones under `## Flagged ambiguities`.
+### Step 5 — TDD the confirmed behavior (one test at a time)
+Make the confirmed fragment real with the red-green loop in the `tdd` skill (`.claude/skills/tdd/SKILL.md`) — its rules on one-test-at-a-time, minimal green, testing observable behavior through the public surface, and never refactoring while red all apply here unchanged.
 
-Edit the context's existing root-level `CONTEXT.md` directly — it is canonical, and is
-also your seed (Step 1). If the module is new and has no `CONTEXT.md` yet, create one from
-`assets/context.template.md`.
+Two amendments for a crunching session:
 
-### Step 7 — Distill, then loop
-Drop concepts the current scenario doesn't need and say so ("I'll leave `Topology` out for now; we'll
-bring it back when we model routing"). When a new scenario arrives and the model can't express it,
-brainstorm a new concept or refactor an existing one toward deeper insight — that is crunching the
-knowledge further. Return to Step 3 for the next scenario.
+- **Domain layer only.** No persistence, no application handlers, no UI. Ignore that skill's full-vertical-slice default — here the slice stops at the domain, and what comes next is the expert's next concept, not the next layer.
+- **The Step 4 sketch is a drawing in the chat, not a file.** Do not create the production type ahead of its first failing test. A compile error because the type does not exist yet is a legitimate red, and that failing run is the point.
 
-## Pace and etiquette
+### Step 6 — Record the language immediately
+The ubiquitous language lives in **one** place: `docs/ubiquitous-language.md`. There is no separate glossary file. The moment a term is confirmed, add one line — `Term: ` then what it means in the expert's words. Nothing else: no rejected-synonym list, no deferred section, no grouping. The term is already the type's name (stance 3), so don't restate it. Rename in code, rename here in the same turn.
 
-- Move **one concept per turn**. A wall of ten types with no questions is the failure mode — it skips
-  the verification that makes this skill worth running.
-- When the user's explanation makes your "head spin," say so and pull back to one concrete scenario.
-- Keep the prototype runnable at every step; a red build is fine *during* a cycle, never at a pause.
+Write a dictionary entry, not prose. One line. No lead-in, no narrative, no "this is the concept that…". Keep implementation and vendor words out — they name the mechanism, not the concept (stance 5). Keep invariants out — rules live in the code and its tests (Step 5).
 
-## Resources
+If the doc does not exist yet, copy `assets/ubiquitous-language.template.md` from this skill to `docs/ubiquitous-language.md`. If it already exists, edit it — never overwrite it, and never start a second one. It is canonical, and is also your seed (Step 1).
 
-- `references/crunching-dialogue.md` — the verifying-question catalog, the PCB session worked
-  end-to-end (dialogue → code → `CONTEXT.md`), and drift triggers in existing code. Read at Step 4.
-- `assets/context.template.md` — starter `CONTEXT.md` (repo's `## Language` format) for a **new**
-  module that has none yet; if the context already has a `CONTEXT.md`, edit that one instead.
+### Step 7 — Distill, then loop
+Drop concepts the current scenario doesn't need and say so ("I'll leave scheduling out for now; we'll bring it back when a feature needs it"). When a new scenario arrives and the model can't express it, brainstorm a new concept or refactor an existing one toward deeper insight — that is crunching the knowledge further. Return to Step 3 for the next scenario.

package/template/.claude/skills/knowledge-crunching/assets/ubiquitous-language.template.md

@@ -0,0 +1,3 @@
+# Ubiquitous Language
+
+<Term>: <what it means, in the expert's own words>

package/template/.claude/hooks/inject-context.cjs

@@ -1,52 +0,0 @@
-#!/usr/bin/env node
-// SessionStart hook (dotnet company): auto-load the repo-root `CONTEXT.md` — the
-// bounded-context model produced by the knowledge-crunching skill — into every
-// session, so the domain's ubiquitous language and invariants "lead the code".
-//
-// If the root CONTEXT.md is missing, ALERT the user (systemMessage) so they
-// create one. Any other error fails open (emits nothing, exit 0) so it can never
-// block a session.
-const fs = require("fs");
-const path = require("path");
-
-const root = process.env.CLAUDE_PROJECT_DIR || process.cwd();
-const file = path.join(root, "CONTEXT.md");
-
-try {
-  let content;
-  try {
-    content = fs.readFileSync(file, "utf-8");
-  } catch {
-    // Not found — surface a visible warning to the user, inject nothing.
-    process.stdout.write(
-      JSON.stringify({
-        systemMessage:
-          "musketeer: no CONTEXT.md at the repo root — the bounded-context model is missing. " +
-          "Run the knowledge-crunching skill (/knowledge-crunching) to create one.",
-      })
-    );
-    process.exit(0);
-  }
-
-  const additionalContext =
-    "Bounded-context model (root CONTEXT.md) — injected every session. It is the " +
-    "ubiquitous language and model rules of this bounded context, kept vendor- and " +
-    "decision-neutral. Treat it as canonical for domain naming, concepts, and invariants: " +
-    "name new code after it, and when a concept is renamed update CONTEXT.md and the code in " +
-    "the same turn. It bounds what the DOMAIN model sees, not what infrastructure may do " +
-    "(an ACL can legitimately key on more).\n\n" +
-    "===== CONTEXT.md =====\n" +
-    content.trimEnd();
-
-  process.stdout.write(
-    JSON.stringify({
-      hookSpecificOutput: {
-        hookEventName: "SessionStart",
-        additionalContext,
-      },
-    })
-  );
-  process.exit(0);
-} catch {
-  process.exit(0); // fail open
-}

package/template/.claude/skills/knowledge-crunching/assets/context.template.md

@@ -1,59 +0,0 @@
-# {{CONTEXT_TITLE}}
-
-<One line: the slice of the domain this context covers — the flow you crunched, in the expert's words.>
-
-> Starter for a context that has **no `CONTEXT.md` yet**. It lives at the
-> root folder as `CONTEXT.md`. If the context already has one, edit that — never a second.
-
-## Language
-
-The vocabulary of *this* context, crunched with the domain expert. Each entry must clear this bar:
-
-- **One meaning.** A term denotes exactly one thing here. If it means two things, split it into two.
-- **Defined in the expert's words**, present tense — never with implementation or vendor terms, and
-  never using the term to define itself.
-- **Says what it is _not_** whenever it's easily confused with a neighbour — the sharpest
-  disambiguator there is.
-- **Carries its governing rule** when one exists ("… finishes when …") — the language should imply the
-  behavior, not just label a noun.
-- **Bound to code:** name the `TypeName` that embodies it. The type and the term are the same word.
-- **`_Avoid_:` rejected synonyms** so the wrong word can't creep back (add a half-line *why* if it
-  isn't obvious).
-
-Group related terms under `###` subsections. Reference other defined terms by their exact name.
-
-Worked example of the bar (delete once you have your own):
-
-### Connectivity
-
-**Net**:
-A conductor that carries one signal to every `Pin` connected to it; a signal crossing a `Net` counts as
-one **hop**. _Not_ a physical wire segment — one `Net` may span many segments.
-_Avoid_: wire, trace, connection
-
-**Pin**:
-A single connection point on a `ComponentInstance`. Belongs to exactly one `ComponentInstance` and
-connects to exactly one `Net` — that one-to-one-to-one rule is an invariant.
-_Avoid_: leg, terminal (terminal means the physical metal, not the model concept)
-
----
-
-### <your first group>
-
-**<Term>**:
-<One sentence in the expert's words; fold in the governing rule if any, and what it is _not_ if it's
-confusable; name the `TypeName` that embodies it.>
-_Avoid_: <rejected synonyms>
-
-## Deferred
-
-Concepts that exist in the domain but this scenario doesn't need yet — distilled out, the way Evans
-dropped `Topology` for the probe simulation. Bring one back only when a feature actually pulls it in.
-
-- **<Term>** — <what it is; why it isn't needed yet>
-
-## Flagged ambiguities
-
-Open questions or contradictions between experts, to resolve in a later loop.
-
-- <the question — and who or what would settle it>

package/template/.claude/skills/knowledge-crunching/references/crunching-dialogue.md

@@ -1,113 +0,0 @@
-# The Crunching Dialogue
-
-How to run Step 4's per-concept loop well: the kinds of questions that actually move the model, and
-the full PCB session translated from Evans' diagrams into the code/test/glossary this skill produces.
-
-> The model fragments below are written in **language-neutral pseudocode** so the modeling moves stay
-> the point. In a real session, write them as actual runnable types and tests in the bounded context's
-> own language and test framework.
-
-## Verifying-question catalog
-
-Each loop turn asks **one** question whose answer would change the code if your guess is wrong. Pick
-the type that fits the fragment you just proposed. A good question is falsifiable, concrete, and
-answerable in a sentence — not "does this look right?"
-
-| Type | What it pins down | Template | PCB example |
-|---|---|---|---|
-| **Cardinality** | how many relate to how many | "Does one X belong to exactly one Y, or many?" | "A `Pin` belongs to one `ComponentInstance` and one `Net`?" |
-| **Synonym** | two words, one concept | "Are X and Y the same thing?" | "Is `ref-des` the same as `component instance`?" |
-| **Ownership of behavior** | which object does the work | "What pushes the signal — X or Y?" | "Does the `Net` carry the signal further, or does the component push it?" |
-| **Exclusion / relevance** | is this concept needed *now* | "Does X matter for this scenario?" | "Does `Topology` come into the probe simulation?" |
-| **Simplification** | how little can we model | "Is a simplified Z enough instead of full X?" | "Can a list of push-throughs stand in for chip internals?" |
-| **Computation goal** | what the output must be | "What exactly do you need from this?" | "What are we looking for — paths longer than 2–3 hops?" |
-| **Definition of a unit** | what one increment is | "What counts as one X?" | "What counts as one hop?" |
-| **Lifetime / sameness** | shared vs per-instance data | "Is this the same for every instance, or per instance?" | "Are the pushes the same for all instances of a component?" |
-
-Rules of thumb:
-- If you can't think of a question, you don't understand the fragment well enough to code it — go
-  smaller.
-- Prefer a question that could get a "no." A question that can only be answered "yes" teaches nothing.
-- After a "no," restate the corrected understanding before moving on, so the correction is shared.
-
-## The PCB session, translated to code
-
-Evans drew object-interaction and class diagrams. This skill produces the same model as code + tests +
-glossary. Below, each beat of the original dialogue maps to what you would actually write.
-
-### Beat 1 — the glimmer ("nets")
-The experts kept asking for reports about *nets*. That recurring noun, not their "read a file and
-sort it" framing, was the first model element. You name it back and ask a cardinality question rather
-than scaffolding a type immediately.
-
-> "A `Net` is a conductor that connects components and carries a signal to everything on it — yes?"
-
-### Beat 2 — reconcile terminology, fix cardinality
-"Component" vs "component instance" vs "ref-des" collide. You reconcile them (synonym question), then
-pin the pin↔instance↔net cardinality (cardinality question). Only once confirmed do you write:
-
-```
-ComponentInstance                 // expert's "ref-des" — reconciled to one name
-    pins -> read-only list of Pin
-
-Pin
-    owner -> ComponentInstance     // exactly one (confirmed)
-    net   -> Net (optional)        // exactly one (confirmed)
-
-Net
-    pins  -> read-only list of Pin // connects many pins
-```
-
-### Beat 3 — narrow to one scenario (probe simulation)
-You drop everything not needed to simulate a signal. You ask the *ownership* question and learn the
-**component pushes the signal through** — the `Net` does not do it alone.
-
-### Beat 4 — simplify what you can't model
-You can't model chip internals; you ask the *simplification* question and the expert offers
-"push-throughs": a list of (fromPin → toPin) for a component **type** (not per instance — that's the
-lifetime question). The behavior, driven by a test:
-
-```
-test "signal propagates through pushes and across nets":
-    // arrange a tiny board: in-pin → component pushes to out-pin → net to next component
-    hops = simulation.probe(startPin)
-    assert hops == 2          // each Net crossing counts as one hop
-```
-
-### Beat 5 — pin the computation goal and the unit
-The *computation-goal* question yields the rule: flag any signal path longer than 2–3 hops. The
-*unit* question yields: **one hop = one Net crossing.** So the `Net` increments the hop count as the
-signal passes:
-
-```
-Net
-    carry(hopsSoFar) -> hopsSoFar + 1   // crossing this Net is one hop
-```
-
-### Beat 6 — distill: drop `Topology`
-`Topology` exists in the domain but isn't used by the probe simulation, so you explicitly leave it
-out ("I'll drop it for now; we'll bring it back for routing"). The model is a distillation, not a
-transcription — it excludes the hundreds of facts the engineers know but this problem doesn't need.
-
-## What "on the same page" looks like at the end of a loop
-
-A loop turn is complete only when **all three** agree:
-1. the **expert** has answered the verifying question,
-2. the **code** (type/method/test) reflects that answer, and
-3. the **`CONTEXT.md` `## Language`** records the term, its definition in their words, the rejected
-   synonyms (`_Avoid_:`), and the `TypeName` that embodies it.
-
-If any of the three lags, close the gap before proposing the next concept.
-
-## Drift triggers in existing code
-
-When the module's domain layer already has a model, read it against the language and let each mismatch
-become a verifying-question loop turn — surface it, verify with the user, then change code +
-`CONTEXT.md` together:
-
-- **Synonym drift** — code says `Learner`, experts now say `Student`. Reconcile, pick one, record the
-  rejected synonym under `_Avoid_:`.
-- **Conflated concept** — one type doing two jobs the experts name separately → candidate split.
-- **Leaked invariant** — a rule enforced in a service/controller that an aggregate should own.
-- **Dead concept** — a type no scenario exercises anymore → deprecate (move to `CONTEXT.md`'s
-  `## Deferred` with the reason).