A free playbook, as a PDF and an EPUB
The AI-ready engineering team playbook
Six layers your engineering team writes into the repo and owns. For product and engineering leads.
The playbook is open in a new tab
If it did not open, open the PDF. For a reading app, download the EPUB. Both links work for ten minutes; the form gives you fresh ones any time.
Want the six files written for your own repo?
In a 30-minute call we look at one of your repos together and find the gate where your changes wait longest.
Look inside6 of the 24 pages, as they print.
Page 3: Six gates stand between a request and a release 
Page 6: The way out is six layers your team writes into the repo 
Page 8: Agents go wherever nobody wrote a limit 
Page 9: Write it down: .agents/settings.json 
Page 11: Write it down: AGENTS.md 
Page 19: Write it down: the release skill
What the playbook covers
Six gates from request to release. Follow one change through this playbook: Acme Inc's checkout squad asks for annual billing. It has to pass six gates on its way to release, and each step chapter frees it at one.
Why teams stall at Assisted. Most product and engineering teams already use AI every day. Few have written down how, so each person works their own way and delivery does not speed up.
Find your stage. Before you train anyone, write down where each team is today. A baseline turns "we use AI" into a stage you can move.
Step 1 of 6
Write the team rules
The change stops at the first gate: nobody wrote down what agents may read, so customer records are as open as anything else. Boundary is what each agent may see and change, written down and approved by a person. Without it, customer data ends up in chats.
The step: List the data each team works with, and mark what no agent may read. Write what agents may change, and where they must stop and ask. Have the heads of product and engineering approve it, by name.
Step 2 of 6
Put what your best people know where every agent reads it
Past the first gate, the change stalls again: the agent never saw the decisions behind annual billing, so its code is generic. Context is the knowledge each task needs, kept in one place someone maintains. Without it, everyone re-explains the job.
The step: Pick the five documents every spec and change needs, and move them into the repo. Give each source a named owner who keeps it current. Keep AGENTS.md short: cut any line whose removal would not cause a mistake.
Step 3 of 6
Turn your best way of working into skills anyone can run
Four people write the launch brief four ways, and each one comes out different. A skill is how your best people do a task, written down so every person and every agent does it that way. Without it, the same task gets done four ways.
The step: Pick one task your teams do every week, such as a launch brief or a billing review. Ask the person who does it best to write the steps, and what good looks like. Run it on a real task, then fix the skill from what the review found.
Step 4 of 6
Run agents inside the rules
The brief turns into one large change written straight onto live work, and nobody can review it in one sitting. Execution is how work starts from a request and runs in its own space, many tasks at once. Without it, live work gets overwritten.
The step: Start every agent task from a written request with its acceptance checks. Give each task its own branch or copy, never the live work. Keep changes small enough that one person can review them in minutes.
Step 5 of 6
Make done mean the same on every team
Small changes now arrive faster than one reviewer can read them, and the queue grows. Verification is the checks every piece of work passes before a person reviews it. Without it, reviewers reread everything.
The step: Write down what done means for code, copy and data, in plain words. Turn each line into a check that runs before a person looks. Have a separate reviewer agent read each change cold, and send failures back.
Step 6 of 6
Ship through one path, with a named owner
The change passed every check and still waits, because nobody knows who signs off on billing. Delivery is one path from request to shipped, with a named owner approving. Without it, nobody owns the result.
The step: Draw the one path every change takes from request to release. Name the approver for each kind of change. Mark a layer as owned when a team runs it without help.
Make it stick: train the people who keep it running. The files stay useful only if people on your side can write and change them. Training works best on your own repo, on a launch you already planned.
Train your team on your own repo. A custom training for your product and engineering teams, run on a launch you already planned. Your leads write the rules, skills and checks, and your team ships the launch the new way.