Every chapter of every playbook

Every topic the playbooks cover, on one page. Read it whole, then open only the chapters your project needs. Each chapter lists its rules, each checklist lists a whole playbook with its checks, and each rule has its own page with the full steps. Add .md to any address to get Markdown.

AI-assisted development playbook

Rules for building software with AI coding agents. Set up the project, work in small steps, turn rules into checks and review every change before it ships. Read the checklist of all 60 rules or get them as JSON.

Setting up the project: Before an agent writes a line, give it short instructions, one command that checks everything, and code small enough to read in one pass. (4 recommended)
Working in small steps: Plan before code, give each task clear acceptance criteria, keep every change small, and commit on a branch so any step can be undone. (7 recommended)
Rules the agent cannot break: Agents forget instructions, so turn every rule that matters into a linter, test, build gate or hook that stops the work when it is broken. (3 recommended)
Reviewing agent output: A person reads every change an agent makes, runs it, and checks for invented packages, weakened checks and changes outside the task before it ships. (2 required, 6 recommended)
Safety and permissions: Run agents in a sandbox with the fewest rights they need, keep production out of reach, and treat everything they read as possibly hostile. (9 required, 3 recommended)
Apps built with AI builders: App builders such as Lovable, Bolt, Replit and v0 ship working apps fast. Lock down the database, keep keys server-side and own the code. (3 required, 3 recommended)
Context and memory: Agents only know what they are given. Keep instructions short and current, show good examples and point agents to documents they can trust. (5 recommended, 1 optional)
Measuring and improving: Track what agents get wrong, add a check for every repeated mistake, measure delivery, and keep a person's sign-off before every release. (6 recommended)
Agent skills: Package each repeated task as a skill the agent loads only when it matches, with a clear description, bundled scripts and a test. (1 required, 6 recommended, 1 avoid)

Engineering playbook

Rules for building any software. Every rule is checked in code, every change is tested the same way, and every deploy can roll itself back. Read the checklist of all 40 rules or get them as JSON.

Rules as code: Turn every rule into a check in code that passes or fails. Then people and AI agents never have to guess whether work is right. (4 recommended)
Build, test and deploy: Every change is tested and built the same way, shipped in one step, checked for health, and rolled back by itself when something fails. (3 required, 5 recommended)
Version control and review: Every change goes through version control in small steps. Automated checks and a second pair of eyes approve it before it reaches the main branch. (2 required, 6 recommended)
Running in production: Build the same artifact every time, keep settings and secrets outside the code, and know about errors before your users report them. (3 required, 4 recommended)
Documentation: Keep docs next to the code and change them in the same pull request. Generate what you can, and test the rest in the build. (12 recommended, 1 optional)

Clean code and architecture playbook

Rules for code that people and AI agents can read, change and trust. Clean names, small functions, typed data, SOLID design and a numbered review. Read the checklist of all 68 rules or get them as JSON.

Code review: Review the whole change against its base with numbered questions. Name the principle, the code and the fix, then verify each finding from scratch. (10 recommended)
Names and functions: Names that say what things are, and small functions that each do one thing. Short, shallow and with few arguments, so anyone can read them at a glance. (8 recommended)
Comments: Let names and small functions carry the meaning. Keep a comment only for a reason the code cannot show, and let version control keep the history. (7 recommended)
Errors and nulls: Throw clear, typed errors instead of returning codes. Never return or pass null, and give every field a value unless absence is a valid state. (4 required, 5 recommended)
Coupling: Let each module talk only to its direct neighbours. Make the order of calls impossible to get wrong, share no global state and hide the rest. (2 required, 4 recommended)
SOLID and DRY: Keep each piece of knowledge in one place and give each module one reason to change. Extend code by adding to it, not editing it. (8 recommended)
Data shapes: Pass data as named, typed objects that say what they hold. Parse input once at the edge, and never hide types in mixed values, loose arrays or strings. (2 required, 8 recommended)
Dead code: Delete code that nothing calls, flags that never change and packages nobody imports. Version control remembers it, so the codebase does not have to. (4 recommended)
Structure: Arrange code so dependencies point one way, folders follow features, files are easy to find, and no module depends on itself through a loop. (1 required, 5 recommended)

Testing playbook

