Changing the Economics of Quality with Claude Code-Generated User Stories

Last month I wrote that skills are the most underrated feature in agentic AI. Everything I’ve built since has made me more convinced. The latest example: a user-story-creator skill that I used to write a user story in the OneBusAway vehicle-positions project.

To start, I used Claude’s official /skill-creator to scaffold the user-story-creator. It generates the SKILL.md frontmatter, suggests which tools to allow, and gives you a working structure in minutes, while providing helpful guard rails. For example, it nudged me toward AskUserQuestion for clarification instead of having the agent guess, and reminded me to declare allowed-tools explicitly, small things that prevent runaway behavior from an unconstrained agent. The scaffolding got me to a working first draft fast, skipping the boilerplate and getting straight to the parts that required domain knowledge and human intuition.

After the initial build, the skill worked but was verbose and had redundant logic. Running /simplify against it collapsed duplicated instruction blocks, tightened the step definitions, and caught places where I’d over-specified things the model could infer from context. The skill got shorter and more reliable at the same time. I ran /simplify multiple times during development: after adding the agent integration, after refining the template, after each structural change. It’s become a reflexive part of my skill-building workflow.

The user-story-creator doesn’t just write a story. Before presenting the draft, it launches two sub-agents in parallel: a Security Engineer and a Product Manager. Each has its own instruction file with role-specific review criteria. For issue #36, the Security Engineer flagged that the POST /api/v1/locations endpoint has no auth middleware, a critical blocker I knew about but hadn’t thought to surface in the story itself. It produced a full STRIDE threat table and data classification matrix. The PM agent caught that Android 11+ requires a two-step background location permission flow, which would have been a real app-review rejection risk if missed.

These agents ran concurrently, each taking about a minute, and their findings were merged back into the story automatically. Another /simplify run surfaced a key design decision: make the agents optional. The skill includes skip conditions. Don’t run a security review on a cosmetic change, don’t run PM review on a config tweak. Knowing when not to run is as important as having the capability.

Economics of Quality

I will never learn to write Mermaid syntax for user flow diagrams. I know they’re valuable for my developers and eliminate confusion down the road, but I’m just not going to make them. The skill produces them automatically. Issue #36 has both a flowchart (the full user journey from login through shift start/stop with error branching) and a sequence diagram (the 10-second location reporting loop between the Android app, FusedLocationProvider, and the Go server). They render natively in GitHub.

A contributor picking up this issue can understand the expected interaction pattern in seconds. The sequence diagram makes the token refresh flow unambiguous in a way that prose acceptance criteria alone don’t. This is what makes the difference between a story implemented correctly the first time and one that takes three rounds of review.

This is what I mean when I say skills change the economics of quality. The cost of producing these diagrams dropped to zero, so now they exist.

I typed /user-story-creator with a two-sentence description and a path to an HTML file containing three mockups. The skill read the mockups, explored the Go codebase, and asked me three targeted multiple-choice questions: setup scope, offline behavior, reporting interval. One round, no back-and-forth.

It drafted the story, launched the two review agents, merged their findings, and presented the result. I answered the five open questions it surfaced, it folded my answers in, and I said “create a github issue,” and it was done. The result: a thorough user story with 30 acceptance criteria, a STRIDE threat analysis, a SMART assessment, and two Mermaid diagrams, filed as a GitHub issue.

Total wall-clock time from invocation to filed issue: roughly ten minutes. The comparable human process (writing the story, drawing the diagrams, doing a security review, checking SMART criteria, filing it) would have been a half-day exercise, minimum, and it wouldn’t have had the diagrams.

The user-story-creator skill isn’t magic. It’s a structured procedure: input classification, codebase analysis, clarification, drafting, parallel review, iteration. Encoded so an agent can execute it reliably. Any experienced PM could describe this process on a whiteboard.

The difference is that a skill runs the process every time, completely, without cutting corners because it’s Friday afternoon. It asks the security questions you’d skip. It draws the diagrams you wouldn’t bother with. It surfaces the Android permission edge case you’d forget.

That’s the argument for skills: not that they replace judgment, but that they apply it consistently. And consistency, in product work, is the thing that’s actually hard.