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 camilooscargbaptista/cto-toolkit --skill domain-modelinggit clone --depth 1 https://github.com/camilooscargbaptista/cto-toolkitWrote 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/camilooscargbaptista/cto-toolkit/domain-modeling)<a href="https://agentmods.dev/skills/camilooscargbaptista/cto-toolkit/domain-modeling"><img src="https://agentmods.dev/badge/skills/camilooscargbaptista/cto-toolkit/domain-modeling/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/camilooscargbaptista/cto-toolkit/domain-modeling"><img src="https://agentmods.dev/badge/skills/camilooscargbaptista/cto-toolkit/domain-modeling.svg" alt="Reviewed on agentmods" width="80" 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.00024 | $0.01346 |
| Opus 5 | $0.00012 | $0.00673 |
| Sonnet 5 | $0.00005 | $0.00269 |
| Haiku 4.5 | $0.00002 | $0.00135 |
Grade A, and why
domain-modeling 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 9d 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 — 201 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Domain Modeling (DDD Practical)
When to Use
- Starting a new module/service and need to define boundaries
- Complex business logic that doesn't fit in simple CRUD
- Team struggling with "where does this logic go?"
- Preparing for microservices decomposition
Event Storming (Discovery)
The Process
1. Invite: developers + domain experts + product
2. Orange stickies: Domain Events (past tense)
"Abastecimento Validado", "Ciclo de Faturamento Fechado"
3. Blue stickies: Commands (what triggers events)
"Validar Abastecimento", "Fechar Ciclo"
4. Yellow stickies: Aggregates (who handles commands)
"Abastecimento", "CicloFaturamento"
5. Pink stickies: External Systems
"Gateway Pagamento", "Emissor NF-e"
6. Group into Bounded Contexts
Example — ZECA Domain
┌─── Refueling Context ──────────────────────────┐
│ Events: │
│ RefeuelingCodeGenerated │
│ RefuelingValidated │
│ RefuelingCancelled │
│ Aggregates: │
│ RefuelingCode, Refueling │
│ Commands: │
│ GenerateCode, ValidateRefueling, CancelCode │
└─────────────────────────────────────────────────┘
┌─── Billing Context ────────────────────────────┐
│ Events: │
│ BillingCycleOpened │
│ FeeCalculated │
│ CycleClosed │
│ InvoiceGenerated │
│ Aggregates: │
│ BillingCycle, Invoice │
│ Commands: │
│ CalculateFee, CloseCycle, GenerateInvoice │
└─────────────────────────────────────────────────┘
Bounded Contexts
Rules:
1. Each context owns its data (no shared database tables)
2. Same word can mean different things in different contexts
"User" in Auth = credentials + session
"User" in Billing = payment info + billing address
3. Communication between contexts via events or APIs
4. One team per context (ideally)
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.
- 9d ago First seen · 201 lines · 24 tokens per session scan A 09abd96ab992
domain-modeling is a skill published in the GitHub repository camilooscargbaptista/cto-toolkit (7 stars, last pushed 5mo ago), licensed MIT. It adds 24 tokens to every session and 1,346 once invoked, about $0.0001 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-31.
Other skills, from other repositories
ddd-aggregate-modeling
Guides aggregate modeling decisions for DDD services: aggregate root boundaries, child entity vs value object decisions, invariants, snapshot/primitives mapping, specification/criteria usage, and repository contract design. Invoked when the user asks to model or refactor domain entities and aggregate behavior.
architecture-patterns
Software architecture patterns and best practices.
tsq-ddd
A guide to Domain-Driven Design, a way to shape software around real business concepts and language. It covers defining clear business boundaries, shared terms, and relationships between parts of a system.
domain-driven-design
Design and review software using patterns from Eric Evans' "Domain-Driven Design." Use for DDD tactical patterns (Entities, Value Objects, Aggregates, Repositories, Factories, Domain Services), strategic patterns (Bounded Context, Context Map, Anticorruption Layer, Shared Kernel, Open Host Service), supple design…
system-architect
Forces data-model-first thinking before service boundaries or code, treating the schema as the geological layer everything else sits on.
ddd-architect
A code-organization guide based on Domain-Driven Design, an approach that keeps business rules separate from application actions, outside systems, and user interfaces. It also separates data-access code from the rest of the application.