5 eines obertes per programar amb IA amb més control
Drawio-skill, Ponytail, Handy, Improve i SkillSpector aporten arquitectura, simplicitat, dictat, auditories i seguretat al vibe coding.
Programar amb agents d'IA no consisteix només a demanar més codi. Els problemes reals apareixen després: entendre l'arquitectura que s'ha creat, eliminar abstraccions innecessàries, donar instruccions prou riques, convertir una auditoria en feina executable i evitar instal·lar una skill maliciosa.
Sean Kochel prova cinc repositoris oberts que ataquen aquests punts: drawio-skill, Ponytail, Handy, Improve i SkillSpector. Junts dibuixen un flux més madur de vibe coding, on l'agent no substitueix la comprensió, sinó que ajuda a construir-la.
1. drawio-skill converteix el repositori en un mapa
A 00:29, Kochel identifica un problema habitual entre persones sense formació d'enginyeria: una aplicació pot funcionar sense que el creador sàpiga quines peces té ni com es relacionen. Quan apareix un error, l'única estratègia és tornar a preguntar al model i confiar que explori el lloc correcte.
drawio-skill analitza el codi i genera un diagrama editable de draw.io. En la demostració, separa presentació, estat del frontal, serveis, base de dades i funcions perifèriques. A 03:23, el mapa permet seguir com una petició de l'usuari passa de la interfície al resolutor, la lògica de negoci i els serveis externs.
El valor no és una il·lustració bonica. Si falla el processament d'un missatge, l'autor ja sap que ha de començar pel resolutor i no pels fitxers d'analítica. Això redueix exploracions innecessàries i, sobretot, converteix cada incidència en una oportunitat d'aprendre.
El repositori oficial admet diagrames d'arquitectura, C4, UML, BPMN, xarxes i esquemes de dades, a més d'extracció des de Python, JavaScript, Go, Rust, Terraform, Kubernetes o SQL. Cal revisar sempre el resultat: un diagrama generat és una hipòtesi sobre el codi, no la documentació definitiva.
2. Ponytail combat la tendència a sobreenginyar
Els models tendeixen a afegir capes, dependències i abstraccions que una versió inicial no necessita. Ponytail adopta la personalitat del desenvolupador veterà que substitueix cinquanta línies per una, però sense eliminar validacions, seguretat o accessibilitat.
A 08:00, Kochel mostra tres usos: orientar una implementació, auditar tot el projecte i revisar codi. En l'auditoria de la seva aplicació, l'eina troba fitxers d'Expo sense ús, components que es poden unificar i funcions creades per a necessitats futures que encara no existeixen.
L'exemple més clar arriba a 10:33. Hi ha tres tires d'error gairebé idèntiques; només canvien el text, el color i el gestor. Ponytail proposa un sol component amb propietats. És una aplicació directa de DRY i YAGNI: reutilitzar abans de crear i no construir avui una flexibilitat hipotètica.
La simplificació automàtica també requereix revisió. Dues peces semblants poden divergir per una raó de domini que el model no entén. La mesura d'èxit no és tenir menys línies, sinó conservar el comportament amb menys conceptes i menys punts de fallada.
3. Handy permet donar més context parlant
Una instrucció curta sovint no és una instrucció precisa. Escriure cansa i anima a resumir massa; parlant és més fàcil explicar objectius, restriccions i exemples. Handy és una aplicació gratuïta i oberta que transcriu localment i enganxa el text en qualsevol camp.
La prova comença a 12:06. Després d'instal·lar l'aplicació i concedir permisos de micròfon i accessibilitat, una drecera inicia la gravació. L'usuari pot triar entre models Whisper o Parakeet segons si prioritza exactitud o velocitat.
A 14:34, una frase llarga apareix amb bona precisió. A diferència d'alguns serveis comercials, la demostració no elimina automàticament totes les falques i repeticions, però això acostuma a importar poc quan el destinatari és un model de llenguatge.
La documentació de Handy confirma que el processament pot quedar completament al dispositiu i que funciona a Windows, macOS i Linux. Aquesta privacitat és rellevant quan es dicten detalls d'un repositori privat. Tot i així, cal vigilar què acaba al porta-retalls, a l'historial o al camp d'una aplicació connectada al núvol.
4. Improve separa diagnòstic i execució
Improve utilitza el model més capaç per entendre un repositori, prioritzar problemes i redactar plans. Després, un agent més barat pot executar cada pla. La idea central és que el producte de l'eina no és el codi: és una especificació revisable.
Kochel combina Handy i Improve a 16:21. Dicta un encàrrec detallat perquè auditi el resolutor d'una aplicació d'alimentació: ha de reduir crides a models quan una cerca determinista sigui suficient, sense perdre exactitud.
L'auditoria detecta que una optimització ja existeix en una funció de receptes, però no en quatre camins semblants. A 19:12, classifica els canvis com a baix risc i poc esforç. No els aplica immediatament; redacta plans que l'autor transforma en incidències de GitHub.
Aquesta separació crea un punt de control humà. Cada issue explica el motiu, l'abast i la verificació. Després, agents en segon pla poden obrir pull requests, però una persona encara decideix què entra a la branca principal. És un flux més lent que el «fes-ho tot», però escala millor perquè deixa rastre i permet aturar una proposta equivocada abans que modifiqui el producte.
5. SkillSpector revisa una skill abans d'instal·lar-la
Una skill pot contenir scripts, ordres de terminal, dependències i instruccions que l'agent executarà amb permisos locals. Per això representa una superfície d'atac. SkillSpector, publicat per NVIDIA, fa anàlisi estàtica i pot afegir una revisió semàntica amb un model.
A 22:50, Kochel escaneja un repositori escrit en un idioma que no domina. L'informe marca risc crític per funcions executables, ús de cookies de sessió i una instal·lació remota que descarrega un script i l'envia directament a l'intèrpret. Cap alerta demostra per si sola una intenció maliciosa, però sí identifica conseqüències que l'usuari ha d'entendre abans de donar permisos.
L'anàlisi sense model produeix molts falsos positius; afegir una API ajuda a valorar el context, però té cost i envia el contingut al proveïdor configurat. El repositori actual també permet informes JSON, Markdown i SARIF, consultes de vulnerabilitats a OSV i línies base per acceptar troballes conegudes.
A 26:27, el vídeo insisteix en el risc d'executar scripts remots sense verificar. SkillSpector és una capa defensiva, no una sandbox ni una garantia. La pràctica prudent continua sent llegir els canvis, evitar secrets reals, limitar permisos i provar codi desconegut en un entorn aïllat.
Conclusions
Les cinc eines encaixen com un procés: drawio-skill explica què s'ha construït; Ponytail elimina complexitat; Handy aporta context; Improve converteix el diagnòstic en un backlog revisable; i SkillSpector redueix el risc abans d'ampliar les capacitats de l'agent.
La idea més valuosa no és instal·lar-les totes. És deixar de mesurar el vibe coding pel nombre de pantalles generades i començar a mesurar-lo per comprensió, simplicitat, verificació i seguretat. Un agent és més útil quan el seu treball deixa mapes, plans, proves i decisions que una persona pot entendre.
Contrast i context
Fonts consultades
-
01
Sean Kochel 5 NEW Vibe Coding Repos You Haven't Heard of Yet
-
02
Agents365.ai drawio-skill
- 03
-
04
NVIDIA SkillSpector
Font de treball
Transcripció amb marques de temps
Consulta la transcripció
-
0:00
, obre el vídeo en una pestanya nova
There are five new GitHub repos that I've come across recently that are pretty awesome and half of them don't even have 10,000 stars yet, which is pretty surprising to me because these things solved some pretty big problems that I deal with on a daily basis trying to build apps with AI. So we're going to go through each one, we're going to demo it and we're going to talk about like where this can fit in your process and where some of these things can actually be used together. Starting with my favorite of the bunch that you might make fun of me for, Draw IO. So one of the things that really tends to suck about vibe coding things, especially if you're not an engineer by background, is that you tend to not know number one what you've built realistically, but number two, how those different things that you've built actually connect together. And that can be a big problem because when you want to go through and make improvements or just generally understand where an issue might be coming from or an area that should be improved. You're kind of relying purely on the language model to figure that thing out for you when in reality you do need to have an understanding of how those things work. And so what this skill does specifically is that it uses the draw, the I-O command-blind interface, but it uses it to help you build actual architecture diagrams of your app. So we can see that in an example here where we can see the mobile surface, the web surface, Maybe the admin surface that all gets routed through this API backend, which passes it off to all these different services, depending on what's happening, and then they have different databases, depending on the service and how you've structured your app. And so having this type of understanding can be super valuable because again, it's going to give you the understanding of like, what is actually happening inside of your app, where do things live? And in my opinion, the best way to approach five coding or five engineering. is to approach from perspective that we want to be learning at all times about how this stuff works, so that we can build better and better and better things in the future. The worst thing that could possibly happen is that your skills stay where they are now, and this, in my opinion, is the type of tool that helps you do that. So let me show you how it works specifically. So the first thing that you need to do is just pop in a command, depending on, you know, if you're on Mac, Windows, or maybe you're a complete chat and you're on Linux, make sure that you install this thing.
-
2:24
, obre el vídeo en una pestanya nova
First, I'm not going to go through that because it is very straightforward. And then after you've done that, all you need to do is install the skill. So if you're not using Cloud Code, you can just use the general S skills, add command and then pass this in. But if you want to install this via like a Cloud Code plugin or whatever, you can just use the slash plugin command, add the marketplace, and then install the skills out of the marketplace. And so the first thing you're going to do is you're going to come down. You're just going to invoke the skill, the draw, Ios skill. And then you're going to give it a command. And so one of the things that's really nice about this. is you can give it a natural language description of exactly what you want to see visualize and it is going to move through and do that. So in this example that I'll show you first, I said, I'd like to visualize the different layers of the services inside of my repo. And so this thing moved through, it explored the codebase, which realistically, I mean, didn't take that many tokens. And then from that, it basically drew us an editable architecture diagram. So if we were to go down now into draw, and pop it open, We can see exactly that. So in this case, we can see the overarching architecture of an MVP that we've been building and we're going to be taking it to market inside of my paid community. And so we can see exactly what that looks like. We have our presentation layer, which is purely responsible for just displaying things to the user. So we have the mobile surface. We have all of like the navigation and chrome inside of this thing. All of our different like feedback states and icons and badges. The different overlays we have in our app and everything that's responsible for actually presenting something to the user lives here. So that if you continue to move through, we can see like the presentation layer then is interacting directly with our front end statement. So we can think of that like where's all the data from the front end like actually live or exist when the presentation layer is calling it. This front end then is like resolving everything inside of it against our service layer. So accessing the data, all of the business logic, in this case, it's like a natural language food logging app. And so there's a lot of like resolving of the expressions that a user kind of chats in with. So someone says like, log me my chicken in rice ball. It needs to be able to resolve that expression and then go out and search it. And so then we can see all the different functions inside of this. We have this resolver. We have this recipe function. All right. We have a bunch of other functions and services in this layer.
-
4:45
, obre el vídeo en una pestanya nova
So the reason that something like this is valuable is I think what a lot of people do when they run into some sort of issues, we just say, hey, Claude Cod, go fix this problem and you know, it can typically do that pretty effectively, but to force it to go out and explore a bunch of stuff. At the end of the day, if we could have pointed them to what we knew was the area that the problem most likely lived, we're going to end up saving on tokens in the long term and we're going to actually build an understanding of how things work. So for example, if I'm running into a bunch of issues with relation to like how the chats that a user sending get actually parsed and whether or not it's calling like the agent effectively and things like that, I know that that is most likely going to start with like, hey, we need to go check this like resolver layer inside of our app. So it would be really dumb if we sent it off to like read our analytics or telemetry files. That would just be dumb in a waste of time. So then we can see, okay, well, the server's layer then interacts with our back end database specifically. So the different foods, different food entries, recipes, macro targets, like all that stuff related to our apps specifically, uh, live inside of this database layer. And so then the last piece is that we have these different edge functions, where we're connecting to like external services. So post-tag for like capturing product events, we're using OpenAI for like chat completions, and then we're using edge functions to handle some of the other things that happened. So now this is just one example of what this could look like. If we wanted to see how these different services, for example, like actually connect into very specific databases and like what that logic actually looks like, we could ask this skill in this case to come through and actually like make that type of update to our diagram. And so to drive this point home, there was a tweet recently from the CEO of Microsoft and basically to wrap all of this up in a a too long don't read. We tend to be really focused on the best model and trying to like one shot things and do all of this like hand-wavy type of like demonstrations of these tools. But if you really want to succeed in the long term, you need to use these tools as learning loops because you will only ever be able to push these models as far as your expertise goes. That's why people there are like incredibly talented engineers already.
-
7:06
, obre el vídeo en una pestanya nova
can build really complex things with these tools whereas people that more or more beginners, you know, it's pretty awesome that they can build their, remind me to walk my puppy app, but the reason that it can't really extend beyond that is because they don't have the language or the understanding to know where they can push these things in the first place. And so... While it may seem basic, having a tool like this that can actually start moving you in the direction of like learning exactly what is going on inside of your projects, I think is an incredibly, incredibly valuable thing that everybody should be doing. But even with having something like this in place, you may inevitably run into the situation that maybe even what we have here is unnecessarily complicated. Like sure, we've built all of these things and technically it works. But the one thing that language models love to do is over engineer solutions to problems, and that is what the next tool helps us with. So the next tool up is called ponytail, and it has one of the best abatars, I think, that I have ever seen for GitHub repo. And so like I said earlier, one of the biggest problems with AI code and tools is that they will 100% over engineer solutions to problems, despite your best efforts, despite like Trying, maybe you try to rain that in, maybe you don't care at all, but it will go out there and build abstractions and things that you do not need for where your project is at now. And so this library is meant to help us solve that problem, so you can kind of think of it like those caveman plugins that we see flying around everywhere, where it's meant to have the models speak to you in like less lines, but this is doing that like for the actual implementation, like Ken, what you are doing be done away with entirely or be done a lot more simply. So if you've ever worked inside of like a SaaS company, you might know someone like this long pony tail, oval glasses. He's been at the company longer than version control itself. You show him 50 lines. He looks at them. Sheaches his head. He says nothing and he replaces that with one. That's what we're trying to do with this library. So let's go in and actually look at how it works. Obviously you're going to install this thing.
-
9:16
, obre el vídeo en una pestanya nova
the way you would install a plugin. So you add the marketplace and then install the plugin. So there's actually a few different commands inside of this. They have the straight up pony tail command and this is going to be helpful if you're like actually attempting to implement something. Then they have this audit command that will look through everything you have and try to understand like where you have unnecessary things in place where you could simplify where you could delete things entirely. and then you can also run this for like actual code reviews. So for example, if we were to come down inside of this project and run the audit command, this thing is gonna run through and hopefully maybe hopefully maybe hopefully not. Tear my code base apart and tell me that I've done a horrible job. Alright guys, so now this thing is done. We can see that it came up with a bunch of things to potentially fix. So one, two, three things that it would recommend deleting entirely because they're either like, not actually used. So in this case, it's like an Expo project. And so we're importing like default Expo things that don't actually get you. So we would want to remove those along with some other files. There's a few areas. I think this is the biggest find. We have 1, 2, 3, 4, 5, 6, 7 things that should be shrunk down. So an example, like, well, one of those things to shrink down might look like is in our case in this app. My philosophy with the planning process is that you should be planning for all of the different like error states way ahead of time before you start building. And so in this case, we have at least three different error states specifically as it pertains to this strip thing that we have in our app. And so we have an error strip, we have a correction error strip, and then we have a safe error strip. And these are all individual components. And the only thing that's really different about them is the copy that's used and like the color and the handler that's inside of it. And so in this case, we should just have one error strip component that accepts these as like properties inside of them. So that's an example of what you might find with the shrink command. And then we have this, uh, Yagni, you ain't gonna need it, which are typically situations when you've like over engineered something that like, yeah, okay, you're maybe planning for like some way off in time thing that like is never gonna actually happen. And so
-
11:27
, obre el vídeo en una pestanya nova
Why create the complexity when you could just do something that again is simpler, which is again the point of this entire library. So in a bit, I'm going to show you like a different take on this type of tool because this is incredibly valuable again, especially if you're not an engineer by background. But even if you are an engineer and you want to be able to like drive this thing in a certain direction. I personally think this type of tool is really, really, really awesome. You just need to find, like, based on your experience level where this fits best in your specific process, like what skills you use to build things, like what's Spectre have been tools you use, and again, where this is going to make sense in the context of all that. But before we get to that other kind of, like, implementation of something like this, I want to show you an open source tool that I found recently that is a huge quality of life improvement if you don't already do it. and it is free. And so you've probably heard the staff before that we can speak things out. I think three times faster than we can type them out. And so that's why you see a lot of people going all in on tools like Whisper Flow where they're just speaking into the model what they want to happen instead of sitting there and having to type the thing because what ends up happening is that when you are typing things out you tend to like cut down on the context that you probably would have otherwise given the thing if you were able to like get that context out of your brain a lot more quickly. And so there's a lot of like paid tools for this that I try. I currently use Whisper Flow, which we can see down here. This is me using Whisper Flow down in the bottom, but it costs money. And so this tool, which is called handy, is basically a completely free and open source version of something like Whisper Flow with like technically like a little bit less. functionality inside of it. Like I don't think it has like AI rewriting capabilities and some things like that, which whisper flow does. But if you don't care about that and you just want like an easy way to be able to dump your thoughts, this is a really great tool for that. And so the way that we can install this thing, there's two options you can go through and like install it be a home brew. You can also just go to their website, download it for whatever platform you are on, downloads very quickly.
-
13:37
, obre el vídeo en una pestanya nova
Then all you need to do is drag it into your application folder. Again, in this case on a Mac, you do whatever it is for your operating system. So we can pop the thing open, except the permissions. And now one thing that's pretty cool about this if we look at it is that we can choose the type of model that gets used like based on the machine that we actually have. So whether you care more about like the accuracy or the speed, you can choose which you want to actually use. Parakeet seems to be a model that is getting a lot of traction for people lately. There's also whisper large, which is slower to process things, but it's very accurate. But we can come through and try for example something like Parakeet. And now just to demonstrate how this thing works, I didn't configure any other settings. We can just come through and do command spacebar. And now as we're sitting here typing out, we could be talking about anything, talking about what our feedback is on like a specific spec that we were looking at inside one of our projects. Maybe we didn't like the direction that it was taking, maybe we wanted to zoom out. explain things in a different way, whatever it might be. We can see that we got that entire thing and it is pretty accurate. Nor is here in type A, we can be typing anything. Follow a block. Again, pretty accurate. There are some differences between something like this in Whisper Flow. Whisper Flow will take out like fluff words and like filler words. So if you're rambling or saying like, uh, a lot, it will take those types of things out. But for purposes of using a language model, I don't really think that matters that much. So if you've been interested in using something like whisper flow, but you can't stomach paying the $20 per month or whatever it is for whisper flow, this is a really cool open source option that you can use. But it would be helpful in this situation to actually put this to the test with something valuable. So how can we combine this with the next skill on the list to really improve our overall efficiency as we're moving through and building things? So the next skill that I want to show you is called Improve. And it is developed by Shatsin or Shadesin. I still don't know how to pronounce it. Comment below and tell me the proper way to pronounce it. So I stopped butchering it on my YouTube videos. But basically what this thing is is it is a code base auditor. So if you remember all that time ago when we had access to Fable 5 for like 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
-
15:58
, obre el vídeo en una pestanya nova
projects. Because in my experience, Fable 5 by itself was really good at improving things where you had like an existing project where there were existing patterns. I know a lot of people were showing off like one shots of new things, which is cool, but I thought it was really great at fixing existing things. The fact of the matter is, I think at like every model jump we should be using those opportunities to like actually improve things we've already built. But until they decide to give that back to us, this skill is still pretty dope, so let's look at how it works. So in this case, what we're going to do is we're going to call this improved command. But then we could come down and we could use a tool like handy that we found in the last video. I need you to do a code base audit of our app, but I want you to specifically look at the effectiveness of our resolver function. How are we parsing the information that comes through on the front end from the user via the chat and deciding whether or not that needs to actually be processed by a language model and it needs to like go off to the agent or if that's something that can actually resolve down to something like a simple search. So this is primarily going to be a language model token optimization exercise, but it is important in whatever recommendations you make that we're still optimizing for the accuracy. so that we are taking the proper actions when we need to. Boom, and there we go. So if I was going to have to type all of that out, I probably would have said I need you to optimize our code base for language model calls, right? But now that I have this capability, I can get a lot more context in there and really flesh out my ideas more. If I wasn't doing this in a video, I probably would have spent more time doing like several of these thought drops into like a text file and then pasting it over. But again, One of the reasons this all of these things kind of come together is because if we were to go back to the draw IOS skill that we were looking at earlier, again, the reason that I was able to know like specifically where I think this like inefficiency actually comes from, it's because I have this type of architecture, a diagram and of like, paid attention to the types of things that were being built inside of the app, reading the specs, and trying to understand what it was doing and why. So I know that all of this logic lives inside of this resolver.
-
18:12
, obre el vídeo en una pestanya nova
and so if I'm able to point the model there, then we're gonna get a much better analysis straight out of the gate. And so one of the reasons I really like tools like this doesn't have to be this specific one, but any tool like this is that it finds these edge cases. So what happened previously in the context of this app is that I already asked Opus to fix this thing for me. And what it did was it fixed this in one spot. So the codebase already has this thing that I'm basically asking it to optimize. But it only put it in one place. It's only in the recipe composition function inside of this app. So if someone's like on their phone talking via natural language and saying, Hey, I need a chicken rice bowl. I had a hundred grams of chicken. I had 50 grams of rice and I had my homemade buffalo sauce. That's like the only place that it gets used. And there's a lot of places in the app where this type of optimization should take place. But in reality, what's happening is that most of this stuff is just being sent directly to the language model. When in reality, A lot of this stuff could resolve deterministically, meaning we don't need to use a language model to do that. And so that is exactly what it found here and now it's moving through and it's enumerating like all of those things that it found. So we have one, two, three, at least four different things that it is pretty confident in what it found is an issue. It's relatively low effort and it's a relatively low risk area to go in and try to refactor. And now one of the things that I really do like about this tool is that it will not go through and implement things like I think a lot of these tools like try to implement the thing in the same breath. This is just going to build you a plan so that you can go and implement this in any tool that you could possibly want to implement it in. So now that it has these plans built out to fix all these different issues that it found just to show you guys like what my concrete next steps for a workflow would be is to create these as GitHub issues. Now the reason that I like to do this specifically goes back to a video I did last week on agent loops, which get a lot of shit for some reason, but one of the really valuable workflows that I personally use is anytime I want to build something and I have a clear concept behind that thing, whether it's a bug, whether it's a feature request, an optimization that needs to be made, like whatever it is, I create those as GitHub issues.
-
20:34
, obre el vídeo en una pestanya nova
And then I make sure that I'm really on board with what the plan is to implement against that issue. And then I can create a giant backlog of these things and then as I'm working throughout the week, I can just have something in the background, moving through, pulling any issues that are open out, implementing them, creating a polar quest, reviewing the polar quest. And then I can step in and do any sort of review that I need to before it actually gets merged into the main project. And so... For me, this is like where that type of thing starts if I'm using the tool like improve and I want to be able to create that backlog. This is how I do it. I see no reason not to use something like GitHub. There are other tools you can use like linear and other project management tools. But since my repo is hosted on GitHub and it works for that, I don't need some super complicated solution. That's what I use and this is exactly how that process works. So later on today, after I'm done with this video. I'm going to be kicking off agents to move through and actually implement on these things. If you guys want to see any other types of videos about the types of agent loops like this that I use, you can comment below and let me know and I can put it a video together on something like that. But now if we were to pop into the GitHub repo, we can see that we created all four of those issues right here. And then I would move through like what I would do is add labels to them, depending on like exactly what needs to be done. So anything with the backlog tag, for example. won't get implemented when I have these automated runs moving through. So you can come up with your own system for how you want to manage these things, but this is a really solid process. And now if we pop in, we know like exactly where the plan lives, we can see like exactly why we're making this change, what we are doing. And then you can come through if you want to, and you can have more of a back and forth chat, you could tag, Cloud for example, and tell it to go out and research something. A lot of different things you can do, but overall. This is a really solid process. Now the last thing that I'm going to show you guys is kind of unrelated to all of this, but I think it's a really dope tool that everybody should be using in certain situations. And so that skill, I guess maybe it's not technically a skill, it is a scanner of skills that was released by Nvidia. So what this is is this is a security auditing toolkit for scanning skill libraries specifically.
-
22:50
, obre el vídeo en una pestanya nova
So I want to give you a really concrete example of how I would use something like this. So there's this repo I came across recently that's going really hard in trending. The only issue that I have with it is that the entire thing is in Chinese. And I'm the type of person that when I want to use a new library, I will typically go through and try to understand how it works. First, before I dip in and decide to start building this thing, you could try to maybe swap the repo to English and move through and try to read the thing. But in this case, this is a priming example of where I don't know what could live inside of this script library. I don't know what could be in here. Like, yeah, I could go through maybe and read some of this. But realistically, if it's in a language, you don't understand there's going to be so many potential issues realistically. That could crop up. And so this is an example of where I would want to scan a repo. And so what we can do is we can come through and copy the URL. And then we can pop down into our terminal and in this case we are inside of the skill specter project. One thing that I will say, just popping back to this. The way that you need to install this and get it to work is that you need to actually clone this repository and then you need to have Python on your machine and I mean, you could have a language model help you with this if you're not comfortable with it, but you need to kick off a virtual environment inside of that project. You need to install the dependencies and then the last thing that you do need to run this, you can run it for free. but you will get a shit ton of false positives to the point that it's not even really helpful. In this case, I am using an open AI API key to run this scam. So we're going to pop down in here and then I'm going to run skill specter scan and then I'm just going to paste in the repo. And now this thing is off and running doing this scam. And so especially if you are like an open claw, Hermes, Chad, you know, that's automating their entire life allegedly making a million dollars a day doing no work because the you know the Hermes bot goes out and sells stuff for you. But even if you just like to experiment with things, skills are a huge like attack service for people that live in their parents, basements and he cheetos. And also for serious talented hackers that just want to take advantage of whatever it is that you've built. And so being able to like scan things like this is incredibly valuable.
-
25:01
, obre el vídeo en una pestanya nova
So in this case, I mean, I'm actually somewhat surprised. This says that this is a critical issue, this repo, and do not install it. So it's interesting. Let's try to move through and understand why that's the case because again, it could be something that like maybe you are willing to, I don't know, like bypass that and just do it anyway. So I think the biggest issue is that it has a lot of functions inside of it, which I mean makes sense that are executable, right? So this thing can go out and use like X a search and get hub search and all these other search functions. You're giving like executable access to these scripts on your machine. Now in this case there's like 63 different issues that it found and for me it I mean I think to be able to read through all of these things and parse that out it's like yeah, you could do it, but this is like a ton of stuff and so for me what I did in this case was I pasted all these into clawed and asked it to like describe realistically like based on the design of things like what would the attack situations actually be? Number one, they have these things where you need to like paste your cookies in and That is obviously like a very very very risky thing to do because that can give like any attacker realistically that gets access to those things complete control over any of the things that you pasted in your Twitter sessions, your Reddit sessions, like any of that stuff they can gain access to. So number two, which I think is probably like seems to be for me like a bigger issue is that you can just allow remote code execution through unverified install and update scripts. So in this script file that they have. There's an external install script that you are basically downloading a piping straight into your machine. And that, again, is a serious, serious issue. And I feel like we've seen enough of these like supply chain compromises recently that even if this person wasn't malicious, that just seems like a very easy way to get yourself completely pwned. So that being said, while still specter wasn't like as related to all the other ones, I do think this is like an incredibly valuable thing. And if we were to pop in and see like how much did that actually cost to run. I've done a few of these scans and I've been using my open AI stuff for other things this month. So that did cost actually about $5 for me to run. I've done other ones on smaller repos and it cost more like 20 to 30 cents. And so just for full context, like that is what it cost to do that type of security scan on a like a relatively larger I guess project. There we have it five like I think relatively new repos that I hadn't heard really of any of these. So I think they're pretty dope.
-
27:24
, obre el vídeo en una pestanya nova
If you found this video helpful, make sure to subscribe, but that's it for this video. I will see you in the next one.