Big Idea

The argument in one line.

A two-loop skill system, an outer loop for planning and an inner loop for building, makes AI coding reliable by writing the testing strategy into the plan before a single line of code is written.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

You already have some kind of AI coding workflow and want composable pieces to mix into it rather than replace it.
You lead a team shipping features with Claude Code, Codex, or a similar coding agent and want a repeatable planning-to-PR pipeline.
You keep getting inconsistent or overconfident output from a coding agent and suspect your process, not the model, is the gap.
You want a concrete template for splitting a feature into a PRD, a spec, and independently workable tickets.

SKIP IF…

You're starting from zero and would rather adopt one rigid, fully-specified framework wholesale instead of assembling your own from parts.
You're not using an agentic coding tool at all, since the entire system is built around delegating planning and implementation to one.

TL;DR

The full version, fast.

The video breaks down a personal skill library for AI-assisted development, organized as two loops. The outer loop runs once per epic: a PRD skill interviews you to define what to build and why, a spec skill defines how in a separate conversation, and a slice-epic skill maps dependencies and cuts the work into independent tickets. The inner loop runs once per ticket: a prime skill loads codebase context, a plan skill interviews you again and writes a fixed-template plan whose most important section is the testing strategy, an implement skill executes that plan in a fresh conversation and runs the validation as it goes, and a human still reviews the work before opening the PR. The core discipline is writing the exit criteria and guardrails before any code exists, then letting the agent work out its own path to satisfy them.

Free for members

Chat with this breakdown — free.

Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.

Create a free account →

Chapters

Where the time goes.

00:00 – 01:24

01 · I haven't written code in a year

Opens with the claim that drives the whole video: an engineer who hasn't handwritten a line of code in over a year, running everything through a library of reusable Claude Code skills.

01:24 – 03:01

02 · Why not a framework

Contrasts this skill library with fully prescriptive frameworks like GitHub Spec Kit and Gas Town, and explains why plug-and-play beats adopt-everything for anyone who already has a workflow.

03:01 – 04:43

03 · Installing the skills

Demos installing the library as a Claude Code marketplace plugin in two commands, then explains how to add the skills to any other coding agent by pointing it at the GitHub repo URL.

04:43 – 05:26

04 · The full process

Sets up the high-level walkthrough of the whole development process before demoing the individual pieces.

05:26 – 06:23

05 · The two loops

Defines the core framework: an outer loop that decides what to build (run once per epic) and an inner loop that builds and validates (run once per ticket).

06:23 – 08:06

06 · PRD Skill: the what and the why

Demos the PRD skill, which interviews the user to extract the target audience, hypothesis, and problem statement, and distinguishes greenfield MVP scoping from brownfield feature scoping.

08:06 – 09:44

07 · Sponsor: Agora

Mid-roll sponsor segment for Agora, a real-time voice/video agent infrastructure platform, including a live voice-agent demo.

09:44 – 10:47

08 · Spec Skill: why the how is separate

Explains why the architecture/spec document is written in a separate conversation from the PRD, keeping what-and-why distinct from how.

10:47 – 12:14

09 · Slice Epic Skill: cutting the tickets

Demos the skill that takes the PRD and spec together, maps dependencies, and slices the epic into independent, parallelizable tickets, optionally pulling source docs from Confluence.

12:14 – 13:00

10 · The inner loop

Transitions into the inner loop, noting this is where most time gets spent since it runs once per ticket rather than once per epic.

13:00 – 13:40

11 · Prime Skill: loading context

Demos the prime skill, which loads the coding agent with codebase context relevant to a specific ticket before planning starts.

13:40 – 15:56

12 · Plan Skill: the agent interviews you

Walks through the plan-implementation skill: another interview step, then a fixed-template plan document covering problem statement, files to touch, task-by-task steps, and the testing strategy.

15:56 – 17:51

13 · Validation first