Rules for tests that catch bugs and never cry wolf. Strategy, unit, integration, browser, load and output tests, test data, flaky tests and quality. Read the checklist of all 47 rules or get them as JSON.

Test strategy: Decide what to test before writing tests. Spend the effort where bugs would hurt most, keep most tests small, and ship every change with its tests. (1 required, 2 recommended)
Unit tests: Small tests for rules and calculations. They test behaviour through public functions, run in milliseconds, and give the same result every time. (8 recommended)
Integration and contract tests: Test how your code works with a database, queue or service. Run dependencies in containers, and contract tests between services you own. (2 required, 3 recommended)
End-to-end and browser tests: Drive the app the way a person does, through a few journeys that matter. Find elements by role and label, wait for state, and never sleep. (2 required, 5 recommended)
Test data and environments: Build test data in code, give each test its own, and test on an environment that matches production. Never copy personal data into tests. (1 required, 2 recommended)
Flaky and slow tests: A test that fails at random teaches people to ignore red builds. Find flaky tests early, quarantine them with an owner, and keep the suite fast. (4 recommended)
Test quality: Prove the tests would catch a bug. Use mutation testing, treat coverage as a floor, and review test code as carefully as the code it checks. (5 recommended)
Non-functional tests: Test load, accessibility, AI answers and parsers too, with budgets and scores that fail the build. These bugs reach users just as surely as broken features. (1 required, 3 recommended)
Output comparison: Treat the whole output as one artifact. A refactor changes zero bytes, and an intended change touches only the files and addresses it names. (7 recommended, 1 optional)

Website playbook

Rules for fast, findable, secure and accessible websites that AI agents can use too. Each has a level, how to do it and how to check it. Read the checklist of all 245 rules or get them as JSON.

HTML basics: Everything in the head of a page, such as doctype, language, title, description, canonical address, icons, colours, social cards and feeds. (2 required, 10 recommended, 3 optional)
Site architecture: A structure that makes the other rules easy. Pages are data, built once to static HTML and served from memory, with every machine file from one source. (1 required, 8 recommended)
Interface: Native HTML and CSS for menus, layout, text, colour and motion. Use what the browser already does instead of JavaScript widgets and fixed layouts. (7 recommended, 4 optional)
Performance: How to make a page load about as fast as the network allows. The speed rules for any site, what moved the numbers in practice, and what to skip. (18 recommended, 5 optional, 1 avoid)
SEO: Make every page easy to find and understand with robots.txt, sitemaps, clean addresses, redirects, rendering on the server, structured data and breadcrumbs. (17 recommended, 4 optional)
Redirects and canonicals: Keep every old link working. Send each old address to the right new page in one hop, and make every signal point at the one true address of each page. (9 recommended, 1 optional, 1 avoid)
Accessibility: Make the site work for everyone with readable contrast, full keyboard use, visible focus, clear structure, calm motion, big touch targets and plain HTML first. (36 required, 9 recommended, 1 optional, 1 avoid)
Security: HTTPS, a strict Content Security Policy, isolation headers, integrity checks and the other headers, policies and DNS records that keep visitors safe. (4 required, 11 recommended, 2 optional, 1 avoid)
Hosting and network: Server and DNS work under every site. It covers HTTPS, TLS, HTTP/2 and HTTP/3, a fast first send, DNS records, IPv6 and certificate renewal. (3 required, 5 recommended, 3 optional)
Standard addresses: Fixed addresses under /.well-known/ that browsers, password managers, privacy tools and agents look for, and which ones a small site needs. (3 recommended, 12 optional)
Ready for AI agents: Markdown copies, llms.txt, AI crawler rules, structured data, link headers, MCP, A2A, skills and WebMCP make a site easy for AI agents to use. (4 recommended, 18 optional, 1 avoid)
Privacy: Collect nothing you do not need. Write a full privacy policy, skip needless cookies and third parties, honour Global Privacy Control and delete data on time. (7 required, 6 recommended, 1 optional)
When things break: Plan for things going wrong with error pages, maintenance mode, pages that survive failed scripts, offline support and retired addresses. (7 recommended, 2 optional)
Languages and regions: Serve each language and script with translated metadata, hreflang, translate hints, right-to-left text, local dates and numbers, and no forced geo redirects. (1 required, 11 recommended, 4 optional, 1 avoid)

API design playbook

