← ClaudeAtlas

hexagonal-with-enforced-contractslisted

Use when building an app that touches external systems (LLMs, DBs, cloud SDKs, HTTP APIs) — isolate a framework-free core behind ports a linter enforces.
pedro-angel/agent-methodology · ★ 0 · AI & Automation · score 70
Install: claude install-skill pedro-angel/agent-methodology
# Hexagonal Boundaries Enforced by a Linter Put your business logic in a core that imports no framework or SDK, reach every external system through a Protocol/interface port, and let an automated import-checker — not reviewer discipline — fail the build when anything inner imports anything outer. ## When to use Reach for this whenever an app integrates volatile externals — LLM providers, databases, cloud SDKs, message queues, third-party HTTP APIs — and you want those choices to stay swappable and testable. Red-flag thoughts that mean STOP and apply this skill: - "I'll just import the SDK here in the logic, it's only one call." - "We'll all remember to keep the cloud client out of the core." - "I'll inject it as a generic/`Any`/`object` for now and type it later." - "Let me build the real cloud adapter first; the local stub can wait." - "The config/logging module can import from the adapter — it's just a helper." ## The rule 1. **Name the layers and order them.** Driving (entrypoints: CLI, HTTP, jobs) → adapters (concrete integrations) → application (use cases, orchestration) → domain (pure logic + models). Dependencies point only inward. The domain imports nothing but itself and the standard library. 2. **Make every external collaborator a port.** Define an interface/Protocol/abstract type for each seam (storage, LLM, retrieval, clock, mailer). The application depends on the port's signature, never on a concrete class. 3. **Treat an untyped seam as a defect.** If a co