These 3 skills changed my life Transcript, AI Summary & Key Points

00:00 Oh, how the times have changed. I still remember the days where I would sit up here and tell you guys all about these new technologies, frameworks, and ways of building software. And now I'm about to do a whole video about three markdown files. In some ways it feels silly, but these markdown files have meaningfully changed how I built. I have been using these three skills a ton recently, and I've been getting so many questions about them that I figured it was time to finally sit down and explain what they do and how I

00:22 use them. The skills are sole loop, full send, and full stop. These aren't skills that I had some super crazy clever concept for and decided to force into my work. It's actually the opposite. It's behaviors I found myself doing again and again that I turned into skills. When I'm working on T3 Code, almost half of my threads end up using one of these three skills.

00:45 And I would bet that the ones that end up being merged into main almost always are using at least one of these three. These skills have really helped me solidify some of the ways that I've been building, and I hope I can help you guys build more effectively once I teach you about them. But I got one more thing I want to tell you guys about that's been helping me build too.

00:59 Today's sponsor. Modern AI models have made it way too easy to rewrite pretty much all the things that your business probably relies on. We've been doing this a ton at my companies in order to trim our costs and make things that better fit our needs. But I've noticed there's a few things where as good as your custom rewrites can be, they're still going to hit edges.

01:15 What if I told you that one of these things is so annoying that even OpenAI and Anthropic have chosen to use a vendor instead of rolling it themselves? If I told you the thing was auth, you'd probably call me crazy. Sadly, auth has driven me even crazier, and that's why I'm so thankful for WorkOS. There's a reason everyone from OpenAI and Anthropic to Cursor are relying on them for their auth layer.

01:33 And it's not just because setting up auth is hard. I'll be real, getting a simple sign-in with Google button is relatively easy once you've gotten through all of Google's dashboards. The problems start to show up with different types of customers. For example, enterprises that are going to need a very specific set of things for their weird SSO setups.

01:47 The admin portal in WorkOS will take care of this for you. You send the business a link and they can sign up however they want. Then one of those customers is going to hit you up and say they want to set up an MCP to connect with their agents. Setting up auth for that is nearly impossible. Unless you're using WorkOS, then MCP auth is built in. But what if you want to go further?

02:02 What if you want your agents to be able to sign up for the service themselves? That's when authmd comes in. This isn't just a product WorkOS has. This is a standard that they built with companies like Cloudflare and Firecrawl to make a good way for agents to sign up for a service on a user's behalf. And as you can guess, there's a one-click setup if you're using authkit with WorkOS.

02:19 Get your auth right for enterprises and for your agents at swiyft.link/workos. I think the easiest way to go through these is from the top, but they will make a lot more sense when I give you a little bit of an overview on how I manage all of my skills. I have a repo on my computer called fleet. This is the only repo I find myself opening in VS Code almost ever.

02:37 The reason is because this is where I keep all of the data about my fleet of machines, the different computers that I work on. And if you didn't know this already, with T3 Code, you can connect to many different machines and control them all from one app or a phone app as well, which is very nice. But keeping everything synced between those machines, like making sure they have auth set up, making sure they have my skills, my MCPs, and all of that can be annoying.

03:00 So I have this one repo named fleet where I track all of this. I have folders that are categorized for the different types of skills. I have some that I only like in Claude. I have some that I only like on this particular machine, which I call command center. And then I have some that I want pretty much everything to have. I'm probably going to do a pass and delete a bunch of these cuz I have not been using as many of them as I expected.

03:19 I still love pulling out the Matt Pocock grilling skill here and there, but I find that it is mostly just sole loop and false end, false stop, and then all my PR-related things like file PR and babysit PR I use a lot. Leaving PR comments is another useful one, too. I have a pretty simple skill here where I tell my agents to call out what model they are and that they are responding on behalf of me if they're using my account to leave comments.

03:45 None of that is what we're here to talk about, though. We're here to talk about sole loop. One of the things I've said many times before, and I still believe this even if I don't personally follow it as much as I should, is that it is a good idea to write these things yourself. This one, I let the agents take over a bit. Initially, I did write it by hand, but I noticed a couple things that Claude was doing wrong, so I told it to update the skill to fix the mistakes.

