The JSM Engineering Workflow Your
Agent has to Follow
From vague idea to shipped, verified, documented code. The context lives in files in your repo, not in a chat session.
One skill per phase. Run only the ones a change needs.
A bug goes straight to /debug. A small change can be /develop then /check verify. Nothing is a track you're locked onto.
Nine skills. Each one owns a phase, and the files that phase produces.
Context in a chat is a single point of failure.
A chat can end, a session can be cleared, a teammate can pull the branch. Everything the workflow knows is written into your repo, so the knowledge is still there because it was never trapped in a conversation.
Each skill suggests /clear at handoffs, so a fresh session reads from disk again and long chats do not pile up cost.
Pick how much checking a project earns. Override it per feature, anytime.
Depth just sets which checks are suggested after /develop. Skip any of them and mark a feature done when you say it is. The only thing asked at every depth: write the decision down.
Ownership is fixed. That's what keeps the files from turning into mush.
Only /architect writes the content of a spec. Only /develop moves its status line. No skill rewrites your prose.
Three starting points. Same loop after that.
One idea, followed all the way to shipped.
A small app where people sign in and keep their own to-do list. Brand new project, so it touches almost every stage, and every question the workflow asks along the way.
Read the full walkthroughWhat it will not do.
The limits matter as much as the features.
One command. Then commit the folder and your team has the workflow.
Works on any Agent Skills client: Claude Code, Cursor, Codex, Gemini CLI and more. Each skill's instructions live in its SKILL.md, which is what every client reads.
Frequently Asked Questions
No. You run only the ones a change needs. A tiny change can be just /develop and then /check verify. A bug is just /debug.
If a real decision is missing, /develop stops and offers three ways forward: decide it first in /architect, build directly if you judge there is nothing to decide, or skip for now, which records the assumption as an Assumed spec and flags the feature until /architect confirms it.
A long chat costs more and drifts. Because the work is saved in files, a fresh session reads the current state from disk and continues cleanly, so clearing loses nothing.
If docs/ is a live documentation site, the workflow writes its files to a .workflow/ folder instead, so they do not ship with your site.
Yes. The style you pick in /scope is the project default, and any single feature can override it when that feature is better built a different way.
Yes, that is the point of keeping state in files. Before it changes anything, /develop warns you if your branch is behind the shared branch, if you have uncommitted work in the area it is about to touch, or if a teammate looks to be partway through the same feature. Warnings, not walls.