5 Claude Code Skills I Use Every Day to Ship Fast, Safe Code

These are some Claude Code and Open AI Codeex skills that I use every single day to build my startup. For a little bit of context about myself, I was a solo developer who's built over 14 different apps in the past 6 years or so, and right now my current startup is called Yorbie, the AI social media marketer, and I have a co-founder, but I'm still the sole developer, and he's mostly on the marketing and growth side of things. And we were working on Yorbie from October all the way through March, and during that period, I was pretty much the only person shipping code the entire time. But as of recently, we are not only hired an additional software engineering intern who's a college student to start contributing to the code base, but we've also been working on getting my non-technical co-founder to start building out features as well with all the proper guidance in place.

So, all the Claude Code and Open AI Codeex skills that I'm going to go over today, and some of them are going to be largely for my own personal workflow as a very technical developer, but then I'm also going to talk about some brand new skills that I've been adding into my code base to allow my less technically savvy intern as well as co-founder to still contribute meaningfully into the code without always relying on me to make all of these architectural decisions for them. So, we'll give you a little bit of glimpse of that as well. So, that's kind of where a lot of the two skills are being bucketed. Bucketed skills that I personally use as a technical developer, and then skills that I built to let my less technical team members still contribute meaningfully to the code base. All right, so let's get into it. So, we're going to go over into my terminal, Yorbie repository, and I'm going to open up Neovim. And then before we even get into the actual skills, let me just show you how they're all set up. So, historically, I've been a really big Claude Code user, but then lately, Open AI Codeex has been really, really good, and I'm always switching between the two a lot. And sometimes I'll even bust out a Gemini CLI. I know, kind of rogue, but I do that every now and then. So, the

way that I've been working around this is that I actually define all of my skills in the. agents directory. Something that kind of annoys me about Claude is, once again, don't quote me on this, I could be getting this factually incorrect, but I do think Claude was the one that came out with this open. agents directory structure and open agent skills and stuff like that to write all your skills, but then if you open up Claude Code, Claude actually doesn't pick up the skills that are defined in your. agents directory. They only. claude/agents directory. Oh, I mean sorry, your. claude/skills directory. Once again, don't quote me on that, but if that is true, that's kind of weird. Like you come out with this open standard, but you're not adhering to it. All right, instead of just spewing out incorrect information, I literally looked this up on Google. Who came out with the. agents/skills open standard? And it said Anthropic officially introduced and open-sourced the. agents/skills open standard, but Claude code doesn't read from there. Claude code only reads from their non-open-source proprietary. claude/skills directory. So, I didn't really understand why that's the case. But, that's a little tangent. Regardless, I define all of my skills directly in the. agents directory and the. skills directory as well. And these are where all my skills are laid out. And then Codex and Gemini are able to pick up those skills immediately because they do adhere to that open standard. But, for Claude, I had to do a little bit of work-around by creating a skills directory in the. claude directory. And then the skills directory is essentially just a symlink to that aforementioned. agents/skills directory. So, that's how I'm able to write all of my agentic coding skills into one singular source of truth in the. agents/skills directory. But, then I'm also always able to make sure that Codex and Claude code are always able to pick up on any skills that I write. So, let's go into the actual first of all, I'm going to go over my personal coding process, the skills that I personally use on a regular basis. And then later on in this video, I'll go over some of the skills that I created to help my less technical co-workers contribute meaningfully to the code base and not be blocked by me. So, the very

first skill that I always use is grill me and then phase plant. So, grill me, I'm sure that you've probably heard about it from our good old friend Matt Pocock. I don't know, sorry if I'm totally butchering the name. I got it from this repository right here. And for those of you that don't know, chances are if you're watching my channel, you probably do know who this guy Matt Pocock is. I don't really know. He started off as like a really big TypeScript technical developer. I was super great with educating people on TypeScript. Now, he's been diving really hard into AI code development. And he it was actually largely inspired from this video right here, the Grill Me skill, and he published this into an open GitHub repository, and that is Oh, it seems to be gone right here. I don't know what happened to it. Let me see. Ah, right here. So, this is where the skill exists, in the Grill Me skill right here. So, I did not make this on my own. I copied from Matt's directory just this skill definition, and this is essentially a very lightweight skill, but what it does is it just grills you on whatever you're trying to build, all the technical requirements, all the product requirements, any unresolved questions that the LLM may have before going off and building out whatever feature you're requesting it to build. So, I pretty much always use the Grill Me skill. I'm not going to lie, every now and then it gets a little bit too intense with the grilling, and I'm just like, "Dude, you're getting too deep in the weeds. Just go build the Please, please. " But, it is still a good skill to use, and I use it all the time. And I use that in conjunction with a phased plan skill. So, essentially, what