04:09 And then I read it for the first time in a while last night and realized it got quite bloated. So, I'm going to be going through and cleaning this up in the near future, but for now, the thing that matters is the core concept. One other important thing to know is the role of descriptions. Descriptions are not what they sound like. This shouldn't describe what the skill is.

04:29 This is an indicator to the model on when it should be used. So, most of my descriptions are really simple like this. They are effectively triggers. I'm describing when the model should do this thing. So, the skill is named Soul Loop and the description is use when the user says Soul Loop. So, this should not be pulled in unless it was specifically mentioned by me or by another skill.

04:50 So, what is this skill? You own the code and Soul reviews it. Fix what's right, push back on what's wrong, and stop when you agree or the budget ends. Goal, get the smallest change that meets the intent. Reviews make it correct, not bigger. This is some slop that it added. You can tell that Opus wrote this. I I'm going to rewrite this myself now. I have now rewritten this to be a better description of what it's supposed to be used for.

05:11 This is a workflow for making your code changes more correct before or sometimes after filing a pull request. The TLDR is that you should use GPT-4 Soul to review your code in a loop. Make the most minimal possible changes to appease the Soul reviewers. Be careful of scope creep and don't be scared to push back. The be careful of scope creep and don't be scared to push back is very important.

05:30 One of the issues with a skill like this is that if you have too many agents that have different opinions talking over each other, you could quickly end up in a state where your scope blows up and the PR ends up significantly larger than it needs to be. This simple addition can help prevent a lot of that. I have a budget section saying how much this should go cuz otherwise it'll just go forever.

05:47 I say three rounds total. Round one is full. Later rounds check only change code and open findings. Extend to five only if there's security permission of data loss or other potential like risky things. Stop early if the round returns only nits, decline nits and comments, docs, or things that aren't as important. Yada yada. Well, only one reviewer at a time.

06:05 Soul should not start sub agents or its own reviewers, otherwise this gets nested real real fast. And then keep track of the things that it reports. Then there's a bit about the scope and also a section on how to actually call Soul. There's a couple different ways to do this. As you can guess, I'm mostly using this skill with Opus 5.5. I found that Opus 5.5 is a much better collaborator, overall smarter, writes way better code, just more pleasant to work with in general.

06:31 GPT-61 Soul is more thorough, though. It really does feel like the Rottweiler. It grabs onto the problem and doesn't let go, and I really like using it for reviews for this reason. I have been amazed at how much this skill and this workflow has prevented PRs from ending up in an infinite review loop once they're up on GitHub. Having this here running on your own machine helps a ton with like the first pass before you put it up in a PR, so things like, in our case, macroscope, Grab Tile, Code Rabbit, and other code

06:58 reviewer AI tools, before they get it, is usually solid. This is also great because you can take advantage of the subsidization that you get for your Codex subs. And since I'm personally not using my Codex sub a whole lot recently, this has been a great way to continue taking advantage of it even though I've been doing my day-to-day work in Opus. One other little thing I do with this that I found is pretty cool is I have a blurb at the end for when the PR is filed or updated that calls out that it should have this

07:25 section added to the bottom, reviewed with Soul loop, N rounds with model. I'm going to have uh another piece here, Soul verdict, approved. This is because I've noticed a few times Opus almost wants to hide the fact that Soul wasn't happy with the changes. Now, this will call that out directly. This is why it's important to actually like edit these files yourself.

07:46 On that note, I'm going to ship these changes. Uh updated the Soul Loop skill. I'll just say fix formatting and push it across the fleet. The thing I was going to say that I forgot is how you actually give Claude Code access to Soul. There's a few different ways to do this. The easiest way to do this in something like Claude Code is to set up CLI proxy in order to have all of your auth in one place.

