This Tech-CEO's Claude Code Toolkit Will Blow You Away

I wasted a million dollars over two and a half years building an app where people didn't even end up wanting 90% of what we had built. And I see most vibe

coders making the same mistakes except they're just doing it very fast. And

that's why I was stoked to come across the Y Combinator CEO's skill library because it's got an entire suite of tools to help make sure you're building

the right thing at the right time in the right way. And so if you don't know what

right way. And so if you don't know what Y Combinator actually is, it's a startup incubator that's created some of the biggest companies, you know, Airbnb,

Door Dash, Coinbase, Twitch, even Reddit, all went through Y Combinator.

So yeah, they know what it takes to build a SAS product and do it well. And

the really cool thing is that they are all in on vibe coding. They encourage

anyone that goes through their accelerator to use AI to code their products. And the CEO himself is very

products. And the CEO himself is very bullish on vibe coding as a thing. So, I

picked out what I think are the top five of the nearly 30 skills inside of this thing. And I'm going to show you how

thing. And I'm going to show you how they work, how to use them, what it looks like in the context of actually building something, and why they just might be the unlock that you have been

waiting for. and we're going to start

waiting for. and we're going to start with the first one, which is the YC office hours. So, I'm going to just copy

office hours. So, I'm going to just copy this command right here that they give you. I'm going to hop down into my

you. I'm going to hop down into my terminal and we're going to let this thing go. Now, I had a good friend of

thing go. Now, I had a good friend of mine go through Y Cominator back in 2020 and he always talked about how the office hours were one of the biggest benefits. And the reason for that is

benefits. And the reason for that is that you would get one-on-one guidance from one of the Y Combinator partners.

And so you could talk with them about like whatever your constraint happened to be. And so I think it's pretty cool

to be. And so I think it's pretty cool that the CEO of YC built that office hour system into a skill. So now that that is cloned and it's on our computer

in our claude skills library, we're going to run the command for office hours and I'm going to just paste in a description of an app that I'm thinking about building for myself. And so the thing that's really cool about this is

it will push back on your app framing, your fundamental assumptions. It'll even

suggest different things that maybe you should consider. It'll even generate

should consider. It'll even generate implementation suggestions for you based on what you were trying to build. So the

first question that we're going to get asked is what exactly are we doing? Is

this a startup? Is it a side project?

We're just learning. Is this an open- source project? What is it? For purposes

source project? What is it? For purposes

of this video, I'm going to just pick that hey, we're building a startup. And

now it's asking us, well, what's the strongest evidence that you have that someone actually wants this thing? Not

like, hey, they'd be interested. Not,

hey, yeah, maybe they'll sign up for a wait list but never buy. Like, they

would be upset if this thing disappeared from the world. So, I'm going to come through here. I'm going to say, in my

through here. I'm going to say, in my case, I am a user of this thing and I I I need it myself. And just for context on this app, because I didn't explain it earlier, I want to build an agentnative

business to consumer nutrition tracking app. And so for me personally, there's

app. And so for me personally, there's an app that I have used in the past called Chronometer. And it is not up to

called Chronometer. And it is not up to date with the times. I can't use an LLM with it. There's all these like

with it. There's all these like incredible things that I want to be able to do with my fitness data, my nutrition data, and my biometrics, and I just can't do it. And so people have all these janky workarounds that they're trying to use. And I'm like, why don't I

just build this for myself? There are

public databases that have all of the nutrition data in them. So like, what are we doing here? here. I can just vibe code this for myself if they're not going to build it. So that is the context behind this thing. And so the

next question is asking us when you tried to do this before like what broke?

What did you try to do that failed? So

it is taking this kind of like demand push in this case, but it's trying to frame it through what I just said. So

it's not going to let you off the hook with a really surface level app understanding or idea. And so in my case, there's a lot of frustrations. I

mean honestly the whole system is closed is really what the issue is. Um where

like I can't use a language model to get insights about anything that I am doing.