this phased plan does is it's pretty similar to the existing plan modes that exist in OpenAI Codex, as well as Claude Code, like this whole plan mode thing right here. But, really, it just forces the output of the plan to be broken down into individual phases. And I do this for multiple reasons. Number one is I hate doing code reviews of gigantic PR's. If one of my coworkers or myself has to review like 2,000 lines of code written by AI, I want to blow my brains out, and I absolutely hate it. And I know that I also can't provide a really thorough and in-depth review when that many lines of code is written. I'm very honest with myself about that. So, phase plan intentionally just chunks each group of code changes into like similar groupings of features. And within my phase plan implementation, I also make sure that each plan, if to the best of its ability, is a user-testable feature. Like, it's not just all back end, front end, but it's something that creates an actual testable feature on the client, whether that be just client-side or it requires some back end implementation as well, for the user to actually go out and test the various small sandbox amounts of features. I find it easier when code is structured that way for me to review it, and just know holistically, like, "All right, what's going on here? What feature am I trying to test? Okay, what am I doing on the UI? " Okay, that's cool. I know what the UI is doing. Now, let's go look at the actual implementation on the back end side of things as well. So, that's what I use the phase plan for. So, then the way a typical AI coding session work goes for me is I'll say like, you know, blah blah, build feature, blah blah blah, and then I'll say grill me for any open questions you have, and then when you're ready, make a phase plan and show me. So, I pretty much always use grill me in conjunction with the phase plan skill. Whenever I'm trying to build out a longer term feature that I know it's going to take a multiple milestones to hit. If I'm doing just like a really small bug fix, I'll probably omit both of these, or at most, I'll just use like the grill me and I'll skip the phase

plan. But, yeah, if I'm ever trying to create a very thorough big feature, like right now, one of the big features we're working on Yourbie that I'm definitely using the both the grill me and the phase plan skill all the time is to create our AI UGC studio to create AI UGC content to market our tool and our clients' tools as well, since we're making an AI social media market. Like, this account right here, autumnluna. creates, this is one of our most successful marketing accounts that markets our tool, Yourbie, the AI social media marketer, and it's literally all AI generated. This is something that we have been doing internally, and then we're taking our And now that we've kind of refined and mastered our own internal process of how we like to make this AI UGC content to market our tool, we're productizing it and building out a whole feature dedicated to building that kind of content within Yourbie right here. Not launched yet, but if you're interested, then, you know, sign up for the platform, subscribe to the channel, so then we'll alert you whenever this launches. But, obviously, this is a gigantic feature, and I've been using the grill me and the phase plan skills in conjunction all the time. The past year has been a huge time of transition for us, from raising a little bit of capital to fund my startup, to also going all in and making YouTube and social media my main source of income. And through this transition, surprisingly, one of the hardest parts about this has been figuring out how to stay on top of my finances. You know, previously, when I was working at that big tech company, I would get my bi-weekly paycheck coming in all the time. But, now that I'm running my own business, some months I'll make a lot of money, and virtually no money, and that's just the name of the game. It's been pretty hard to figure out how exactly to manage all this cash flow, manage all the money. But luckily companies like Xero, the sponsor of today's video, makes that a lot easier. Xero is accounting software built for small businesses. And what I like the most about it is the fact that it combines everything, my invoicing, my bills, my bank feeds and payments, all into one easy place to organize everything so I can get a holistic view of the entire financial situation of my business. So instead of having to open up my bank account to manually check what's my money, what can I spend, what can I not? Within Xero I can see the money that's coming in, the money that's going out, and the money that's left for me. The two things that helped me out the most with Xero is I send all of my invoice payments for brand deals for social media all through Xero. It has support for multiple payment options, automatic reminders for before and after the due date, which can help you get paid up to two times faster. I always hated having to awkwardly chase after a late invoice, but now Xero handles that all for me. Secondly, Xero analytics gives me a much clearer picture of my financial situation. So instead of guessing whether the next month is going to be tight on finances or not, see it coming very clearly. For someone whose income swings a lot month to month, that is the difference between making decisions out of anxiety and clarity. To get started with managing your finances and cash flow with Xero, then you can click on the link in the description below to get up to 90% off of your first six months. Thanks again to Xero for sponsoring today's video. So then the next skill

