I did not start by building an agent framework. I started with a Kanban board.
Each column on it represents a state. Transitions between columns have explicit rules. Agents execute the work between states, and some transitions deliberately require a human decision.
The interesting part is not how many agents are running. It is that every one of them operates inside an explicit workflow. The model is the same for everyone. What differs is everything around it.
In this system, most of the complexity lives in the workflow, not in the runtime. The board and its rules came first, and they are what this series is about.
That surrounding structure is where the competition is right now: spec-driven frameworks such as GitHub’s Spec Kit, OpenSpec and BMAD, whole IDEs built around the idea, like Kiro, orchestrators that run several agents in parallel, like Claude Squad, Conductor or Vibe Kanban, and countless private setups made of skills, prompts and shell scripts that never leave their author’s machine. Everyone is building their own version, and nobody has won, because there is no single right answer yet: a workflow encodes how one team, or one person, actually works.
This is mine. It grew out of Shockley, the software project I work on.
How a Task Moves
kanban
testing["Testing STG/DEV [Human]"]
t1["USER: tests"]
pr["PR [AI] {4}"]
q1["SKILL: dev-test"]
cr["CR [AI] {3}"]
c1["SKILL: review-pr"]
inprogress["In Progress [AI]"]
p1["SKILL: autopilot"]
ready["Ready [AI] {2}"]
r1["SKILL: autopilot"]
grilling["Grilling [AI] {1}"]
g1["SKILL: grill-card"]
backlog["Backlog [Human] {0}"]
b1["USER: triages"]
The flow runs right to left, with a human column at each end.
The simplest board has three states: to do, doing, done. The more defined a process is, the more states it has, because every state answers one question: what is this task waiting for right now?
This board works the same way, only with more states and stricter transitions. Each column name says who owns the transition, [Human] or [AI]. Most boards read left to right; this one runs from right to left: a task enters on the far right, in Backlog, and ends on the far left, in Testing.
Even when people do all the work, the process is essentially the same. None of these states were invented for agents; what changed is who performs each step.
- Backlog: everything that could be worked on. Here it is also the intake for findings the agents surface on their own.
- Grilling: understanding the task, alone or together with the team. Here an agent interviews me until the design is resolved.
- Ready: the task is ready to be worked on. Here it waits for the autopilot to pick it up.
- In Progress: someone is working on the task. Here an agent implements the card and opens a draft PR.
- CR: the task waits for code review. Here a second pass reviews the PR, and the findings are then fixed.
- PR: the PR is ready. Here it gets merged, and then tested on the deployed app.
- Testing: a human tests the result, on STG/DEV.
Two rules hold for every task. There is exactly one legal move backwards: a card whose review failed goes from CR back to Grilling, with a comment explaining why. And an agent never moves a card to Done, never cancels a card, and never invents a column.
The Skills
Every [AI] column is served by one skill, and the stage number in the column name is the number in the skill’s name: {1} is 1-grill-card, {2} is 2-autopilot, {3} is 3-review-pr and 3-resolve-review, {4} is 4-dev-test. A skill does its work while the card sits in its column, and finishes by moving the card to the next one.
grill-card: resolve the design before any code is written. It reads the card, analyzes it against the codebase, and then interviews me until every open question is resolved. This matters because the agent is allowed to challenge and clarify the task before implementation.
The resolved technical details are written back onto the card, and the card moves to Ready. From that point the next agent needs nothing but the card.
Keeping grilling separate from implementation means a card can come out of it changed, or cancelled, before any code exists. Autopilot only ever starts from a card that reached Ready.
The idea is not mine. grill-card is a variant of the original grill-me skill by Matt Pocock, which is four sentences long:
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree resolving dependencies between decisions one by one. If a question can be answered by exploring the codebase, explore the codebase instead. For each question, provide your recommended answer.
My variant keeps that interview exactly as it is, but seeds it from a card instead of a loose plan and writes the outcome back onto that card.
autopilot: implement the card, end to end. It cuts a fresh branch from the server’s main in its own git worktree, makes the change, adds tests where needed, runs the related tests, commits, pushes, opens a PR and adds a changelog entry.
review-pr: review one PR against its card, read-only. It fetches the diff and the linked card, checks that the PR covers the card’s action list and follows the project conventions, and posts one structured GitHub review: a summary plus inline comments on exact lines. It fixes nothing.
resolve-review: fix what the review found. The other half of the same stage. It works through the unresolved review threads one by one: analyzes each, applies the fix, commits, pushes, and resolves the thread.
The split means the findings exist as review threads on the PR before anything acts on them, where I can read them too. resolve-review then takes those threads as its input, one at a time.
One detail between those two skills deserves its own paragraph, because it drastically sped up my work. CI is configured to skip pull requests while they are drafts, on purpose. Autopilot opens every PR as a draft, and the PR stays a draft through the review and through all the fixes. Only resolve-review flips it to ready, exactly once, on the fully fixed code.
The result is one full CI run per card, on the final state, instead of one run when the PR opens and another after the fixes. No extra infrastructure is involved: it is GitHub’s own draft flag, used as a switch for when CI is allowed to spend time.
dev-test: test the merged change on the deployed app. It runs after the merge, while the card is still in the PR column. It opens a browser and tests the card’s feature on the DEV environment; currently that is Claude driving Chrome and clicking through the application. Only if every planned flow passes does it move the card to Testing, where a human takes over.
Not All Tasks Are the Same
How closely a human has to look depends entirely on the task, and tasks are not equal.
It is one thing to change a database schema, to pick a partition key in a NoSQL store, or to make an architectural decision about, say, the shape of the project. Those decisions are expensive to get wrong and hard to undo, and they deserve a human who reads every line, asks why, and is prepared to say no at the PR.
It is something else entirely with the other 95+% of tasks: cosmetic changes, work modeled on something that is already done, one more variation of an existing pattern. There the design was settled long ago, the agent is following an example, and the human check can be proportionally light.
The flow is the same for both. What changes is how much of the human’s attention each step gets, and deciding that is the human’s job.
Orchestration: One Card Deep, or One Stage Wide
The stage skills do the work. Two more kinds of skills decide how much of it runs at once.
Deep: the pipeline skill. It follows one card through stage after stage until it reaches a human gate.
It starts by detecting which column the card is sitting in, and enters the chain at that stage. A card does not have to begin at Grilling.
From there it chains. When a stage completes, the next stage’s skill runs. The pipeline never reimplements a stage: it delegates each one to that stage’s own skill.
At the merge it stops and waits for my word. Only then does it continue into the DEV test.
Wide: the queue skills. Each stage has one. It takes one column and processes all N eligible cards in it before anything advances.
This is what I reach for when I, as the ultimate orchestrator, want something done in bulk. The Ready queue, for example, starts one background agent per card. Each runs the full autopilot skill in its own worktree, with at most three in flight at a time.
Grilling is the clearest case for going wide. It is the one AI stage that requires my input, so it makes complete sense to do just that step, for N cards, in one sitting. The codebase analysis for every card runs in parallel in the background, while the interview itself is strictly sequential, one card at a time, because there is only one of me to answer.
What the Human Still Does
The agents do most of the work. They do not make the decisions. At every point where something has to be decided, the flow stops and waits for a human.
- Backlog. A human decides what enters the flow at all. Agents may add cards to Backlog, but nothing leaves it on its own. We can tell an agent to do the moving for us when that makes sense; the decision is still ours.
- Grilling. A human answers the questions. This is where the task is actually understood, and it is completely valid for a grilling session to end with the conclusion that the task should not be done at all. A cancelled card is a good outcome, not a failed one: it cost one conversation instead of one implementation.
- PR. A human approves the merge. No agent merges anything, no matter how green the PR is. And it is just as valid to get all the way to a finished PR and decide, at that point, that it does not go in.
- Testing. A human tests the result by hand.
That is also why the whole thing lives on a Kanban board, and why I insist on it. A Kanban board is, before anything else, a visual tool. The point is not only that a machine can follow the process, but that a human can see all of it: every task, the state it is in, and what it is waiting for, without asking any agent anything.
Additional Columns, and Why the Board Runs Right to Left
A classic Kanban board runs left to right, with done on the far right. This one is mirrored: Done is on the far left, and a card travels towards it from the right.
The reason is what sits on the other side. To the right of Backlog there can be N additional columns that are not part of the flow at all: a Blocked column, a column per feature holding N cards each, and whatever else is needed. These are things I will work on, but not yet. No skill serves them, and no agent touches them.
kanban
backlog["Backlog [Human] {0}"]
blocked["Blocked"]
featurea["Feature A"]
featureb["Feature B"]
Everything to the right of Backlog is outside the flow.
With Done pinned to the left edge, the flow has a fixed end and the board stays open on the right: a new column is simply added at the far right, and nothing in the flow shifts. A card enters the flow only when I move it into Backlog or Grilling. Until then it is just parked.
Where the Agents Live
Everything above is board and skills. The runtime, the place where the agents physically run, is the youngest layer of the workflow. At first it was nothing special: a plain terminal. Then Herdr, a generic agent runtime that I still use for everything outside Shockley. And now Wolfr, my own runtime, which knows the board and follows each card through the flow.
The order matters. The board and the skills worked before any dedicated runtime existed: most of the complexity lives in the workflow, not in the runtime. The runtime did not create the flow, it made the flow visible.
The board itself is currently Trello. The agents reach it through a Trello MCP server I wrote for this purpose, and Wolfr talks to the Trello API directly. That API drives me crazy, which is a large part of why the board is next in line to be replaced.
The tools themselves are private, and they will very likely stay that way. They are welded to the current state of one project. The ideas are not private, and they are what this series is for.
Conclusion
Everyone is building their own version of this. Mine is not clever. It is an ordinary development process, written down precisely enough that a machine can follow it.
The agents do the work between decisions. The human owns the decisions.
The Series
| Type | # | Post | Focus |
|---|---|---|---|
| Map | Shockley Flow (this post) | The board, the skills, the orchestration | |
| Prequel | Herdr: an Agent-First tmux | The generic runtime, and where it stops | |
| Part | 1 | Shockley Flow: Wolfr | A runtime that knows the card, the stage and the PR (coming) |
| Part | 2 | 156 Findings, Zero Opinions | An audit on top of the same board (coming) |
| Part | 3 | Replacing the board | (planned) |
| Part | 4 | The hardware under all of it | (planned) |