How an OSS Tool Matures in 9 Days: session-orchestrator in the Engine Room

TL;DR

session-orchestrator is an MIT-licensed open-source tool that turns ad-hoc AI sessions into a repeatable loop with verification gates: /plan through /session and /go to /close and /evolve. I use it every day on my own projects, and that daily self-use is exactly what drives its maturing. Within a window of 9 days, 18 sessions pushed the tool forward considerably: sharply grown test coverage, four supported runtimes, a bundle of hardening patterns. At the web3 hub vienna meetup on 2026-06-10 I demonstrated it live to a full room. This article explains how the loop works and why daily self-use is the fastest force for maturing a tool.

The Problem: AI Agents Drift Without a Process

Anyone who works with an AI coding agent on a real project knows the pattern: the first few tasks fly by, then the agent starts to drift. It invents functions that do not exist. It picks up patterns that were replaced three sessions ago. It makes the same mistake as last week because it remembers nothing. I wrote more about the mechanics of this drift and how a good harness catches it in Harness Design: Keeping AI Coding Agents Productive.

The obvious reaction is to prompt faster. The effective reaction is a process. That is exactly what session-orchestrator is: not a replacement for the coding agent, but a layer on top that decomposes every session into five typed waves with verification gates between them. The tool is a Claude Code plugin, MIT-licensed, and public at github.com/Kanevry/session-orchestrator. It is not an Anthropic product but a community plugin for solo developers and small teams.

This is about a tool that I use myself every day on my own repositories, and that anyone can install and read for free. Every line is plain-text Markdown plus a thin Node runtime. If something goes wrong, you can read every file and see what happened.

The Lifecycle: /plan, /session, /go, /close, /evolve

The core process is a sequence of five slash commands. They form the loop that turns an ad-hoc session into a repeatable flow:

/plan feature     # optional: clarify WHAT gets built first (PRD, requirements)
/session deep     # research + Q&A, then a wave plan
/go               # 5 typed waves with verification gates between them
/close            # verifies every task, commits cleanly, mirrors to GitHub
/evolve analyze   # extracts patterns from session history as a learning loop

Each command has a clearly bounded job:

• /plan. Runs before a session when the WHAT is still unclear. Produces a PRD or a retrospective. Optional: if you already have clear issues, you jump straight to /session.
• /session. Inspects git state, open issues, recent commits, SSOT freshness, and the memory of prior sessions. The result is a structured overview with a recommendation, not a wall of raw data. Then you agree on scope through a picker.
• /go. Executes. The work splits into five waves: Discovery (read-only), Impl-Core, Impl-Polish, Quality, Finalize. Agents work in parallel within a wave. Between waves a reviewer agent audits the output across eight dimensions, from implementation correctness through test coverage to OWASP security. Only findings above a confidence threshold reach me.
• /close. Verifies every planned task. The quality gates run full. Unfinished work automatically becomes carryover issues so nothing slips through. Files are staged individually, not via git add ., so parallel sessions cannot stomp each other.
• /evolve. Runs deliberately, not automatically. It analyses session history across runs, surfaces patterns that only become visible over time, and feeds them back as learning entries.

The prompts are the obvious part. The process around them is what separates an impressive first day from a productive hundredth.

The reason for the wave structure is not aesthetics. Discovery first, so the implementation agents start with shared context. Impl-Core before Impl-Polish, so the architecture decisions land before the integrations. And the Quality wave runs a simplification pass over the AI-generated code before tests are written, otherwise the tests pin down exactly the patterns you wanted to clean up.

State survives crashes along the way. A state file records wave progress, mission status, and deviations. If a session is interrupted, the next /session invocation offers to resume from the last completed wave instead of starting over. And the hooks enforce rather than merely warn: a pre-bash guard blocks destructive shell commands like a hard reset or a force-push by firm rules, in the main session as well as in the parallel sub-agent waves.

What 18 Sessions in 9 Days Made of It

This is where it gets interesting. Over a window of 9 days, 18 sessions ran on the tool itself, with the tool itself. It orchestrates its own development. The result of that phase, rounded and stated timelessly because exact numbers drift daily:

Test coverage grew by over two thousand tests in this window, without a single breaking change and without a CI regression. Today the suite sits at close to ten thousand tests and runs on every commit. The count alone proves nothing: what matters is that these are deterministic gates that catch real regressions, not assert-true theatre that merely lights up green. That is not for its own sake: for a tool meant to safeguard other repositories, its own test coverage is the first credibility argument.

Four bundles of maturing stood out:

