Product spec
Roles, features, screens and acceptance criteria — a living document your agent reads and extends
Works with your stack and your agents
Your agent works in Studio the way you do: through the spec, the schema and the architecture — and forgets nothing
You describe the idea to your agent — it creates a project in Studio and writes the spec
Roles, screens, data and acceptance criteria — Studio checks the spec against the schema
# Barbershop «Moustache»
Online booking with a barber and reviews after a visit
## Features
### Online booking
Tables, a linter, migrations and real Postgres right in the browser
Load simulation before launch, a build plan and AGENTS.md for the repository
Your agent works in Studio the way you do: through the spec, the schema and the architecture — and forgets nothing
# Barbershop «Moustache»
Online booking with a barber and reviews after a visit
## Features
### Online booking
Roles, features, screens and acceptance criteria — a living document your agent reads and extends
DBML or the canvas, import from SQL and Prisma, a linter that fixes in one click
Test data, queries and migrations checked on real Postgres — nothing to install
Build the system from blocks and see whether it survives the peak before launch
Every change is a version, a structural diff and a ready SQL migration
Invite links, shared access for your organization and public projects
Plugins
Tests from the criteria, OpenAPI from the tables, a failure drill and Docker Compose from the architecture. A plugin adds a tab, checks, export formats and a tool for the agent.
Built-in only: no third-party code runs
Tests from the acceptance criteria
Feature: Online booking
Scenario: free slots
Then 14 days aheadFeatures and the plan as issues
gh issue create \ --title 'Online booking' --label feature
The words the spec relies on
## Glossary - **Slot** — 30 minutes of a barber - **Visit** — a booking that took place
What such products trip on
## Risks - **Double booking** — a unique slot - **Payment fails** — check again
How to tell a feature works
## Metrics - **Booking conversion** — above 30 % - **Retention** — after 7 and 30 days
A pull request with the project's context
branch coddle/agents-md-20261014 commit + AGENTS.md PR acme/shop#7
OpenAPI 3.1 from the tables
GET /clients
POST /appointments
PATCH /appointments/{id}Where the schema keeps data about people
clients.phone contact clients.password ⚠ hash masters.passport special
How the app will read the tables
+ users(email) [unique] + orders(user_id, created_at) − orders(user_id)
One convention for the whole schema
user → users firstName → first_name active → is_active
What if a block goes down
lb outage ✕ api ×3 ok ✓ db degraded ~
The architecture on your laptop
services:
db: postgres:17-alpine
api: { replicas: 3 }Studio is an MCP server: your agent reads and edits projects right from the chat, only within the permissions you grant
The agent writes the schema, the canvas draws it, Studio checks and fixes it
From the spec the agent designs the database and writes it straight into Studio — the canvas updates live.
The agent is connected to Coddle over MCP and sees your projects.
Message your agent…
The checks appear with the schema.
The canvas is empty — the agent will draw the schema.
Coding practice for those who learn and those who teach