Plan, Implement, Autobuild
The three-skill workflow I use to direct agents
The agents do the typing. The hard part is keeping them on track across a feature that is too big to hold in one context — so I push the state out of the conversation and into one plain Markdown file.
Anyone who has driven a coding agent through real work has hit the same wall: the feature is bigger than the context window. Halfway through, the model is juggling the original goal, three half-finished files, and a verification step it half-remembers — and quality starts to slide. The instinct is to keep feeding the same long session until it cracks.
I went the other way. Instead of fighting to keep everything in context, I push the state out of context — into a plan file the agent can always read back. That single decision is what makes the three skills below work together. (RPK is just my initials.)
How the skills are written
Each one is an agent skill: a SKILL.md file with a small YAML frontmatter block — a name, a version, and a description that tells the agent exactly when to reach for it — followed by the operating instructions in plain Markdown. There is no application code to deploy. The skill is the prose; the agent reads it and behaves accordingly.
A few conventions hold across all three:
- They announce their version on every run. rpk-plan v1.2.3 prints up front, so I can confirm the installed copy matches the source at a glance.
- They take a slug, not a path. You invoke /rpk-plan about; the skill validates the slug, resolves the project root, and writes exactly one file — about.md. No path traversal, no surprises.
- The plan file is the single source of truth. Every skill reads and writes that one <slug>.md. State lives in the file, not in the conversation.
That last point is the whole trick. Because the file owns the state, a brand-new, empty context can pick up exactly where the last one left off. Context becomes disposable.
Interrogate the idea into phases
Planning comes first, and it is deliberately adversarial. rpk-plan runs a grill-style interview: it challenges assumptions, inspects the repo when the conversation calls for it, researches when the facts are not in the code, and asks one question at a time — each with a recommended answer — updating the plan after every answer. There is no fixed question count; the queue grows as your answers reveal new follow-ups.
It is planning-only. It never edits code and never touches source control. It only writes the plan.
The output is a multi-phase implementation plan. Every phase is a Markdown checkbox, and a compact Phase Overview table sits near the top — one row per phase, each with its own Done box. You keep the .md open while the work runs and watch one small area tick from [ ] to [x] without scrolling.
- [ ] **Phase 2: Wire the contact form to the API**
- Reason: the form currently posts nowhere
- Goal: submissions reach the inbox endpoint
- Key work: handler, validation, success + error states
- Done when: a test submission lands and is acknowledgedOne phase, verified, uncommitted
rpk-implement about does exactly one thing: it implements the next unchecked phase. It reads the plan, repeats the summary back to you, names the phase it is about to build, and waits for your explicit confirmation before it changes a single file.
Then it:
- Creates (once) and works on a feature branch, rpk/<slug>.
- Implements only that phase — scoped tightly, no wandering into adjacent work.
- Verifies with the checks that fit the repo — tests, build, a browser check.
- Flips the phase checkbox and its Overview row to [x], updates the status, and appends an entry to the Implementation Log.
It never commits. It leaves the work uncommitted on the branch for me to review and commit myself. If a phase is blocked, it leaves the box unchecked, writes a visible "⛔ Blocked" callout at the top of the plan, logs why, and stops — rather than faking progress.
This is the manual, one-phase-at-a-time mode — and here is where context cleaning becomes your lever. Because all the state lives in about.md, you can run one phase, start a fresh session, run the next, and so on. Each phase begins with a clean, empty context that rehydrates itself purely from the plan file. You decide when to clear — between any two phases, deliberately.
Every phase, fresh context, automatically
rpk-autobuild is the same idea with the clearing automated. It is a thin orchestrator — it does not implement code itself. It drives rpk-implement headlessly in a loop.
/rpk-autobuild aboutAfter a one-screen preflight — slug, root, branch, how many phases remain, the first one up — it loops:
- It launches the next phase in a brand-new, ephemeral context — a separate claude -p or codex exec process with persistence off — so every phase starts empty.
- That process runs rpk-implement, pre-confirmed so the gate passes non-interactively, builds the phase, and verifies it — without committing (git mutation is denied inside the run).
- Back in the orchestrator, it re-reads the plan file — not the model’s chatter — to decide what happened. A box flipped to [x]? It makes one commit for that phase and continues. Status now Blocked? It surfaces the blocker and stops. No progress? The stall guard stops it.
The loop ends on its own when the plan is Complete, a phase is Blocked, or an iteration makes no headway — with a hard iteration cap as a backstop. You treat the /rpk-autobuild invocation itself as the authorization; there is no per-phase prompt, because that would defeat the point. You can stop it any time.
Implement vs. Autobuild
They are two speeds on one engine.
| rpk-implement | rpk-autobuild | |
|---|---|---|
| Scope per run | one phase | all remaining phases |
| Who is driving | you, with a confirmation gate | the loop, unattended |
| Context cleaning | manual — you start a fresh session | automatic — fresh process per phase |
| Commits | none — you commit | one per phase, on the branch |
| Best for | risky or exploratory phases I want to eyeball | a solid plan I trust to run end to end |
Reach for implement when I want to inspect each step — early phases, anything touching something fragile. Reach for autobuild when the plan is solid and I would rather review a clean string of per-phase commits than babysit each one.
Importantly, autobuild does not reimplement anything; it composes implement. Phase behavior is defined in exactly one place, so the unattended run and the manual run produce the same work.
Why it holds together
The three skills are really one design, with the state pulled out of the conversation and into a file:
- rpk-plan turns an idea into ordered, checkbox-tracked phases.
- rpk-implement executes one phase at a time, verified and uncommitted, and lets me clear context between phases.
- rpk-autobuild runs the whole sequence, clearing context automatically and committing as it goes.
Long features stop being a fight against a filling context window. Each phase gets a clean slate, reads the plan, does its one job, proves it, and records the result back into the file the next phase will read. The agents do the typing. The plan keeps them honest.