The core thesis: the testing strategy is written into the plan before any code exists, covering unit, integration, edge-case, and manual validation, so the agent checks its own work as it builds.

17:51 – 19:05

14 · Be specific about the end, not the means

Cites Claude Code creator Boris Cherny's advice to describe the task, guardrails, and exit criteria, then let the model work out its own path there.

19:05 – 20:20

15 · Implement Skill: a fresh conversation

Demos handing the plan document to the implement skill in a brand-new conversation to avoid context rot, with validation running automatically as part of implementation.

20:20 – 21:14

16 · Your review and the PR

Even with validation built in, a human still reviews the finished work before opening the pull request and moving on to the next ticket.

21:14 – 23:00

17 · Customizing the skills

Explains that skills are never hand-edited directly, changes are described to a coding agent which rewrites the skill file, and closes with an invite to pick and choose from the library.

Atomic Insights

Lines worth screenshotting.

A validation-first plan writes the testing strategy before any code exists, so the coding agent's first output is never really a first draft.
Splitting planning into a PRD (the what and why) and a spec (the how) forces two separate conversations, because mixing them lets the agent quietly make architecture decisions nobody signed off on.
The outer loop runs once per epic and the inner loop runs once per ticket, with tickets inside the same epic scoped to run independently in parallel.
Being specific about exit criteria and letting the agent choose its own path scales better as models get more capable than trying to specify every step by hand.
A prime skill exists because a coding agent starts every fresh conversation with its global rules but zero working knowledge of the actual codebase.
Planning and implementation are deliberately split into separate conversations to avoid context rot, since very long conversations degrade a model's output quality.
Adopting a fully prescriptive framework like GitHub Spec Kit or Gas Town usually backfires unless a team has no existing development process to begin with.
Skills are edited by describing the desired change to a coding agent in plain language, never by hand-writing the markdown file directly.
A fixed plan template, problem statement through testing strategy, is what makes every ticket's output predictable regardless of which ticket it covers.
Validation built into implementation means the coding agent iterates and self-corrects against its own test suite instead of handing back untested code for a human to catch.

Takeaway

A two-loop skill system built on writing tests before code

WHAT TO LEARN

The reliability of AI-assisted development comes less from the model and more from a process that separates planning from building and writes the testing strategy before any code exists.

02Why not a framework

Full frameworks like GitHub Spec Kit or Gas Town make you adopt an entire prescribed software development lifecycle, which usually backfires unless you have zero existing process to begin with.
The skills here are deliberately plug-and-play: take one skill, take an idea, or take the whole set, and drop them into whatever workflow you already run.

03Installing the skills

The skill library installs as a Claude Code marketplace plugin in two commands, and works with any other coding agent just by pointing it at the GitHub repo URL.

05The two loops

The whole system reduces to two loops: an outer loop that decides what to build, run once per epic, and an inner loop that builds and validates, run once per ticket.
Tickets in the inner loop are scoped to run independently, so multiple tickets from the same epic can be worked in parallel.

06PRD Skill: the what and the why

The PRD skill interviews you to extract the target user, the hypothesis being tested, and the problem worth solving, before any architecture or code gets discussed.
Greenfield projects use the PRD to outline the MVP; brownfield projects use it to define the next feature set for an existing codebase.

08Spec Skill: why the how is separate

The spec or architecture document is deliberately written in a separate conversation from the PRD, because 'what and why' and 'how' are two different kinds of thinking.

09Slice Epic Skill: cutting the tickets

A dedicated skill takes the PRD and the spec together, maps dependencies between the work, and slices the epic into independent, parallelizable tickets.
The skill can pull source documents from Confluence or from local markdown, as long as it has an MCP connection to wherever the documents live.

11Prime Skill: loading context

Before planning, a prime skill loads the coding agent with codebase context relevant to the specific ticket, since a fresh conversation otherwise starts with no working knowledge of the repo.

12Plan Skill: the agent interviews you

