Development playbooks, served straight into the IDE
Conventions, patterns and how-we-build-it rules, read by the coding assistant at the moment it writes code.
Who it’s for: Tech leads and engineering teams who want generated code to follow house rules.
Conventions live in review comments
Most team conventions exist as review comments and one long document nobody opens. Coding assistants don’t know them, so they produce code that passes the tests and fails the review.
Connect the playbook to the IDE
Write the rules down in Markdown (naming, architecture, testing, error handling) and connect the repository to Cursor or any other MCP-capable IDE. The assistant can search the playbook before it writes code, the way a new developer would.
One playbook across projects
Keep the playbook in its own repository and every project reads the same version. Change a rule once, and the next session reads the new one.
How to structure the repository
- Write rules as short, specific statements with an example of right and wrong. A rule the assistant can match against code works better than a principle it has to interpret.
- Split the playbook by concern (architecture, naming, testing, review) so a search returns the relevant rule rather than the whole book.
- Keep the review checklist as its own file. It doubles as a prompt: ask the assistant to check a diff against it.
Setting it up
-
Step 1: Create a playbook repository separate from your application code, so every project reads the same version.
-
Step 2: Assign the developers who should read it.
-
Step 3: In Cursor or any other MCP-capable IDE, add the endpoint as a custom MCP server. Each developer signs in with their own account.