08:11 I've been doing this for a while now and have customized the hell out of my dashboard to see like how fast I'm burning through my rate limits, what traffic's going where. I even went as far as setting this up to dump all of my requests and responses into a ClickHouse DB so that I can query them to get useful info. CLI proxy is one of my favorite things I've done to my setup.

08:27 I highly recommend forking and setting something like this up yourself. And once you have that set up, you can use all of the models that are accessible in it in whatever tools you want. Be careful using the Claude models other places though. If you're using a Claude Code sub, Anthropic is really upset if the system prompt isn't the Claude Code system prompt.

08:45 So, you should only use this with Claude Code if you're using your Claude subs. I use my Codex subs with Codex. I use my Claude subs with Claude, but I also use my Codex subs in other things like Claude through this because OpenAI doesn't care where you use your tokens effectively. Anthropic cares a lot. OpenAI doesn't. So, if you do set this up, be careful with that.

09:04 The reason I'm bringing it up here is it makes it very easy to set up Claude Code to let you use OpenAI models in it. And if you're worried about getting banned for this, don't worry. Tibo actually quote tweeted this saying that it is a blessed solution and if this does get you blocked, then he owes you a reset. So, this is allowed as far as they have officially said.

09:23 So, if you really want to stick with Claude Code but get these reviews in and also let it do its thing its normal way inside of Claude Code with sub agents, this is a good solution for that. And this was how I was doing it for a while up until the newest update shipped on T3Code nightly, which is Orchestrator V2. Quick TLDR of Orchestrator V2 is that it lets your agents and threads call other agents harnesses threads and whatever else within T3Code.

09:46 So, I'm going to ask in this thread where I made a PR doing some changes to how we log data about the SQLite database connections, and I'm going to tell it to have Muse, wonderful GPT-61 Sol, and Gemini 4 Argon review your changes in delegates. Address any useful feedback they give. And despite the fact that I'm using Opus and Claude Code right now in T3Code, which by the way uses your actual Claude Code with your actual Claude Code sub, this will now spin up with T3's built-in orchestration all of these other agents

10:16 using their native harnesses. So, I'm not stuffing 61 Sol into Claude Code here. I've taught Claude Code how to call Muse, Codex, and Gemini models all within T3Code itself. And now you see all of these sub-agents spinning up. They all get their own threads internally that allow them to review these changes and to communicate with the main thread. This makes setting things up much easier.

10:38 The T3Code nightly has this. The stable release is coming very soon. Being able to have your agent spin up other sub-agents like this to get feedback is great. This isn't just cuz like using all of your subs is great. This is because the different models have different training. They act differently. This is similar to like if you get three different people with different experiences to review a PR, the likelihood that they find unique things goes up.

11:02 So, if you take advantage of your other subs this way, it's very useful. I personally find that OpenAI models are the most thorough and find things better than others do. Claude models can find like really weird, potentially dangerous things that other stuff will miss. And then Muse and Gemini both can find things here and there, but I find that Gemini hallucinates more than actually finds.

11:23 So, if you don't want to make this a scale or you just want to test the flow, what Morg said here is a great way to start. Delegate to N sub-agents, compare the answers, refine your dispatching, and then repeat however many times. And we now have our verdict from Soul here. No important product code findings, all seven tests passed. Here are other issues that it cares about.

11:40 You get the idea. I have found that when I invoke this skill, that the PR that goes up has fewer issues, is more likely to be correct, and ends up getting through review faster, and being merged faster. It does take longer for when I send the prompt for the PR to open, but it takes a lot less time for that PR to get closed. And most importantly, is the thing I value a lot.

11:59 I don't want to throw a bunch of slop at my team. And I found that this skill reduces the likelihood that slop goes from a thread in T3 Code, or whatever else you're using, up into a pull request. If you have seen PRs your agents opened and felt guilty, this should help quite a bit. Now it's time to talk about those other two skills, full stop and full send.

12:18 I think this will all make more sense if we start with full send, but before we can do that, I want to talk a bit about how I have been doing things in T3 Code. And this is kind of becoming a T3 Code atom. I'm sorry, it's free and open source, so I hope you're not too mad at me for building the things I like into my products. If you haven't used T3 Code before, one of the important mindset changes to understand is this idea of the sidebar being an inbox.