The plan skill interviews you again at the ticket level, because letting the agent guess at your intent is the most common way AI coding assistants go wrong.
Every plan follows the same fixed template: problem statement, files to touch, task-by-task implementation steps, and a testing strategy, which keeps the agent's output predictable across tickets.

13Validation first

The testing strategy is written into the plan before a single line of code exists, covering unit tests, integration tests, edge cases, and the exact commands the agent will run to check its own work.
Writing the validation strategy first means the code the agent hands back was never really its first draft, since it already ran and corrected against its own tests.

14Be specific about the end, not the means

The instruction that matters most is being specific about the exit criteria and the guardrails, then letting the model work out its own path to get there.
As models get more capable, this validation-first approach keeps paying off, because the agent's ability to self-correct against a defined test suite scales with the model, not with how detailed the human's instructions were.

15Implement Skill: a fresh conversation

Implementation runs in a brand new conversation, separate from planning, because a long planning conversation risks context rot, and the plan document itself carries all the context the agent needs to build.

16Your review and the PR

Validation runs automatically as part of implementation, but a human still reviews the finished work and opens the pull request before it merges.

17Customizing the skills

Skills are never hand-edited directly; changes are described in plain language to a coding agent, which rewrites the skill file itself.
The library is meant to be picked apart, not adopted wholesale — take the two or three skills that solve a real gap in your own process.

Glossary

Terms worth knowing.

PRD: A document defining the target user, the problem being solved, and the hypothesis for why a feature is worth building, deliberately excluding any discussion of how it will be built.
Spec / architecture document: The technical counterpart to a PRD, written in a separate conversation, that defines how a feature will actually be implemented.
Outer loop: The planning phase of the workflow, covering PRD, spec, and ticket creation, run once per epic rather than once per ticket.
Inner loop: The build phase of the workflow, covering priming, planning, implementing, validating, and reviewing a single ticket, run independently for each ticket.
Epic: A larger feature or set of features planned together as one unit, later broken down into individual tickets.
Prime skill: A step that loads a coding agent with relevant codebase context for a specific ticket before any planning happens.
Context rot: The degradation in a large language model's output quality as a single conversation grows very long, which is why planning and implementation are split into separate chats.
Validation-first strategy: Writing the full testing strategy for a piece of work before any code is written, so the coding agent can check and correct its own output as it builds.

Resources

Things they pointed at.

01:35toolGitHub Spec Kit

01:40toolGas Town

02:28productDynamous community / Agentic Coding Course ↗

03:05linkcoleam00/skills GitHub repo ↗

08:07productAgora (sponsor) ↗

Quotables

Lines you could clip.

00:00

“I haven't written a single line of code myself in over a year now, and it feels crazy to even say that because I've been an engineer my entire life.”

cold-open credibility hook stated in one breath→ TikTok hook↗ Tweet quote

14:37

“LLMs will confidently make terrible assumptions.”

blunt, standalone warning that needs no setup→ newsletter pull-quote↗ Tweet quote

18:10

“Just let the model cook.”

tight mantra that anchors the video's central philosophy→ IG reel cold open↗ Tweet quote

19:27

“Large language models have a dumb zone where they get overwhelmed with information just like people do.”

memorable analogy for why context gets split across conversations→ TikTok hook↗ Tweet quote

The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.

metaphoranalogy

I haven't written a single line of code myself in over a year now, and it feels crazy to even say that because I've been an engineer my entire life. In fact, when I started my YouTube channel, I was showing you line by line how to build AI agents. But now I lean on AI coding assistance for every single part of my development process.

And the system that I've settled on for myself that's been working really well for half a year now is actually quite simple but very effective. Really, it's just a collection of skills at its core. And skills for your coding agents like Clogcode or Codex, it's just a reusable prompt.

It's a workflow to guide your coding agent through a certain process. And so I just have a collection of processes here just as a bunch of skills that I've bundled up together and now I'm giving it to you. And so in this video, I wanna show you all the skills that I have here that I use myself every single day.

