Boundary and modeling
Skill AnamKwon/agent-skill-router/plugins/skill-router/skills/boundary-and-modeling
Cross-agent skill router that organizes large local skill libraries into category routers and loads leaf skills on demand.
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.
- 10 stars10 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.
What its author says it does
Copied from the file, not written here
Use first for API boundaries, module ownership, domain modeling, contracts, architecture seams, and recurring design structures.
SKILL.md
2.6 KB, 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.