that I use a lot of is also this phased implementation plan. And phased implementation is really simple compared to phase plan and grill me. Phase implementation is just that whenever a plan is provided, like plan that is produced from the phase plan, phase implementation makes it so that it will only work on one phase at a time and it will never move on to the next phase until I manually review and I manually approve that individual phase of work. Then only once I manually approve and tell the LLM this looks good to go, commit the changes or stage the changes, and then it will then go on and move on to the next phase. This is just a really small lightweight skill just to make my life a little bit simpler. And the reason why I created this skill is because when I first created the phase plan, and I would just tell AI to go ahead and implement it. It would implement all the phases, like phase one through eight without me knowing, and I'd come back to review the code, and I'm like, "Oh my god, it just wrote like 5,000 lines of code. I can't review this. " So, by invoking this phased implementation, it's just a nice quality of life thing for me, forcing the LLM to only implement one phase at a time and never do more than that. And last but

not least, another critical skill in my pipeline, in my whole workflow, is this babysit PR skill. And the way that I use it is specifically within Let me show you within Claude Code, actually. It's a better use case. It's more explicitly defined there than Codex. I use it with this loop command, which within Claude Code, it basically just triggers a local cron job. So, I'll do like loop 1 minute babysit PR. So, basically, every single minute it executes this babysit PR command. And all this babysit PR command does is it monitors a pull request for its mergeability status. And if any code review comes in or any errors come in, like deployment errors, testing errors, any type of CI/CD errors that comes in, it'll automatically address them and try to fix them immediately. And then, once everything is all green and good to go, it will merge automatically. Well, actually, I lied a little bit right there. I currently have it set up to not merge automatically. It will just alert me instead saying, "Hey, it's ready to go. You can merge it manually if you want. " Depending on my mood, sometimes I'll just say like merge automatically when green. If I don't even want to review it and I just want it to auto merge. Every single time I make any type of code change, this little command is getting run all the time to merge whatever code change that I am working on right then and there. So, those are a lot of the skills that I've been using in my day-to-day like engineering flow to help from like a high-level engineering strategy, engineering design perspective. But lately, I've also been adding some more skills to actually help with some of the more nitty-gritty implementations. And what I mean by that? So, for example, I have this Your B logging skill. This is a brand new skill that I just made. And the reason why I built this skill is because I use PostHog's logging feature a lot. They actually have this guide right here for logging best practices. And look, I've admitted this before on my but I am by no means the most technical engineer. I'm not the most opinionated. I'm very much so just like an a product engineer. I don't really care too much about how it's built. I just want it to be built really well and built really quickly. So, I am not super opinionated about what the best logging practices are. So, instead, I see that PostHog uh resource, a company who has a lot of resources that I trust very deeply for good engineering practices, I essentially just copy this entire guide from PostHog about how to do best practices for logging, and then I dumped it in into a skill, and I created it with your B logging. That's the skill that I use. It's so whenever my app actually has to add any logs, it'll then just reference the your B logging skill to implement it for me. And that's not all too different from what these like Superbase Postgres best practices skill does as well. I believe Superbase launched this whole skill set for, you know, people that might not be the most familiar or the like best industry experts on Postgres and how to use it. They created this whole list of skills right here to help you to implement whatever the best practices are for Postgres. So, as you can see, previously, the first grouping of skills that I talked about was skills that assisted my overall engineering process. But now I also have recently been adding these latest subset of skills, basically transport and use the industry best practices and experts skills and knowledge to implement the various technical aspects of my app as well to fill that gap between what I know and what these providers recommend as the best practices. So, that's been a really great way to use skills as well for the more technical opinionated pieces of my implementation as well. So, those are most of the skills that I use on a personal day-to-day basis. But then