How you can incorporate these yourself and take inspiration from them if you want. Because I also understand that you probably already have a set of skills. You have your AI coding workflow already.

So it's not like I'm expecting you to ditch that and start using all of my skills. Even if you just wanna pick a couple of the good ones or take some of the ideas that I talk about here and incorporate them from this, definitely feel free to do so. I mean, it's so easy these days to just point your coding agent at a repo like this and say, hey, I like this or I want you to grab this skill and then just bring it into what you already have.

And the most important thing for you to understand with all the skills that I have here is they're very minimalistic and plug and play. And what I mean by that is you don't have to adopt all of them.

If you wanna just take a couple or even just take a couple of ideas, you can definitely do that unlike some other agentic coding frameworks that we have out there. Like maybe you've seen GitHub spec kit or Gastown for example. These are very impressive projects.

Don't get me wrong. But when you want to use Gastown or GitHub spec kit, you basically have to adopt their entire process for AI coding. Like the entire software development life cycle is defined for you.

And usually that doesn't work the best unless you have nothing to start with. Right? But like I said, I'm assuming you already have somewhat of a process and so I'm giving you a library here to pick and choose what you want.

It's also extremely easy to take any one of these skills and customize it to your code base or how you like to work. And that's one of the big things we'll be covering here together. And of course, if you really are starting from ground zero, you don't have a collection of skills right now, you can certainly use everything here.

Like, this is a complete list of all of the skills that I use for my full development cycle that we're gonna be covering together here. And later in this video, I'll also cover the validation first approach, how we can let the model cook but still be confident in its outputs.

This honestly is the most important thing in the entire process that I have for you here. And this really is a big focus of the agentic coding course that I have in the dynamist community where I also really go into depth for the full AI software development life cycle using all these skills. So if you're interested in checking that out, I will link to it in the description.

Cool. So with that, let me show you how incredibly easy it is to install these skills and bring them into your own project. And so we're gonna be looking at the read me here in the repo which of course I will link to in the description.

A majority of you are using Claude code. So I do have this as a Claude code marketplace plugin.

I'll talk about other coding agents in just a second here. And so you copy this first command, you go into your cloud code that's already up and running, and you add my marketplace plugin. And then while it's running, I'll copy the second command right here to perform the actual installation.

So this one is done. Now I will install it. There's a couple of options here.

Generally, I recommend just selecting the top one. This will install these skills for you across any code base. You can also install it for just your current repository you have Cloud Code open in or you can install it for collaborators if you're working in a team.

So again, typically you install the first one here. There we go. It just runs in a couple of seconds.

And so now if we do plugins, we can see all of our different plugins that we have installed including Cole's AI skills. And you can also see them if you run slash skills.

There we go. Everything in the repository is immediately available to us. And so now if I do, you know, slash piv for example, we can see all of the different loop commands that we'll be covering in more detail in a little bit here.

And then if you're using a coding agent other than Claude code, it's almost as easy to install everything. This is gonna sound kinda cheesy, but basically you just copy the URL to this repository. You give it to your coding agent and say, here's a collection of Claude code skills.

I want you to install it in this repo for this coding agent like Codex or Pi or GitHub Copilot. And it's gonna work. It's gonna take a couple of minutes.

I mean, it's a little bit longer, but it's still basically as easy to incorporate these skills for any coding agent. Alright. So you have the skills installed.

Let's talk about what you've gotten yourself into now. I wanna show you the full development process here and how each one of the skills play into it. Now we are going to stay pretty high level.

I would have a much longer video for you here if I was getting into the details of every single skill and actually running them. And so let me know in the comments if there's any part of this process here that you want me to cover in more depth in another video. I mean, I pretty much could make a full video for every single skill.

Not that they're complicated, but there's just so many best practices that you can learn to really get the most out of your process. And so right now, I'm just going to show you what everything looks like when we bring it together.

