The playbook I hand every agent before it touches a repo. Seventeen skills, versioned in git and synced to every machine, that turn a vague idea into a planned, reviewed, merged change — and stop, five separate times, to wait for a human. It is the least glamorous project in the fleet and the one the other four are built with.
Figures measured 2026-07-14.
It writes down what I'd otherwise have to say twice. Every agent session starts from the same context I'd give a new teammate: how this project is branched, what its tests are, what "done" means, which mistakes have already been made. That used to live in my head and get re-explained every session. Now it lives in a git repo, and a hook fast-forwards it onto whichever machine I'm working from before the session starts. Change a rule once; every machine and every project has it next time.
It makes the work stop in the right places. The pipeline below runs eight steps and pauses at five of them, and none of the pauses are decorative — each is a place where an agent could otherwise do something irreversible. The build step is the clearest: it implements, tests, and reviews with no gate at all, then stops dead and writes a file with a blank signature line. Nothing proceeds until the line is filled. The machine stops itself by producing something a person has to sign.
It gets the same change read twice, by two agents that can't see each other. Two reviewers run in parallel over the same diff. A third pass reconciles what they found against the actual code and throws out the findings that are wrong — because reviewers are confidently wrong often enough that taking their word for it would be its own bug. What survives gets a disposition, and the whole package lands in one file for me to approve, change, or reject.
A surprising amount of it happens on a phone. Not the code — the decisions. The planner is forbidden from asking questions inline; it writes them to a file instead, and a walker reads them back one at a time in chat. That is why the questions are phrased for a product manager rather than a developer, and why "approve" is a single keystroke. The work is done at a desk. The judgement gets made in a queue at the grocery store.
/workflow-task-kickoff
Explains the task in plain English, re-checks it against today's code, and says whether it's still worth doing.
You approve the breakdown. Nothing is written until you do.
/workflow-async-plan
Explores the code and writes every open question to a file instead of interrupting you.
The questions file. Answer it whenever; the pipeline waits.
/workflow-answer-questions
Walks the questions one at a time in chat. Built for a phone.
/workflow-async-resume
Turns the answers into the plan. Refuses to write one while any answer is blank.
/workflow-build
Implements, tests, and hands the diff to two independent reviewers. Reconciles their findings against the real code. Then stops — it does not open a pull request.
You sign the review file. Fixed, deferred, or dropped, per finding.
/workflow-drain-review-queue
Applies the fixes, opens the pull request, waits for CI, and asks the bot reviewer for its own pass.
You sign the bot's findings the same way.
/workflow-drain-review-queue
Same command, second run — the bot's queue is its own review.
Merge? [y/N]
The five gates are the design. An agent that can plan, write, review, and merge without stopping is not a colleague, it is an outage waiting for a cause. Every gate is a place where the work is complete and unsent — which is the only state from which a human can cheaply say no.
This page was planned, built, reviewed by two agents and merged through the pipeline it describes. The questions I answered to produce it are sitting in a file in this repo.
Seventeen skills. Ten are typed by a human; seven are never typed at all — they are read and followed by the skills above them, which is why two different sessions review code the same way.
/workflow-task-kickoff
Explains a task in plain English, re-checks it against today's code (tasks go stale), gives a verdict on whether it's still worth doing, and proposes how to slice it. Nothing is written until you approve.
Reach for it: starting any new task.
/workflow-async-plan
Explores the code for one subtask and writes every open question to a file. It is forbidden from asking inline.
Reach for it: a subtask needs a plan.
/workflow-answer-questions
Walks the open questions one at a time in chat, and writes your answers back to the file.
Reach for it: questions are waiting and you have five minutes.
/workflow-async-resume
Turns the answered questions into the implementation plan. Refuses to generate one while any answer is blank.
Reach for it: every question is answered.
/workflow-build
Implements the plan, runs the tests, gets the diff read by two independent reviewers, reconciles their findings against the real code, and packages the survivors into one file for you. It does not open a pull request. It stops.
Reach for it: a plan is ready to build.
/workflow-drain-review-queue
Carries a reviewed change all the way to merged: applies the fixes you approved, updates the docs and the task, opens the pull request, waits for CI, gets the bot's pass, and finally asks permission to merge. Runs twice.
Reach for it: you've signed the review.
/triage
Drop a screenshot or a console dump in a folder; get back a diagnosed root cause and a recommendation, optionally filed as a task. It diagnoses and stops: it never writes code, never edits config, and never writes to a database.
Reach for it: something broke and you have a picture of it.
/wrap-up
Closes a session. Recaps what actually landed against what you asked for, with every claim tied to a commit; forces every loose end into exactly one of four fates — fixed, filed, deferred, or dropped with a reason — and writes the opening message for the next session.
Reach for it: end of a working session.
/workflow-ask-cto
A CTO persona loaded with the project's real stack and architectural rules, for arguing through a decision too big to settle inline. Recommendation first, then the alternatives. It is the only skill an agent may reach for on its own; no other skill can invoke itself.
Reach for it: an architecture call you want pushed back on.
/verify-nightly
A read-only morning sweep: did last night's scheduled jobs actually run, and is anything down now. Every check is three-valued — a signal it cannot read is reported as inconclusive, never as passing, because a check that quietly passes when it can't see anything is worse than no check at all. It writes nothing, so it needs no confirmation gate.
Reach for it: every morning.
workflow-explore
Understands the code and surfaces every ambiguity before a line is written. Read by the planner.
workflow-resolve-context
Answers the planner's questions it can already answer from authoritative sources, so you're only asked the genuinely new ones — and leaves a receipt for every question it closed on your behalf, which you can veto. Read by the planner.
workflow-create-plan
Renders the plan document from decisions already made. Read by the planner.
workflow-execute
Implements a plan exactly as written, test-first, marking progress as it goes. Read by the builder.
workflow-review
Reviews a diff against a quality checklist and assigns each issue a severity. Read by the builder — twice over, by two agents that never see each other's findings.
workflow-peer-review
The team lead who doesn't take the reviewers' word for it: verifies every finding against the real code and throws out the ones that are wrong. Read by the builder.
workflow-draft-pr
Writes the pull-request title and description from the actual commits. Read by the shipper.
The always-on assistant — it runs on OpenClaw — does not live on the machine I work from. It runs on a dedicated sandboxed machine, and that machine has no outbound network access by default — not "restricted", not "monitored": none. Everything it is allowed to reach is granted one destination at a time, deliberately, and a grant that isn't needed doesn't exist.
That is the difference between isolation by construction and isolation by promise. An agent I have instructed not to touch something is relying on my instructions being complete, which they never are. An agent that cannot reach the thing is not relying on anything. The sandbox is the version of that argument I actually trust, and it is why the assistant is allowed to be always-on at all.
The last row is the odd one out, and it is honest. The vaults that live on GitHub end their pipeline at a pull request where an automated reviewer takes its own pass. This one doesn't — it lives on the home server, with no public copy, so there is no pull request for a bot to review. The playbook that prescribes the bot review doesn't get one itself.
The sync is the part that makes it a system rather than a folder. The config is symlinked into place on each machine, and a hook fast-forwards it at the start of every session — silent when it works, loud when it can't, and structurally incapable of overwriting a local edit. Change a rule on the laptop; the sandbox machine has it next time it wakes up.
An agent ran a command to see what it would do, and shipped
it.
The command was gh pr merge --auto, and the intent was
diagnostic — find out whether auto-merge was enabled by watching what
happened. On a repo with auto-merge disabled, that flag is
not a no-op and not a query: it falls back to merging the pull request
immediately. It merged. One step before my final go-ahead, on a real
project. Nothing broke, which is the only luck in the story.
The rule it produced is now in the playbook every agent reads: a state-mutating command is never a diagnostic. If you want to know the state, use a command that reads it. The deeper lesson is about the shape of the mistake rather than the command — the agent wasn't reckless, it was curious, and curiosity expressed through a side-effecting call is indistinguishable from recklessness after the fact. "What happens if I run this" is a question you ask a read-only tool.
The values in the paperwork were being typed from memory. Agents were writing commit hashes, findings, and statuses into artifacts — review files, pull-request bodies, reports — by recalling them. Recall is where fabrication gets in. Not deliberate invention: a hash that's almost right, a status that was true two steps ago. Every one of those is a small lie in a document that later gets trusted.
So the rule changed to something a machine can enforce: a value in an artifact must come from a tool call that already returned. Fetch in one step, write in a later one, and generate derived values in-band rather than retyping them. A hook now checks that a review file's commit hash actually matches the commit, and fails loudly when it doesn't. The general principle is the one I keep relearning in this fleet: don't ask an agent to be honest about something you could simply make it impossible to get wrong.