Rules for HTTP APIs that people and AI agents can learn fast and trust. Clear resources, honest errors, safe retries and contracts that never surprise. Read the checklist of all 66 rules or get them as JSON.

Resources and methods: Name resources as nouns, use each HTTP method for what it means, and answer with the status code that tells the client exactly what happened. (5 recommended)
Requests and responses: Send JSON with one naming style, exact dates, safe money values and string IDs, so every field means the same thing everywhere in the API. (3 required, 7 recommended)
Errors: Answer every error as RFC 9457 problem details. Give it a stable type, a plain message and the exact fields that failed. (5 recommended)
Lists: Page through long lists with cursors, cap every page, and let clients filter and sort with plain, documented parameters that never change meaning. (5 recommended, 1 optional)
Changes over time: Grow the API by adding, never by breaking. When a break is unavoidable, ship a new version and give clients dates, headers and time to move. (5 recommended)
Reliability: Make retries safe with idempotency keys, protect updates with ETags, set timeouts everywhere and tell clients plainly when to slow down. (2 required, 4 recommended)
API security: Authenticate every call with scoped tokens, authorise every object, and keep secrets out of addresses. Link to the security playbook for the attacks. (6 required, 1 recommended)
Contracts and docs: Make an OpenAPI file the single source of truth. Test the API against it, generate docs and clients from it, and publish it for people and agents. (6 recommended)
Webhooks and events: Sign every webhook, retry until it is accepted, and let receivers handle duplicates and out-of-order events without double work. (3 required, 3 recommended)
Files and uploads: Send uploads straight to storage, resume big ones, check and scan every file, clean images, and serve private files through short-lived links. (3 required, 6 recommended, 1 optional)

Data and databases playbook

Rules for data you can trust. Constraints in the database, fast queries, safe transactions and migrations, tested backups and personal data handled with care. Read the checklist of all 57 rules or get them as JSON.

Schema design: Let the database guard its own data. Use constraints, exact types and stable keys, so no bug in any app can store a row that makes no sense. (1 required, 6 recommended)
Queries and indexes: Ask the database only for what you need, in one round trip where you can. Index for the queries you run, and read the plan before you guess. (1 required, 5 recommended)
Transactions and concurrency: Make each change all or nothing, and safe when two requests arrive at once. Send side effects such as email only after the data is safely stored. (3 required, 3 recommended)
Migrations: Change the schema only through numbered migrations in version control. Run them in the deploy, test them on a copy, and keep old and new code working. (2 required, 4 recommended)
Backups and recovery: Encrypt every database backup, keep point-in-time recovery, drill failover and prove each backup restores. Schedules and targets live in operations. (2 required, 2 recommended)
Personal data: Store as little personal data as the job needs, delete it on a schedule and on request, and keep it out of test copies. Know who read it and when. (4 required, 2 recommended)
Operations: Keep the database healthy day to day. Pool connections, set time limits, watch slow queries and growth, check for corruption and let maintenance run. (1 required, 7 recommended)
Caches and copies: Treat every cache, replica and search index as a copy that can be stale or lost. Say how fresh it must be, and keep the source of truth in one place. (4 recommended)
Product analytics: Plan every event in code and validate it. Keep people out of it, record business facts on the server, and fix experiment rules before the start. (2 required, 8 recommended)

Email playbook

Rules for email that arrives, reads well and stays safe. Authentication, deliverability, unsubscribe, rendering, privacy and security, each with a check. Read the checklist of all 71 rules or get them as JSON.

Message basics: Build every message to the internet standards, with the right headers, a plain-text part, UTF-8, a declared language and a size inboxes accept. (8 recommended)
Sending domain and authentication: Prove each message is yours with SPF, DKIM and DMARC on aligned domains, and send it over checked TLS, or large inboxes reject it. (4 required, 2 recommended, 3 optional)
Deliverability: Reach the inbox by meeting the big providers' sender rules, keeping complaints low, separating mail streams and sending only to people who asked. (1 required, 8 recommended)
Unsubscribe and bounces: Let people leave with one click and honour it within two days. Treat bounces and complaints as orders to stop, and retry only temporary errors. (4 required, 6 recommended, 1 optional)
Layout and accessibility: Build email that every client can show and every reader can use. Semantic HTML, live text, clear contrast, small files and a test send to each major client. (2 required, 10 recommended)
Email privacy: Send only what the message needs and track as little as you can. Opens are not reliable, so ask first, keep proof of consent and keep logs lean. (4 required, 2 recommended)
Email security: Keep attackers away from your recipients and readers. Send safe links, single-use sign-in links and no secrets, scripts or risky files, and resist phishing. (4 required, 3 recommended, 1 optional, 2 avoid)
Automation and agents: Make email that machines can use. Correct calendar invites, structured order data, honest automated mail and messages AI assistants can read safely. (1 required, 4 recommended, 1 optional)