So it really is this one. Um so we could just move forward with that and see how it responds based on us saying hey it's all of these things. So next question up who's the target user? So you can see it is moving us through a very specific

flow of questions and these will be mostly the same every single time you run this. So who is the human that needs

run this. So who is the human that needs it most beyond just you? like who are they? What are they trying to do? So in

they? What are they trying to do? So in

this case for me it's really like a merger between the fitness focused person and more of like the biohacker type of person. But again if I'm thinking of like the MVP for this thing

it's not someone that wants to optimize protein timing. You know it's more about

protein timing. You know it's more about the person wants to look across all of their food intake and understand like what's going on why do I feel a certain way? What can I change? All of that type

way? What can I change? All of that type of stuff. that's who I'm going after for

of stuff. that's who I'm going after for the first version of this thing. So what

are people doing now in order to solve this problem? Like is there any sort of

this problem? Like is there any sort of workaround that they are using? So in

this case I'm going to say other because the workarounds now are that people have kind of duct taped together. Actually

this is kind of what it is duct taping APIs. It's kind of what it is. So I'm

APIs. It's kind of what it is. So I'm

going to say people have built their own gobased scripts that export the chronometer data directly from their interface. Their

APIs are closed. Okay, so that's really what the big problem is. Like they don't even have a public API for consumers.

You have to like apply and get approved and they don't really approve anybody.

Really a show. So you have all these like engineery types that are creating things on the fly and putting them on GitHub and it's like okay you have to go in and know enough to be able to like use that thing which people like

you and I could probably do but a lot of people who would consider themselves biohackers aren't going to do that and so they just they aren't able to do the thing. So then they have this concept

thing. So then they have this concept which is really interesting which is like what is the wedge? So what's the smallest possible version of this thing that someone would actually pay real

money for? Not like after you've built

money for? Not like after you've built this thing in its entirety, like your first week, the first thing you could possibly ship, what is that thing that people would actually pay for as it

pertains to this problem? Because we're

just trying to quantify like the demand of this thing realistically and if there's a fit between the problem and and the people. So for me, an MCP would be ideal again for me. But the issue with that is that they don't really have

APIs and so then I would need to like build a system to to scrape the thing, which is like a pain in the ass. And

then I would need to build that into an MCP that I can interact with. No way I want to do any of that stuff. And so I think if I was able to at least like import my data and then ask questions to

Claude like that that would be valuable.

I do also want the food logging stuff, but if I was think like what's the one thing that's really the pain? The real

real pain is not I want to be able to log my food through natural language.

It's that I want to be able to like get all of my data and start asking questions about that information. And so

the last question, assuming this wedge works and we start getting paying customers, what does this future fit look like? Does it become more essential

look like? Does it become more essential or less essential over time? So the very obvious thing is that I mean is at risk chronometer or my fitness pal could just build this thing, right? They could

build that AI piece into their system and then it's like, okay, well, what do I have now? So I'm not going to just go down the happy path and say, oh, people will just love it cuz it's but it's there, right? that's not acceptable. And

there, right? that's not acceptable. And

so we're going to say at risk. So now

it's going to go out and it's going to actually do a research phase. So it's

going to go out and it's going to find all the different conversations and all this stuff where people are talking about the problems or just like the category in general. And we are going to say yes, you can go out and do that. And

so we can see it's now going out and it's just running multiple web searches for different pieces of this puzzle. So

it's looking at maybe new startups that are entering the same space and see the same problem. It's looking at why people

same problem. It's looking at why people are frustrated with the current solutions. Uh it's looking at like MCP

solutions. Uh it's looking at like MCP servers, open source food logging. It's

probably going to find some of those APIs that we'll need to use. And so now it's going to break down like everything we're doing into a few core premises.

And we can see that here where it's looking at the landscape. So what is everybody kind of talking about? What do

they see happening? Uh what's that Eureka moment for this app going to be where the conventional wisdom gets kind of flipped on its head. So, for example,

most AI nutrition apps are replacing the logging experience. They're saying,

