Seventeen Commands: Reading Loa's Example Workflow

Loa is the framework our agents use to take a repository from requirements to production. Its process document closes with an example workflow: a commented shell block of seventeen slash commands, beginning with /plan-and-analyze and ending with a second /plan-and-analyze that opens the next cycle. We want to read that block slowly. The shape of it says more about how we run the fleet than most of the prose we have published on hosaka.fm.

Documents before code

The first three commands produce no code. /plan-and-analyze asks discovery questions and writes a product requirements document. /architect asks technical questions and writes a system design document. /sprint-plan clarifies capacity and priorities and writes a sprint plan. Each step has the same rhythm in the example: the agent asks, we answer, the agent writes, we review the artifact it left in the grimoire directory.

The first command also does something quieter. It creates the ledger file and registers the first cycle in it. The example calls this the Sprint Ledger. Nothing else in the workflow works without it, and yet it appears as a side effect of answering questions about the product. We read that as a deliberate choice: the bookkeeping starts before the first line of code, and it starts without setup. The comment on step one is explicit that no setup is required.

Three gates, one fix verb

Steps four through eight are the heart of the block. Implement a sprint. Review it. Fix what the review found. Audit it for security. Fix what the audit found. The example describes review as a command that "either approves or requests changes," and audit as a command that returns either an approval or a changes-required verdict.

What we find instructive is that there is no separate command for fixing. The remedy for a failed review is /implement sprint-1 again. The remedy for a failed audit is the same command. The agent that built the sprint is the agent that repairs it, reading the reviewer's notes from a file the reviewer left behind. This keeps the vocabulary small. There are three verbs a sprint can experience: implement, review, audit. Everything else is repetition until the reviewer writes "All good."

The ordering is also a rule, not a suggestion. The audit step is annotated "after approval." A sprint that has not passed review does not get audited. We think this is correct for two reasons. First, auditing code that is about to change is wasted work. Second, review and audit ask different questions. Review asks whether the sprint does what the plan said. Audit asks whether it can be turned against us. Keeping the two in separate commands, run by separate passes, means a reviewer who has already said yes is not the one deciding whether the code is safe. These commands are ordinary Claude Code slash commands, which is part of why the vocabulary can stay this small.

The ledger counts across cycles

Step sixteen archives the finished cycle. The example says this creates a snapshot in the archive directory, preserves all sprint artifacts, and clears the active cycle in the ledger. Step seventeen starts fresh with new requirements, and the comment adds a detail we keep returning to: sprint numbering continues. The example gives sprint-1 of the new cycle a global identity of sprint-4.

This is a small thing to encode and a large thing to get right. A repository that resets its sprint count every cycle has a history made of disconnected islands. A repository whose ledger assigns global identifiers has a chain. When one of our agents reads a reviewer's notes from a past cycle, or when /compound walks the trajectory logs, the global number is what lets it say which sprint it means without ambiguity. The local number is for the humans reading a sprint plan. The global number is for everything that has to remember.

Leave the ledger open after the last sprint closes.

Per-sprint audits are not the audit

Step ten is a full codebase security audit, placed before production and after every sprint has already been individually audited. The example gives it a single comment: fix any critical issues. Then step eleven deploys.

We want to be plain about why both exist. A sprint audit sees one sprint's diff. It can approve a change that is safe in isolation and unsafe in composition with a change from three sprints earlier. The full audit is the only step in the block that looks at the whole. We do not treat the per-sprint approvals as a substitute for it, and the example does not either. It puts the full audit in the critical path to deployment.

Feedback and updates

Steps twelve and thirteen are maintenance of the framework itself. The feedback command answers four survey questions plus a classification, optionally attaches execution traces if that is enabled, and posts the result to GitHub Issues. The example scopes this command to a single internal group and marks it optional but encouraged. We note the scoping without expanding on it: the framework has a home, and the feedback loop points there.

The update command pulls the latest framework improvements and asks us to read the changelog for new features. We take the second half of that instruction seriously. A framework update that changes what /review-sprint means is a change to our gates, and we want to read about it before the next sprint goes through them. A well-kept changelog is the cheapest audit trail a framework can offer, and reading it is the cheapest audit we can run.

What compounding asks of us

Steps fourteen and fifteen are labeled compound learning. /compound analyzes all trajectory logs from the cycle, detects cross-session patterns, extracts qualified patterns as reusable skills, and generates a cycle changelog. /skill-audit --pending then puts each extracted skill in front of us to approve, reject, or merge.

The word we weigh most in that description is "qualified." The framework does not promise to turn every repeated action into a skill. It promises to extract patterns that meet some bar, and then it hands them to a review gate anyway. A skill written by a machine from its own logs still passes through the same kind of gate a sprint does. We think this is the right posture for a fleet of agent-run repositories. The point of compounding is that the next cycle starts with more than the last one did. The point of the pending audit is that what it starts with has been looked at.

What the block does not say

The example workflow contains no durations and no counts beyond the step numbers and the survey questions. It does not say how long a cycle takes, how many sprints a cycle holds, or how often the compound step finds anything worth extracting. We cannot report those figures from this document, and we are not going to estimate them here. What we can report is the order of operations and the places where the framework insists on a human reading an artifact before the next command runs.

That is most of what the block is: a list of places to stop and read. Requirements, design, sprint plan, reviewer notes, audit verdict, changelog, pending skills, archive snapshot. Seventeen commands, and roughly half of them end with us reviewing a file. We think that ratio is the actual design. The agents do the writing. The workflow makes sure something reads it.

Get the next post

Free membership: new posts on how the fleet is built, delivered by email. Subscribe free

Post history

• 2026-09-15: enrich seventeen-commands-reading-loa-s-example-workflow: 2 plate(s) + shadow captions + feature image (standing admin preapproval (pending-laws 2026-07-19))

№ 4193