Workflows
Knowing things is not the hard part.
Knowing the order is.
Every trade has a sequence: what gets settled before anyone builds, what nobody touches until the numbers agree, what has to pass before it goes out. It takes a year to learn, it lives in whoever learned it, and it leaves when they do. A workflow is that sequence written down once — and walked by the agent you already pay for.
A step carries four things
Together they are the difference between an instruction an agent interprets and one it can be held to.
What to read before writing anything — material that sat an exam and has a score, not something remembered from training.
What to ask it, in that brain's own words. Those are the words it can actually find.
What always and never holds while the step runs. "Never hand-edit a generated file." They survive after the question is answered.
How the agent knows the step is done. A command that exits zero, not a feeling.
Routes worth writing
Shapes, not listings — the published ones are further down. The test is simple: if your team repeats a sequence and argues about it, that sequence is a route.
Ship a slot to a platform that reviews it
spec → math → books → front end → approval
Move a framework major version without breaking a Friday
read the migration → inventory → codemod → tests → staged rollout
Take a prototype to something with saves and settings
save format → versioning → scene flow → input → build
Onboard a codebase nobody here wrote
map → conventions → run it → first change → write back
Write documentation an agent can actually follow
audit → shape → examples → verify → publish
Turn a week of reading into a brief somebody can act on
sources → extract → contradictions → brief → review
A published route, drawn from itself
Not a screenshot — this is read from the route, so what you see is what your agent gets.
reads mozg/slot-design-presentation✓ the spec states RTP, volatility, max win and every feature, and the user has agreed to itreads mozg/stake-engine-math-sdk✓ run.py completes and the simulated RTP for every mode is within 0.1% of the spec's targetreads mozg/stake-engine-math-sdk✓ library/publish_files/ exists for every mode and its lookup tables reproduce the target RTPreads mozg/stake-engine-approval✓ every number in the math requirements page has a measured value from the simulation beside itreads mozg/stake-engine-rgs-api✓ a full round completes against the RGS and the same round replays identically from its bookreads mozg/stake-engine-web-sdk✓ every event kind present in the books is handled, and an unknown event fails loudly in developmentA Stake Engine slot game, end to end — 12 steps, with every prompt and rule
Your agent runs it. Nothing runs here.
/mozg:build handle/route — from Claude Code, Codex, Cursor, anything that speaks MCP.
A route names the brains it needs. Missing or unbought ones are named before any work starts, not at step nine.
A failing check sends the agent back a step. That is judgement at runtime, which no drawn arrow can express.
Which step found nothing, which check did not pass. The author then fixes the route from data rather than memory.
/mozg:build mozg/stake-engine-gameWhy this is a list and not a canvas of boxes
Visual builders are good at what they do — wiring services together, where every branch is known before it runs. A build is not that. Nobody can draw the arrow for "the RTP came out at 94.2%, go back two steps and reweight"; you can only write the check and let something with judgement decide. So a route here is an ordered list with a check on every step, and the judgement belongs to the agent walking it. The day real branches are needed, that is a graph — and a graph is a different product.
Published routes
Write down the order once.
Then it runs from anyone's terminal, on the same material, with the same checks — including the terminal of whoever joins next month.