12:39 When your work is done, it should go away. Settled is similar to archive. When your thing has merged, or you're throwing it away, or you've solved the problem you have, you should not ever be scared to settle it. And ideally, you have a small number of threads at any given time. I'll show you what I mean with this particular thread that has a PR open that I just reviewed and seems fine to me.

13:01 Now this PR has been merged on GitHub in approximately 60 seconds at most, probably less. It now gets marked as merged, and this one doesn't auto settle cuz I actually turned it off cuz this was a long-running one. But if I didn't have that flag off, which is very annoying timing-wise, this would have just disappeared. And that's your goal with T3 Code, all threads should be working or gone.

13:23 So I specifically really want to optimize to get my PRs merged because I want these threads to go away. So, once again, showing these workflows cuz I want to get this idea across of my goal being every thread should get merged and closed as reasonably quickly as possible. I'm not saying merge a bunch of slop. I'm saying that you should try to optimize for not having too much stuff that is waiting on you.

13:45 And you should make it as easy as possible to merge with confidence so that you can get these threads gone. So, hopefully at the end of the day, you have a bunch of stuff in the little optional working section and not a whole lot of stuff that you owe responses to. So, with all that said, it's probably time to talk about my full send skill. The point of this skill is to really lean into this idea of not taking up space in my brain unless it has to.

14:09 Remember, when PRs merge, the thread gets auto-archived. I also have things set up with this optional working section in T3 Code. This is a beta feature. I really like it and I might even make it the default in the near future. It looks like they just made it the default in Claude Code, funny enough. The point of the section is that if a thread is currently working, it doesn't need your attention.

14:29 It should just go hide until it's ready for you. This also means that I'm not going to see what the threads are doing if they're doing something like waiting, for example, like this one has 10 sub-agents it's currently running. This thread might output something that it wants me to see and I won't see it because it's stuck under this working section.

14:45 I think that's ideal. If it does ask a question with like the question tool, it will get yanked out and thrown into your inbox up here. But I decided to build more of my workflow around all of this. I wanted the ability to agree with the model, to know what it's going to do roughly, to know it's going to verify it, to test it, check it. And if it's a small fix that I know what it's going to do and how it's going to do it, or maybe it already made the fix and it has to do one more small thing before it's mergeable.

15:11 I don't want to have to go back to that thread. I don't want it to interrupt me again to force me to re-remember all of this just so that I can go click the one button merge. Ideally, once the model and I have gone back and forth and I have confidence that it knows what I want and roughly how to do it, it will not bother me again unless it gets stuck.

15:30 And that's why I made this full send skill. Again, the description is just a trigger. I say trigger if the user requests full send. If the user triggered this, it's because they're not watching the thread and they want you to complete the work end-to-end autonomously. Your updates and your final message go unread until long after you stop. You own the work from its current state to a merged PR.

15:50 If the user did not explicitly request this in some clear way, do not assume full autonomy. If they did, everything else below applies. This is an escape in case it randomly pulls in the skill. I call out explicitly what I'm granting permission for because I found that certain models, OpenAI models, get antsy about merging unless they have in their context user gave explicit permission to.

16:11 So, I have Theo granted you permission to merge the PR when the merge gates pass and to force push the PR's own branch with force with lease after rebase. This is one of those things I added cuz again, my skills are malleable. If I notice things not working how I want, I ask the model, "Why did you do that?" And it says, "I thought this because of this."

16:30 And then I go update the skill to prevent the thing I didn't like. So, these bullet points here are all because OpenAI models were doing things I didn't like. Then I describe the flow. Finish the change, prove it, file the PR, babysit the PR, merge, and report. The prove it section is important. I want the model to have found some way to verify that its changes worked.

16:52 I also mention my other skills to make sure it properly babysits and watches pull requests. This is again cuz my babysit PR skill was leading to OpenAI models not taking advantage of T3 Code's built-in watchers and doing stupid instead. So, I added another section here. In T3 Code, you should use the watch pull request feature. If you stop before the merge, call unwatch pull request first.