logging experience. They're saying, "Hey, you can take a photo and you can see how many calories are in it." But

that's not really what I'm trying to to build here. I don't really care about

build here. I don't really care about that. There's something else which is

that. There's something else which is this like reasoning layer, how we make action behind the data. So, a few core premises then. The reasoning is more

premises then. The reasoning is more important than anything, not the logging of meals is like secondary. They're

saying that the primary wedge is an import first, query first product. So,

bring your existing data in. I don't

really like that and I don't want to do that. So, I'm probably going to push

that. So, I'm probably going to push back there. Uh, and then a few other

back there. Uh, and then a few other premises that, you know, we'd want to actually read through and reason through and push back on. So, I'm going to push back in here and I'm going to say

logging matters for MVP. It's easy

enough to build quickly, which may or may not be good sound logic, but that's how I feel about it. Actually, they

already have that here for me. Premise

one. So I'm just going to say premise one is the only thing that I don't really agree with. So we're going to submit the answers and then see how it iterates. Now one thing that's cool is

iterates. Now one thing that's cool is that you can use a secondary model like codeex to challenge your ideas. That's

really cool. For purposes of this I'm going to just say no and skip through.

And so what it's doing now at this point is it's building out what are the few different approaches that we could consider taking to build this thing. So

now the thing here is I don't necessarily agree with this option C.

One of the premises actually of this YC CEO is this concept of boiling the ocean with how cheap it's getting to build things especially with like claw loops and all this stuff that can just happen

autonomously. You can build a lot more a

autonomously. You can build a lot more a lot more quickly. And so I'm going to do the agent native full stack because I am fully intending on building this thing for myself. It's a huge pain point I

for myself. It's a huge pain point I have right now and I don't want to go importing or exporting data out of my chronometer and all of that type of stuff. And so the interesting thing that

stuff. And so the interesting thing that it's going to do here is it actually goes out and it sketches up a very basic wireframe. Now, this wireframe that it's

wireframe. Now, this wireframe that it's going to give us isn't super impressive, but it gives us just like a a slight directional understanding of like this is approximately what like the again the

wedge version of this thing is going to look like. And so this is the type of

look like. And so this is the type of like rough wireframing that you get to understand like is this directionally kind of what I'm thinking it's going to be. And in this case, I think one of the

be. And in this case, I think one of the big things that is missed so far is that the natural language logging for me needs to support me giving like specific

like I should be able to create a recipe and save it and reuse it over and over again, which is very common if you're someone that like prepares meals and stuff like that. So, that's the one thing I'm going to push back on and then

we will move to the next step. Okay, so

this UI style is not anywhere near what I would want it to actually be. But now

we can see we're at least getting some mockups of what the overall UX might look like for how we're going to create meals and and log them and do all of that stuff. So once we're done with

that stuff. So once we're done with this, we can just say, "Hey, yeah, we're good to go." And then what it's going to do is it's going to move through and create an actual design documentation.

And so out the other side of all of this, we get this uh plan. And so the insights from this section alone about the target user and the wedge and really

what you should be building and all of the research that gets done already incredibly valuable because a lot of us in this situation might have speced out something that was way too involved.

Then we build something super big and then we don't really know if the features are even needed or necessary.

Now, as you can see at the bottom, there are two other commands that it's recommending we run. One is the engineering review and one is called the

CEO review. And this is when you want to

CEO review. And this is when you want to pressure test the strategy further before you commit to build. So, I'm

going to clear our context window out.

So, let's run it and see what happens.

So, again, the skill that is running now is called the CEO review. And the

concept behind this is that there's often a 10star product hidden within your current product. And so if you were to look at a lot of successful companies, they're actually offshoots of

a separate product within what they were originally trying to make or sell. A

good example of this is actually Slack.

Slack was an internal tool built by an engineer that I believe was working on a game company or something like that.

they're working on another company and he just built this thing called Slack for them to communicate internally about what they were doing. And when they were struggling with that project, they went

