Seven Stages of Building a Feature with AI,Skills Over Prompts

Most teams using AI for code generation do the same thing. They write a long instruction,requirements, an example, maybe some constraints,and fire it off. Sometimes the output is good. More often it's 80% right but wrong in ways that are hard to spot and slow to fix. The team spends two days cleaning up what was supposed to save them three.

The issue isn't capability. It's that a prompt asks the AI to understand the problem, plan the approach, write the code, and verify the result all at once. You'd never hand a junior developer a requirements doc and say "come back when it's done." You'd talk through the problem first, sketch an approach, review it together, then let them build.

I've been building what I call skills,small, repeatable workflows that each handle one stage of development. Less like prompts, more like job descriptions. Each one defines the role, the inputs, what good output looks like, and where to hand off. Individually they're nothing special. Chained together, they change how the work gets done.

Let me make this concrete. Say a product manager asks for a notification system. Users should get an email when someone comments on their post. Sounds simple. It never is.

Stage 1: Research,read before you write. Before anything else, the AI reads. It explores the existing codebase,how does the app currently send emails? Is there already a notification model? What does the comment creation flow look like? This takes two minutes. It replaces the half-day a developer spends grepping through the codebase and piecing together how things connect.

Stage 2: Brainstorm: ask before you assume. "Send an email when someone comments" sounds straightforward until you start asking questions. What if someone gets 30 comments in ten minutes, do they get 30 emails? What about self-comments? What if the commenter deletes the comment before the email goes out? Rather than letting the AI guess, each answer gets captured in a structured decision document.

Stage 3: Plan,define the work before doing it. The brainstorm decisions feed into a planning step that produces concrete implementation. Specific files to create, which existing classes to modify, what the database migration looks like, what tests to write and what they should assert. It also calls out what's explicitly not in scope.

Stage 4: Review: challenge the plan before building from it. A review step reads the plan with sceptical eyes. Are there unstated assumptions? Missing edge cases? Say the review catches that the plan assumes every user has an email address, but the app supports OAuth sign-up where email is optional. A thirty-second catch that would have been a production bug report two weeks after launch.

Stage 5: Build,generate code from a clear brief. Now the AI writes code. By this point it has the codebase patterns from research, explicit decisions about every edge case, a reviewed implementation plan, and clear scope boundaries. Nothing is invented. Nothing is assumed.

Stage 6: Code review: automated quality gate. A code review step runs automatically. Convention violations. Missing error handling. A background job that doesn't handle the case where the user gets deleted between queueing and execution. This isn't a replacement for human review; it's a safety net that catches the mechanical stuff.

Stage 7: Capture,remember what you learned. After the feature ships, a capture step records what went well and what tripped the team up. The missing-email edge case becomes a documented pattern. The next feature benefits from everything learned building this one.

The full chain: Research → Brainstorm → Plan → Review → Build → Code Review → Capture. Each stage produces a visible artifact that the next stage consumes. Nothing gets thrown over a wall. Every handoff is explicit.

When the one-big-prompt approach produces bad code, you're staring at the output trying to figure out whether the problem is the requirements, the approach, or the implementation. Usually all three. With skills, you trace back. Bad code? Check the plan. Bad plan? Check the brainstorm decisions. Bad decisions? Check whether the research surfaced the right context. You debug the process, not the AI.

Where to start: pick your most repetitive development task. Write down the steps a senior developer follows when they do it well. Not the code; the thinking. Those steps are your skills. The skills get sharper with every build.