Compare commits

...
Author SHA1 Message Date
remote-box d419977fe0 chore: add changeset for grilling em-dash removal 2026-08-15 20:50:05 +00:00
remote-box 86cba45f42 Remove em-dashes from grilling skill
Replaces em-dash punctuation in SKILL.md with colons and semicolons for plain-text consistency.
2026-08-15 20:45:25 +00:00
Matt Pocock 8b78b531ab Merge pull request #848 from mattpocock/domain-modeling-trigger-context-adr
domain-modeling: trigger on CONTEXT.md / ADR writes
2026-08-13 10:06:21 +01:00
Claude 54bc6b6040 domain-modeling: drop the "another skill needs to maintain" caveat
Every skill that delegates to domain-modeling (grill-with-docs,
wayfinder, improve-codebase-architecture, triage) already invokes
/domain-modeling explicitly by name, so the description never needed
to carry that branch — it's the invoking skill's job to say so, not
this one's to anticipate it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-13 08:34:35 +00:00
Claude e12e7ec6a7 domain-modeling: reword terminology trigger to "discussing codebase terminology"
"Pin down domain terminology or a ubiquitous language" was stiff and
leaned on DDD jargon. Swap it for the plainer, more naturally-phrased
"discussing codebase terminology".

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-13 08:21:20 +00:00
Claude f02e2ed362 chore: add changeset for domain-modeling trigger update
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-13 08:14:55 +00:00
Claude bd8e81baaf domain-modeling: trigger on CONTEXT.md / ADR writes explicitly
The description only fired on conversational framing ("pin down
terminology", "record a decision"). Add explicit triggers for writing
or editing a CONTEXT.md or an ADR directly, so the skill loads even
when the file operation itself is the request rather than the
underlying activity.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-13 08:13:05 +00:00
Matt Pocock 84fdeffd12 Merge pull request #788 from mattpocock/grill-me-align
docs(grill-me): drop the "holds decisions" phrasing
2026-08-06 20:49:51 +01:00
4 changed files with 14 additions and 4 deletions
@@ -0,0 +1,5 @@
---
"mattpocock-skills": patch
---
domain-modeling: trigger on discussing codebase terminology and on writing or editing a CONTEXT.md or an ADR directly, replacing the narrower "pin down domain terminology or a ubiquitous language" / "record an architectural decision" phrasing. Also drops the "another skill needs to maintain the domain model" caveat — that's the invoking skill's job to state explicitly, not this description's.
+5
View File
@@ -0,0 +1,5 @@
---
"mattpocock-skills": patch
---
grilling: remove em-dashes from `SKILL.md`, replacing them with colons and semicolons so the instructions read as plain text.
+1 -1
View File
@@ -1,6 +1,6 @@
---
name: domain-modeling
description: Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
description: Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR.
---
# Domain Modeling
+3 -3
View File
@@ -5,7 +5,7 @@ description: Grill the user relentlessly about a plan, decision, or idea. Use wh
Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it.
Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled: the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
Each question should be formatted like so:
@@ -15,8 +15,8 @@ Each question should be formatted like so:
➡️ <your recommended answer>
```
Each round the user answers reshapes the tree settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.
Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.
Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report ask the rest of the frontier now. The _decisions_ are the user's put each to them and wait.
Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The _decisions_ are the user's: put each to them and wait.
The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.