to one of their adviserss who looked at this tool they had built called Slack. I

don't know if it was called Slack at the time actually. He looked at this tool

time actually. He looked at this tool and said, "Dude, this is the this is the gold. This is the thing. That's what you

gold. This is the thing. That's what you need to go build." So in that concept, there's often like a 10star concept hidden within what you are currently

doing. And this is meant to help us kind

doing. And this is meant to help us kind of uncover these gems within our idea.

And so the thing that's really cool about this is they give you an option about what you want to do after they've run through this analysis. So they

looked at all of the docs that we had.

They did a little bit of like an adversarial back and forth like understanding if this is the right way to go, the right thing to do. And then

we have four options. The first is called selective expansion, which we could say, hey, this is the baseline, but I still want you to go through and brainstorm all of the future expansion

opportunities. So, this means that our

opportunities. So, this means that our spec as we have it now is solid, but we want to see what are the other again things that are sitting there waiting in the wings for us to kind of grab onto and maybe use in future iterations. Now,

the hold scope option is like I'm good with what we have. Let's just go plan it out and build this thing. Scope

expansion means, hey, like I have bigger dreams for this thing and I want to push this beyond our original scope. And then

scope reduction is probably what most of us need, which is cutting out things that aren't required to actually ship value that people would pay for. So in

this case, I'm going to go with the selective expansion because I haven't actually seen what the output of this looks like. So we're going to discover

looks like. So we're going to discover this one together. So the first thing that it's saying is that based on that Calai acquisition which happened recently they got acquired by my fitness pal. They're saying basically that photo

pal. They're saying basically that photo logging is actually very valuable to users who are often they they're about to eat the thing and it's like okay let me log what's in there right very intuitive and it's saying this is a very

quick implementation based on what we have. Do you want to add it in or not?

have. Do you want to add it in or not?

I'm going to add it in just because I am curious, but I don't want to get carried away with that if it ends up being a super big pain in the ass. I am going to abandon that one because it's it's not the core of what I want to do. So, the

second expansion opportunity is around the gamification of this, I suppose. So,

like are they logging regularly? People

that are biohackers are obsessed with like logging the things. So, do we want to add that in? Um, I'm going to defer it to to-dos. Like, I don't really care about that right now. That's not super meaningful to me, but we'll keep it in

the backlog just in case. So, the next one is, do we want to add proactive push notifications in? So, I guess the mental

notifications in? So, I guess the mental model here is like open claw kind of.

So, do I want the user to have to message me or do I want to actually message them proactively on a set schedule to tell them what's going on?

Now, I actually like the idea of that. I

don't want it to add a ton of time to what we're doing. But at the end of the day, just having like one worker in the background that can kind of do this thing. Like I I don't think that's a

thing. Like I I don't think that's a huge pain in the ass. And I think it would be pretty cool for someone like me. I wake up in the morning and it's

me. I wake up in the morning and it's like, "Hey, here's what your nutrients look like yesterday. Here was your baseline. Here's what I'm seeing. This

baseline. Here's what I'm seeing. This

is what I recommend you do today." So, I mean, I think it's pretty cool. It says

it's only going to add an hour with claw code. I like that. No, no more of those.

code. I like that. No, no more of those.

This is going to take five months to do.

was like, "No, it's not. Don't you want to know I got a clawed loop?" And so, now that I've gone through and I've answered most of the questions that they have, they wrote this to a kind of CEO plan. And now what's happening is that

plan. And now what's happening is that it's kicking off this thing that it does called an adversarial review where it's basically kicking off an agent that is going to look at the plan and challenge

and push back and try to make sure we're super dialed in on something that makes sense. So, this is super powerful

sense. So, this is super powerful because it one helps us understand what the gaps are in our plan and what we're trying to build. And then number two, make sure it's it's really aligned with the strategy of what we're trying to do

and that it's going to be additive and that we're not signing up for something that's going to take a ton of time to complete. But once we have this

