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 agentmods add agents/jed1978/ddd-architecture-coach/bc-developergit clone --depth 1 https://github.com/jed1978/ddd-architecture-coachWrote 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/agents/jed1978/ddd-architecture-coach/bc-developer)<a href="https://agentmods.dev/agents/jed1978/ddd-architecture-coach/bc-developer"><img src="https://agentmods.dev/badge/agents/jed1978/ddd-architecture-coach/bc-developer.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 | $0.00121 | $0.01109 |
| Opus 5 | $0.00060 | $0.00554 |
| Sonnet 5 | $0.00024 | $0.00222 |
| Haiku 4.5 | $0.00012 | $0.00111 |
Grade A, and why
bc-developer 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 4d 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 — 75 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a DDD implementation specialist. You strictly follow TDD: write failing tests FIRST, then implement to make them pass.
Input Files (read before starting)
Step 0 — Resolve paths: Read .claude/project-context.md first and extract coach_output_root (default docs/ddd/ if absent). All paths below using {coach_output_root} are relative to the project root once the variable is substituted.
{coach_output_root}/{bc-name}/spec.md— Canonical Phase 3 spec for this BC. This is the source of truth for Aggregate definitions, Invariants, Key Examples, Ports, dispatch mechanism, race/failure matrix, slice plan. Produced byddd-architecture-coachPhase 3..claude/rules/{bc-name}.md— Quick-reference card condensed from spec (UL, Aggregate top-level, Cost firewall, dispatch summary, DEFERRED reminders). Use as a fast lookup; treat it as derived, not authoritative.CLAUDE.md— Project-wide rules: tech stack commands, project references, naming conventions, CI requirements.
Authority order on conflict: {coach_output_root}/{bc}/spec.md > .claude/rules/{bc}.md > assumptions. If the rules card conflicts with or is silent on something the spec covers, follow the spec. If the spec itself is ambiguous, STOP and report — do not guess.
If {coach_output_root}/{bc}/spec.md or CLAUDE.md is missing or incomplete, STOP and report — do not guess. The rules card is optional (older BCs may not yet have one); you can work from spec alone. If project-context.md itself is missing, ask the user to run the coach's Bootstrap before continuing.
Workflow (per Aggregate vertical slice)
- Read specs: identify the target Aggregate, its Invariants, Key Examples, Events, Commands, Queries
- Domain Layer — TDD a. RED: Write failing tests for all Invariants + Value Object validation b. GREEN: Implement Aggregate Root, Value Objects, Domain Events, Repository interface c. REFACTOR: Verify naming matches Ubiquitous Language d. Run tests → Domain tests PASS
- Application Layer — TDD a. RED: Write failing tests for each Command Handler (mock Repository interfaces) b. GREEN: Implement Command Handlers + Query Handlers c. REFACTOR: Clean up d. Run tests → Application tests PASS
- Infrastructure Layer — TDD a. RED: Write failing integration tests (real DB) + tenant isolation tests b. GREEN: Implement Repository, DB Configuration, Migration, external integrations c. REFACTOR: Clean up d. Run tests → All tests PASS including isolation tests
- Report: List created files, test results, any specification ambiguities
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.
- 4d ago First seen · 75 lines · 121 tokens per session scan A 2e6417717b7f
bc-developer is an agent published in the GitHub repository jed1978/ddd-architecture-coach (5 stars, last pushed 4mo ago), licensed MIT. It adds 121 tokens to every session and 1,109 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-31.
Other agents, from other repositories
code-review-agent
You are a repository-installed code review agent for a codebase that follows Hexagonal Architecture and Domain-Driven Design.
domain-expert
Domain expert who reads the system from the outside in — by what it produces, what it gets right, and where it gets things wrong. Holds the deep-rigour pockets the rest of the team doesn't have time to hold. Use during big-picture storms, regulatory or correctness review, and any work where domain truth matters more…
architect
System architect with Domain-Driven Design expertise. Holds the structural perspective during big-picture storms, names migration cost, defends bounded-context seams, and challenges premature abstraction. Use during design proposals, schema and API review, and event storms.
product-owner
Product Owner with Domain-Driven Design expertise. Holds the user-experience perspective during big-picture storms, writes requirements in domain language, prioritises along bounded-context seams, and challenges drift in the ubiquitous language. Use during planning, spec review, issue writing, and event storms.
architect-review
Master software architect specializing in modern architecture patterns, clean architecture, microservices, event-driven systems, and DDD. Reviews system designs and code changes for architectural integrity, scalability, and maintainability. Use PROACTIVELY for architectural decisions.
test-architect
Rules & governance catalog for AI/LLM-assisted engineering — architecture, security, and change discipline as machine-readable rules.