菜单
Core rules for developing code with hexagonal architecture. Use this whenever writing, reviewing, or refactoring any codebase that follows hexagonal architecture or making any recommendations about hexagonal architecture. References the other hex-arch skills for specifics.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Rules for writing domain objects in hexagonal architecture. Use this when creating or modifying or reviewing entities, value objects, aggregates, or domain services.
Rules for writing inbound adapters (also called presenters, controllers, or primary adapters) in hexagonal architecture. Use this when creating or modifying or reviewing any code that receives input from the outside world (HTTP handlers, CLI commands, queue consumers, event listeners, etc.).
Rules for writing outbound adapters (also called secondary adapters or infrastructure adapters) in hexagonal architecture. Use this when creating or modifying or reviewing any code that talks to the outside world on behalf of the application (databases, external APIs, file systems, message brokers, etc.).
Rules for defining ports in hexagonal architecture. Use this when creating or modifying or reviewing an interface or abstract type that acts as a boundary between the application and its adapters.
Rules for writing use cases in hexagonal architecture. Use this when creating or modifying or reviewing a use case / application service class or function.
| name | hexagonal-architecture |
| description | Core rules for developing code with hexagonal architecture. Use this whenever writing, reviewing, or refactoring any codebase that follows hexagonal architecture or making any recommendations about hexagonal architecture. References the other hex-arch skills for specifics. |
Apply hexagonal architecture principles whenever writing new code or modifying existing code in a project that says it should use hexagonal architecture in its agent file or architecture docs.
The architecture is divided into the following layers. Consult the dedicated skill for each when working on that layer:
domain skill)use-cases skill)ports skill)inbound-adapters skill)outbound-adapters skill)YOU MUST look at the specific skill WHENEVER making judgements about how a layer should work. ONLY load the skill when you need it.
Dependencies always point inward:
Inbound Adapters → Use Cases → Domain
Outbound Adapters ← (implement) Ports ← Use Cases
The domain and use cases must never depend on adapters or infrastructure or even know about them.
THE MOST IMPORTANT THING is that the application layer (usecases and domain) MUST NOT know about the outside world. It is less important that the domain and usecases have a neat separation.
In the event that you want to make a change or give advice that conflicts with the codebase IN ANY WAY, refer to conflict_resolution.md.