• Memory and personas. An agent-writable memory through which agents submit learning proposals at session end that I approve or discard. Plus a per-repository behavioural identity that records how I work and what the agent should watch for. So session 19 does not start from zero, but with the knowledge from sessions 1 through 18.
• Hardening patterns. Four mechanical hardenings: a cross-process write lock on the state file, so parallel sessions do not break each other. A hook that enforces reading issue templates before an issue is created. A check against package names hallucinated by the AI. And a bounded auto-fix loop that retries after a failed quality gate with a diagnostics bundle.
• Persona panel. A skill that lets several personas judge a file or output in parallel, such as domain experts, buyer personas, or compliance reviewers. Three voting modes, from majority quorum to hard-gate threshold. I actually use this same panel to have blog drafts like this one reviewed through different reader lenses.
• harness-audit. A skill that checks your own repository against Anthropic's best practices for large codebases and emits a rubric score: layered instruction files, code-intelligence wiring, lean root files. So you can run the tool on yourself and on other people's repositories.

Today the tool covers four runtimes: Claude Code, Codex CLI, Cursor, and Pi. On top of that come hooks that enforce scope, block destructive commands, and capture telemetry. I deliberately do not list the exact count of skills and commands here, because it drifts daily anyway and a parade of such numbers says nothing about the substance.

Why Daily Self-Use Is the Fastest Maturing

The decisive factor is not the number of sessions, but that they are real sessions on real projects. I build my own things with the tool, and every time something rubs, the friction becomes the next feature.

A practical example: one day it surfaced that eight CI pipelines were silently red while the local tests reported green. Local green is simply no proof of CI green. The consequence was not a note in the backlog, but a firm rule: at session start, CI status is the source of truth, not the local test run. Today the tool renders a warning banner at start when CI is red on the current head. That is how maturing happens: a mistake that once hurt becomes the gate that never lets it through again.

The same principle applies to security. A pre-commit hook scans staged changes for secrets and for private paths before a commit even comes together, because that exact gap slipped through several times before. No magic, just the lesson from concrete pain, cast into code.

This way of working is also the proof that counts. My own GitHub profile with its daily open-source activity is more visible and more honest than any slide. If you want to know whether someone really builds with these methods every day, you look at the commit graph, not the LinkedIn profile.

From the Repository to the Stage: web3 hub vienna

On 2026-06-10 I demonstrated session-orchestrator live at the web3 hub vienna meetup, to a full room. Not a slide deck as the main act, but the running tool: the lifecycle from /plan through /session and /go to /close and /evolve on the big screen, on a real repository.

The part that landed best in the room was the install. Two slash commands in open Claude Code, read along on the open README:

/plugin marketplace add Kanevry/session-orchestrator
/plugin install session-orchestrator@kanevry

Then a one-time npm install in the plugin directory, restart, done. No cloud, no account, no hidden component. That is the point where the skepticism in the room flips: it is not a product with a sales path, but a piece of software you can try in two lines. The BitGN hackathon win I wrote about in First Place at the BitGN Hackathon in Vienna came up that evening only as a brief proof of the security focus.

Talks are a by-product for me, not the product. What I show on stage is the same thing I do in the repository the day before and the day after. That overlap is the whole trick: no demo theatre, just the real state of the work.

From Tool to Method

A tool like session-orchestrator is more than its commands. It is a method cast into code: why execution runs in waves, why every wave ends at a verification gate, how to build an autonomous loop that finishes reliably. The same is true for the other tools that grew out of the same practice, such as the path from an open-source experiment to a production-ready agent that I described in From OpenClaw to Hermes Agent.

If you want to not just install the 5-wave workflow but understand and build it yourself, the method behind it is laid out: I teach it step by step in the course Multi-Agent Orchestration in Practice on agenticbuilders.at, that is, when parallelism is worth the effort, how to brief subagents cleanly, and how real failures become firm gates. And if you want a look at the raw data: under Resources you will find the "numbers from the engine room", drawn from this very tool. The plugin itself stays free and MIT-licensed. The courses are for going deeper, not a requirement for using it.

If you would rather have this method applied directly to a concrete project: I deliberately work with only one or two clients at a time so the substance holds. Contact is the direct route.

Conclusion

What matters about session-orchestrator is not the feature list, but the maturing mechanics behind it:

1. A process beats faster prompts. The lifecycle from /plan to /evolve turns ad-hoc sessions into a repeatable loop with verification gates.
2. Self-use is the fastest maturing. 18 sessions in 9 days, each on real code: every friction became the next feature, every mistake became a gate.
3. Proof beats claims. A public MIT repository, a daily commit graph, and an install in two lines are more honest than any slide.

AI is a tool here too: powerful, but not magical. What makes it productive is the system around it and the discipline to use it yourself every day.