Boundary and Modeling
Use first for API boundaries, module ownership, domain modeling, contracts, architecture seams, and recurring design structures. This is a router skill: use it to select the
smallest relevant leaf skill, then read that leaf skill before doing the work.
Route First
Identify what kind of boundary is under pressure: domain meaning, volatile decision, caller contract, ownership seam, or recurring design force.
- Restate the user's task as one concrete force or uncertainty.
- Choose the first route that directly names that force.
- Read the selected linked leaf
SKILL.md before implementing, reviewing, or advising.
- Load a second leaf only when the task has two independent forces that both affect the outcome.
- If no route fits, continue without a leaf skill and say the category did not match.
Routes
| Leaf Skill |
Use When |
domain-driven-design |
Use when business/domain language, bounded contexts, aggregates, or invariants should shape the model. |
information-hiding |
Use when a volatile design decision should be hidden behind a stable interface. |
design-by-contract |
Use when caller obligations, provider guarantees, and invariants must be explicit at a boundary. |
conways-law |
Use when architecture should match ownership, team communication, review, deployment, or support paths. |
design-patterns |
Use when a known recurring design solution may fit current forces better than a simpler structure. |
Avoid
- If the task is just a bounded code edit with no boundary question, route to code-change-core.
- If stakeholders disagree about the problem frame, route to ambiguity-and-learning first.
Prompting Pattern
Before loading a leaf, answer briefly:
- Category force: What makes this task belong here?
- Chosen route: Which leaf skill most directly matches the force?
- Why not others: Which nearby route was rejected and why?
Then load the chosen leaf skill and follow its workflow. Do not blend every
nearby theory into the task; route narrowly and let evidence pull in more context only when needed.
1---2name: boundary-and-modeling3description: Use first for API boundaries, module ownership, domain modeling, contracts, architecture seams, and recurring design structures.4---56# Boundary and Modeling78Use first for API boundaries, module ownership, domain modeling, contracts, architecture seams, and recurring design structures. This is a router skill: use it to select the9smallest relevant leaf skill, then read that leaf skill before doing the work.1011## Route First1213Identify what kind of boundary is under pressure: domain meaning, volatile decision, caller contract, ownership seam, or recurring design force.14151. Restate the user's task as one concrete force or uncertainty.162. Choose the first route that directly names that force.173. Read the selected linked leaf `SKILL.md` before implementing, reviewing, or advising.184. Load a second leaf only when the task has two independent forces that both affect the outcome.195. If no route fits, continue without a leaf skill and say the category did not match.2021## Routes2223| Leaf Skill | Use When |24| --- | --- |25| [`domain-driven-design`](../../../../libraries/theory-skills/domain-driven-design/SKILL.md) | Use when business/domain language, bounded contexts, aggregates, or invariants should shape the model. |26| [`information-hiding`](../../../../libraries/theory-skills/information-hiding/SKILL.md) | Use when a volatile design decision should be hidden behind a stable interface. |27| [`design-by-contract`](../../../../libraries/theory-skills/design-by-contract/SKILL.md) | Use when caller obligations, provider guarantees, and invariants must be explicit at a boundary. |28| [`conways-law`](../../../../libraries/theory-skills/conways-law/SKILL.md) | Use when architecture should match ownership, team communication, review, deployment, or support paths. |29| [`design-patterns`](../../../../libraries/theory-skills/design-patterns/SKILL.md) | Use when a known recurring design solution may fit current forces better than a simpler structure. |3031## Avoid3233- If the task is just a bounded code edit with no boundary question, route to code-change-core.34- If stakeholders disagree about the problem frame, route to ambiguity-and-learning first.3536## Prompting Pattern3738Before loading a leaf, answer briefly:3940- **Category force:** What makes this task belong here?41- **Chosen route:** Which leaf skill most directly matches the force?42- **Why not others:** Which nearby route was rejected and why?4344Then load the chosen leaf skill and follow its workflow. Do not blend every45nearby theory into the task; route narrowly and let evidence pull in more context only when needed.
anamkwon