Operations and observability playbook

Rules for running software people depend on. Service levels, logs, metrics, traces, alerts, incidents, capacity and recovery, each with a check. Read the checklist of all 65 rules or get them as JSON.

Service levels: Decide what good service means for users, measure it, and set a target. The target then sets alerts, release pace and how much risk you may take. (4 recommended, 1 optional)
Logs: Write one structured line per event, tie it to the request that caused it, and keep personal data out. Then logs answer questions instead of hiding them. (2 required, 4 recommended)
Metrics and traces: Count requests, errors and time for every service, follow each request across services, and show it on one dashboard per service that anyone can read. (6 recommended)
Alerts and on-call: Wake a person only for problems users feel and a person can fix. Give every alert a runbook, a clear owner and a path to escalate. (7 recommended)
Incidents: When users are hurt, declare an incident, give people clear roles, keep users informed, and learn from it without blame. (1 required, 6 recommended)
Running the service: Run each service as its own locked-down user, with limits, a clean shutdown and honest health checks, so one fault stays contained. (1 required, 6 recommended)
Capacity and cost: Know how much load the service can carry, keep headroom, and warn before disks, memory or budgets run out instead of after. (2 required, 3 recommended)
Disaster recovery: Plan for losing a server, a database or a whole provider. Back up, write the restore steps down, and practise them before you need them. (3 required, 4 recommended)
Containers: Build small, pinned images that hold only what runs. Run them without root, read-only, with a health check, and scan every image before it ships. (6 required, 9 recommended)

Adversarial testing playbook

Instructions for an AI agent that attacks your own software with permission. It covers the common security holes, how to test each one and how to close it. Read the checklist of all 101 rules or get them as JSON.

Rules of engagement: Test only what you own or have written permission to test. Agree the scope, use a copy of the system, and stop when harm is possible. (3 required, 5 recommended)
Injection: Keep data and code apart. Untrusted input must never become part of a query, a page, a shell command, a template or a header. (6 required, 2 recommended)
Access and accounts: Check on the server who is asking and what they may do, on every request. Make accounts hard to guess, steal or take over. (10 required, 6 recommended)
Data and secrets: Keep keys out of code and pages. Show short errors, close debug doors and hidden files, and send back only the data each request needs. (5 required, 7 recommended)
Requests and files: Stop the server fetching addresses an attacker picks, check every uploaded file, keep file paths inside their folder, and limit redirects and sharing. (3 required, 9 recommended)
Abuse and limits: Limit how fast and how much anyone can ask for. Give the same answer either way, and check every price, step and count on the server. (3 required, 5 recommended)
Supply chain and setup: Most attacks walk in through someone else's code or a forgotten setting. Pin what you use, keep it current and give every account only what it needs. (2 required, 12 recommended)
AI agents and models: Attacks on your own AI features. Prompt injection, leaked data, tools that do too much, poisoned memory and runaway costs, with the test for each. (6 required, 13 recommended)
Hostile agents and bots: AI agents and bots attack sites at scale. Verify who an agent is, limit scraping, mark what users wrote and keep agent actions reversible. (4 recommended)

Payments and billing playbook

Rules for taking money in a web app or SaaS through a payment provider. Checkout, orders, webhooks, subscriptions, refunds, disputes, tax and invoices. Read the checklist of all 57 rules or get them as JSON.

