Agent Skills | LIVE150

Key Takeaways

All right. All right, am I Tom, am I supposed to say we're back? >> We are back. >> We're back. All right, folks. As I was saying, uh director Google Cloud AI best-selling author, yeah, speaker on AI developer experience, user experience, Addy Osmani. >> You're You're very kind. >> Thank you for being here. >> Hi folks, nice to be here. >> I was I was I told you I was watching uh a Bloomberg piece about AI, and you were in it. And I told my wife, I was like, "I know that guy." She was like, "No, you don't." I was like, "I do." She didn't believe me. >> She didn't believe you? >> No. >> It was probably for the best. >> Yeah. But Addy, uh Addy, I've known you for a long time. You've been writing and uh making videos and speaking since way back uh jQuery days. >> god. >> Doing the web, yes. A lot of web performance stuff. And now, a lot of AI agents and skills. >> Yes. Yes. A lot of agents. >> And today, we uh talked about you coming on and talking about you have a skills repo, which was on the front page of Hacker News multiple times. >> I try not to look at Hacker News too much [laughter] these days. You never know if it's going to be good or bad. >> Well, tell us about it. >> All right. Um so, today I wanted to talk to you about agent skills, and you know, a lot of people here probably know what they are. Uh but very quickly, I'm I'm Addy. I work on a bunch of agent stuff at Google. So, things like the agent development kit, agent platform, and we work on a number of skills-related projects at Google. So, we've been thinking about skills for a while. If you're not really sure um what skills are, um they're basically a standardized way to give AI agents new capabilities and expertise. Um and they've been a really hot topic over the last couple of months. Um especially as Do you Do you remember back in the days when people would like share their secret like shell config, and they'd be like, "A lot of files." And they'd be like, "Hey, this is These are my magic tricks." >> Yes, my dot files. >> These are my dot files that work really well for me. >> My magic tricks. >> These are my magic This is my bag of tricks. And you're like, "I want that bag of tricks." >> Yeah. >> But then you you think, well, my my bag of tricks might be different than your bag of tricks. And so, I think of skills in a very similar way. You know, sometimes you want to be inspired by other people's ones. Sometimes it's okay to just take, you know, copy their bag of tricks. >> Right. >> there I think there's going to be some stuff in here where people can just copy and take themselves. And sometimes there're going to be things here that will be inspirational. Now, just in case uh skills are not something you have spent a lot of time on, I thought it'd be interesting to just give people a very quick primer. Um and so, I I vibe coded this very quick, very silly uh Windows desktop in a browser. Um and I thought that I'd drop Clippy in here because I haven't seen Clippy. I haven't seen Clippy so much at Build. >> We're not We're not allowed to mention Clippy. It's a very >> It's a very Okay. >> very Well, there there actually is a Clippy suit that you can wear, but if you wear it, you're not allowed to speak. True story. >> Really? >> Yep. Those are the rules. >> Well, you didn't mention it. I did. So, So, we're fine. We're totally fine. I broke I broke you into jail. >> This is weird cuz we have the Mac OS dock down here, but then the Windows above it. I like it. It's like >> It's bringing the best of all It's just This is just terrible. It's like the worst of all the worst of all worlds. [laughter] Okay. So, if you're not really sure what skills are, basically there's a standardized way of packaging expertise and and context that, you know, your agent may not necessarily have. They can package their workflows, their instructions for your agent. And, you know, the structure of them is kind of this. Uh you have a name, you have a description. There can be a lot more content in here, but basically the name and the description are the main pieces um that every single uh skill file is going to have. And these are repeatable. Typically, you're not going to have a skill for something that's one-off because a one-off thing is going to to more like a prompt, but a skill is something that you or your team might be using on a reusable basis that might be useful across a few different projects. Now, um skills load on demand. So, you know, you have a task that arrives into your agent, it will match it with a skill, it will load its steps, and then it will try to follow them. It doesn't necessarily need to know more than the name and the description. So, agent skills, as you mentioned, uh this is a project that I created a while back. Um and for some for some backstory, uh I I had uh been taking a little bit slower on open source for a few years. You and I have been doing a lot of open source for a long time. I think you know, long time. As you know, you create an open source project, it's a lot like having a kid. You have to maintain it. And so, you have to be explicit about like when you want to get an open source project out to the world. And been a while, so I thought, okay, I'll I will get one of these things out there. I had seen that Gary Tan uh had put out G stack. That's right. Right? And I thought, well, you know, if if Gary Tan is doing G stack and people are are learning from it, there's nothing to stop me from putting my perspective on agent skills out to the world. And so, I started this project, um and it got some traction, and I thought, you know, it'd be interesting to maybe walk folks through it. My perspective on agent skills is I would say just a little bit different to other folks. I ground my agent skills around the software development life cycle. Um I think that they're you know, I I lean very heavily into agentic engineering, AI-assisted engineering, that side of things where you try to be very disciplined about, you know, I'm going to be explicit about what I want built. I'm going to verify what gets built. I'm going to keep quality in mind. And so, for my agent skills, I have a lot of steps that kind of map to the SDLC in here. So, define, plan, build, verify, review, and ship. And for each of these different phases of the SDLC, there are a number of different skills that are inside this project that the map in here. So, for defining, we've got skills that can interview you to get clarity around an idea. If you have a very vague idea, so maybe you have you know you had an idea in the shower and you're like, well, I kind of know what the outcome is, but I actually don't know what the UI is going to look like or I don't know what the details are going to be. You've got a skill here that can help refine it into something more concrete. You can do spec-driven development. We've got planning skills for turning things into tasks. We've got building skills that can help you sort of refine this to a place where you've got a very good front-end UI, your API and interface design is in a good place. And then sort of skills for a number of these other phases for verification, that's really important. You know, I think you and I have done a lot in the browser over time, right? I still build I I used to work on Chrome. I still build a lot of, you know, projects that will render in the browser. And so, testing in the browser automatically with an agent these days is something that I care about. So, I have a skill that will do that. Automated debugging is also part of this workflow. I've got a code review loop in here, too. Um, that includes things like code simplification, security. And then I've got chip skills, as well, that will help you with everything from your CI to your Git workflow, your documentation, shipping, and launch. Now, there are a lot of phases in here. I'm actually going to show you how these work, but there's basically a pattern that I use for all of my skills. There's an overview. I capture like when these things should be used. Um, I have rationalizations, like why should this be used and why should this not be used, so the agent has a little bit of a guardrail that it can it can keep in mind. And then red flags, as well, so that the agent knows if things are really going kind of off-kilter. And then verification, so how do we know that we actually did the steps right and did a good job. Now, all that stuff just maps to commands, as well. So, you can explicitly just use like a slash command in Copilot, in any of your agentic coding tools, and trigger any of these phases. Now, you don't have to use, of course, my agent skills. As I was saying, they're a lot like your bag of magic tricks, your dot files. If there's something in here that's useful to you, copy it, steal it, you know, help, you know, have it make you productive. If you find that the way that I do things is helpful, you know, you can go and use it wholesale. But, I wanted to show you um bit of this in action. So, I've got um a scaffolded out project here where I've installed the skills. We've got some agent files. We've got prompts for just mapping all of those skills. This is what happens when you just install it inside a project. And then, we've got some of the skills themselves. And I'm over here inside uh sort of the Copilot sidebar. Um I've selected Gemini 3.5 Flash. Um I work at Google. I work on Gemini. So, I'm going to be using Gemini 3.5 Flash here. It's a great model for agentic coding and and for agent tasks. Um I believe that, you know, uh VS Code has also got like an agents view these days as well, right? So, all of these commands, you know, you can just type in slash. You will see that there are additional commands populated here through using the agent skills. And you can use any of these. So, like things like refine, things like the code simplification, etc. But, just so that we can see what's actually getting built out, I'm going to stick with using this view. Um and we can start off with maybe just even doing uh a quick look at uh our skills. And I'm just going to show you test-driven development. I was talking about, you know, maybe giving you a bit of a an insight to what these files contain. Now, you'll see a lot of content in here. Um I try to be very diligent about what ends up in context windows. So, again, if you feel that there is too much that is in here for your needs, you can always trim it back. You can always optimize it further. But, I try to be very explicit. So, for test-driven development, I capture the TDD cycle. I have a very explicit take on like, what does it mean to have a failing test? What does it mean to have a passing test? How should you think about refactoring? What are other patterns that I personally think work really well? Many of these patterns are ones that have been inspired by how we build software at scale at Google. And so, I thought they'd be interesting to kind of uh encode inside these skills. So, you'll see things like the test pyramid in here, decision guides. There's a number of best practices that are encoded in here, as well. Lower down, you'll also see that I capture things like test anti-patterns, things to explicitly avoid. Um how to approach browser testing. So, this is that connective tissue that can then take us back to things like browser testing, browser debugging. Um I tell it what to check. I tell it how to think about security boundaries um where testing is concerned. You can be as explicit or open-ended as you kind of want with these things. I try to be explicit just because I think that there's value to being intentional with how you you approach these things. Now, what I thought would be interesting, um I I've been someone that for a lot of my life has been trying to optimize my productivity. I think I've probably failed at it a lot. Um and so, habit tracking is something that I look at now and then, right? I think a lot of people try to improve their habits and their systems. So, I thought it'd be interesting for us to try building um out a habit tracker. And maybe, you know, if you take a look at uh yeah, everybody's kind of looked at their GitHub contributions graph. Maybe we have a habit tracker that uses that kind of visual to show you like, how how well are you doing at following your habits over time? So, what we're going to kind of start off with here is I'm just going to trigger the refine command. And the reason I'm going to do this is I have a raw idea. So, I want to build out a habit tracker, right? So, uh we're going to say just something like a habit tracker GitHub inspired and I don't really want a a database backend. Maybe let's just have it all work in the browser. So, store everything in the browser. That's relatively vague. >> It's pretty vague. Are you going to say contribution graph or are you going to leave that out? >> going to keep it GitHub inspired. I could say contribution graph, but that's being explicit, right? So, we're just going to go and trigger refine now. And so, it's analyzing our prompt parameters. It's analyzing the core components of the request. It's triggering the skill. You can see that it's been reading that skill in place. Now, the first thing that's popped up here is it's asking me clarifying questions. So, who is the primary target user? Great question. It doesn't know if this is just for me or I'm building this for a team or I'm building this for my family or my friends or what. So, the audience is going to be let's say a a room of software engineers at Built, right? Or YouTube cuz people are going to be watching this later. >> Just Just anyone. >> Just anybody. What are the constraints and expectations for browser only storage? Great question. You could be using IndexDB, local storage, session storage, lots of different options. I'm going to keep it very simple. I'm okay with local storage for this. Beyond the standard contribution grid, so here it was able to figure that out itself. What GitHub analogies do you want to explore? Like committing a habit, branching variations, pull requests. I don't want to go too deep into these analogies. So, >> I think let's keep it Let's keep it simple with the contribution grid. >> Interesting that it's a leaning into that. It's like it wants to make the whole thing about GitHub. >> And this is one of those things if you take a look at how that skill is defined, it actually has language around trying to begin converging on the direction, the idea that you have uh leaning into like, "Okay, okay, well, I kind of get what you're going for. Let's keep going down that path." So, what does success look like for the MVP? Because very often, if you define like just a high uh a high-level prompt, it doesn't know if you're trying to build out something for a startup or a side project at the weekend or what. So, I feel like um the performance requirements are good. Like, all of the stuff seems good. I don't necessarily need it to be offline first with service workers just yet. So, um load fast, clean UI, uh that's about it. Load fast and have a clean UI. Be responsive. Okay. So, we've got all these answers now. Didn't take us very long just to start getting clarity around this, right? I didn't have to go writing a big spec myself or anything like that just yet. And so, it's trying to read the rest of my project yet just now, trying to see if there's any other context in there. This is a fresh project, so there's not a whole lot that it needs. And here's the output, right? It has a problem statement. Um it has statements around like how we differentiate directions, think about stress tests, and it gives us a few directions we can take. So, direction A is a dev dev profile configurator. So, a very minimalist, high-fidelity clone of a GitHub profile that allows us to track habits the same way that you would GitHub repositories. There's a lot more detail in here. Direction B is more of a keyboard-driven habit terminal. Um I'm more of a >> To use are so hot right now. >> Yeah. To use are To use are so hot. Direction uh C is a markdown SVG exporter, so a plain text back-end tool. Your habit configuration and grid data are up. So, this is more data. This is more like, you really want to enter in raw data and manage that, which is It's really the vibe I was going for. I think that the first one's probably the closest to what I had in mind. So, I'm going to go with direction A. And you can also see that it's got other assumptions in here and push backs. So, it's asking me which direction resonates the most. I'm just going to say direction A. >> Did it Did it recommend one? [clears throat] I couldn't see under the counter there. >> So, we can scroll back. Uh once you pick A, B, or C, I will produce one. It didn't recommend one. You can actually change your skill files to say, "Well, I want you to provide your own perspective on it." >> Okay. >> In this case, I'm trying to, you know, >> Cuz I notice models like to recommend and they almost always, when they give you a choice, they'll be like, "Well, this is what I do." And then I'm like, "Well, if that's what you do, then that's what I want to do." >> and sometimes I will ask the model like, "Give me three choices and tell me what you think I should do, just in case." >> Yes, but then I feel like I'm not I'm just always doing what the model wants. You know what I mean? I'm like, "Well, if you think it's best, then it's probably best." Which is not true at all. >> to say about cognitive debt and cognitive surrender. >> That's right. That your next article on the front page of High Growth [laughter] Engineer. >> Um so, what we have here So, the app is called Streak. We have a problem statement. We've got a direction here. We've got some assumptions to validate. Like, what is the retention rate? Um what is like the frequency going to be around habits? What's the mobile usability going to be? Since engineer configure setups on desktops, but often complete habits on mobile, is local storage enough? Well, probably. Yeah, local storage is well supported everywhere at this point. So, I think that pretty much all of these ideas are cool. Um so, we have our MVP scope defined for us here. And it also says what it's not doing. So, it's not doing cloud sync. It's not going to be doing advanced social features. And it's got some open questions for us if we want to provide clarity around that. And it also asked us, "Do we want to just save it?" So, I'm going to say yes, save it. So, we've now taken a very high-level idea and we've refined it. Now, the next phase of this is actually turning this high-level idea. We've gotten it into a better place. Let's turn this into a more detailed spec. >> Yep. >> Now, for some folks, you might say, "Well, this feels like it's a few It's a few steps." You don't have to follow my way of doing things. If you want to just have like one step for creating your spec, you can do that. I just happen to like specificity. >> So, you like to plan you want the plan, the spec, and then the implementation. >> Yes. Yes. Exactly. >> I'm a plan-implement guy myself. I just skip over >> Yeah. That's totally okay. Everybody's got their own workflow. Here you can see the file that is generated. And this is going to be a starting point and entry for the next step. So, the next step is going to be spec. So, we've got our idea. We can go and just type in {slash} spec. And it's then going to read in the output from that last phase. It's going to start being able to generate something that's much more concrete. So, it's taking in those assumptions, is defining success criteria, um scaffolding out the tech stack a lot more in detail. And then it's got those open questions in a little bit more detail for us. >> really snappy. >> Yeah, it's pretty quick. I guess. >> quick. >> Used Gemini 3.5 Flash. >> [laughter] >> Or whatever model is out at the time you're watching this on YouTube. >> Yeah, cuz it >> It move AI moves fast, man. >> 24 hours, everything will be different. >> Everything will be different. So, we've got some open questions. Um Grid generation technique, should we use a standard GitHub contribution grid? Uh Do we prefer rendering grids as modular dynamic SVG group structure or CSS grid element layouts? I'm going to I know CSS grid. I use SVG, but I'm not an expert. So, I'm just going to For one, I'm going to say choose what you think is best. And then, first visit boilerplate, what default habits should we set up for new visitors? Um >> It's a good question. >> Oh, >> Like bad habits? Are Are we tracking bad habits here? Is that what that is? >> We're tracking good habits. Good habits we should. Good habits, exercise, hydration, uh reading. >> Reading? Meditation? Do people meditate? >> Doom Doom scrolling, okay. Meditation. Meditation probably better than Meditation after your doom scrolling. Okay. Do you have a desired location for this file? I'm just going to let it do what you think is best. Cool. What I love about this is all of this UI, all these questions are directly inside of the Copilot sidebar. I don't have to use some other app for it. Whatever your Agentic UI surfaces, you can just have a similar experience there. So, it's now created a spec for us. I'm going to keep this. And the next phase, you can go and you can take a look at the spec, by the way. It's over here. It's going to be a much more detailed version of that original file that we had. But, you'll see that we have success criteria. We've got metrics in place here for performance, so things like largest contentful paint. We've got a tech stack that's defined. This is going to be very simplistic. So, vanilla JavaScript. I didn't say I wanted something in React. I'm okay with >> asked you about the tech stack, did it? >> It didn't ask me about the tech stack. And that's another thing that you can encode inside of your skills. >> So, this is an assumption that you just letting go with. >> that I'm okay with. Um you can assume like it's defined by test and playwright for our end-to-end testing, which I'm okay with. Our storage and then project structure and code style. And if there's anything in here that you don't like, you can always go back and either manually tweak it or work with your agent to configure this more. So, you've got your spec now. The next thing that you might want to do is actually start breaking this down into individual pieces. Now, this is useful if you've got a large project that you're working on. If you're working on something small, you probably just want to go straight into implementation. But, I'm going to show you this plan in action anyway. So, we've got a plan step here. And what we can do with plan is uh I can go and I can run plan. I'm just going to show you this working. And what this can do is help break down what we say in software engineering often is if you've got a big problem, break it down into smaller pieces, right? And plan kind of helps you with that. It breaks your big spec down into granular chunks that can then be implemented. And that's really good if you're working with TDD because you've got, you know, very individual pieces that can be tested, verified as you move on to other pieces. People have lots of different ways that they like doing TDD, so I'm not going to assume that my way is is the right way or anything like that. So, it's going and it's scaffolding out the basic parts of the project right now because that's fine. Like it can set up our boilerplate before we actually go and start implementing the rest. I'm just going to do keep on that. And you'll see that it's asking, "Before beginning phase one, um I should initialize our structured to-do list to provide full transparency." And it's going to do that now. So, um what you're going to have uh here is the package.json file uh which we see has been created. Um the implementation plan is established and saved to plan. So, we've got a task list here. You see phases and tasks. So, we've got phase one, task one, which has its acceptance criteria. And this is like build the pure logic TypeScript interfaces, your types, your functions to compute the streaks, your total contributions within the last like 365 days, the local storage pieces. Basically, stuff that doesn't necessarily touch your UI. And we've got some acceptance criteria here as well. So, we've got a list of things that have to be true as well as verification. So, the test suite has to be able to run on that piece of logic in order to move forward. It also suggests like what files are probably going to be touched as a part of this just to like really home them down. If you've been doing any vibe coding or genetic engineering for a while, you know that one of the ways in which we try to limit our blast radius is by saying, "Well, I'm just going to target these specific files." Because, especially if you're working on an existing project, you don't want it to start overriding or touching files that maybe have nothing to do with the task at hand. >> Yeah. >> Right? So, we have a few different phases of tasks here. Some of the other phases will include our data storage, so that layer for local storage. It'll include sort of the visualization of our habits as that GitHub-style contribution graph, as well as the rest of our UI. So, we've got our plan here. What you can do, again, this supports being very granular or or not having to think about that in as much detail. So, if I wanted, I could do something like {slash} build task one and just have it do the first task on that list. So, let's see what it does. It's created four to-dos as a part of that. Um it's evaluating it. It's reading our test-driven development skill right now. You can see that it's installing those first things. I'm also just going to do >> if you go down to the very bottom and turn on bypass approvals if you want to. >> I'm learning something new. Where do I Oh, wait, wait, wait. I see what you're you're talking about here. >> Right there. Yeah. And then you will stop asking. Are you a bypass approvals? You recommend bypassing it? >> I bypass approvals on all my personal projects. >> [laughter] >> So, now you're building one phase at a time. Is this generally how you work or are you more >> it really depends on what you're building. So, if I am building a personal side project and I just want to build something like maybe it has one purpose. I'm probably going to skip building out one phase at a time this way and just have it build the entire thing. If I'm building something relatively complex, I'm okay doing it a phase at a time. It might feel like it's slower, but the fact that you go through all of these steps and you know, well, this slice is tested. As we build out the UI, I know nothing else is broken. >> Yeah. >> I've now done our data layer, nothing else is broken. This gives you a lot more confidence as you're working through. It's just a just a different way of approaching this. >> It's such a trade-off though because then, you know, the human's back in the loop. Like once again, you're the problem. You're slowing the agent down. It's tough. I struggle with this myself. >> Yes. Yes, absolutely. And I would say that, you know, you have to make a judgment call at the end of the day about how much time you want to invest in where in in the software development life cycle you want to invest in. Do you want to put a lot of time into your spec? Just have your agent build out a lot of code and then spend time reviewing it, defining your tests at that point, figuring out like how do I evaluate quality. Like that that can be okay as well. Or do you want to approach it with TDD in mind? Do you want to have like an explicit strategy around how you're going to verify quality so that as you're going through, it's already addressing these things. And I don't think there's a right or wrong way. It's just different ways of working. You know what I mean? So, what you can see with this first phase is that the implementation is test-driven. We have our first target failing red test to uh to tell us that, "Okay, we have a test. It's failing. We're going to implement the minimal clean logic in streaks." >> So, we're in a red green here, yes? Okay. >> And as I said, you don't have to do this with like individual task. We can just keep running built to work through the rest of this. Um and then we can get on to other phases. So, you can see that it is thanks to to Burke's tip around bypassing approvals, we're just going to keep running through this. And I'm a person that people will often talk about, you know, how do you as an engineer understand what is getting generated if you're not reading all of the code? >> Yeah. >> Very often as as your agent is generating stuff, what are you doing? Are you switching over to another agentic task? Like very often I like I I found myself doing that. And so, I started to slow down a little bit. And these days I try to read the trajectory a little bit more. Like, what did it say? What was it thinking? Why was it thinking what it was thinking? And is there any nugget of information in there that I can extract that just lets me know, oh okay, well, that was the way I I I was expecting or wasn't. You know what I mean? >> Yeah, so it it's interesting because I I don't know what everybody else does, but I I watch the agent work. Now, I'm not reading everything that it's doing. I'm mostly just staring at it >> Yep. >> when I should be doing something else. But I'm just I'm literally watching agent spin. But I'm curious, like are you like are you looking at the code? >> Great question. >> Or >> So, I try to I generally unless it's a personal project, cuz a lot of personal projects end up being throw away things. >> Yeah. >> Oh, I have this I have this need for an hour. I'm just going to build something and throw it away. >> And in those situations, I'm very okay with saying, if I don't understand the code, the agent is going to go fix something for me. Um however, if it's going to be something I'm going to maintain for at least a few weeks or a few months, I generally go back and at least understand the architecture. And I try to read through some of the core files so that if I discover that the agent wasn't able to fix something or it goes off on a tangent, I am able to go back in and make fixes myself. >> Yeah. >> You know? >> Yeah. >> Um very often, like I so I'm going to keep working through build and we can keep chatting. >> Yeah. >> Um so, it's going to keep doing its TDD phases. As each slice gets implemented, it's going to go from red to green, implement the phase, and get everything done. >> This is so interesting. I didn't even know about red-green testing until SpecKit came out. It was my first It was the first time I'd ever seen that That's the idea of writing failing tests and then making them work. And I was like 40 >> Yeah. >> 5 years old. It's kind of sad. >> You do not look You do not look over 45 at all. >> I'm not, yeah. >> Yeah. Over 45. It was yesterday. Happy birthday. >> Thank you so much. >> So, we're going to keep doing this. Um, I also wanted to to have to share a comment on this. I think that very often in the entire sort of agentic engineering diaspora, the industry paints very broad strokes about best practices. Like if you're if you're on Twitter, if you're on any social network, very often the best practices for a solo founder or a small startup team will be shared. And >> Yeah. >> the best practices for that kind of team that are maybe don't have users yet. Maybe they're working on an evergreen codebase. Those are very different to people who are working on something either a legacy, brownfield with a team. And so, I think that it's important just to understand that, you know, there are situations where it's okay to just give in to the vibes and have the agent figure things out. And if something goes wrong, they'll just have the agent fix it. Other situations where actually understanding what's happening behind the scenes is still quite important. >> Yeah, 100% agree. I actually So, what's super interesting about this is that I think myself and most people are looking for what it just tell me what to install that's going to make everything work. Right? Is it Is it agent skills? Is it superpowers? Is it G stack? Like what is it? And the answer is it might be some of any of those things, but your job is less about writing code now and more about building these workflows that actually work. And it's not always the same even for different projects within the same organization. So, it's a it's a very I it's a I don't know what to call it. It's not software engineering. It's it's not automation. It's How would you even describe this? Like we all work at McKinsey now. I I don't know. I I I acknowledge that um agentic engineering we're we're we're now working on a spectrum, right? And there're are to be times when we're vibe coding, there's going to be times when we're genetic engineering, and the more diligence you have to apply to the process, the closer you were getting to genetic engineering. And I think that at big companies, small companies, anytime that you're working on something that that exists and has existing users, you owe it to them to care about quality, to care about not breaking things in ways sometimes agents subtly do. >> Yeah, 100% agree. If you're building a a habit tracker, that's one thing. If you're shipping VS Code, you have to be pretty meticulous about not breaking that. Yeah. So, we have uh about 10 minutes left here. >> So, what I'm going to do is I'm just going to skip ahead a little bit and just show you very quickly some of these other phases. So, the agent skills package also includes a verify step. Um Now, what verify does is it's able to just check that the implementation as it um has been has been done so far, whether it's complete or whether we've partially implemented something that can actually be used just yet, can run in a browser and actually do what it needs to do. So, it's going to go and check that it's actually able to spin something up. Let's see if enough of it has been built that it's able to do that. So, it's doing its NPM run build right now. It's going to spin up its NPM run dev. And we'll see if this actually works. So, we have we have something that looks like a GitHub profile. >> [laughter] >> Where did you pull that picture from? >> I have no idea. >> Who is that? >> of LLMs. >> [laughter] >> THAT'S SOMEONE IF THAT person's watching this stream, I hope >> Someone Someone in the world. >> Hey. >> [snorts] >> Hello, whoever this is. This could This could be like a non-developer as well. This could be a person that just likes to like bake cookies somewhere in the world and they're not >> to be on GitHub? >> Yeah, it just happens to be on GitHub. But, you know, it's it's opened up this browser directly inside of VS Code. Um it's able to run its checks behind the scenes to see, okay, well, is anything actually broken? If I interact with UI, does anything actually begin um to break? And I think that this is very interesting. Like if you actually go to um the prompts and you go to our verify skill, it will end up trying out the browser testing with dev tools skill. There are many ways to do sort of automated browser testing these days, whether you're using um Puppeteer, Playwright, uh the Vercel like agent browsers. There's a lot of different options. I'm not going to say there's there's a right one, but choose what makes sense to you. Um I just think there's a lot of really great tools these days for just making sure that your thing basically works, whether you decide to kind of encode all of your user journeys and test them out very, very holistically is kind of up to you at the end of the day. >> web devs as usual have it better than anybody else, right? Like it's so much harder to do with native apps. >> Now, um for for my skills, the review phase ends up being really important. And people have a lot of opinions about review. Um I tend to find and this is something that I found talking to engineers at Google as well. We still have a culture where we tend to have uh engineers manually review code. Even even with that, even with trying to bring AI into our code review process, having um you know, an agent do a local first pass or multi-pass is really, really valuable. Now, there are some people that will take this all the way to adversarial code review with very deep, you know, patterns. There are people who will have other models, you know, like, "Hey, I'm going to I'm going maybe I'm going to use Gemini for the implementation and Opus or Codex for other" So, you have a lot of flexibility here. There is again, no right or wrong way. People will often decide these things based on vibes. But what you'll see is we have a number of different kinds of review checks that were done here. So, what's working well? What's technically considered correctness? So, all of the unit tests that were implemented so far appear to be, you know, passing. Um we have no security issues, it seems. Um you know, we're working with vanilla JavaScript. Uh it we of course want to avoid XSS issues or cross-site, you know, cross-site scripting, anything like that. Um readability and architecture seems to be in a good place. Performance seems to be in a good place. This is a simple, you know, application. And it also applies some recommendations. So, keyboard navigations for that contribution graph make sense. Like >> Yeah. >> Uh that's not something that I had considered. Um and you might find that depending on the complexity of what you're working on, that you you can have this be much more um elaborate. Uh another part of code review that I find useful these days is code simplification. Now, very often what we'll do is we'll have an agent implement something. We'll verify Maybe you'll read the code. Maybe you'll verify that, hey, it at least runs in the browser or, you know, if you're building a native app, hey, it at least runs. But you don't necessarily go back and ask yourself, hey, could this actually be simpler? And one of the wonderful things about TDD or having tests or quality gates um around is that you can now go and do that code simplification loop and have something that can verify the rest of your logic still works. Yeah, right? >> interesting. So, I question on the security one. How much do you trust the non-deterministic? Cuz to me, this is the this is the this is where the the rubber meets the road, right? The rest of this stuff you can deal with. The security stuff cannot. How much do you trust that review that you're not pushing a key, you're not pushing some sequel injection, something that's just going to get you in a ton of trouble down the road. >> Oh, yeah. I think that there are a lot of good open-source and commercial offerings that go even deeper into security than than these skills do. And so, there are a lot of things that like we've seen Anybody that's been doing live coding and generating and entering for a while has run into these issues, right? Very often people will be using API keys in horrendous ways, yeah, right? Um, they will be quickly putting together something and not realize that, oh hey, wait, there are actually tons of data leakage issues or the way that off is implemented is leaving you exposed all kinds of problems. >> Right, or somebody can just kind nail your API over and over again cuz it's not locked down. Yeah. >> And if you're if you're a senior engineer, if you're experienced, you know what to look out for. If you're intermediate, if you're not quite as technical, if you're coming at this without as much of that background, or maybe you are an experienced engineer and you're just lazy, cuz sometimes we are lazy, it's useful to encode those things in skills just as like a sanity check for yourself. >> Oh, actually list specifically. Yeah. So, I find that I cannot think of all the edge cases. But, models are actually really, really good at this. Like, if you when if you ever ask a model to review a code base, it will almost always find something that you need to change your input. >> Yeah. >> Right? They're really, really meticulous and good at that. So, yeah, again, I don't know. I I feel like we need maybe better products or whatever it is, but all of this to me, a gentle code, should go through some deterministic gate that's like, yes, security sign off has been achieved. I don't trust I'm scared to death to push anything live on Twitter and be like, here's what I built and then have somebody be like, oh, and here's your Gemini key. >> And I think that's that's where there is a lot of value in understanding what does good mean, what does done mean, right? And if you care about security, you care about quality, you care about performance, you care about accessibility, you care about any of these things, that's a good reminder to try encoding those into how you approach quality gates in your projects. >> Yeah. >> Skills are just one way of of encoding that into how you think about all this stuff, but I think that just having tooling in place makes sure you're not merging in code that's going against those best practices is always is always a good idea. >> Yeah, I feel like we need more of these deterministic gates. I just don't know what they are, you know? Like right now markdown is the solution to everything. It's like, well, we have nondeterminism. How are we going to fix that? With more nondeterminism. >> With text files. >> With text files. So, we're at about 6 minutes here. I'd like to do some Q&A because you can continue building as you do >> So, I'll wrap this up in a minute. So, um there are a lot of great teams, labs who've been thinking about code simplification. And very often what I love to do is anytime that they open source their work or they write up a blog post about their work, I go and study like is there something that I can learn from what they're doing that I can then incorporate into my skills or how I work. Um you can do that for code simplification as well. Even for this simple app, it's already found like three or four opportunities to simplify the code. So, that's great. We've got a ship step in here as well. Just for time, I'm just going to skip ahead and show you like one that I built earlier. This is like this is called streak. It's got a GitHub contribution graph style, you know, graph at the very bottom. And it just shows us over time like are you actually following some of these best practices? So, for me, am I going screen-free for some part portion of the morning? Am I, you know, getting my work day goals planned? Um am I reflecting? So, you can you know, this is not a complicated app, but you can pop open, you know, your browser dev tools. You can go into the application panel, local storage. And we can see that all of our data is kind of here. We've got all of our entries for each of these things. It's all local. It all works like all of this will work offline. But it does the trick. Now, um You can do we can do Q&A. >> You want to do Q&A? Yeah, we can do Q&A. >> So, let's spend a few minutes Do we have a Tom, how do we do this? Do we have a mic or we're going to do Q&A? Uh right there. Yeah, so if you do we'll continue building here. If you want to ask questions, uh now is your chance to do so. In the meantime, we can continue building or chatting about skills if you want to. It's up to you. >> Awesome. If folks have questions, I'm happy to take it. Otherwise, I'm happy to keep showing you stuff. >> All right, we got one. It's Anthony. >> Hey. Uh yeah, question for you. How would you split up the work between like a flash type model and a pro model? Would you plan in flash and then implement in pro? How would you split the work? >> Did you hear that? >> Yeah, interesting question. So, how do you split up between models? Like do you plan in flash and then implement in pro? Like are you multi-model between the Gemini family? Like what's your personal take here? >> Yeah, I That's exactly my workflow. I tend to And especially if you're trying to optimize for cost, that's a great way to go about it. You can use a lower-cost model often for the planning phase, especially if you're trying to like optimize for tokens. Use a lower-cost model for the planning phase. Use a much more um capable model for implementation. And whether that's, you know, going to be one of the Gemini Pro models or Opus or Codex, any of those options can be good for your needs. But I found that that flexibility works well. And Copilot and many other tools also let you just like easily switch right between different models for these needs and these different phases, which is which is great. >> Interesting. I have a question for you. Where does MCP factor into this workflow? >> That's a great question. I have too many strong opinions on MCP these days. I think that >> Let's do [laughter] it. We have We actually have some extra time, so we can go over a little bit. >> Right. I I personally think that things are things have been moving so fast, right? And earlier on, we would talk about the difference in, you know, hey, MCP was really good for, you know, the the connectivity, right? Between data and agents and so on. And I think the people found that very often there were cases where you actually want a CLI instead of an MCP. And we started to see workflows begin to evolve a little bit more because maybe you don't need to have so many tools exposed. Maybe just directly using a CLI is going to be a more efficient way to achieve your goals. So, I personally feel like we are still in that kind of evolution phase of seeing like okay, well where is MCP going to be the best fit versus just having people directly use the CLIs >> Yeah. >> for things. >> This is kind of a contentious area I feel like. Uh I cuz I had one point I did say your MCP server should probably be a skill in a CLI. I kind of still stand by that just because AIs are so good at using CLIs. The only rejoinder I have to that, I was chatting with um uh um with Reese, who I think is over at Open Code now, about this on on X, and he pointed out that the authentication is a real problem. >> Yeah. >> And that MCP does this really, really well. And with CLIs, it's really hard to control auth and permissions for your agent. So, I agree with it, but generally speaking, I almost use entirely skills. The only MCPs I use is, of course, Work IQ, right? Cuz if you're in the Microsoft ecosystem, that's like the best thing ever. And then Context 7. I I always >> Context 7 is great. >> It's amazing. If y'all aren't using the Context 7 MCP server, that's the one thing you should install today and just tell your agent always read the docs before you do anything, and it will use Context 7 to read the documentation. >> Yeah, brilliant. >> I feel I love that, you know, even in Google Cloud, I know in lots of other places people have started to release and maintain more skill packs just because you can you can get so far these days with making sure that regardless of like what cut off date your agent's data is going to be, you've got up-to-date documentation, up-to-date instructions about like where to go, where to find things, exactly like what the developer workflow should be. So, I'm a I'm a huge fan of skills. People don't know that by now. >> Yeah, they're they're amazing. And I one of the things the other thing advantage you talked about this early on is like that they're loaded progressively, right? So, one of the things we're all struggling with right now is that the context window is a problem. And honestly, I feel like we need a better solution than a context window in general at some point in the future. This is like a really rudimentary primitive for interacting with LLMs. But, the problem is that the context window fills up really fast and MCP has to specify all the tools. So, if you didn't know, skills are progressively loaded. So, what the model gets is like the skill name and a brief description. And then from that, it then will load in the skill and then the skill may point to other files and then it will load in those files. And so, it's just really, really economical um for token usage, which is more important now. It's becoming more important every day as we are moving from a world of use as much AI as you want to to this is how many tokens you have. Use them wisely. All right, well, Addy, thank you so very, very much for being here. Uh I learned a ton. I was looking forward to it just for the free uh training on >> [laughter] >> your skills repo. So, I got something out of it. Thank you for being here. >> Thanks for having me. Appreciate it. It's great. >> Uh all right. Thank you so much. So, we will be uh right back with our next guest. And uh I guess maybe folks can come chat with you if they want to. >> Sure thing. >> All right. >> Thanks, folks. >> Here we go.