Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add ccheney/robust-skills --skill clean-ddd-hexagonalgit clone --depth 1 https://github.com/ccheney/robust-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/ccheney/robust-skills/clean-ddd-hexagonal)<a href="https://agentmods.dev/skills/ccheney/robust-skills/clean-ddd-hexagonal"><img src="https://agentmods.dev/badge/skills/ccheney/robust-skills/clean-ddd-hexagonal.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00120 | $0.03107 |
| Opus 5 | $0.00060 | $0.01554 |
| Sonnet 5 | $0.00024 | $0.00621 |
| Haiku 4.5 | $0.00012 | $0.00311 |
Grade A, and why
clean-ddd-hexagonal scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 213 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Clean Architecture + DDD + Hexagonal
Backend architecture combining DDD tactical patterns, Clean Architecture dependency rules, and Hexagonal ports/adapters for maintainable, testable systems.
This skill is an opinionated synthesis of several related architecture traditions. It is not a single canonical architecture model. Use the original source that matches the design question you are answering: DDD for domain modeling, Hexagonal Architecture for ports/adapters, Clean Architecture for dependency direction, Onion Architecture for domain-centered layering, and CQRS/Event Sourcing only for specific read/write or temporal requirements.
When to Use (and When NOT to)
| Use When | Skip When |
|---|---|
| Complex business domain with many rules | Simple CRUD, few business rules |
| Long-lived system (years of maintenance) | Prototype, MVP, throwaway code |
| Team of 5+ developers | Solo developer or small team (1-2) |
| Multiple entry points (API, CLI, events) | Single entry point, simple API |
| Need to swap infrastructure (DB, broker) | Fixed infrastructure, unlikely to change |
| High test coverage required | Quick scripts, internal tools |
Start simple. Evolve complexity only when needed. Most systems don't need full CQRS or Event Sourcing.
Pattern Boundaries
| Pattern | Primary Question | Use It For | Do Not Treat As |
|---|---|---|---|
| DDD | How do we model a complex business domain? | Ubiquitous language, bounded contexts, aggregates, value objects | A folder structure by itself |
| Hexagonal Architecture | How does the application interact with the outside world? | Ports, driver adapters, driven adapters, testable application core | A mandate for six sides or one exact package layout |
| Clean Architecture | Which direction should dependencies point? | Inward dependency rule, use case boundaries, framework independence | A universal four-folder template |
| Onion Architecture | How do we keep the domain model central? | Domain-centered layers and dependency inversion | A separate requirement when Clean/Hexagonal already solve the local problem |
| CQRS | Do reads and writes need different models? | Bounded contexts with divergent read/write workloads | A default application architecture |
| Event Sourcing | Do we need state from a complete event history? | Audit, temporal queries, replayable workflows | A persistence default for CRUD systems |
What ships with it
7 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 213 lines · 120 tokens per session scan A 5b7dcd3f34d5
clean-ddd-hexagonal is a skill published in the GitHub repository ccheney/robust-skills (57 stars, last pushed 10d ago), licensed MIT. It adds 120 tokens to every session and 3,107 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
principle-clean-architecture
Clean Architecture, hexagonal architecture, ports and adapters, and dependency rule. Auto-load when designing architecture, choosing layers, ports, adapters, or keeping the domain free of framework code.
principle-resiliency
Resiliency principles — fault tolerance, partial failure, failure domains, bulkheads, fail-fast vs fail-soft, health checks, liveness vs readiness probes, idempotency keys, safe retry, deduplication, exactly-once effects, token and leaky buckets, synchronized retries, and 429 responses. Auto-load when isolating…
principle-distributed-systems
Distributed systems principles — CAP, consistency models (linearizable, causal, eventual, read-your-writes), quorum, leader election, partitioning, idempotency across nodes, fallacies of distributed computing. Auto-load when reasoning about CAP/PACELC trade-offs, choosing a consistency model, ordering events with…
principle-error-handling
Error handling principles — errors as values vs exceptions, wrapping and context chains, retry with exponential backoff and jitter, circuit breakers and bulkheads, log-once boundary discipline. Auto-load when discussing errors as values, retry, exponential backoff, jitter, fail fast, fail soft, idempotent retry, error…
principle-event-driven
Event-driven architecture — event sourcing, CQRS, sagas, schema evolution, consumer groups, partitions, idempotent handlers, outbox pattern, dead letter queues. Auto-load when designing event-driven systems, evaluating event sourcing or CQRS, planning saga workflows, implementing idempotent consumers or the outbox…
principle-performance
Performance engineering principles — latency vs throughput, profile-before-optimize discipline, Big-O instincts for common patterns, data locality and cache-friendliness, N+1 queries on a list endpoint, TTL sizing for hot-path endpoints, stampede prevention with single-flight. Auto-load when reviewing hot-path code…