Module Boundary Governance

Use this skill to keep module boundaries explicit before code changes make them fuzzy. Treat the boundary manifest as a small control surface: it should describe module ownership, public surface, internal layers, dependency direction, and review questions without becoming a second architecture codebase.

This skill works best alongside a planning workflow such as plan-driven-change. Use it to decide the owning module, choose whether a new nested layer is warranted, update or create the manifest, and run a boundary audit after implementation.

Default Recommendation

Prefer one manifest per major module root with nested layers inside the same file.

Use a separate manifest file only when a submodule is independently owned or reused and has meaningfully different boundary rules.

Keep automation strict for dependency direction and public entrypoints. Keep semantic placement review human-readable via purpose, allowed contents, forbidden contents, and audit questions.

Adopt manifests incrementally. Prefer small structural corrections over broad redesign.

Trigger Checklist

Load this skill when any of these are true: