The repo sat there untouched until last month. I picked it back up because of Claude Code, I wanted to see how fast coding can become, plus I’d still use the app so it’s a win.

Well, what I expected was faster coding but what I got was a different way of working entirely.

I believe most devs start using AI coding tools the same way: excited to try it out and eager to jump into writing code with it. What I experienced is — describe a vague feature, generate code that’s almost right, iterate in circles, accumulate a mess.

Vague input = vague output.

The fix is a planning workflow. Here’s the one I use now.

The loop that changed how I build features

Three steps, in order: /grill-me, then /to-prd, then /to-issues. All three are skills built by Matt Pocock and published at github.com/mattpocock/skills.

Skills are slash commands that extend Claude Code’s default behavior. Install them in a few minutes, and they’re available in every session.

The loop: describe a feature roughly, run it through /grill-me until it's clear, turn the output into a PRD with /to-prd, break the PRD into issues with /to-issues, then let Claude Code work those issues one by one.

Simple in principle and very different in practice from just typing “build me a recommendations feature.”

/grill-me: stop coding before you know what you’re building

I’ll write out a rough feature description, drop it into Claude Code, and run /grill-me. Claude doesn't build anything at this point, it interrogates me about the idea.

For the recommendations engine, I started with something along these lines: “I want users to rate movies they’ve seen and get personalized recommendations based on those ratings.”

That was the rough direction.

It asked whether I was using collaborative filtering or content-based recommendations. What happens when two users in a couple have opposite tastes? What do I show a new user with no ratings history yet? Do old ratings carry the same weight as recent ones? What’s the fallback if the algorithm has nothing confident to return?

Each question comes with a recommended answer. You either accept or grill deeper. A few I pushed back on, which forced me to say why. And other recommendations were perfect.

The moment I have to articulate why I disagree, I either change my mind or discover a real constraint I hadn’t surfaced.

The session took 20 minutes. Without it, I’d have coded the feature I thought I wanted, not the one I actually wanted.

Planning is still engineering. The tool changed. The thinking didn’t.

# ~/.claude/skills/grill-me/SKILL.md

Interview me relentlessly about every aspect of this plan until we reach
a shared understanding. Walk down each branch of the design tree, resolving
dependencies between decisions one-by-one. For each question, provide your
recommended answer.

Ask the questions one at a time.

If a question can be answered by exploring the codebase, explore the
codebase instead.

/to-prd: write the spec before you write the code

Once the grilling is done, /to-prd synthesizes everything into a spec. You could start with this skill right away, it would grill you, but in my workflow we already have a good grasp on the feature and its behavior — so no re-interviewing. It works from what's already in the conversation.

For the recommendations feature, the PRD covered: ratings schema (user, movie ID, score, timestamp), algorithm choice (content-based to start, cold-start fallback for new users), caching strategy, API endpoint contract, and frontend data shape.

I don’t use the PRD as a document to share. I use it as a forcing function.

If a feature can’t be turned into a PRD, it isn’t clear enough yet. That’s information worth having before a single line of code gets written.

When Claude Code drifts during development, I point back at the PRD. When an issue is ambiguous, the PRD resolves it. Those corrections take seconds instead of judgment calls mid-session.

# ~/.claude/skills/to-prd/SKILL.md

This skill takes the current conversation context and codebase understanding
and produces a PRD. Do NOT interview the user - just synthesize what you
already know.

Process:

1. Explore the repo to understand the current state of the codebase.
   Use the project's domain glossary vocabulary throughout the PRD,
   and respect any ADRs in the area you're touching.

2. Sketch out the major modules you will need to build or modify.
   Actively look for opportunities to extract deep modules that can
   be tested in isolation. A deep module encapsulates a lot of
   functionality in a simple, testable interface which rarely changes.

   Check with the user that these modules match their expectations.
   Check with the user which modules they want tests written for.

