Spec-driven development assumes a spec. Crema is where you build it.
Crema is the spec control plane for teams building software with AI agents. It puts your spec in GitHub as one source of truth, and it sizes every step of writing and reviewing that spec for human judgment: one card, 25 minutes, the reason on the card.
Engineering put code under version control, review, and blame. The spec that drives it has none of that.
Product managers are understaffed about 3× against engineering, supply the spec with a chat window and a Drive folder, and are asked for more of it every quarter. Five governance problems emerge, and engineers already solved each of them for code.
- 01
Length
Agents write longest where they are least certain (Zhang et al., 2024). The longest sections are the least reliable and the least read.
- 02
Drift
Each spec is appended to a core spec no one can read. Versions multiply in Drive. Engineering, marketing, and the PM each pull context from Claude, pointed at whichever copy they found.
- 03
Readability
The text is written for a machine audience, at a length and density a human cannot review. Text for a model reader keeps its meaning at about a quarter of its length; text for a person does not (Zhu et al., 2026).
- 04
Authorship
A model wrote it and did not sign it. No one can say which sections a human decided. Most agent-authored pull requests receive no recorded review (Duma et al., 2026).
- 05
Dependencies
A change in one section breaks three others and nothing shows the chain.
Your code lives in GitHub. Crema puts your spec there too, and engineering points its coding agents at the repo.
One monorepo holds the spec. New sections and revisions are pull requests. A gate sizes each one to a cycle and requires its reason. You decide on a card. The decision record captures who decided what.
| GOVERNANCE CHALLENGE | AGENT CONTROL |
|---|---|
| Length | Limits on words per proposal. A new section or revision is at most 2,000 words when it reaches you. The gate returns anything larger to the agent to split. Review finds most defects at 200 lines per hour or slower (Kemerer & Paulk, 2009). |
| Drift | Single source of truth in GitHub. One version is current; every prior version is in the history. Linear, Jira, and Slack connect over MCP. Engineering's coding agents read from the same repo. |
| Readability | Two renderings from one source. The machine-facing spec your agents consume, and the human-facing card you review: who this is for, why we're doing this, what is new or changed, the controls that apply, the spec text. |
| Authorship | The audit trail and decision records. Every section records who drafted it (you or an agent by name and version), the controls that governed the change, who decided, and when. Approvals are rationed so tired reviewers don't become a weakness (Turan, 2026). |
| Dependencies | Dependency graph enforcement. Cross-references between sections and links to tickets are parsed on every pull request. A change that would exceed the control limit blocks merge; Crema shows why. |
You set the mix. Every step fits 25 minutes.
For every section you choose: write it, edit the agent's draft, regenerate with a prompt or a preset, or let the agent draft within your limits. A cycle is 25 minutes. Two cycles, then a break. Attention holds for about that long, and a tired reviewer approves more (McCarley et al., 2026).
- 01DRAFTED
Write
You bring notes, tickets, a transcript, an idea. You say who it is for and why. You write the section, or your agent drafts it, its tests, and its dependencies as a pull request within your agent's standing permissions. Crema PRD formats it.
- 02ADMITTED
Admission gate
A GitHub check confirms the reason and audience are present, the proposal fits one cycle, and the dependency impact is within agent limits. Anything over returns to the agent to split.
- 03APPROVED
Decide
One card per decision. You approve, deny, regenerate with a note, or edit the spec text in place. The clock sits in the rail; the card has your attention.
- 04audit trail · append-only
Record
The decision record captures the author, the agent limits that governed the change, the decision, the time, and the reason. Cards you did not reach stay marked open. Slack and Linear receive the entry over MCP.
Set agent controls on each proposer, in the repo.
Agent controls define which sections a proposer has permission to change, word and test limits per proposal, how many dependencies it may touch, and how often. They live in a file in the repo. Revoking them is a one-line change.
Who proposed, who decided, when, and why. For every section.
The audit trail is append-only and derived from merged pull requests and recorded decisions. Nothing writes to it directly. It feeds Slack, Claude, and the dashboard, and it is the record a regulated team hands an auditor.
| TIME | SECTION | DRAFTED BY | AGENT CONTROLS | DECIDED BY | STATE |
|---|---|---|---|---|---|
| 11:19 | §2.4 Reports · CSV export | spec-agent 0.4 | controls v3 | I. Leonard | APPROVED |
| 11:08 | §2.3 Reports · Scheduling | I. Leonard | — | M. Boyd | APPROVED |
| 10:51 | §4.1 Billing · Refund window | spec-agent 0.4 | controls v2 | I. Leonard | DENIED · over dependency limit |
| 10:40 | §4.2 Billing · Proration | spec-agent 0.4 | controls v2 | — | NOT YET · cycle closed |
Illustrative entries.
The free skill for writing specs and spec changes.
Your agent loads Crema PRD before it writes a spec. The skill requires who each section is for and why it exists, caps every section at one cycle, and lists open questions with owners. It works with Claude Code, Cursor, Kiro, and Spec Kit.
Get Crema PRD