Every Claude Code Skill I Use to Drive My Entire Development Process

summarized

TLDR

Cole Medin hasn't written a line of code in over a year. He relies entirely on a collection of reusable "skills" (prompts) for coding agents like Claude Code. The system is a two-loop process: an outer loop for planning (PRD, spec, slicing epics into tickets) and an inner loop for implementation (prime, plan, implement with validation). The key is validation first — define the test strategy before writing code, then let the agent iterate until it passes. The skills are minimalistic, plug-and-play, and easily customizable.

Key points

  • Cole Medin's development workflow is entirely agent-driven; he uses a library of reusable prompts called "skills" to guide Claude Code and other coding agents.
  • The process is split into two loops: an outer loop for high-level planning (PRD, architecture spec, slicing epics into tickets) and an inner loop for per-ticket implementation.
  • The validation first strategy is the most important part: before writing any code, the agent defines the testing strategy, exit criteria, and how to validate each piece of work.
  • Skills are plug-and-play and minimalistic, unlike frameworks like GitHub Spec Kit or Gastown that force you to adopt their entire SDLC — you can pick and choose what fits.
  • The planning phase involves the agent interviewing you to extract requirements, ensuring you're aligned before coding begins — this avoids the LLM making confident but terrible assumptions.
  • Implementation is run in a separate conversation from planning to avoid context rot; the plan document is the sole input to the implement skill.
  • Every skill has a template for its output (e.g., PRD, plan), making the process repeatable and reliable across projects.
  • You can customize any skill by having your coding agent edit the skill.md file based on a simple description — no manual editing needed.

Tools mentioned

Techniques

  • Two-loop development process (outer loop for planning, inner loop for implementation)
  • Validation first approach (test-driven development for agents)
  • Priming the codebase before planning
  • Splitting epics into tickets with dependencies
  • Separate conversations for planning and implementation
  • Letting the model cook (define exit criteria, then let agent iterate)
  • Using templates for skill outputs
Transcript (captions)

0: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. In fact, when I started my YouTube channel, I was

0:10 showing you line by line how to build AI agents. But now, I lean on AI coding assistants for every single part of my development process. And the system that I've settled on for myself that's been

0:21 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

0:32 Claude Code or Codeex, 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

0:43 bunch of skills that I've bundled up together and now I'm giving it to you. And so, in this video, I want to show you all the skills that I have here that I use myself every single day. how you

0:53 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

1:02 already. So, it's not like I'm expecting you to ditch that and start using all of my skills. Even if you just want to pick a couple of the good ones or take some of the ideas that I talk about here and

1:11 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

1:22 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-andplay. And what

1:32 I mean by that is you don't have to adopt all of them. If you want to just take a couple or even just take a couple of ideas, you can definitely do that. Unlike some other agentic coding

1:41 frameworks that we have out there like maybe you've seen GitHub spec kit or gas town for example these are very impressive projects don't get me wrong but when you want to use Gastown or

1:51 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

2:01 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

2:12 extremely easy to take any one of these skills and customize it to your codebase 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

2:21 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

2:32 development cycle that we're going to 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

2:41 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

2:51 Dynamis 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

3:00 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 going to be looking at the readme here in the

3:10 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

3:20 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

3:29 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

3:39 install the skills for you across any codebase. 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

3:49 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

3:58 installed, including Koh's AI skills. And you can also see them if you run /skills. There we go. Everything in the repository is immediately available to us. And so now if I do, you know, /piv

4:09 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 cloud code, it's almost

4:19 as easy to install everything. This is going to sound kind of 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

4:28 Cloud Code skills. I want you to install it in this repo for this coding agent like Codeex or Pi or GitHub Copilot." And it's going to work. It's going to take a couple of minutes. I mean, it's a

4:38 little bit longer, but it's still basically as easy to incorporate these skills for any coding agent. All right, so you have the skills installed. Let's talk about what you've gotten yourself

4:46 into. Now, I want to 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

4:57 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

5:06 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

5:16 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 shipped code with my coding

5:26 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

5:36 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

5:47 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

5:57 any work. The outer loop you're doing less because you're doing it once per ticket. So for green field development, if you're starting a project from scratch, this is where you're outlining

6:06 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 codebase, you're

6:15 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

6:27 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

6:37 through helping you establish what exactly are we building here? What's the problem we're really trying to solve? Cuz you want to make sure that everything else that we have here in the

6:45 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

6:54 take a look here, we have ourclad skills repository folder. And within this we have the plan create prd. Now, I said that I'm not going to get into the weeds of every single skill, but I at least

7:05 want to 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

7:14 go into cloud code and I do slash plan PRD, and I can do tab to autocomplete, you can see that we have the argument hints here. So, this is giving you an idea of what you can specify. What is

7:24 the input to this 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

7:36 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 going to ask a ton of

7:44 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.

7:55 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 going to format that in a PRD

8:06 document. The sponsor of today's video is Agora, the infrastructure platform for building your voice AI agents. They have their own realtime network with over 200 points of presence across the

8:18 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

8:27 agent is a lot more than just downloading an SDK. You'll use one to stitch together your LLM, texttospech, and speech to text. But then once you have the voice agent, where do you

8:36 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

8:46 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 in their docs, you can get your

8:54 own Agora voice agent up and running in less than 5 minutes. One command to install. Give this prompt to your coding agent, and then it builds this for you. Take a look.