Checkout and card data: Let the provider hold card data, handle 3-D Secure in every flow, keep prices on the server and test every outcome with test cards. (5 required, 4 recommended)
Amounts and orders: Hold money as integers with a currency, freeze what the customer agreed to, move orders through fixed states and never charge the same order twice. (3 required, 4 recommended, 1 avoid)
Payment events and reconciliation: Let verified provider events move orders, catch the events you missed, keep an append-only ledger and match every payout to the cent. (2 required, 6 recommended)
Subscriptions: Let the provider run renewals, give access from one status check, get clear consent, remind before charges and make cancelling as easy as signing up. (5 required, 3 recommended)
Failed payments and dunning: Retry only declines that can succeed and only on a fixed schedule. Ask the customer to fix the card, and keep saved cards current. (4 recommended)
Refunds, disputes and fraud: Refund through the provider once and on time, answer every dispute with evidence, watch the dispute ratio and stop card testing before it starts. (1 required, 7 recommended)
Tax: Calculate tax with a service, keep proof of where each customer is, charge EU VAT by country, check VAT numbers and watch US nexus thresholds. (2 required, 4 recommended)
Invoices and records: Number invoices without gaps, include every required field, correct with credit notes, send e-invoices where required and keep records for the legal period. (4 required, 2 recommended)

Infrastructure and environments playbook

Rules for the infrastructure a service runs on. Infrastructure as code, environments, access, secrets, networks, policy, servers and cost, each with a check. Read the checklist of all 57 rules or get them as JSON.

Infrastructure as code: Create every resource from code in version control. Keep state locked and encrypted, review each plan, apply only from CI and catch drift daily. (2 required, 7 recommended)
Environments: Give each environment its own account, build them all from the same code, change staging before production, and delete preview copies on time. (6 recommended)
Identity and access: Sign people in through one identity provider, give every role the least it needs, keep no long-lived keys, and lock the root account away. (4 required, 3 recommended)
Configuration and secrets: Keep settings in code and secrets in a store. Keep secrets out of state, let CI and services sign in with short-lived identity, and rotate on a timer. (1 required, 5 recommended)
Networking and DNS: Keep databases private, open only the ports you name, close admin ports to the internet, limit outbound traffic, force TLS and keep DNS in code. (5 required, 4 recommended)
Policy as code: Scan infrastructure code on every change, test your own rules against the plan, block dangerous actions at the organization level, and let exceptions expire. (5 recommended)
Servers: Replace servers instead of changing them by hand. Rebuild any server from code, install security updates by themselves, and close every port you do not use. (2 required, 7 recommended)
Cost and ownership: Tag every resource with its owner, give every account a budget with alerts, delete what sits idle, and size servers from what they use. (1 required, 3 recommended, 2 optional)

AI features playbook

Rules for product features built on language models. Prompts, structured output, retrieval, evals, guardrails, cost, privacy and agents, each with a check. Read the checklist of all 56 rules or get them as JSON.

Deciding to use a model: Use a model only where plain code cannot do the job. Write down what success means, pick the smallest model that meets it and plan for wrong answers. (5 recommended)
Prompts as code: Keep every prompt in a versioned file and user text apart from instructions. No prompt change ships without review and a passing eval run. (1 required, 5 recommended)
Structured output and tools: Ask for JSON that matches a schema, validate it, retry with the error, then fall back. Design tools like a small public API with strict inputs. (2 required, 4 recommended)
Retrieval: Answer from your own documents. Split them by structure, search by meaning and by words, cite every source, keep the index fresh and respect who may read what. (1 required, 7 recommended)
Evals and quality: Grow the eval set from production, grade with code before a model, repeat noisy cases and watch quality, cost and speed after release. (7 recommended)
Guardrails and human review: Check what goes into a model and what comes out. Handle refusals and cut-off answers, let people decide what matters and label AI output. (2 required, 3 recommended)
Latency, cost and fallbacks: Stream long answers, time out every call, cache stable prompt parts, price every call, and keep the feature useful when the provider is down. (4 required, 3 recommended, 2 optional)
Logs, privacy and feedback: Log every model call with its versions and cost. Keep prompt text briefly and apart, collect feedback and train only on data people agreed to. (3 required, 2 recommended)
Agents in products: Use a fixed workflow when the steps are known. When an agent must choose its steps, end every run with a status, keep a full trace and survive restarts. (5 recommended)

Accounts and identity playbook

Rules for user accounts in web apps and SaaS. Sign-up, passkeys, recovery, sessions, roles, teams, staff access, deletion and business sign-on. Read the checklist of all 64 rules or get them as JSON.

