Why session-flow is a chain

The coding is the easy part of working with an agent in a terminal. What is hard is everything wrapped around it: deciding whether a piece of work is worth doing at all, cutting it into pieces small enough that one session can finish one of them, checking the result honestly rather than being told it went fine, and then shipping it. For a long time I did that by retyping roughly the same instructions in slightly different words, session after session, and getting slightly different behaviour each time. session-flow is what came out of writing those instructions down.

It is a Claude Code plugin, MIT licensed, at github.com/matshoppenbrouwers/session-flow: fifteen skills and six agents arranged as a chain. Work enters through a gatekeeper that triages incoming issues against the project's architecture docs and its stated product direction, passes through research and design, gets broken into session-sized tasks tagged with their dependencies, is dispatched to agents that run in parallel wherever the tags allow it, comes back for simplification, review and a security and liability audit, can be put through an evidence-based verification pass, and ends at a release. Alongside that sits a standing backlog: one line per task in SEQUENCE.md, each line linked to a breakdown detailed enough to hand an agent on its own, and each surviving the end of the session that produced it.

The thing I would defend hardest is that the chain is composable rather than mandatory. Every stage declares what it consumes, so you enter at whichever one your work is already ready for; an existing backlog gets /session-next, a plan you wrote yourself gets /session-task-planning, a bug gets /session-debug and nothing before it. Skipping a stage is a stated rule with a table behind it saying what "too small to need this" means for each one, which I think matters more than it sounds: an instruction like "when in doubt, run it" reads as caution to a person and produces a model that runs everything.

Fifteen skills sounds like a lot to carry into every session, and it would be if they were all loaded. A skill loads only when its description matches what you are actually asking for, so the standing cost is the metadata, around 1,700 tokens, with one or two skill bodies open in a typical session. That is what makes it reasonable to have a skill for backlog grooming that most weeks never fires.

The same instinct explains where the judgment sits. Every stage pauses at its decision points and asks, and the review agents report every finding they can tie to a file and a line, labelled high, medium or low confidence, rather than filtering to what they are sure about. I used to instruct them the other way, because telling a colleague to be selective is sound advice; the colleague keeps the judgment that makes it sound, and the model keeps only the disposition to say less. So the filtering moved up a level, to the skill that called the agent, and from there to me. Verification works on the same principle: it cites a file and line or a command's output for every claim it makes, and treats missing evidence as a failure rather than as probably fine.

I should bound this. It is one person's working habits made explicit, and I have not measured it against the alternative of just asking an agent for what I want each time; my evidence is that I stopped rewriting the same instructions, which is a weaker claim than it looks. If someone showed me that the gates cost more attention than the mistakes they catch, I would cut gates rather than defend them.