9:02 >> Hey Cole, I'm your Agora voice agent. Ask me anything. >> Hey, how's it going? >> Hello. >> Very, very responsive. Like, this is

9:10 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

9:19 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

9:30 300 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

9:40 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

9:49 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

9:59 describing at all how we're actually going to build these new features into the codebase. We're sticking to the what and the why because we have a separate skill that defines our spec. This is the

10:10 how. Actually getting into the architecture for our implementation. And it's very important to have this split here. It's important because these really are two separate conversations

10:20 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.

10:30 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 going to show this one right now because it is a very

10:39 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

10:49 tickets. And so each conversation produces a document that feeds into the last step of the outer loop. Because what we want to do now that we have the full scope of work planned out for our

11:00 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

11:11 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

11:22 show you what this looks like now going into cloud 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

11:31 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

11:41 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

11:52 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

12:02 skill is going to 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

12:12 to create all of the tickets for you to implement in your inner loop. And you're going to be spending most of your time in the inner loop because remember, we're just doing the outer loop once per

12:21 epic. These skills are very, very important, but you're going to 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

12:32 on. So, we're going to go through the pro 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.

12:43 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

12:53 point the coding agent at that ticket and we're going to say this is what we want to implement. I want you to explore the codebase and help me plan out this specific implementation. So I generally

13:03 start with a prime skill. So I have this right here just prime codebase. There's a couple different examples that I have here if you want to you know understand a specific part of your codebase like

13:12 you know you're only working on the front end for example. This prime codebase is the more general one where it's just going to explore the codebase potentially from the lens of the

13:21 specific issue you want to give it. Like if you want to give it a Jira ticket or a markdown file for that next piece of work, it'll explore the codebase as it relates to, you know, what you want to

13:31 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

13:40 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

13:49 the plan skill here is we're going to 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

13:57 get the idea, right? Can you do SLP prime codebase or whatever? And then after you explore the codebase, we're going to use that as context to go into PIV plan implementation. And here you

14:07 can also specify the ticket you're working on if you didn't already specify that in the priming step because that is optional. And so now we're going to plan this specific ticket. And the process is

14:18 actually quite similar to creating our PRD or spec document. The agent is going to start by interviewing you, asking you a bunch of questions to make sure you're on the same page for everything. Because

14:28 the most dangerous thing here is if 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.

14:40 That's why we need a full workflow here of the agent really asking you a bunch of things, doing a lot of research in the codebase, and then only then creating the plan file to go into

14:50 implementation. And yes, it is worth spending a lot of time up front. And 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

14:59 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've customized things in the

15:08 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?

15:18 Like we always want to 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

15:27 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. I mean, you can change all these sections

15:37 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

15:45 calling out things in the codebase like here is the context we want to reference, the files that we have to touch, the documentation that we want to read. We even have a taskbytask

15:55 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 want to focus on for a

16:06 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

16:17 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

16:25 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

16:34 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 is just gets

16:46 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,

16:55 what we're doing here is before we write a single line of code, we're going to plan how to test that code. And this is important because it means that what we get back from the agent is never its

17:05 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

17:17 able to do all of these tests and correct its own work. And so, every single thing that we're going to be building in this ticket, like an endpoint or error handling, we're

17:26 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

17:36 documentation it's going to 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

17:46 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 Turney, the creator of Claw Code, he

17:55 said this just last month. He said, "You want to describe the task, you want to describe the guard rails and the exit criteria, including the validation, and then just let the model cook and come

18:06 back in a little bit." I love that. Just let the model cook. Basically, the mantra here is you want to be specific about the end, like what exactly are you looking for? What is the validation

18:17 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

18:28 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

18:36 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

18:45 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 going to create and edit, but don't

18:55 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

19:04 the agent truly understands what you want to build. Because now what we're going to do, just to finish off the interloop quickly here, is we're going to take the plan document that we just

19:13 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

19:24 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

19:35 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

19:44 can just go into the implement skill in a new conversation, right? So I just do /piv and then the one argument here is the path to the plan. So just rightclick in

19:54 VS 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

20:05 automatically going to go through the validation steps that we have in the plan as well. And so really the validate step is kind of built right into the implementation. You can run it as a

20:15 separate thing. I have a totally separate skill if you want to 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

20:23 done, you're just going to 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

20:32 because you have the validation strategy specified up front, 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.

20:41 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 poll request, right? So, usually you're going to be using something like GitHub

20:52 to manage your code bases. So, you have that proposal, right? Here's the work that I did in the interloop for this ticket. I'm proposing now to merge this into the main codebase. And so once you

21:02 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

21:12 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

21:21 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

21:32 the same like we do with prime and plan. And yeah, you can definitely customize all of these skills to your liking. Every single one of these skills, I try to make them as minimalistic as

21:43 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

21:54 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.md for PIV. Uh well, let's do like plan

22:03 implementation for example. Copy this. Go in here and I'll just say, "Hey Claude, I want to change XYZ about this skill, right? Like I'm never handwriting these skills or making the tweaks by

22:14 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,

22:23 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 want to change the structure, if you want to change the templates, very

22:31 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 going to use all of them or just some of them. And I'm going to keep

22:39 adding on to this repository, just kind of 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

22:49 lot more planned as well. And so if you appreciate 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

22:58 see you in the next

Frontier News · by Hyperjump Technology