From software-design
Use only when the user explicitly asks for Clean Architecture design, implementation, or review. Applies a domain, use case, interface adapter, and infrastructure layer model, with persistence and RPC adapters outside the domain and use-case rules. Do not trigger for generic architecture advice, hexagonal architecture, onion architecture, or ordinary design review unless Clean Architecture is named.
How this skill is triggered — by the user, by Claude, or both
Slash command
/software-design:j5ik2o-clean-architectureThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill only for projects that intentionally follow Clean Architecture. Keep policy inward and mechanisms outward.
Use this skill only for projects that intentionally follow Clean Architecture. Keep policy inward and mechanisms outward.
Domain: entities, value objects, aggregates, domain services, domain events, and invariants.
Use cases: application-specific orchestration, transaction boundaries, ports, authorization decisions that are application policy, and repository interface usage.
Interface adapters: controllers, presenters, gateways, repository implementations, RPC adapters, DTO mapping, and persistence mapping.
Infrastructure: cross-cutting mechanisms such as logging, configuration, metrics, DI wiring, clocks, IDs, and concrete driver setup.
Confirm the project actually uses Clean Architecture.
Map the touched code to the four layers.
Check dependency direction: outer layers may depend inward; inward layers must not know outer mechanisms.
Move persistence, RPC, UI, and framework details out of domain and use-case code.
Report the minimal relocation or interface extraction needed.
Read references/layer-responsibilities.md when placement is ambiguous.
For non-trivial implementation, review, or refactoring work, read references/details.md before giving final guidance. It contains the detailed rules, examples, smells, and migration notes that do not belong in the short invocation body.
Provide a layer-by-layer finding list, dependency violations, and concrete file-placement recommendations.
npx claudepluginhub j5ik2o/ai-tools --plugin software-designGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Synthesizes the current conversation into a structured spec (PRD) and publishes it to the project issue tracker with a ready-for-agent label, without interviewing the user.