Purpose
Use this skill to design boundaries that prevent change ripple: keep the core logic independent from volatile outer layers (UI/DB/frameworks/services).
It follows Clean Architecture ideas: dependency direction, dependency inversion, and simple data transfer across boundaries.
When to use
Use this skill when:
- •You are introducing or changing an integration with a DB, external service, or framework.
- •You need to define a new interface boundary, wrapper, or adapter.
- •You are reviewing code that leaks framework types or vendor errors into core logic.
How to use
- •
Open
references/architecture-boundaries.md. Select 1–3 relevant headings and cite them by heading name in your reasoning. - •
Identify the boundary crossing points (where external things meet your code).
- •
Ensure dependency direction is outward → inward: inner code should not import outer-layer types.
- •
Define a small interface in the inner layer and implement it in the outer layer (DIP).
- •
Use simple DTOs for boundary data. Convert at the boundary; do not pass framework objects inward.
Output expectation
- •Provide a boundary diagram or a short mapping (outer types → DTO → core types).
- •Show how errors are translated at the boundary.