メニュー
Use first for API boundaries, module ownership, domain modeling, contracts, architecture seams, and recurring design structures.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Use when organizing a large local skill library into category router skills, refreshing a compact skill inventory, or deciding which leaf skill bodies need to be read before agent classification.
Use first for ambiguous failures, messy project context, surprising results, repeated failures, postmortems, or contested product and architecture framing.
Use first for bounded code edits, refactors, implementation, simplification, control-flow cleanup, or maintainer clarity before choosing a more specific theory skill.
Use to organize a large skill library into category routers, route new skills, and propose new categories when existing routers are insufficient.
Use first when the user asks for tests, correctness, high reliability, static reasoning, proof, or safety evidence.
Use first for work shaped by users, tools, procedures, runtime evidence, operational artifacts, interfaces, or organizational workflows.
| name | boundary-and-modeling |
| description | Use first for API boundaries, module ownership, domain modeling, contracts, architecture seams, and recurring design structures. |
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.
Identify what kind of boundary is under pressure: domain meaning, volatile decision, caller contract, ownership seam, or recurring design force.
SKILL.md before implementing, reviewing, or advising.| 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. |
Before loading a leaf, answer briefly:
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.