17:13 Again, bug fixes in my skills. Here I have my proof section. Proof is evidence that you observed yourself in the session. Command outputs, reproduction, screenshots. Use the most direct proof that the change allows. Reproduce the original failure, apply the fix, then watch the same reproduction pass. Run the checks that the repo CI runs. Add one focused test that fails without the fix when the behavior has none and the repo has a test setup.

17:36 Enforce UI and runtime behavior. Run the app and look at the change. Green mocked tests don't prove the user experience, yada yada. I also call out my file upload skill so that it can upload screenshots or videos when it proves the thing is fixed. I then have an explicit merge gate. This is what I'm expecting before it can merge. The proof covers every change.

17:57 The required checks are all green. All review bots have finished and the findings are fixed or dismissed with a written review. No human review is still requesting changes and the branch is up-to-date with the default and GitHub reports it is mergeable. Then we have the most important section. As I mentioned before, the point of this skill and the point of this flow is to make it so that when I'm done with the thread, I don't have to look at it again and I trust it to get the change in without having to look at it one

18:19 last time. Asking Theo is an important section for this reason. The model needs to know how to get a hold of me when I'm ignoring the thread. I told it explicitly to use the question tools that it has available to it. A question in a normal message goes unseen and the thread looks done. To ask Theo something, use the harness's question tool so the thread shows that it's waiting.

18:39 Ask user question in Claude code, request user input async or normal request user input in Codex, or the available question tools and things like antigravity. Put all of the context in the question. The PR link, what blocks you, and the options that you are recommending first. Ask only when you can't continue alone. Cuz I noticed after adding the section, it was asking all the time.

18:57 So I put this here as like a gate saying, "Don't ask unless." And one last, take the safe path if you don't have access to the things that you need. You know how nice it is having all of this data in one database on my network so my agents can like query against it. It's so cool. So, in the limited window that I am currently querying for my usage here, I had 32 times where I said full send, and of those, 27 merged without me having to look at them again.

19:22 Do you know how cool that is? I know it seems kind of insane to not look, but as I've talked about in other videos, you should build good verification systems so your agents can check if the thing works, but you should also build good safety nets. So, if it does fail, you can catch it before it hits a large percentage of your users and fix it before that happens.

19:40 In T3 Code, we have a nightly that goes out every 6 hours, and we get feedback immediately if it breaks something. So, I can fix it before the next stable release goes out. And I know this whole workload might seem kind of insane, but here is one of the lead devs on the Cloud Code desktop app publicly saying that they might change the default to grouping by status to better align with this type of workflow.

20:00 More and more, we are seeing devs that are taking advantage of AI, trying to think less about how do I get the best code for me to go look at, and more about how do we build workflows where the agent can verify itself and ship confidently, while also being able to undo broken stuff when it does happen. Cuz in the end, no matter how good you, your agents, your verification systems, or your developers are, mistakes will happen.

20:25 You need to make sure you can undo those mistakes with as little damage as possible. That said, of the 32 times I've used this in the last couple of days, 27 merged themselves, and I know which threads I used this on, none of them caused problems. Once you've done enough of this type of like agentic coding, you know what the models can and can't do, what they can and can't verify, what needs an extra look, and what doesn't.

20:48 And once you've built that intuition, it's relatively simple to know this thing can probably merge itself, this thing probably needs another look. But I love this workflow way too much to not use something like it, even when the changes are a bit hairy. And this is where my final skill comes in. Full stop. If you've been paying attention, you might have an idea of what full stop is and how it differs from full sent.

21:10 I'm going to be real. This skill is pretty much entirely slop. It should probably be called full slop. The reason this skill exists is because I liked the full sent workflow so much that on the scarier changes I missed it. I didn't want them to merge, but I wanted them to do everything else. So by the time it bugs me, it's ready to go. So full stop is Claude rebuilding my full sent skill with one big change.