to complete. But once we have this product direction like really locked in, where do we go from there? So, in a second, we're going to look at how Y Combinator scopes the technical build

with these skills. But first, let's look at how they design great products. So,

most people make the mistake of designing the back-end logic and then just say, "Hey, we'll get to the UI when we get there." But the real truth is that you need to have both, right? This

thing needs to have a brain while also looking the part. Now, according to YC, the difference between a product that looks nice and one that people actually

recognize is deliberate creative risks.

And so, the thing that's cool is that this skill actually helps us do that.

And so, while this CEO thing is still running on the side, we're going to run this. So, we're going to do slashdesign

this. So, we're going to do slashdesign consultation and then we're just going to paste in the link to the plan that we had. And so the first step of this is

had. And so the first step of this is that it's going to actually offer to research the space. So it's going to go it's going to try to pull actual competitor screenshots so that we know

like what is the overall aesthetic and feel and user experience of our competitors and then we can have different sub agents pulling together

different alternative design directions so that we get some of those more like creative riskoriented approaches to what we're going to build. So we'll let this thing run and then look at each stage as

it completes. And so now once this thing

it completes. And so now once this thing has run its course, we get a design proposal. And so what this thing does is

proposal. And so what this thing does is it breaks down the overall aesthetic, the typography, the different colors that are going to be used, the layout, the spacing, how motion will be used,

what are the safe choices versus the risky choices, which is interesting. And

then at the end of this, we have the opportunity to adjust certain things if we want to. Maybe we want to see even crazier risks taken. But once we're good with it, we have this opportunity to

have an HTML page generated that kind of encapsulates the design system. And so

this is what the design system looks like out the other side once it is done.

So it's breaking down the typography and giving examples of the usage. I think

this looks really cohesive. So we have really nice UI buttons and labels. the

way that the numbers and the time stamps and all this is formatted. I think it all works really well together. We have

our color palette, what the different components are going to actually look like, what alerts look like. So, we have like again a pretty cohesive design system coming together. We can even see different app mockups. Um, I think this

all looks looks really nice to be honest. So, might we come in and make

honest. So, might we come in and make some tweaks and modifications? Of

course. But as far as like a first pass goes based on what our intent for the app was and who our audience was, I think this is really good. So now we have our product direction locked in and that was done in two phases. Our

original office hours and the CEO review which is still running. So this thing goes in a crazy amount of depth. We have

a design system that we can now codify and pass along to the upcoming stages of the process. So the next piece is that

the process. So the next piece is that we want to make sure the actual architecture and the engineering side of how we're going to make this thing come to life actually makes sense. So, I'm

going to kick this thing off so that it is running in the background while we go and talk about what exactly this thing is about to do. So, there's a few pieces that it really tries to nail to make

sure it's doing its job properly. So,

the first is going to be the actual architecture of what we're building. So,

making sure the components are structured and make sense that we have different layers defined, right? What

are we going to be presenting to the user on the front end? What is the where does the business logic sit? what does

the data actually look like? Because

this kind of sets the stage for everything else that we are going to do.

Then defines the system boundaries. So

like what owns what in terms of like the actual code. Where do certain decisions

actual code. Where do certain decisions get made inside the system or outside the system? How does data actually flow

the system? How does data actually flow between the different pieces of the app?

So between components when data is getting changed or morphed or handed off somewhere else. What are the different

somewhere else. What are the different states that things are going to exist in the different failure modes when things can go wrong and the likelihood they'll go wrong? What are the different edge

go wrong? What are the different edge cases and what do we do in those specific edge cases? What should

authenticated users be able to do or not be able to do? What should they be able to access? And then making sure that we

to access? And then making sure that we have proper test coverage. So, it's

going to make sure again on a high level that we have our system designed out properly. This is all of the type of

properly. This is all of the type of stuff that this tool is handling for us.

And so like all of our other skills that we've been using here, it is going to continue to ask us questions which we're going to go through and answer. And

these are all based on our specific app.