3. Write the PRD using this template:

   ## Problem Statement
   The problem that the user is facing, from the user's perspective.

   ## Solution
   The solution to the problem, from the user's perspective.

   ## User Stories
   A long, numbered list:
   As an <actor>, I want <feature>, so that <benefit>

   ## Implementation Decisions
   Modules, interfaces, schema changes, API contracts, architectural
   decisions. No file paths or code snippets - they go stale fast.

   ## Testing Decisions
   What makes a good test. Which modules will be tested.

   ## Out of Scope
   What is explicitly not being built.

   ## Further Notes
   Any remaining context.

/to-issues: turn the spec into a sprint

The PRD goes in, a list of independently workable tickets comes out.

Each issue is a vertical slice through all integration layers, not a horizontal layer slice. So instead of “write the database schema” as one issue and “write the API” as another, each slice is a thin but complete path from schema to API to UI. You can demo or verify it on its own.

Each issue also gets tagged as AFK (Claude Code can implement and merge without human input) or HITL (needs a human decision point, like an architectural choice or a design review).

For the recommendations engine, I got eight issues:

1. Database schema for movie ratings
2. Ratings API (create, update, delete)
3. Recommendation algorithm implementation
4. Caching layer for recommendations
5. Recommendations API endpoint
6. Frontend hook for fetching recommendations
7. RecommendationCard UI component
8. Test suite for the algorithm

That’s a sprint.

I didn’t design that breakdown. /to-issues did and it worked really well.

# ~/.claude/skills/to-issues/SKILL.md

Break the plan into tracer bullet issues. Each issue is a thin vertical
slice that cuts through ALL integration layers end-to-end, NOT a horizontal
slice of one layer.

- Each slice delivers a narrow but COMPLETE path through every layer
  (schema, API, UI, tests)
- A completed slice is demoable or verifiable on its own
- Prefer many thin slices over few thick ones

Slices may be AFK or HITL.

AFK: can be implemented and merged without human interaction.

HITL: requires a human decision point (architectural choice, design review).
Prefer AFK over HITL where possible.

Also, you could simply track issues on GitHub, you can create a project for the repo, create a Kanban board and track progress easily.

Claude Code does the rest of the work

Development becomes mechanical. Pick an issue, hand it to Claude, review the output, commit, move to the next one.

The issue gives Claude a bounded scope. The PRD gives it the wider context. It rarely goes in the wrong direction, and when it does, the fix is pointing at the relevant section in the PRD.

The recommendations engine took one focused weekend.

The codebase it produced is clean enough that I’m building on top of it now, not refactoring before I can continue. In 2021, the same feature took two months of weekend evenings, and I’d have wanted to rewrite it before shipping anyway.

If you have a side project sitting half-finished, try this on the next feature. The planning overhead is front-loaded and it compounds. By the third feature, the loop is default.

Why this works when vibe coding doesn’t

The pattern I see most often, and used to follow: describe a vague feature, ask Claude to build it, get output that’s close but not right, iterate in conversation, accumulate spaghetti, give up or start over.

The fix isn’t about a better prompt.

/grill-me handles the ambiguity. /to-prd captures the output. /to-issues makes it executable. By the time code is being written, the complex decisions are already made. Claude is working on implementation and won't make blind decisions.

The reason I pasted the skills above is to show that these three skills aren’t magic. They enforce the same process a senior developer uses before starting any non-trivial feature: ask hard questions, write down the answers, break the work into pieces.

The difference is the whole loop takes 30–40 minutes, not a day of planning meetings.

The movies app sat in a repo for five years. Two more sessions and it’s shipped.

Getting started takes 5 minutes

Install the skills from Matt Pocock’s repo at github.com/mattpocock/skills. The install instructions are in the README.

Once installed:

1. Start a Claude Code session in your project
2. Describe a feature you want to build
3. Run /grill-me and answer the questions it asks
4. Run /to-prd to generate the spec from the conversation
5. Run /to-issues to break the spec into tickets
6. Work the issues with Claude Code one by one

The first time through takes longer because the questions are unfamiliar. By the third feature, it’s the default.