21:35 Own the work until the PR is ready for him to merge. Keep fixing, verifying, and reviewing. Never merge it. This is again, let the model operate without me paying attention to it, but don't bother me until you are very high confidence the thing is ready to go. Do everything in your power to verify your changes, to talk to other agents and other models to get verification of your changes, put up the PR, baby sit it, deal with all the CI failures, deal with all of the review bots leaving comments, deal with all of the

22:06 other people on my team reviewing and leaving comments, and do not bug me unless there is something hard blocking you that you need before or you think it's ready to merge. I love this skill. This has quickly become my most used skill to the point where when I was starting stream today, people were sending me PRs they wanted me to look at and pretty much all of them I opened up and just immediately opened with figure it out full stop.

22:29 This one is actually funny. Somebody reported a bug to me in Twitter DMs, sent me the two PRs they filed to fix it. I didn't feel like going through it all and dealing with it. So I copy pasted his message and said, "Friend sent this. Triage and takeover. Full stop." I do also have a takeover skill. This one's relatively simple. I wouldn't overthink this.

22:46 This is very much like a I'm a maintainer and I have I have to deal with skill. Take over existing work. Use when the user asks to take over a PR branch or agent thread or request to take over. Take responsibility for finishing the original goal while preserving the original contributor's credit. The reason I made this is when I saw PRs that were fixing things that mattered, but I couldn't necessarily trust or I didn't want to just like push a bunch of things on top of their branch or PR, I made this skill so I can

23:10 link a PR to T3 code or whatever agent I'm using within it and say, "Take this over." Full stop. Now, what this will do is it will take a look at that PR, review it, read the description, see why they made it, decide if the code is in a good enough state to continue or if it should be scrapped and treated as a reference rather than actual like starting points, make a new PR with all of the changes if that's what makes sense, contribute to the existing one if that's what makes sense, credit to the original authors.

23:38 This is very important to me cuz I don't want people feeling like I am just closing their PRs and cloning their ideas. I want the people who make those original PRs to get credit. It's just too much work to try and get them to make the PR perfect. I would much rather have somebody on my team that I know can get this through to the end and can hit the merge button most importantly.

23:58 I'd rather have them own the PR and get the thing through. So, this skill allows me to do that without killing the credit for those contributors. I also call it my modernize skill in this one, which is a really, really simple deal with this PR being out of date, rebase on main, check to make sure nothing else has merged in this time that addresses the same stuff so that we know if this is necessary or not, and close it if it's no longer necessary.

24:22 What you might be noticing here is this weird like graph of skills that is happening. I started with my modernize skill, which is a flow I found myself doing a lot. I was saying the exact same thing to models like, "Make sure the PR is up to date, close it if it doesn't make sense anymore cuz other things that are similar merged." So, I turned that into a skill.

24:39 I kept telling my threads to take over PRs and branches from other things, realized that should be a skill cuz I was running into the same problems consistently. Then I wanted to take more advantage of using sole sub-agents to review, which I did by hand a lot, so I made the sole loop skill. I realized the quality of the code coming out was better than I expected, so I introduced the full send skill to see it all the way to the end.

25:00 Then I missed that flow a whole bunch, so I made the full stop skill to get as much of it as I could without having to be bothered. Before I forget, I'm going to fix this description. Change the description to use when Theo explicitly asks for full stop. This is actually how I update my skills across the fleet. I think there's a script in the repo somewhere that gets run when I do this.

25:18 I don't know. I don't care. I would much rather just say what I want, and the models are smart enough to do this. One more thing before I forget cuz I saw people saying this in the comments, and I need you guys to understand why I don't like it. Wouldn't it be better to just invoke it directly? I saw other people saying, "Why don't you turn off skill invocation?"

25:34 For those who don't know, in the skill standard, there's an option for disable model invocation. What this means is the model can't pull the skill in itself. You have to manually invoke the skill. So, this would be like a {slash} soul loop or {slash} full send. These are the {slash} commands or like the dollar sign syntax for it to pull skills in. Those are great if you are typing yourself, and you want to manually make sure the skill only comes in when I specifically do the thing like that.

