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.
git 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/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/agents/jed1978/ddd-architecture-coach/bc-developer"><img src="https://agentmods.dev/badge/agents/jed1978/ddd-architecture-coach/bc-developer.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.00121 | $0.01109 |
| Opus 5.5 | $0.00048 | $0.00444 |
| Sonnet 5.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 1mo 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.
- 1mo 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 5mo ago), licensed MIT. It adds 121 tokens to every session and 1,109 once invoked, about $0.0005 per session on Opus 5.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
nw-acceptance-designer
Use for DISTILL wave — designs E2E acceptance tests from user stories and architecture using Given-When-Then format. EXPANDED scope (plan v3 §3.A, 2026-05-19) — exclusive test-expertise owner; authors ATs with maximum PBT + parametrize density, runs self-completeness audit (7-category taxonomy + 15-item checklist)…
nw-software-crafter-reviewer
Use for review and critique tasks. Code-quality + TDD-discipline review of Outside-In TDD implementations. Runs on Haiku for cost efficiency.
nw-test-optimizer-reviewer
Use to validate test-optimizer outputs - hard-blocks if coverage dropped, production code touched, or anti-patterns went unmarked. Runs on Haiku for cost efficiency. Read-only.
nw-test-optimizer
Use to minimize test count while preserving coverage. Invoke after a feature lands, when a suite feels slow or noisy, on a scheduled audit, or whenever the maintainer suspects overtesting. Detects byte-identical pairs, parametrize-inflation, language-guarantee tests, AST-shape tests, and migration-collapse…
tdd-coach
Test-Driven Development coach.
executor
Specialized agent for executing implementation plans. Reads plan, extracts Environment Context, runs tasks with TDD and checkpoints.