Overview

Specbench is a collaborative spec-authoring platform for engineering teams. Specs live as structured, project-scoped artefacts — not wiki pages — that your whole team can author, review, and ship to your repository with confidence, whether or not they write code.

Specbench is a hosted product with two surfaces:

• The web app — where your team authors, reviews, and ships specs in the browser. Nothing to install.
• The MCP server — a hosted Model Context Protocol endpoint that lets coding agents like Claude Code read and author the same specs your team works on. Everything you can write in the web app, an agent can write over MCP — the two surfaces are deliberately kept at parity.

Specbench is currently in early access. Features marked coming soon are on the roadmap but not yet available.

The core ideas

Projects

Everything is scoped to a Project — Workstreams, Tasks, and every spec artefact. Cross-project references are not permitted, so each Project is a self-contained spec space.

Workstreams

A Workstream is a long-lived thread of context for a slice of product work. Spec changes accumulate as drafts inside a Workstream — alongside the conversation and iteration that produced them — without touching your repository.

Tasks

A Task is the unit of delivery. It bundles a subset of a Workstream's drafts and ships them: when a Task moves from Draft to Ready, the selected spec changes merge to your configured target. Spec leads code by exactly one Task boundary. Tasks are also how Specbench maps onto delivery trackers like Jira and Linear (integration coming soon).

Decision Points

Open questions raised during authoring are captured as Decision Points — first-class records of what needs deciding, attached to the artefacts they concern. Resolve them in place; the decision trail stays with the spec work that prompted it.

What you can model

The model is organised into four groups: Domain (the always-valid inside of a context), Behaviour (what the system does), Contracts (shapes that cross a boundary), and Product (the product-facing surfaces).

Domain

• Bounded Contexts — the macro-containers of your domain. Most artefacts can be owned by a context, and context filters keep large models navigable.
• Aggregates — write-side models with properties, invariants, methods, rich nested child entities, and the Domain Events they raise (what happens inside a context lives with the aggregate that owns it).
• Value Objects — identity-less types with properties, invariants, and methods.
• Enums — named case sets.
• Domain Services — cross-aggregate operations modelled as methods.

Behaviour

• Use Cases — the operations your system exposes: their trigger (an actor or an event), parameters, steps, and named outcomes. Features link to the Use Cases that realise them.
• Event Handlers — how contexts react to events; emissions are derived, so the flow graph stays truthful.

Contracts

• Data Contracts — named shapes for data crossing an operation boundary: command inputs and results, event payloads. No invariants — the values they carry may not be validated yet. Rule of thumb: a Read Model names state you're reading; a Data Contract names data crossing an operation boundary.
• Read Models and Read Interfaces — the query side: shaped data and the interfaces that serve it.
• Integration Events — what crosses context boundaries (with translated-from lineage back to the domain events they publish).

Product

• Features and Scenarios — a Feature describes a user-facing behaviour of your product. Each Feature holds Scenarios: named examples written as ordered Given/When/Then Steps (Gherkin form). Edit step by step, or paste a Gherkin block and let Specbench parse it.
• Roles — the actors in your product, with their responsibilities, needs, and pain points.
• Terms — a ubiquitous-language glossary: definitions, synonyms, and terms to avoid, scoped to bounded contexts.
• Applications and Elements — the applications in your landscape and the UI/system elements they're made of.

The graph

Every reference between artefacts feeds a relationship graph. Graph views let you trace flows across the model — from a use case through the events it emits to the contexts that react — and save those traces as live queries that stay current as the spec evolves.

Repository sync

Specbench writes specs to your GitHub repository through a manual Sync action — you decide when spec content lands, and Specbench handles the git-side mechanics for you. No branches to manage, no merge conflicts to untangle by hand.

For coding agents

The hosted MCP server exposes the full authoring surface as tools: an agent can list your aggregates, raise a decision point, draft scenarios, or trace the graph — against the same project your team sees in the browser, with changes attributed and visible in real time. See Getting started for connection instructions.

What's next

Next steps