All skills
module-boundary-design
FoundationJIT onlyUse for cross-module ownership, surface, dependency, cycle, state, split, merge, or move decisions; skip owner-internal placement.
- Group
- Architecture & design
- Supported roles
- MainAnalysisTaskReview
- Source
- SKILL.md
Use when
Trigger signals that make this skill the right owner
- module ownership public surface dependency direction cycle shared state or split merge move changes
- cross-module internal import direct storage access or shared common utility ownership
Do not use when
Anti-triggers — as binding as the triggers above
- owner-internal method class or file placement preserves consumers state authority exports and dependency edges
- system architecture style or fixed layer responsibility selection
Required inputs
What must be supplied before this skill can decide anything
- boundary-kind and its authoritative language build package distributable or runtime mechanism
- current modules owners imports exports verified consumers and enforcement owner
- state source-of-truth mutation authority accepted constraints and current boundary validation
Output contract
What this skill owes the next role
- Module boundary decision with boundary-kind, authoritative mechanism, enforcement owner, responsibility and state authority, public/private surface, consumers, allowed/forbidden edges, cycle result, split/merge rationale, migration, evidence, proof limits, and residual risks.
Escalation signals
When this skill must hand the decision back
- state or source authority is unresolved across modules
- a required dependency creates a cycle or bypasses the owning contract
- a public boundary change has unknown consumers or disputed ownership
Loaded by
This skill never owns a task. These professionals may pull it in as Layer 3.
Targeted references
Each reference carries its own load condition. None of them enter context by default.
| Reference | Load when | Do not load when | Required by |
|---|---|---|---|
| benchmarks-and-enforcement.mdbenchmark-pattern | module boundary enforcement choice or static generated and runtime proof limits remain disputed | the changed module edges are covered by fresh boundary enforcement results | AnalysisReview |
| boundary-kind-and-authority.mdtargeted | boundary kind authoritative mechanism owner state surface or dependency direction remains open | current mechanism owner state authority surface and allowed edges already fix the boundary | AnalysisReview |
| split-merge-and-move-decisions.mdtargeted | a module split merge or move remains open after authority lifecycle consumer and change-reason analysis | module owner state lifecycle and dependency direction already fix keep split move or merge | AnalysisReview |