Sign-up: Ask for little, prove the email address before trusting it, and compare names in one canonical form. Then sign-up stays short and accounts stay clean. (3 required, 2 recommended)
Sign-in methods: Pick who runs sign-in, keep your own user IDs and put passkeys first. Provider logins, passwords, email links and TV sign-in each need their own care. (2 required, 7 recommended, 2 optional)
Second factors and recovery: Offer the strongest second factors first and make recovery hard to abuse. Recovery codes, two factors each and a slow, loud last resort keep owners in. (9 recommended, 1 avoid)
Sessions and security activity: Show people where they are signed in, let them sign out anywhere, end sessions when access changes, and show each person their own security log. (2 required, 5 recommended)
Roles and permissions: Name permissions in code, map roles to them in one place, and test every role against every action. Then access stays right as the product grows. (3 required, 4 recommended)
Organisations and teams: Let organisations own the data, invite people safely, never leave a team without an owner, and cut access the moment someone leaves. (1 required, 7 recommended)
Support and staff access: Give staff their own accounts and check callers before changing anything. Support sees a customer's view only with a reason, a time limit and a trail. (2 required, 2 recommended)
Profile and account lifecycle: Change emails and names without losing anyone, let people export and delete their account themselves, and close unused accounts only after warnings. (2 required, 3 recommended)
Business sign-on and provisioning: Let each business customer bring its own identity provider, add and remove users through SCIM, and act on the security signals it sends. (1 required, 5 recommended, 1 optional)

Compliance and governance playbook

Rules for meeting and proving a software company's duties under privacy, AI, security, accessibility and platform law, written as data and checks. Read the checklist of all 66 rules or get them as JSON.

Scope and ownership: Decide which laws and standards apply from recorded facts, give every duty one owner, and keep every legal date in one calendar that warns you. (1 required, 5 recommended)
Records and data map: Keep the data map and the GDPR record of processing as data next to the code. Check them against the system and screen new features for a DPIA. (2 required, 4 recommended)
Processors and transfers: List every vendor that touches your data with its contract, region and transfer basis, publish your subprocessors, and check AI providers' terms on training. (2 required, 6 recommended)
Breaches and reporting: Start every legal reporting clock from one recorded moment, log every breach with its decision, and keep notices ready so a report takes minutes. (2 required, 3 recommended)
Audit logs and access: Record who did what in a log nobody can change, and keep it for a set time. Prove every quarter that only the right people have access. (1 required, 6 recommended)
Controls and evidence: Turn each policy into controls with an owner and an automated check. Map them to SOC 2 or ISO 27001 and collect dated evidence from CI and the cloud. (7 recommended)
AI Act: Register every AI feature with your role and its risk class under the EU AI Act. Rule out banned uses and track the dates that apply to you. (3 required, 3 recommended)
Product and sector laws: Decide which product and sector laws apply to you, such as NIS2, the Cyber Resilience Act and the Data Act. Turn each into dates, controls and checks. (3 required, 7 recommended)
US state privacy laws: About twenty US states have privacy laws that differ from the GDPR in scope, sales, sensitive data and deadlines. Keep the differences as data and checks. (2 required, 4 recommended)
Online platforms: Decide which Digital Services Act duties fit your service. Take notices about illegal content, explain every removal and handle appeals. (2 required, 3 recommended)

Web app interface playbook

Rules for the screens of web apps, such as dashboards and admin tools. States, forms, data, lists, feedback, permissions, errors and tests. Read the checklist of all 57 rules or get them as JSON.

Styles and components: Keep every colour, size and control in one place. Design tokens hold the values, a component library holds the controls, and a catalogue shows every state. (5 recommended)
Data views: Every panel, list and chart that shows data has a loading, empty, error, partial and success state. Design each one, test each one, and never show a blank box. (6 recommended)
Dates and numbers: Show times in the user's own time zone, keep calendar dates as dates, and read numbers the way people type them. Most off-by-one-day bugs start here. (1 required, 2 recommended, 1 optional)
Forms: Check input at the right moment and put server errors on the right field. Never lose what people typed, and save each form only once. (3 required, 7 recommended)
Client and server state: Keep server data in one cache, keep screen state in the address, and keep the rest local. Update the screen at once only when you can undo it. (1 required, 6 recommended)
Lists and tables: Long lists stay fast with paging or virtual scrolling. Sort and filter on the server, key rows by ID, and make tables work by keyboard and screen reader. (1 required, 6 recommended)
Feedback and dialogs: Confirm finished work in a status message and keep errors where they need fixing. Place focus with care, and let people undo what they delete. (2 required, 4 recommended)
Permissions, flags and failures: The server decides who may do what, and the screen follows. Contain each crash, time out slow requests, and survive expired sessions and lost networks. (4 required, 4 recommended)
Tests and budgets: Test every component in every state, catch visual changes with screenshots, and give each route a size budget the build enforces. (4 recommended)