How do I go from nothing to shift code with my coding agents? So my AI coding workflow consists of two loops. This is the dead simple framework that makes it easier for me to build anything.

The outer loop is the highest level planning, building your PRDs and spec documents. And then the inner loop is where we are writing the code. We take an individual ticket or issue and we're planning out the work with the coding agent.

We're having it write the code, and then we are validating the code along with the coding agent doing the same thing. And so, of course, let's start with the outer loop here because this is how you begin any work. The outer loop, you're doing less because you're doing it once per ticket.

So for greenfield development, if you're starting a project from scratch, this is where you're outlining your MVP. What is it that we have to build to get to that first proof of concept for our application?

And then for brownfield development, if you're working on an existing code base, you're basically defining the larger feature or sets of features that you want for your next sprint. Right? Like, what's that next evolution of my project?

And the very first skill that we use is the PRD skill. Because your PRD or your product requirements document is defining the what and the why for your next scope of work.

You're putting on the project manager hat to guide your coding agent through helping you establish what exactly are we building here, what's the problem we're really trying to solve. So you wanna make sure that everything else that we have here in the development process is building something that we know is worth building.

That's what we're establishing here. And so I'll show you what the skill looks like in the repo. So if we take a look here, we have our dot claud skills repository folder.

And within this, we have the plan create PRD. Now I said that I'm not gonna get into the weeds of every single skill but I at least wanna show you this one. So you have a couple of examples of how my skills typically work.

And so most of my skills have an argument. There's something we specify here. So when we go into Claude code and I do slash plan create PRD and I can do tab to auto complete, you can see that we have the argument hints here.

So this is giving you an idea of what you can specify. What is the input to the skill so it knows what to work with? And so right here, we can specify our product idea.

So this can be really at a high level like I want to build a finance tracker. I don't know. I'm just coming up with some random example here.

You don't have to be specific because as a part of this skill, it's actually going to interview you. It's gonna ask a ton of questions to extract from you the important things that we need to define in a PRD, like the user that we're targeting, the hypothesis that we have to prove this thing is worth building. The typical things that you would have in a PRD, this skill teaches the agent, here's what we need to extract from the user, I e you, and then here's how we're gonna format that in a PRD document.

The sponsor of today's video is Agora, the infrastructure platform for building your voice AI agents. They have their own real time network with over 200 points of presence across the globe, routing your audio and video around congestion. And with it, they've been powering the largest voice and video apps for a decade.

And that matters because building your voice agent is a lot more than just downloading an SDK. You'll use one to stitch together your LLM, a text to speech, and speech to text. But then once you have the voice agent, where do you deploy it?

And how do you deploy it in a way where it's truly scalable and fast enough to feel like it's delivering real conversations? Well, with Agora, not only do they give you the SDK to build the voice agent, but they also give you the pipeline and the network underneath so you don't have to maintain and scale your voice agent.

And with the quick start and their docs, you can get your own Agora voice agent up and running in less than five minutes. One command to install, give this prompt to your coding agent, then it builds this for you. Take a look.

Hey, Cole. I'm your Agora voice agent. Ask me anything.

Hey. How's it going? Hello?

It's very, very responsive. Like, this is pretty good. Thanks.

I'm glad you think so. Now, obviously, their quick start is just a starting point, but there's so much that you can configure within Agora. You can connect to any model.

Their engine also speaks to OpenAI compatible LLMs, and so any agent that you've already built, you can turn into an Agora voice agent. You get your first three hundred conversational AI minutes free, and the only credentials you need to build your voice agent are your app ID and certificate. And so if you've been hesitant to build a voice agent because you're not sure how to build, deploy, and scale them, Agora is your solution.

I'll have a link to them in the description. And just to show you an example really quick, this is a PRD that I generated from that skill. So we have the problem statement, the evidence, all the sections that we're telling the agent to create after it interviews us.

