Five MCP tools
start_task, get_standard, find_standards, list_templates, scaffold_standards
Writing code got cheap.Writing good code didn't.
Your agent can turn out a thousand lines before lunch. It still doesn't know that your team logs and rethrows, that the tests sit beside the source, or what you mean by done. dev-playbook serves those rules over MCP so the agent reads them before it writes, and generates the whole set if your repo hasn't got any.
@app.get("/orders")def get_orders(page: int = 1, size: int = 20): rows = db.execute( f"SELECT * FROM orders LIMIT {size} OFFSET {(page-1)*size}" ).fetchall() return rows
- size has no ceiling, so ?size=100000 is a full table scan.
- The query is an f-string. Every other query in this repo is parameterised.
- Rows go out as they come back, so adding a column changes the public API.
- No test. "Done" here means the endpoint returned 200 once, by hand.
@app.get("/orders", response_model=Page[OrderOut])def list_orders(page: PageParams = Depends()) -> Page[OrderOut]: return orders.paginate(page)
Nothing to mark. It read core/guardrails.md, the pagination pattern and the definition of done before it wrote a line, so the ceiling, the parameterised query, the response model and the test were never up for negotiation.
One prompt: add pagination to /orders. The difference is which repo the agent was standing in.
In the box
Six language packs
go, java, kotlin, python, rust, typescript
What gets generated
guardrails, definition of done, architecture, git rules, task workflows
Claude Code plugin
five tools, two skills, SessionStart and PreToolUse hooks
Two transports
stdio for local, SSE for a shared team server
Dashboard
authoring wizard, four-tab editor, adoption and latency
Local auth
users, pbkdf2 hashes, issuable bearer tokens
Runs anywhere
uv, Docker, Compose, one SQLite file
The problem
You already wrote the standards. Nobody reads them.
They're in a Confluence page, or a README nobody opens, or in the head of whoever reviews the pull request.
So agent-written changes keep arriving technically correct and quietly wrong. The wrong test framework. A service where your team uses a repository. An error swallowed where your team logs and rethrows. You catch it in review, explain the convention again, and watch the next change make a different version of the same mistake.
The rules aren't the problem. Getting them in front of the agent at the moment it matters is.
How it works
The agent asks first, then writes.
One call opens the task. What comes back is scoped to the change at hand rather than the whole corpus, so it costs a round trip instead of a context window.
That first call, in full:
→ playbook_start_task("billing", "add pagination to /orders")←
- guardrails
- every list endpoint has a maximum page size
- never widen a public response without a version
- workflow
- feature, small
- done when
- tests sit beside the source, one assertion per behaviour
- read next
- core/guardrails.md
- patterns/python/pagination.md
Then it reads what it was pointed at, with playbook_get_standard when it knows which document it wants and playbook_find_standards when it doesn't.
In Claude Code you don't see any of that. A session-start hook puts the repo's guardrails in context before you've typed anything, and the definition of done arrives before the first edit of the session. If the repo has no standards project yet, the first call says so and names the command that fixes it.
The surface
Five tools. Four read, one writes.
| Tool | What comes back |
|---|---|
| playbook_start_task | Guardrails, the workflow matching the change at hand, and the refs to read next. |
| playbook_get_standard | One document, addressed by path or by shorthand. |
| playbook_find_standards | Search a project's standards, or list all of them when given no query. |
| playbook_list_templates | The pack catalogue: rule counts, required placeholders, per-pack detail. |
| playbook_scaffold_standards | A standards project written from the base pack plus the language packs you pick. writes |
Every tool ships its MCP annotations, so your client knows which call needs a confirmation before it makes one. A client that sees no annotations is entitled to assume the worst, so none go out bare.
The one that writes is additive but not idempotent: it creates a standards project and refuses to merge into an existing one. Call it with dry_run=True and you get the manifest with nothing written, which is how an agent can show you what it is about to create before it creates it.
Starting from zero
No standards yet? That's the case this was built for.
Ask most teams where their coding standards live and you get a shrug and a link to something from 2021.
So the write tool generates the set: guardrails, definition of done, architecture and git rules, task workflows, and per-language standards, anti-patterns and testing docs. 290 rules across six languages, each one something a reviewer has had to ask for more than once.
playbook_list_templates()playbook_scaffold_standards(project="billing", languages=["python"], placeholders={"package": "acme.billing"}, dry_run=True)playbook_scaffold_standards(..., dry_run=False)
You accept or reject them one at a time. Every rule carries two to four sentences on what goes wrong without it and a do/don't pair, so you are deciding rather than rubber-stamping a list you have never read.
The tool and the dashboard wizard call the same function, and a test diffs the two resulting stores, so the path you took can't change what you got.
Template packs
A base pack, plus one per language.
The base pack owns what every repo needs, and each language pack contributes its rules into those documents. Pick two languages and you get one set of shared docs with both languages' rules in it, not two copies fighting over the same filename.
- Go
- Java
- Kotlin
- Python
- Rust
- TypeScript
A pack is a directory with a pack.yaml in it. Point the loader at your own checkout and yours shadow the bundled ones, so a team with house rules doesn't have to fork anything.
The dashboard
Author in the browser. See what is actually being read.
Standards live in SQLite, and the dashboard reads the same store the MCP tools do. Create projects through the wizard, edit any document in a four-tab viewer, and check corpus health against the validation rules.
The telemetry answers the question you will have in month two: who is calling the tools, which standards get read, and which ones nobody has touched since you wrote them.
Where it runs
On your machine, or for the whole team.
On your machine
For one developer, or a repo you are trying this on. The plugin starts the server itself over stdio against its own database. Nothing to deploy, no port, no dashboard. It needs uv on your PATH and nothing else.
For the team
Everyone reads the same standards. Run the server, issue bearer tokens from the dashboard, and point each plugin at it. One place for the standards, one place for everyone's telemetry.
Same five tools either way.
Enforcement
Off by default.
Installing a plugin should not stop anyone's work by surprise. Out of the box you get the definition of done as context before your first edit, and one line naming the scaffold command if the repo has no standards. Nothing is blocked.
Turn enforcement on and Write and Edit are denied in a repo with no standards project, with a reason that names what is missing. Every edit, not just the first: a gate that closes once is not a gate.
Install
Put it in front of your agent this afternoon.
/plugin marketplace add arockiaraj1994/dev-agent-playbook/plugin install dev-playbook@dev-playbook
Two commands in Claude Code, then restart it. No server to run, no port, no bearer token. Cursor and Windsurf have no plugin system, so they use themanual MCP setup, which is two lines.