26:04 I don't want to have to remember to {slash} command the different skills. It's also worth noting that certain harnesses, mostly cloud code, don't let you manually invoke multiple skills at the same time. So, if you disable the model's ability to invoke, you will not be able to trigger multiple at once in certain cases. It's incredibly annoying, and I'm going to be real.

26:24 I don't remember the last time I invoked a skill with {slash} other than the grilling skill, because I do have the Matt Pocock grilling skill as manually invoked cuz that's how they provide it. I don't manually trigger my skills. I write descriptions that describe the trigger phrase, and then I can do something like soul loop takeover, full stop, or even press my speech-to-text button say, "Full stop takeover soul loop."

26:48 And it will get it right like that. I don't need to do a bunch of special syntax just to invoke the different skills I need. But when do you invoke multiple skills? I don't know, the five times I just showed it. Here's one that I did literally as I was starting stream today cuz somebody linked an issue that they had fixed with this PR for opening explorer in Windows.

27:08 So I took the PR that they linked, I copy pasted it, said take over and get this landed. Full send. Now I have invoked two different skills and it got this fixed merged and it closed the old PR cuz it wasn't needed anymore. And I bet if we go to the one that it merged, which by the way I've never even opened, it merged and it gave credit to the original author.

27:28 So this combination of skills allowed me to take a PR I hadn't looked at, make a new PR based on that, credit the original user, verify the fix has worked. I think it actually used a Windows PowerShell like VM to test this, and then merge it. All without ever having to look at it. And since my skill specifies to make sure that this works and is safe before merging and if not, call Theo and make sure, I'm pretty confident if I never had to see this thread again, that we're good.

27:58 This is also very good to know. Thank you, Alex. When you invoke a skill manually in Claude code, it injects the prompt as a argument to the skill because skills in Claude code can be a bit more programmatic like you can pass them information. So when you do invoke a skill manually in Claude code, it's going to put your whole prompt twice in the context.

28:17 Not ideal. Don't manually invoke, it sucks. And there you go. I think that showcases why I'm enjoying these skills so much and how I've been thinking about my skills. I already know how many of y'all want me to include all of this in some repo somewhere. I I am leaning towards doing that. You know what? it, it's time. New project and it looks like we are going with T-Stack.

28:41 I will not have this ready particularly soon, but you should definitely keep an eye out for a T-stack video in the future. So, if you haven't already subscribed, you should consider that. Helps us a lot, and it keeps you on top of all of these cool developments in the AI dev world. Educational content is not the best performing stuff on YouTube. I appreciate you immensely for getting this far into the video.

29:00 I am finally caving and doing my first ever course. If you don't have a full-time job as a software dev, and you're not being paid real ends money, you probably shouldn't do this. But, if you can get your educational budget to cover it, or you can convince your boss to cover the cost for you, Mega Dev is going to be really really cool. I've spent the last few months working on the first chapter for this course.

29:23 I'm the opener, John Lindquist, the creator of Egghead, the closer, Kenzie Dots and Angie are filling up the middle. This isn't going to be your usual course on like build an app from scratch type stuff. This is how we use AI to really ship at actual companies doing real-world work. And we tried to make it not so specific to how things work today, rather more general how we think about AI and how we use these tools and technologies to navigate in this new world.

29:51 Very excited about what we're cooking there. Tell your boss about it so you can get it covered. But, please don't buy this in order to get a job. Buy it because your job covers it, and you want to level up your skills. Maybe get your team to sign up, too. I think that's all I have to say on this one. I hope you guys got the lesson I was trying to teach here, which is not you should go copy my markdown files cuz I'm super smart, rather that you see how I find solutions to the problems I have, and I'm building a more and

30:13 more abstracted workflow where I am involved at a different layer than I used to be. I'm becoming a manager of myself in a way. And in order to get the most out of your agents, it's important to analyze your flow and figure out what you do and don't trust them with, and start encoding that in stuff like skills, so that you can ship more effectively. All that said, I guess T-stack is coming soon. So, keep an eye out for that. Sub if you haven't already, and until next time, peace, nerds.