The important thing here is we're not describing at all how we're actually going to build these new features into the code base. We're sticking to the what and the why because we have a separate skill that defines our spec. This is the how, actually getting into the architecture for our implementation.

It's very important to have this split here. It's important because these really are two separate conversations you're going to have with your coding agent. First, you describe and figure out the what and the why, then you plan out the architecture.

You get more into the technical implementation, the how. How are we going to build the next set of features?

And so I do recommend running these skills in separate conversations. I'm not gonna show this one right now because it is a very similar process to this one where the agent interviews you, it goes off of a template to create the architecture document, and now you have that as the second artifact going into creating the tickets.

And so each conversation produces a document that feeds into the last step of the outer loop because what we wanna do now that we have the full scope of work planned out for our next epic, we need to split it up into the bite sized pieces of work so we're not overwhelming our agent with too big of an ask per conversation.

So really the responsibility of this skill is taking the two prior outputs and mapping dependencies, figuring out what we can do in parallel, really just setting the stage for all of the inner loops when we do the actual development.

And so I'll show you what this looks like now going into Claude code. So the name of the skill for this step is PIV slice epic. Right?

Because we're taking the epic and we're splitting it into the bite sized pieces of work. And this accepts two arguments. We have the spec or architecture document and the PRD.

So now it knows the what, the why, and the how so it can create all the dependencies and map them out. And you can see here that we can also specify confluence pages if we want. A lot of companies I work with, they're not just storing their PRDs and spec documents locally, they have it stored in confluence.

So I wanted to make this skill really flexible. Doesn't really matter if you have it in confluence or you have the PRD and markdown. This skill is gonna be able to pull it as long as it has, you know, the MCP server to reach out to wherever you're storing your documents.

And so you give the two paths or URLs here and then it's going to create all of the tickets for you to implement in your inner loop. And you're gonna be spending most of your time in the inner loop because remember, we're just doing the outer loop once per epic. These skills are very, very important, but you're gonna be using the ones here a lot more because now you might even have dozens of tickets if you have a larger epic that you're working on.

So we're gonna go through the process of planning, implementing, and validating for every single one of them. So our slice skill, it outputs a bunch of individual pieces of work. Those can be markdown documents, GitHub issues, Jira tickets, it doesn't really matter.

The point is each one of these tickets is an input to an entire inner loop. And so right here, we're going to point the coding agent at that ticket and we're gonna say this is what we wanna implement. I want you to explore the code base and help me plan out this specific implementation.

So I generally start with a prime skill. So I have this right here, just prime code base. There's a couple different examples that I have here if you wanted to, you know, understand a specific part of your code base.

Like, you know, you're only working on the front end for example. This prime code base is the more general one where it's just going to explore the code base potentially from the lens of the specific issue you want to give it. Like if you wanna give it a Jira ticket or a markdown file for that next piece of work, it'll explore the code base as it relates to, you know, what you want to build next.

Regardless, the important thing here is that your coding agent, it has its global rules, but otherwise it's pretty stupid at the start of a conversation. Right? So we're basically just doing a bunch of context loading here.

So after you run the prime skill, then we get into this skill where we really plan out the work with the agent. The important thing to understand for the plan skill here is we're gonna do it in the same conversation where we just ran the prime. I mean, maybe I should have like a real conversation up to make this concrete, but I think you get the idea.

Right? Can you do slash prime code base or whatever? And then after you explore the code base, we're gonna use that as context to go into PIV plan implementation.

And here you can also specify the ticket you're working on if you didn't already specify that in the priming steps. That is optional. And so now we're going to plan this specific ticket.

And the process is actually quite similar to creating our PRD or spec document. The agent is gonna start by interviewing you, asking you a bunch of questions to make sure you're on the same page for everything. Because the most dangerous thing here is that the coding agent is making assumptions for what you actually want to build or how you want to build it.

Because LLMs will confidently make terrible assumptions. That's why we would need a full workflow here of the agent really asking you a bunch of things, doing a lot of research in the code base and then only then creating the plan file to go into implementation.