next up, let's go over some of the skills that I created to help my less technical co-workers contribute meaningfully to the code base without having me as a blocker. So, honestly, the main skill is going to be this vibe code skill. And I'll get to that soon, but before getting into that vibe code skill, I also have this eng onboarding skill. And if you've worked in any type of big company, you're probably familiar with onboarding at a new company. They have an entire document like a Notion page, a Confluence page, whatever document provider that they have of how to onboard onto your app and set everything up. Like for a long time I had that hosted within Notion right here in the Enge onboarding guide, but then I realized, "Wait a minute. What am I doing defining this Enge onboarding guide directly within Notion? Let's just define it directly in a Claude code skill. " Like which is exactly what I did. So this is just my entire onboarding guide for how to set up and run all the different apps and services that Yorvi uses for local development. And then whenever a newcomer comes in and wants to set everything up, Claude is able to reference this skill immediately and get all the contacts and all the knowledge necessary to set up the entirety of the local development pipeline. So then if we go on to go on over to the actual Vibe code skill, this Vibe code skill is pretty much a parent level skill that I created that calls all of these other things down below. It will call the Grill me, the Enge onboarding phase, implementation phase, plan skills, all within one skill. So this is probably one of the most opinionated skills that I've created up to date. Obviously, I don't know how helpful it'll be. I'm not going to read this entire skill, but essentially, this is the skill that I ask all of my less technical coworkers use to build out any type of features that they're trying to do. Vibe code, it sets up basic processes saying, "Hey, if you're having any type of difficulty setting up and running a local environment, reference the Enge onboarding guide. If you're trying to build out a brand new feature that's really technical, use the Grill me feature in conjunction with the phase plan guide. And then once the plan is all done, go forward with the phase implementation guide. " Then I have these rules as well saying, "Never write to production. You're only allowed to read to production and you must always read production data using the Yorvi Superbase prod MCP, which is only read-only, no write access granted there. " And then you can see right here, rule number three is to always never combine multiple phases into one implementation pass or PR. Always make sure you just to do one phase of implementation at a time. And honestly, with a lot of the Vibe coding that's being done to build out features, anything that's just like client work that's being done is usually pretty straightforward and I have no problems with them just playing around and going current crazy and doing tricks on it and stuff like that. But the part that I do always want to be involved in is whenever there's any database changes that are being done. Like when we're creating a new Superbase database migration to alter a table or introduce a new table, add new columns, and all of that. And with that in mind, I actually have a specific section of listed out right here such that for any like overly technical questions about database design, like anything remotely architectural as I define in the rule right here, to defer the question answering to me, the CTO, so that they don't have to answer it themselves. And the way that works is that they write out the entire plan, but they leave open questions that are a lot more technical and architectural, and they don't answer them. Then they write this plan into some directory. We actually have this directory right here called the plans directory. It has all these plans I've written up using the phase the plan uh skill. And then this gets committed into a PR, and then once this initial plan is committed at into the PR, then my coworkers will then tag me saying, "Hey, um check out this PR. There's some open questions in this new plan that I generated that I created. " Then I go in, open whatever plan that they just created, and then I reference whatever open questions, open architectural, more technical questions that are there, and then I then invoke the grill me skill again to answer and clear up any technical requirements that weren't answered in the original creation of this plan when the vibe code skill was used. And so far, I've really been enjoying the setup that we've had going on because really once you get a really detailed spec, AI is usually pretty good at implementing things that these days. So, my coworkers, they'll kind of go in, make that initial plan all the way up to the point where the only leftover questions or ambiguities that are left over are the technical implementations. I jump in, answer all the technical stuff, hand it over back to them, and then they're able to go on with the phase implementation. And for the most part, build out the entire feature end to end, obviously with me reviewing the code during a PR review, but with relatively little involvement from me just with how powerful AI is at writing code and writing really good high-quality code as well. It's been great for me because now I feel like we're shipping a lot faster where I'm still very much so involved. I know all the code that's being written, but I also don't have to handle the back and forth, iterating, tweaking the UI, and stuff like that, especially if it's a part of the feature or app that I'm less strongly opinionated about, but my co-workers are because maybe they are more strongly opinionated about what text and the copy should look like, what the UI should look like. So, it's been much faster turnaround for them to feel empowered to actually go out and build and make those changes themselves knowing that they're fully unblocked by me. It is a crazy time to be a developer, builder, product person. It is just like everyone is writing code, everyone's pushing, and it's pretty awesome. I really, really love it. But, that is everything that I got for today. Those are all of the skills that I use in my OpenAI Codex as well as Claude code setup. Let me know what you thought of the video. Is there any one that stood out to you? Are there any skills that you're personally using that you feel like have really contributed to your developer velocity? Let me know in the comments down below. I'm always trying to see what the latest meta, what the latest things people are doing out there these days. But, that is all I got for today. Thank you so much for watching, and I'll see you in the next