I lost a Sunday to a Laravel feature that should have taken four hours. The code was not hard. I lost the day because I let Claude Code start writing before I had answered the questions that shaped the design. By the second prompt the agent had assumed a one-to-many relationship that needed to be many-to-many, generated thirty tests against the wrong contract, and was confidently refactoring deeper into the wrong abstraction. By dinner I had rolled the branch back to its first commit.
That Sunday taught me what engineering with AI agents actually is: it is not prompting better, it is moving your effort earlier. The agent is a phenomenal executor and a mediocre requirements analyst. So I run every non-trivial feature through five skills, in order, and each one exists as a real folder in my ~/.claude/skills directory right now. I installed the suite from Matt Pocock's skill collection, then edited each file until it matched how I ship. Here is the pipeline, with the parts of each skill file that do the actual work.
The Mental Model: Ambiguity Is the Expensive Part
Every failed agent session I have ever had traces back to the same root cause: ambiguity that survived until code generation. A human junior developer hits ambiguity and asks. An agent hits ambiguity and picks, silently, at machine speed, and then builds fifty consistent decisions on top of the wrong pick.
So the pipeline is arranged by a single principle: kill ambiguity in the cheapest possible phase. A wrong assumption costs one sentence to fix during an interview, one paragraph in a PRD, one issue in a tracker, and an entire branch after implementation.
Skill 1: grill-me — Interview the Idea Before Any Code
grill-me instructs the agent to interview me relentlessly about a plan, one question at a time, resolving each branch of the decision tree with a recommended answer attached to every question. The instruction in my SKILL.md that earns its keep:
If a question can be answered by exploring the codebase, explore the codebase instead.
In practice this means the agent asks me five questions instead of twenty, because the other fifteen were answerable from the repo. The five it does ask are precisely the ones I was avoiding. On the many-to-many disaster above, question three of a grill session would have surfaced the relationship in ninety seconds.
A grill session on a mid-size feature takes me 10 to 20 minutes. It has never once been the wrong trade.
Skill 2: to-prd — Freeze the Understanding While It's Warm
The moment grilling ends, the shared understanding exists only in one session's context window, which is the most perishable storage on earth. to-prd converts it into a durable document, and the skill file explicitly says: do NOT interview the user, just synthesize what you already know. The grilling already happened; a second interrogation would be ceremony.
Two details in my version matter. First, the skill pushes toward deep modules, lots of functionality behind a small, stable interface, and makes the agent check the proposed module boundaries with me before writing. Second, it publishes the finished PRD straight to the project issue tracker with a ready-for-agent label. That label is the handoff contract: any session, on any machine, including a parallel agent that has never seen the conversation, can pick the work up cold. That property is what makes running multiple agents in parallel feasible at all.
Skill 3: to-issues — Vertical Slices, Not Horizontal Layers
to-issues breaks the PRD into issues, and the only rule that matters is the slicing direction. Horizontal slices ("build the migration," "build the service layer," "build the UI") are how agents drift, because each layer forces the agent to invent the contract of the layer above it. Vertical slices ("a user can archive a post and see it vanish from the index") pin every layer to an observable behavior.
The first slice is always a tracer bullet: the thinnest possible path through every layer of the feature. It flushes out integration surprises while the diff is still small enough to read in one sitting.
Skill 4: tdd — Red, Green, and the Refactor Nobody Wants to Do
My tdd skill opens with philosophy rather than mechanics, and the philosophy is the part agents need most: tests verify behavior through public interfaces, not implementation details. If a refactor breaks a test but behavior did not change, the test was wrong.
The skill's most important section is an anti-pattern warning in bold: do not write all tests first and then all implementation. That is horizontal slicing again, smuggled in through the test suite, and it is the default behavior of every model I have used, because emitting thirty tests in one response looks like progress. Real red-green-refactor is one failing test, minimal code to green, refactor, repeat. It is slower per minute and dramatically faster per feature.
The refactor step is where agents are weakest. Left alone, a model treats green tests as done. Mine only refactors reliably because the skill demands it as a named phase, and because the whole loop echoes the plan-first discipline I laid out in the Claude Code strategy most developers miss.
Skill 5: improve-codebase-architecture — When the Pipeline Loops Back
After three or four features land in the same area, entropy wins locally: shallow modules accumulate, near-duplicate helpers appear, an interface that made sense for slice one is wrong for slice nine. improve-codebase-architecture is the skill I run on that moment. It surveys the area, identifies shallow modules, and proposes consolidations into deeper ones, with the tests from skill four acting as the safety net that makes accepting the proposal cheap. I wrote a full field report on this skill in Deep Modules: the skill saving my codebase.
This is also the honest answer to "why do agents never refactor their own code?" They do, but only when refactoring is an explicit, named mandate rather than an implied virtue.
A Real Feature Through the Pipeline
For calibration, here is what the pipeline did to a real multi-model feature on this site, a Filament-managed content type with six locales:
- grill-me: 15 minutes, 6 questions, 2 of which changed the design.
- to-prd + to-issues: about 20 minutes to a PRD and 5 vertical slices.
- tdd: the bulk of the work, spread over two days of sessions.
- improve-codebase-architecture: one 40-minute pass at the end.
Total planning overhead: under an hour. The Sunday I lost before adopting this cost eight.
Where the Pipeline Falls Apart
Three honest failure modes. First, tiny changes: running five skills to rename a config key is ceremony, and my own CLAUDE.md keeps an explicit skip-list for trivial work. Second, genuinely exploratory work: when I do not know what I want, grilling me produces confident answers to questions I should not be answering yet; prototype first, pipeline second. Third, stale PRDs: if implementation diverges from the document and nobody updates it, the tracker becomes fiction. The discipline of writing decisions down has to extend past the kickoff, which is the same muscle behind the nine-skill workflow I run daily.
What This Does to the Job Description
Run this pipeline for a month and you notice your day has inverted. Most of your keyboard time goes into interviews, review, and slicing decisions. The agent gets the typing. Your judgment gets the leverage. That is not a smaller job, it is the senior half of the job, applied earlier and more often.
If you are staring at a backlog and wondering whether this would hold up in your stack, that is a conversation I have a lot lately, with my own 8+ years and 1,500+ projects' worth of scar tissue behind it. Tell me what you're building and I will tell you honestly whether an agent pipeline fits it, and where it will bite you first.