And yes, it is worth spending a lot of time upfront. I know we're not even writing a single line of code yet, but this is what it takes to get reliable results with AI coding assistance. Make sure you're on the same page, create the plan, then you implement from that.

So here's what the output of the planning skill looks like unless you customize things in this skill, which we'll talk about that at the end of the video. But the format for the plan is always the same. That's one of the things that we specify in the planning skill is the template.

Right? Like, we always wanna have the feature description and the user story. This is what makes the skills reliable and repeatable because every single skill where there's an output document like this, I have a template for the coding agent to follow.

And so we have our problem statement, solution statement, what's out of scope, and the non goals. Mean, you can change all these sections if you want, but this works so well for me as guidance for the agent going into the implementation. And because we're really getting into the weeds of a specific piece of work now, we're even calling out things in the code base.

Like, here is the context we wanna reference, the files that we have to touch, the documentation that we want to read. We even have a task by task implementation plan for the files we want to create and edit.

And then the most important part of the entire plan document here is the testing strategy. This is what I wanna focus on for a few minutes with you here. It's what really makes my approach stand out over others.

It's the way that I have the coding agent define the validation strategy before we even write a single line of code. And you can see it's pretty comprehensive here.

We have our unit tests, integration tests, the edge cases we want the agent to test. We have all the specific commands that it's going to run for the linting and the type checking and the unit testing, the integration testing, the manual validation as well. How can we drive the application as a user also would using tools like, you know, the agent browser so it can perform browser automation.

This is the most important part of the plan. And let me explain to you why. Like, the validation first strategy it just gets better and better as LLMs get more capable.

So I call it test driven development but for agents. If you're an engineer, you know what that means. Otherwise, don't worry.

Essentially, what we're doing here is before we write a single line of code, we're gonna plan how to test that code. And this is important because it means that what we get back from the agent is never its first pass. It's able to write and run all of the tests that we have defined in the plan so it can iterate on its own work.

We have to intervene a lot less. We get back a lot less AI slop when it's able to do all of these tests and correct its own work. And so every single thing that we're gonna be building in this ticket, like an endpoint or error handling, we're specifying with the agent in the plan how are we going to test that thing.

And so I encourage you when you create these plans to look through it yourself. Make sure the validation looks good. The documentation it's gonna reference looks good.

Because if this plan is good, now you're being very specific about the end. You're saying like here is what done looks like and here is how you can validate things to be confident in that.

And like I said, this strategy is getting more and more powerful the more capable LLMs are getting. Boris Churney, the creator of Claw Code, he said this just last month. He said, you want to describe the task, you want to describe the guardrails and the exit criteria including the validation, and then just let the model cook and come back in a little bit.

I love that. Just let the model cook. Basically, the mantra here is you wanna be specific about the end, like what exactly are you looking for, what is a validation strategy, and then you let the agent build the road to get there.

You don't have to be specific about the means. That's why I say the validation strategy is the most important part for your plans these days because as long as the agent has the harness and the instructions to test and iterate on its own work, it's going to get there because it builds the path, it writes the code, and it's able to adapt for anything that goes wrong as it is checking its own work.

And I love this because this helps us wrap our mind around where do we actually dedicate our time. When we're going through the inner loop here, the plan documents sometimes feel pretty overwhelming with all the context reference, the files that we're gonna create and edit, but don't worry about that too much.

Like, of course, it's still important to validate the entire plan, but I'm giving you permission here to mostly just focus on the validation strategy and making sure the agent truly understands what you want to build. Cause now what we're gonna do, just to finish off the interlude quickly here, is we're going to take the plan document that we just created and we're going to send that into the implement skill.

And we're going to do this in a brand new conversation. We're doing a split here just like we did with these two skills because the implementation work is very separate from planning.

