Boundary and modeling
Skill AnamKwon/agent-skill-router/plugins/skill-router/skills/boundary-and-modeling
Use first for API boundaries, module ownership, domain modeling, contracts, architecture seams, and recurring design structures.From its SKILL.md
npx -y skills add AnamKwon/agent-skill-router --skill boundary-and-modelingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.6 KB, 518 tokens by cl100k_base, as published. Nobody here has run it
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.mdbefore 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.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.