Stop writing tests. Start writing specs. We generate everything else.
Unify DDD models, user story maps, requirements DSL, screen maps, and data schemas — then auto-generate tests, prompts, and code for any AI coding agent.
Every model generates tests, traces requirements, and feeds AI agents the exact context they need.
Visual canvas for aggregates, value objects, invariants, and domain events. Generates unit tests and constraint checks.
Personas, stories, and acceptance criteria. Generates behavior tests and E2E scenarios from your story map.
Formal requirements language with traceability to DDD and USM. Aspects like @security and @accessibility auto-generate targeted tests.
Structural screen maps linked to domain aggregates. Generates E2E navigation tests, route tests, and accessibility audits.
Schema-level ERD modeling with auto-proposed columns from DDD. Generates schema validation, migration safety, and constraint tests.
Atomic work units bundling context + failing tests + work items. Agents implement code to make tests pass. Done = green + review.
The single question that separates the two categories: does the spec exist before the code, or after it?
Green BEFORE deploy, not after.
Useful for legacy discovery; not for shipping new code with confidence.
Use visual canvases (DDD, USM, SCM, DSM) and the CBRL text editor to capture your complete system specification.
ContextBrew produces Gherkin scenarios, unit tests, E2E tests, API specs, TypeScript stubs, and AI-ready prompts — all traced back to requirements.
Recipes bundle failing tests + context for Claude, GPT, Gemini, or any agent. Agents implement against tests. CI verifies. You ship with confidence.
Every project earns a tier based on spec coverage and the ACM access-completion gate.
Green BEFORE deploy, not after.
Models authored but no recipes generated yet.
Generated tests trace back to requirements.
Zero un-traced code, full access gate.
Tiers are leading indicators — not lagging DORA metrics. They tell you whether the upcoming deploy is safe, not whether last quarter's was.
You can't ship a fix for a bug that never shipped. The deepest value of spec-first development is invisible — until you price it.
The classic cost-of-defect curve (IBM Systems Sciences Institute, widely cited across NASA, IBM, NIST) — relative cost to fix a defect at each stage of the SDLC:
A defect caught at design time costs 1 hour. The same defect caught in production costs 1000 hours — incident triage, rollback, hotfix, postmortem, customer trust. The cheapest defect is the one that never exists.
A USM story for the Travel Booking recipe maps a "guest cancels a reservation" path. The user story has 4 acceptance criteria — but no criterion for the partial-refund case: what happens when a guest cancels 48 hours before check-in?
A code-first pipeline would ship this gap as an unhandled 500 error in
POST /bookings/:id/cancel,
discovered when the first customer hits it. With ContextBrew, the spec
is the source of truth, and the USM canvas flags the missing criterion
the moment the story is saved.
Without spec-first
The USM canvas surfaces a coverage gap for the partial-refund path in the same authoring session that creates the story. The PM adds the missing criterion; the DDD aggregate regenerates; the SCM screen coverage test goes green before the ticket ever leaves the canvas.
The completenessTier()
engine (the same one powering the scorecard above) blocks the recipe
from advancing to "executing" while the gap exists. The bug is caught at
design cost, not production cost.
With ContextBrew
The 1× / 10× / 100× / 1000× multiplier is the long-standing relative cost-to-fix curve (commonly attributed to IBM Systems Sciences Institute and replicated in NIST, NASA, and Microsoft Research studies). The specific worked example is from the ContextBrew Travel Booking recipe, where every USM story is auto-traced to DDD aggregates, ACM rules, and generated tests — the same completeness engine that powers the scorecard above.
Pair this with the Token Savings ROI Calculator (coming soon) to translate the multiplier into dollars and engineering hours for your team's specific deployment.
Teams shipping with ContextBrew spend less time writing prompts and more time shipping product.
"We went from spending hours crafting prompts to generating complete test suites in minutes. The DDD canvas alone saved us a sprint of work."
"The traceability between CBRL requirements and generated tests is a game-changer. Our QA team finally knows what's covered and what's not."
"Recipes changed how our team works with AI. We define specs once, and every agent gets perfect context. Code review time dropped 40%."
Start free. Scale when you're ready.
ContextBrew is an open-core platform that unifies five specification models — DDD domain models, USM user story maps, CBRL requirements language, SCM screen maps, and DSM data storage schemas — into a single source of truth. It auto-generates tests, prompts, and context for any AI coding agent.
Each specification model has dedicated generators. DDD aggregates produce unit tests and constraint checks. USM stories produce behavior and E2E tests. CBRL requirements produce Gherkin scenarios. SCM screen maps produce navigation and accessibility tests. DSM schemas produce validation and migration tests. All tests are traced back to their originating specification.
Developer portals catalog code that already exists. ContextBrew is spec-first: you author the specification (DDD, USM, CBRL, SCM, DSM) before any code is written, and we generate the tests, code, and AI context from the spec. The spec is the source of truth, not a retroactive mirror of the repo.
Every project earns a tier based on how completely its spec generates the deploy-time safety net. Bronze = models authored, no recipes yet. Silver = ≥60% of requirements are linked to generated tests. Gold = 100% of screens have ACM access rules and every requirement traces to a test, so recipes block ship without coverage. The tier is a leading indicator — green before deploy, not after.
Specs are the source of truth in ContextBrew — DDD aggregates, USM stories, CBRL requirements, SCM screens, DSM tables all cross-link. When a USM story has a missing acceptance criterion (e.g. partial refund, edge-case error path), the completeness engine flags it during the same authoring session that creates the gap. The recipe cannot advance to "executing" while the gap exists; the generated tests re-run, and a 90-second re-generation closes the loop. The same defect caught in production would cost 100–1000× more (industry standard cost-to-fix curve). See the ROI section for the worked example.
Yes. The free tier includes 3 projects with all 5 models and recipe export (generates a pasteable prompt for any AI agent). No credit card required. Upgrade to Pro for the Execution Engine, Recipe Server version control, and unlimited projects.
ContextBrew works with any AI coding agent. The free tier exports recipes as pasteable prompts compatible with Claude Code, Cursor, Copilot, Aider, and others. The Pro tier adds automated execution via the Execution Engine, supporting Claude, GPT, Gemini, and local models through Ollama.
A Recipe is an atomic work unit that bundles relevant specifications, failing tests, and a work description for an AI agent. The agent implements code to make all tests pass. A Recipe is "done" when all tests are green and code review is approved. Recipes can be versioned, branched, and compared using the Recipe Server.
Yes. The free tier is genuinely free — no credit card, no trial countdown, 3 projects with the full agent integration surface (recipe export to any AI agent, the five spec models, and the verification loop). Upgrade to Pro when you need the Execution Engine, Recipe Server version control, and unlimited projects. See /pricing for the full breakdown.
Yes. ContextBrew is open core — you can self-host the full stack. Cloud deployments use encrypted storage, and your specifications are never used for model training. The Team plan adds SSO/SAML, audit logs, and dedicated support for enterprise security requirements.
CBRL (ContextBrew Requirements Language) is a formal domain-specific language for writing requirements with built-in traceability. It supports structured requirements, acceptance criteria, test case annotations, and cross-cutting aspects like @security, @audit, and @accessibility that auto-generate additional targeted tests.
Stop writing tests. Start writing specs. We generate everything else.
Get Started Free