Planning slows down when clarity has to be created from a blank page. Product owners, development managers, and solo developers may know the shape of the feature, but turning that shape into developer-ready requirements is slow, detailed work.
Product management teams were already under pressure to deliver a steady stream of ready stories in an agile world. AI increases that pressure. If development teams can move faster with agents, product management has to produce more clarity at a faster pace or become the bottleneck in delivery.
That is where AI is useful. It can take rough ideas, notes, existing documents, screenshots, stakeholder feedback, and half-formed thoughts and help turn them into a coherent feature definition. This is a big lift for product managers or anyone developing requirements. It is very often easier to read something, react to it, correct it, or refine it than it is to create the entire document from nothing.
I built a pipeline around that idea. Four AI skills, chained together, that take a product owner from “I have an idea for a feature” to “here are refined, developer-ready stories with acceptance criteria” in a single working session.
The inspiration did not come from AI. It came from years of eliciting requirements from customers and business stakeholders. I have held the business analyst role at a physical security products company, and I have worked with high-level executives through my own consulting business to identify the needs and wants behind IT projects. The pipeline is a structured version of that same work.
This does not replace planning. It makes planning faster. Alignment, priority, sequencing, and tradeoffs still require human judgment. What the pipeline replaces is blank-page drafting, repetitive requirements cleanup, and the first few rounds of “what did you mean by this?”
That matters even more when the work is AI-driven. Agents need context, acceptance criteria, validation rules, error states, and explicit constraints. The pipeline gets that information onto the page without slowing the development team down.
For solo developers, the pressure is different but the need is the same. When you’re both the PO and the developer, the temptation to skip planning and start coding is overwhelming. This pipeline makes the planning step fast enough that skipping it is harder to justify than doing it.
The Pipeline
The pipeline has four steps:
Feature Writer → Story Splitter → Story Writer → Story Prefinement
The point is not to automate product judgment. The point is to force the right questions onto the page before the work reaches development. By the end, the requirements are specific enough for AI agents to execute and clear enough that a developer could pick them up six months later and know exactly what to build.
Step 1: Feature Writer
The feature writer conducts a structured interview with the product owner. Not a blank page. Not “write me a requirements doc.” A guided conversation that asks the right questions in the right order.
It starts by identifying whether this is a UI feature, a backend feature, or both (full-stack). Then it branches:
For UI features, it walks through a screen inventory. For each screen: what’s the purpose, who can access it, what data appears, what actions can the user take, and where does each action lead? One screen at a time, conversational, no forms.
For backend features, it walks through resources and operations. What entity does this operate on? What operations are needed? Who calls it? What goes in, what comes out, what are the dependencies?
For full-stack features, it does both. UI first (what the user sees), then backend (what supports it).
After the happy path, it asks about non-happy paths. What happens when permissions are wrong? When inputs are invalid? When downstream services fail? When there’s no data to display?
The output is a structured feature document. Every feature covers the same ground: user experience, backend behavior, data, permissions, non-happy paths, and constraints.
Step 2: Story Splitter
The story splitter takes the feature document and decomposes it into individual stories. One story per user action. One story per CRUD operation. One story per backend operation.
This is a common failure point. Teams either create stories that are too big, covering multiple screens and operations in one story, or too granular, with a story for every button click. The splitter follows consistent rules:
For UI features: one story per CRUD verb per entity. Create, Read/List, Read/Detail, Update, and Delete are separate stories. Screens with collections and screens with detail views are separate stories.
For backend features: one story per operation, one per event, one per scheduled job, one per external integration.
For full-stack features: vertical slices. Each story covers the full stack for one user action. The form, the API call, the persistence, the response, and the user feedback are all one story. You don’t split UI and backend into separate stories because the backend should be built to serve exactly what the UI needs.
The splitter proposes the list, the PO reviews and adjusts, and then it creates each story one at a time through the story writer.
Step 3: Story Writer
The story writer takes each story from the splitter and runs a focused interview to fill in the details. It knows the feature context (passed from the splitter), so it doesn’t start from scratch. It pre-fills what it can and only asks about what’s missing.
For each story, it captures:
- Title that describes the deliverable, not the task (“Flagging a message for SMS responses” not “Add checkbox to form”)
- Description written from the user’s perspective, not the database schema
- CRUD verb alignment to ensure the story doesn’t accidentally cover multiple operations
- Input fields and data types for every UI element involved
- Validation rules for every input (what’s invalid, what error message appears, does it block the action)
- User feedback (success toasts, confirmation modals, redirects, exact message text)
- Acceptance criteria that are numbered, specific, and grouped with sub-points
The AC draft is generated from the interview answers. The PO reviews, edits, and approves. Then the story gets created in the tracking system and linked to the parent feature.
Step 4: Story Prefinement
After each story is written, the prefinement reviewer evaluates it against a quality framework. Prefinement is refinement before refinement: the process of running a story through a solo refinement session before it ever goes to the development team. This is the quality gate.
It scores each story across multiple dimensions:
- Title: Does it state the deliverable, not the task steps?
- Description: Does it describe the user journey, not the database changes?
- CRUD alignment: Is it one operation, or did scope creep in?
- INVEST criteria: Is it Independent, Negotiable, Valuable, Estimable, Small, Testable?
- Elements and inputs: Are all form fields identified with data types?
- Validation: Does every input have rules, error messages, and blocking behavior defined?
- Acceptance criteria: Are they numbered, specific, and comprehensive?
The output is a scorecard with specific findings and rewrite suggestions for anything that needs work. Not “this could be better.” Specific rewrites: “Try this instead: …”
Prefinement can also send work backward. If the reviewer finds that a story is too large, mixes multiple operations, or does not represent a clean vertical slice, the right answer is not to polish the bad story. The right answer is to send it back to the story splitter and reshape the work before developers ever see it.
The standard it holds to: a fully refined story could be parked for six months, pulled during planning, and developers would still know exactly what to build.
What This Speeds Up
Without this pipeline, a common planning cycle looks like this: the PO writes a vague story, the team spends a refinement meeting pulling missing details out of it, developers ask follow-up questions over the next few days, the PO updates the story, and then some of the real requirements still get discovered during development.
The pipeline moves much of that discovery earlier. The feature writer pulls out the core idea. The story splitter turns the feature into shippable slices. The story writer fills in the details. Prefinement catches gaps before the story reaches the team.
The timing depends on the size of the feature, but the shape of the work changes. A small feature can move from idea to developer-ready stories in a single focused session instead of several rounds of meetings, edits, and follow-up conversations. The point is not that every meeting disappears. The point is that meetings can be used for judgment and alignment instead of wordsmithing.
At a marketing services SaaS provider, this pipeline was used to define a new screen in one of our internal applications. The screen had dynamic states, error messages, error states, and validation rules that all needed to be explicit before development started. Those are exactly the details teams often struggle to write down when they are still developing agile and scrum-oriented product management habits.
Following the pipeline allowed the product management team to create one feature with four stories. Refinement for all four stories took under ten minutes because the basic requirements were already on the page. The feature was delivered in a single sprint because the team was not discovering basic requirements after implementation had already begun.
That is the value. The pipeline does not make the product decision for you. It lets more planning happen at a faster pace, so AI-driven work has the information it needs before implementation starts and the development team does not become the bottleneck for basic requirements cleanup.
For Solo Developers
If you’re a solo developer, this pipeline might be the single most valuable tool in your workflow.
When you’re both the PO and the developer, the planning step is the first thing that gets cut. You know what you want to build (you think), so you jump straight to coding. Or straight to prompting an AI agent.
The problem is that you usually do not know all the details yet. Edge cases, invalid input, error messages, empty states, permissions, and downstream failures often get discovered during development. When that happens, you solve them ad hoc, and the result is inconsistent.
Running through this pipeline forces you to think through everything before the first line of code. And because it’s conversational (the AI asks the questions), it surfaces gaps you wouldn’t have found on your own.
More importantly, the output is structured stories with acceptance criteria that your AI agent can execute precisely. The stories become the specification, and the agent has a target that is explicit enough to build against.
The Tools Are Open Source
I’ve published the complete skill set on GitHub. Each skill is a self-contained markdown file that you can use with Claude Code or adapt for other AI tools.
The pipeline supports Jira and Azure DevOps natively. It can create features and stories directly in your tracking system, link them together, and pass context from one skill to the next so the PO never has to repeat themselves.
The skills are designed to chain. Feature writer passes the feature document to story splitter. Story splitter passes story context to story writer. Story writer offers to invoke prefinement. Each handoff carries the full context, including the tracking system details, so the flow is seamless.
If you’re a product owner spending too much of the sprint turning intent into stories, this pipeline gives you a better first draft. If you’re a solo developer skipping the planning step, this makes it fast enough that you’ll actually do it.
Clearer requirements earlier create leverage. They give developers and AI agents a better target before implementation starts.
Receipts
- Open-source skills: The feature writer, story splitter, story writer, and prefinement skills are published in the ai_tools repository.
- Internal application screen: At a marketing services SaaS provider, the pipeline produced one feature with four stories for a new internal application screen. Refinement for all four stories took under ten minutes, and the feature was delivered in a single sprint.
- Requirements background: The pipeline is based on prior experience eliciting requirements as a business analyst at a physical security products company and through consulting work with executive stakeholders.
- Scope of claim: The pipeline accelerates drafting and refinement. It does not replace human planning around priority, sequencing, tradeoffs, and alignment. Its value is making AI-driven work better specified without slowing the development team down.