Home

A Scrum Master Made of Slash Commands

A few weeks ago I wrote about a Claude Code skill that runs Jesse James Garrett's Elements of User Experience as a structured pipeline. Feed it meeting notes, get out a Strategy, Scope, Structure, and Skeleton document. Clients said yes faster. The planning trap was solved.
Then the planning was done, and I had to actually build the thing.

From Plan to Ship

The current build is a private, invitation-only neighborhood community platform for a client's first paying customer. Eleven must-have features. Two human-approval funnels. Three messaging surfaces. A ten-to-seventeen week window to be first-customer-ready.
The plan is gorgeous. Four planes, fully resolved strategy questions, a sitemap, wireframes, build estimates with honest ranges. It is also useless as a build instrument.
A plan tells you what to ship. It does not tell you how to ship one feature at a time without skipping the boring parts — the design review, the accessibility check, the persona QA, the "did this actually solve the user's problem" gut check. The temptation to skip those is even higher on the build side than the planning side, because the planning artifacts feel like a license to just start typing.
Half-done features are how betas slip.

What I Built Instead

A PROCESS.md at the project root, four slash commands, and four custom agents. Together they form a one-feature-at-a-time loop that runs the same way every time, until the build is done.
The lifecycle is one outer command and three inner ones:
/scrum-master plans/<project>/

loop:
  /feature-start "<feature>" plans/<project>/
  /feature-review
  human ✅ on the PR
  /feature-complete "<feature>" plans/<project>/
end
/feature-start compiles the feature ticket — pulling the relevant slices out of all four JJG documents into a single self-contained markdown file. It checks dependencies (you can't start "1-on-1 Direct Messaging" before "Private Member Directory" is done). It refuses to begin if any blocking open question is unresolved, and surfaces the unanswered ones so the user decides before code is written. Then it creates the branch and runs /rails-plan.
/feature-review runs the agent battery in parallel against the open PR: design review, security review, Rails architecture review, accessibility check, SEO review (only if the feature is public-facing), and — the part I'm most proud of — a UX session driven by persona agents.

The Personas

Three persona agents drive the dev environment via Chrome MCP before the human sees the feature:
  • The Platform Admin — the founder. Technical, time-poor, zero patience for ceremony. Reviews the application queue and reports friction in his own voice.
  • Pat Sullivan — a 58-year-old HOA board member running the first community. Moderate tech literacy. Cares about not embarrassing herself in front of her neighbors. Tests the Community Manager dashboard.
  • Dana Mitchell — a 42-year-old marketing manager who just moved in. Cautious about privacy. Won't tolerate two signup flows. Tests the resident experience.
Each persona has a written backstory, a priority list, and a reporting format. They drive their flows in dev, find real friction, and post a single PR comment in first-person voice. A product-strategist agent synthesizes their reports into one UX summary.
The human PR reviewer's job becomes judgment — not nit-picking. The agents already caught the nits.

Closing the Loop

/feature-complete runs after the human approves and the PR merges. It marks the feature ✅ Completed: with a UTC timestamp directly in 02-scope.md, appends a one-line entry to the CHANGELOG.md, and drafts a plain-English email to the CEO explaining what shipped and how to test it. The email is a Gmail draft — not sent automatically. The user reads it, edits if needed, and sends.
Then /scrum-master picks the next eligible feature and the loop continues.

Why This Works

The same discipline that made the JJG pipeline work on the planning side makes this loop work on the build side: an opinionated, structured process that refuses to skip steps. Claude Code is happy to generate code at superhuman speed. The slash commands and agents force it to do that inside a frame that produces shippable, reviewed features instead of a pile of half-finished branches.
The plan tells you what to ship. The loop ships it.

What's in the Repo

Everything lives in the project repository — PROCESS.md at the root, .claude/commands/feature-start.md, feature-review.md, feature-complete.md, and scrum-master.md. The persona agents and the copy writer live in .claude/agents/. None of it is a gem, a service, or a subscription. It's just markdown files Claude Code already knows how to read.
If you're building anything bigger than a weekend project with Claude Code and you want a loop that keeps the human in the right role, email me at jonathan@rubygrowthlabs.com with the subject "Build Loop" — tell me what you're shipping.