Your planning conversation is already probably very long. We want to avoid context rot because large language models have a dumb zone where they get overwhelmed with information just like people do. And since the plan document that we output here is really the only context we need to actually write the code, we can just go into the implement skill in a new conversation.

Right? So I just do slash PIV implement and then the one argument here is the path to the plan.

So just right click in Versus code, copy the full path to the plan, paste it in here, and then send it off to the races. That's all you have to do. And then the implementation, as it goes through the plan, the agent is automatically gonna go through the validation steps that we have in the plan as well.

And so, really, the validate step is kinda built right into the implementation. You can run it as a separate thing. I have a totally separate skill if you wanna do more of like a one off validation.

But usually you're doing these things at the same time and then when the agent says it's done, you're just gonna do your own code review and manual testing if you want. Typically, especially if you're more technical, I do recommend still checking the work of the agent.

Just because you have the validation strategy specified upfront does not mean that it's going to do a perfect job. So do whatever validation you want.

Right? This is the review that you do yourself. I have skills that go with this to help you perform the review.

And then you're going to end that ticket by opening up a pull request. Right? So usually you're gonna be using something like GitHub to manage your code bases.

So you have that proposal. Right? Here's the work that I did in the inner loop for this ticket.

I'm proposing now to merge this into the main code base. And so once you do that, right, you perform the review on the pull request, you deem it good, you merge it, then you're simply going to move on to the next ticket and you're going to do the inner loop again until you've knocked out everything that you've created as tickets in this skill.

And there you go. That is the full workflow. Definitely a bit of a longer video than I was expecting, but I wanted to really set you up for success here.

The full development process. I know we didn't run any of these skills, but you know how they fit together, when you do them in new conversations or continue the same like we do with prime and plan.

And, yeah, you can definitely customize all these skills to your liking. Every single one of these skills, I try to make them as minimalistic as possible, but there certainly are some opinions that I have here. Like, what's the best structure for a PRD or a plan?

Or how should the agent interview you? And so if you want to edit any of these files, it's actually quite easy. Typically, what I would do is I would just go into a conversation with Claude here.

I would take the skill dot m d for PIV. Uh, let well, let's do, like, plan implementation, for example. Copy this.

Go in here and I'll just say, hey, Claude. I want to change x y z about this skill. Right?

Like, I'm never handwriting these skills or making the tweaks by hand. I'm always having the coding agent make these edits based on a basic description that I give. And so if there's anything you don't like with these skills as you incorporate them, you pick and choose from the library that I have for you here, It's really easy to adjust it to whatever you need.

If you wanna change the structure, if you wanna change the templates, very easy to use your coding agent to do so. And so with that, I hope that you found all these skills quite helpful, whether you're gonna use all of them or just some of them.

And And I'm gonna keep adding onto this repository, just kinda make it like the collection of all the skills I use for everything. So mostly what's in the repo right now is the core skills for my SDLC, but I got a lot more planned as well.

And so if you appreciated this video, you're looking forward to more things on skills and AI coding, I would really appreciate a like and a subscribe. And with that, I will see you in the next video.

The Hook

The bait, then the rug-pull.

The claim lands hard because of who's making it: an engineer who spent his career writing code by hand, now running his entire development process through a library of reusable AI skills. What follows is the actual system, not a highlight reel of it.

Frameworks

Named ideas worth stealing.

05:26model

The Outer Loop / Inner Loop

Outer loop: PRD → Spec → Tickets (once per epic)
Inner loop: Prime → Plan → Implement → Validate → Review → PR (once per ticket)

The two-loop mental model that organizes the whole skill library: plan once per epic, then build and validate independently for each ticket inside it.

Steal forany team workflow that mixes AI planning with AI implementation

15:56concept

Validation-First Planning

Writing the full testing strategy, unit tests, integration tests, edge cases, and manual validation commands, into the plan document before any code is written, so the coding agent can self-correct against its own tests during implementation.

Steal forany AI coding plan template, regardless of tool

CTA Breakdown