So in this case, it's asking me about I think the continuous integration and deployment, what we want to do. And it's

going to move through all those different pieces that we just outlined to make sure that we have a super bulletproof plan. And once we have this,

bulletproof plan. And once we have this, it's a lot simpler to kick off a tool like Cloud Code and make sure it's going to actually build the thing that we want built because we already made all of these decisions. Okay, so this thing

these decisions. Okay, so this thing asked me like a lot of questions. So I

went back and forth for probably 15 minutes or so at least answering all the different questions about how I wanted to handle different pieces of the build.

And now out the other side, this original CEO plan that we had built now has a lot more considerations in here specifically from the engineering perspective. So talking about the

perspective. So talking about the additions that need to be considered in the architecture, error handling, what we're deferring, key decisions, all of that stuff is documented. So, with just

these four skills that we've gone through so far, we went from pie in the sky idea to something incredibly concrete and hashed out in realistically pretty short period of time. We've got

our product direction, we've got our design plans, and now we have our technical architecture, at least a lot of the key decisions already hashed out for us. So, if you want to see a

for us. So, if you want to see a follow-up video where we actually build something like this based on the plans we have, like in detail, like a 2, three hour video, uh, let me know and I'll record a video on how you would actually

take this and build from it. Now, the

last skill up is one that will save you a lot of headache in the future. It's

something I've had a lot of personal pain with, and it's called the document release skill. Now, one of the biggest

release skill. Now, one of the biggest daggers in the heart kind of patterns for vibe coders is that we tend to move too fast and we don't go back and update

really important artifacts that are now out ofd. So maybe you updated something

out ofd. So maybe you updated something important or you added something entirely new that now interacts with the other pieces, but you never go back to update that original documentation and

all of the little subdocumentation files or folders that you had. And then what happens is that two days later when you build something that touches the updated

area, it's now using outofdate information and it completely breaks and you have to spend a ton of time trying to figure out what went wrong and why.

Luckily, if you had things committed, you can revert back and just start fresh. But you'll always have that issue

fresh. But you'll always have that issue where you have this kind of snake in the grass that you're not aware of that is going to bite you at every chance it gets. And so this skill helps us

gets. And so this skill helps us overcome that. So, here's the steps it's

overcome that. So, here's the steps it's going to move through. First, it finds step one, all of the diffs. So, all of the files that basically just changed.

It's then going to look at all of your existing documentation files and cross reference them against all of those files that just changed. And it's going

to make sure that the changes are compatible with what is inside of these docs. And if it notes a conflict, it is

docs. And if it notes a conflict, it is going to help you resolve that conflict.

So, what changed? Does that now change any of my documentation files? It makes

the updates if needed. It quizzes you on any sort of risky changes that you just made. Maybe you inadvertently broke an

made. Maybe you inadvertently broke an important part of your authentication.

It reads through your change log. It

makes sure that based on any of the files that had to change that detailed your tech setup and your architecture and the changes you make and all of that, that all of these files now don't contradict each other in any way. So

something about the architecture doesn't now contradict what happened in the change log for example. It helps you clean up any dangling to-dos that you have. And then it helps you actually

have. And then it helps you actually commit the changes and manage your versions. So no matter what you do,

versions. So no matter what you do, whether you even choose to use this skill or not, having a structured documentation folder where you have a readme, your architectures outlined, you

have contribution guidelines, your change log is there, all your to-dos are referenced. Having this type of setup,

referenced. Having this type of setup, you can even put like your design artifacts and things like that in here.

Super super valuable to make sure you're not inadvertently breaking things and not knowing about it. So that's it for this video. If you found this helpful,

this video. If you found this helpful, consider giving a subscribe because I refuse to hype bro you guys with stuff and so anything I put out on my channel is something that I genuinely find

valuable and think other people might benefit from. So when I do drop a video,

benefit from. So when I do drop a video, I might not tell you how to make a billion dollars overnight with no work, but it will be useful. But that's it. I

will see you in the next