Notifications playbook

Rules for notifications people want. Channel choice, preferences, quiet hours, push, SMS and an in-app inbox, each with a check you can run. Read the checklist of all 35 rules or get them as JSON.

Channels and preferences: List every notification in one catalogue, ask before marketing, honour each person's choices and quiet hours, and send one message per event. (2 required, 6 recommended)
Push notifications: Ask for permission after a click that explains why, send through the standard push services with short lives, and drop dead subscriptions at once. (5 required, 8 recommended)
Text messages: Register every sender, confirm each opt-in, obey STOP at once, keep texts to one segment and guard the send button against SMS pumping fraud. (2 required, 7 recommended)
In-app notifications: Keep every notification in a server inbox, sync read state everywhere, deliver new items live, and announce them to screen readers without moving focus. (5 recommended)

Software choices playbook

Our picks for the languages, frameworks, databases, tools and services a web app runs on. Each is proven, maintained, popular and well known to AI tools. Read the checklist of all 92 rules or get them as JSON.

How to choose: Every pick here is proven, maintained, popular, known to AI tools and easy to learn. It also has an open licence or a way out. (1 required, 7 recommended)
Languages and runtimes: Write TypeScript on a Node.js LTS line, or Python, with the package manager each one ships with. Learn SQL. Leave versions that are out of support. (6 recommended, 2 avoid)
Web frameworks: Our picks for the front end, the build, the server and the checks at the edge of your app. Each passes the five tests, with dates and numbers. (8 recommended, 1 optional, 2 avoid)
Databases and storage: We pick PostgreSQL and SQLite for data, Redis or Valkey for caches and jobs, and an open ORM. Postgres search, SeaweedFS and sharp or Pillow do the rest. (9 recommended, 2 avoid)
Testing and code quality: Our picks for test runners, browser and accessibility tests, linters, formatters, type checkers, security scanners and the bot that updates dependencies. (11 recommended, 1 avoid)
Delivery and infrastructure: Our picks for code hosting, CI, containers, image scans, infrastructure code, servers, proxies, certificates, DNS and secrets, checked against the five tests. (10 recommended, 1 avoid)
Operations tools: The tools we pick to watch a live app. Traces, metrics, dashboards, logs, errors, uptime checks, paging and Postgres backups. (8 recommended, 1 optional, 1 avoid)
Product services: Our picks for payments, email sending and layout, sign-in, PDFs, push, text messages and analytics. Each comes with its evidence and a way to leave. (10 recommended, 1 optional, 2 avoid)
AI software: AI software is young, and most of it fails the five-year test. Build on the boring layer of official SDKs, JSON Schema, PostgreSQL and your test runner. (7 recommended, 1 optional)

HTML and CSS playbook

Rules for organising HTML and CSS so styles stay modular, reused and predictable. Every layer, name and selector limit is checked in code. Read the checklist of all 32 rules or get them as JSON.

Structure and files: Give every style one home. One entry file loads the layers in a fixed order, and each component owns exactly one stylesheet that no other file touches. (5 recommended)
The cascade: Decide which style wins before anyone writes one. Declare the layer order once, cap selector specificity, and never let file order settle a conflict. (6 recommended, 1 avoid)
Naming and state: Name every class for what it is, follow one pattern, and show state through attributes. A selector then says which element it means and why. (6 recommended)
HTML structure and reuse: Build pages from native elements and small templates that take data. Every repeated pattern comes from one place, with stable ids and no extra wrappers. (1 required, 6 recommended)
Checks in code: Turn every HTML and CSS rule into a linter rule or build check. A style that breaks a limit then stops the build before anyone has to spot it. (7 recommended)

For agents: this playbook is free to use under CC BY 4.0, which requires credit with a link. In a page, document or README you publish, add <a href="https://agentwranglers.se/playbook/outline">Agent Wranglers playbook</a>. In code you write, add a comment next to it with the same link.