Productivitat Intel·ligència artificial Programació Claude Code agents

Cinc ordres de Claude Code per treballar amb menys context perdut i més control

Què fan realment /doctor, /goal, /statusline, /recap i /btw, quan convé usar-les i per què l’autonomia necessita criteris de finalització verificables.

El vídeo de Sean Kochel presenta cinc ordres de Claude Code com si fossin «trucs» reservats a l’1%: /doctor, /goal, /statusline, /recap i /btw. En realitat són funcions documentades i útils quan s’apliquen a problemes concrets. El seu valor no és secret; consisteix a fer visible l’estat de l’agent, donar-li una condició de finalització i evitar que una sessió llarga es converteixi en una pila de fils oberts.

La demostració també conté una idea més important que qualsevol ordre: un agent que escriu codi ha de verificar el comportament real. Que els tests passin no garanteix que provin el que l’usuari necessita.

/doctor: diagnosticar abans de gastar context

Al minut 0:30, Kochel executa /doctor, que també anomena «checkup». L’ordre oficial revisa la instal·lació i la configuració de Claude Code. Les versions recents poden assenyalar problemes en fitxers CLAUDE.md, servidors MCP, paquets o opcions carregades.

La demostració posa l’accent en complements globals que ocupen context encara que una sessió no els necessiti. És una bona disciplina: cada instrucció, memòria, skill o definició d’eina té un cost i també pot confondre l’enrutament. Però el percentatge exacte que «hauria» d’ocupar cada categoria no és una regla universal. Depèn de la finestra disponible, del projecte i de si l’eina aporta prou valor.

Una revisió segura té tres passos:

  1. executar /doctor i llegir cada avís;
  2. usar /context per veure què s’ha carregat realment;
  3. desactivar o moure a nivell de projecte només el que es comprèn.

No convé esborrar configuració automàticament sense saber si un altre repositori la necessita. El mode segur i una còpia del fitxer de configuració redueixen el risc de «netejar» una dependència legítima.

/goal: autonomia amb una condició verificable

Al minut 5:04, el vídeo mostra /goal. L’ordre fixa una condició i permet que Claude continuï treballant entre torns fins que un comprovador determini que s’ha complert. És apropiada per a migracions, cues d’incidències, refactors amb límits mesurables o una bateria de proves.

La qualitat de l’objectiu depèn de la seva sortida. «Millora l’aplicació» és ambigu. «Totes les proves passen, cada criteri d’acceptació està verificat i el diff no conté canvis fora d’aquests mòduls» és auditable.

Kochel aplica la funció a una llista de smoke tests d’una app iOS. Demana que un agent controli el simulador, provi cada cas i documenti si la interfície coincideix amb la intenció. És un bon ús perquè hi ha una llista finita i una evidència observable.

També hi ha límits. Un agent pot:

  • declarar acabada una prova massa aviat;
  • escriure tests que només confirmen la seva pròpia implementació;
  • quedar atrapat corregint símptomes;
  • consumir molt context o executar accions costoses;
  • modificar més superfície de la necessària.

Per això cal definir pressupost, permisos, comprovacions i punts d’aturada. Per a una migració gran, una revisió humana del pla i del diff continua sent part del criteri d’èxit.

Tests verds no equivalen a producte correcte

El vídeo insisteix que els models poden crear una prova que passa però no valida el comportament desitjat. És una observació essencial. Un test pot comprovar que una funció retorna el mateix valor que acaba de codificar l’agent i ignorar el recorregut real de l’usuari.

Una verificació equilibrada combina:

  • proves unitàries per a regles petites;
  • integració per a base de dades, xarxa i serveis;
  • smoke tests sobre el recorregut principal;
  • comprovació visual o d’accessibilitat quan hi ha interfície;
  • revisió del diff i dels registres;
  • un cas negatiu que demostri que la prova falla quan ha de fallar.

La millor condició per a /goal no és «la suite és verda», sinó «la suite és verda i aquests escenaris observables produeixen aquest resultat».

/statusline: l’estat del model i del repositori a la vista

Al minut 11:50, Kochel configura /statusline perquè mostri model, directori, branca, ús de context i límits temporals. Claude Code pot generar un script de barra d’estat a partir d’una descripció en llenguatge natural i registrar-lo a la configuració.

És especialment útil quan hi ha diverses finestres o worktrees. Veure la branca redueix el risc d’editar el lloc equivocat, i el percentatge de context avisa quan una conversa necessita compactació o un nou fil.

La barra no és només decoració: executa una ordre de shell. Cal inspeccionar el script generat abans de confiar-hi, evitar que imprimeixi secrets i mantenir-lo ràpid. Una crida de xarxa o una consulta Git pesada cada pocs segons pot alentir el terminal.

L’ordre /context complementa la barra. Mostra el repartiment entre prompt de sistema, fitxers de memòria, skills, eines MCP i missatges. La status line respon «quant s’està usant»; /context ajuda a entendre «en què».

/recap: reprendre sense rellegir tota la sessió

Al minut 16:22, /recap genera una línia amb el treball actual i el següent pas. El cas del vídeo és un sistema que importa dades de vídeos i recorda actualitzar-les setmanalment.

Aquesta funció redueix la càrrega cognitiva quan es reprenen diversos terminals. També exposa projectes a mig fer: si el resum sempre diu que falta la mateixa acció, potser cal acabar-la, descartar-la o convertir-la en una tasca explícita.

Un recap no substitueix documentació durable. Decisions d’arquitectura, riscos, credencials pendents i passos de desplegament han d’anar en un issue, un fitxer del projecte o el sistema de seguiment. La línia generada depèn de la conversa i pot ometre un detall que demà sigui crític.

/btw: una pregunta lateral sense contaminar el fil principal

Al minut 17:36, el vídeo usa /btw per preguntar on s’estan guardant els informes mentre l’objectiu principal continua provant l’app. La documentació defineix l’ordre com un apart ràpid que no infla l’historial principal.

Si la resposta obre un problema nou, la conversa es pot bifurcar. Kochel ho aprofita per investigar les causes dels tests fallits en paral·lel. És una manera neta de conservar el focus.

El risc és crear dues branques mentals i tècniques que modifiquin els mateixos fitxers. Abans de fusionar resultats cal comprovar:

  • si totes dues branques partien del mateix commit;
  • quins fitxers ha canviat cadascuna;
  • si la investigació lateral ha invalidat el pla principal;
  • quina evidència ha produït cada agent;
  • si els canvis es poden integrar sense duplicar o perdre treball.

/btw és ideal per aclariments i exploració. Una decisió que altera requisits ha de tornar explícitament al fil principal.

No cal usar totes les ordres sempre

Les cinc funcions resolen problemes diferents:

  • /doctor quan la configuració no és fiable o sembla pesada;
  • /goal quan hi ha feina llarga i una sortida mesurable;
  • /statusline i /context per observar sessió i entorn;
  • /recap per recuperar continuïtat;
  • /btw per apartar una pregunta sense interrompre l’execució.

En una correcció de cinc línies, activar autonomia, subagents i una barra complexa pot costar més que el canvi. En una migració de cent fitxers, aquests controls poden evitar hores de supervisió manual. L’eina adequada depèn de la mida i del risc.

En resum

El vídeo converteix cinc ordres documentades en una introducció pràctica a Claude Code. El millor consell no és memoritzar-les, sinó associar cada una a una fallada concreta: configuració opaca, objectius sense final, context invisible, sessions oblidades o preguntes laterals.

Ben utilitzades, fan l’agent més observable i persistent. No eliminen la responsabilitat de definir què significa «fet», limitar permisos, revisar scripts i comprovar el producte real. L’autonomia és útil quan la sortida es pot verificar; sense aquesta condició només accelera la incertesa.

Contrast i context

Fonts consultades

4 fonts
  1. 01
  2. 02
  3. 03
  4. 04

Font de treball

Transcripció amb marques de temps

10 fragments
Consulta la transcripció
  1. 0:00 , obre el vídeo en una pestanya nova

    In this video I'm breaking down five new Claude code commands that can help take you to the next level because most Vibe coders think they need complicated tools or mountain of skills in order to build something that they'd really be proud of, but the reality of the situation is you just need some simple tools executed really well. So I'm going to go through five of these commands, talk about why they're actually valuable, and obviously show you how to use them. We're going to start with the newest of the bunch, checkup. And so this command is again called checkup, also known as doctor. And one thing that I've always been kind of bewildered by is how people blow through like $200 per month Claude Max plans in like the first day of a reset. Then they go out there online and just like complain endlessly about it. And like that that is bewildering to me. And part of the reason that that happens is that when you're going out there and installing all of these different skills and MCP servers, those things are going to clog up your context window. So those things are going to be loaded in by default, especially if they are installed globally on your machine. They're going to get used and passed in every single chat. And that can take up a lot of space. And so what this command does is it helps us look at the like general setup of all of our different MCP servers, agent definitions, skills, plugins, globally installed packages, all of that stuff. And make sure that we're not like shooting ourselves in the foot before we've even gone out and launched anything. And so in our case this thing has run through and it's now done a checkup against like eight different parameters. So let's actually walk through and talk about them really quick. So the first one is just like general setup health. Health so like are is anything like actually straight up broken or do you have like dangling files like install files or configuration files somewhere? That's the first thing that it's going to look at. In our case, nothing to fix. Uh number two, unused extensions. So, are there things like plugins and things like that inside of the system that you have installed and they may be taking up

  2. 2:09 , obre el vídeo en una pestanya nova

    context, but you don't actually use them. And so, these things can obviously be disabled like you are not using them. So, we can move through and cut those things out. Our Claude markdown file, I mean, this is one source of like a lot of waste from people. In this case, like one thing that I'm really big on on this channel, inside of my paid community, like anywhere's that if you really want to be good with this stuff, you have to be like militant about how you manage your Claude markdown files. And there's certain standards that you should conform to. So, like in in my case, there aren't any findings. Like our Claude markdown files are pretty pretty legit. Too legit to quit. And so, they're all under like these warning thresholds. The lines aren't too long. Like they're not contradicting each other. We're not like putting stupid stuff in there. So, all good to go on that side. And so, we're just continuing through. The The one thing, and this is going to be the big thing for like 90% of people that are watching this video, is the context check. The biggest issue that you are going to run into is going to be any like globally installed skills or plugins. That is going to be a big problem and we can see that in this case where roughly like 1% of the context budget should be dedicated to like your skills and your commands and like knowing what they're supposed be used for. And you can run into a lot of issues if that's not actually the case. And so, in this case, I've been developing a lot of skills locally on my machine, which is why I have a bunch of them. I do need to clean everything up. And so, we can see like we are beyond that. And again, that is going to cause problems for you because those definitions are going to get passed through to the model and then you're going to run into situations where skills are not being actually like used or routed properly and other commands can end up not being used properly. So, this is going to be like one of the biggest fixes. Now, the thing that I like about this skill is that it will help you clean everything up. Um I think they just made it so you can actually

  3. 4:07 , obre el vídeo en una pestanya nova

    click on stuff. That's crazy. I don't think I've ever actually clicked on one of those things before. But anyway, hopefully I clicked on the first one. So, I like to use auto mode as a default. Wow, yeah, you can click on it now. That's crazy. My mind is blown. I didn't notice that. Um I'm always on my keyboard. So, I like to use auto mode for like everything now. So, we're doing things like setting auto auto mode to be the default, but generally we're just moving through and again running this like checkup {slash} doctor command to make sure that our general setup is good to go so that we're not just like repeatedly bashing our head against the wall with a bunch of errors that shouldn't even be there in the first place because that sucks. So, if you want a token max on a budget, so token optimize, I guess, you got to make sure that you're not just doing stuff that's completely stupid. Now, this checkup skill is actually a prerequisite for the next skill that we are going to look at. So, one of the big like unsung heroes, I would say, of the last few months, Claude has a version of this, OpenAI has a version of this, it's this goal command. And when you have this goal command, basically what happens is that you can give it a goal that it will continue to work toward, auto compacting along the way as it needs to, until it's actually complete. And so, this is really good when you have like a very large body of work that needs to be done and you have a verifiable end state, meaning you would know and you would be able to tell when that work is actually complete. And so, there's a few situations that they give here that are like examples of where that would make sense. For example, like doing major migrations and making sure that all of your tests pass, implementing a design doc until all of your acceptance criteria are valid, refactoring like very large files maybe into like very focused modules that are under a certain like size budget. My favorite personally, working through issue backlogs until a queue is empty. And this is the one that we're going to use as inspiration for what I want to show you.

  4. 6:19 , obre el vídeo en una pestanya nova

    And so, one of the things I do whenever I want to like build a lot of features at once and have these things just like run autonomously, there's always this idea of the smoke test. Meaning, we need to be able to actually manually test the things that we allegedly just implemented. Like we need to be able to know that those things were implemented the way we needed them to be. And so, if we're trying to, for example, like do a major change or implement something that maybe it's like a few features needing to come together or even one larger feature, typically what you're going to have to do is after you run it and all the you know, the tests are working and all of that, especially if you're building with agents, by the way, you need to go through and actually make sure that the logic that you built is actually functioning because language models will often build tests for you that they are not actually testing anything meaningful and the test passes, but what you wanted it to do is not actually what's happening. And so, this concept is often called a a smoke test where, for example, in the context of like this um agent native like nutrition tracking app, if I was to say something like log my chicken bowl from last Tuesday, it should be able to go out like find that thing in my database and actually log it and then like plan my day based on the things that it found there, for example. And so, if a user was to come through and like type this in, there's different scenarios where different things should happen. And these are cases where like realistically, we would want to go through and test that all of these things are actually happening properly, right? So, for all of these different features, in this case, there's like a lot of different things that we've been implementing inside of Open Spec. All of these things are things that we would need to test manually. And so, we can actually automate this process with something like the goal command. And so, in this case, we could come through and we could do something like this. So, we could use the goal command, and then if we remember what it said needs to be the case is that we have

  5. 8:22 , obre el vídeo en una pestanya nova

    like a verifiable exiting criteria. And so, we could say, "I want you to check every smoke test." So, thinking back to that file we were just looking at, "I want you to test every single one of those things using the iOS MCP." So, this is how we can actually control our simulator. So, I want you to check every single thing with that iOS MCP autonomously, and then I just want you to report the findings. So, I'm not asking it to actually go through and make the fixes. I just want it to go through and actually do each of the test elements. So, in this case, there were, I don't know, a dozen or two different items that need to be tested, and I want it to just go through, actually run these things, and then tell us what the result is. Like, that that's it. I'm not asking it to go through and then spend 50 hours trying to test every single thing and fix it and then retest it. You can do that type of stuff, but that's not what we're going to do in this example. Now, I'm telling you that the task this task is considered done when every single task list item in the smoke test has been tested, and the results have been documented. You should notate if it worked successfully or if there was a failure, and you should be cross-referencing the UI against the intent of the feature. So, this thing that we're testing specifically, this was like a major UI migration. >> [snorts] >> And so we want to make sure that like it it's actually functioning the way it should be. And in this case, just like save our contacts window, I'm saying that each of these phases in here, so like this phase so like this phase, this phase, this phase, they're all done via sub agents. Okay? So now I could run through and I could just kick this thing off. And now this is going to run autonomously in the background. Now the one thing as this thing starts to go that you obviously need to pay attention to is going to be your token usage. And my philosophy with this is that obviously it uses more tokens. Something like a loop or something like a goal is obviously going to use more tokens because it is it's always

  6. 10:20 , obre el vídeo en una pestanya nova

    working, right? Assuming that the goal hasn't been met yet, it is going to continue to be doing things. So when people complain that things like goals and loops and workflows use more tokens, it's like well obviously, right? It's it's working all the time in the background. It's it's constantly moving. So obviously it's going to use more tokens. And so that's fine. We just need to be aware of the fact that this thing is going to be running and running and running. And we need to just accept in our minds that this is like replacing us having to be there doing all of the things manually. And how much that is worth to you is a it's a personal question, right? If you're on a a Claude Code Max plan and a Code X Max plan each on $200 per month, I don't think there's any way in in hell that you could run out of tokens realistically doing these things unless you're just being like incredibly irresponsible about what you're doing. So like yes, this stuff will use more tokens, but it also allows you to go out and do other things. And so this task, this is obviously going to take maybe like one or two hours at least to run through everything and report back. So while this is out and running, we're going to talk about something else, which is well, how then do we actually keep track of all of the spending? So, this one's going to actually be a two-for-one. So, the first thing that I'm going to show you is it's a tool or a command that I've used for a long time, and I'm I'm always surprised when people haven't actually heard of it, and they're asking like, "Hey, how do you get that thing at the bottom that's telling you, you know, all of these tokens that you have used or what you have left?" So, if you come down and you type in status line, we can then come through and actually give it a command. So, for example, I'm going to run status line, and I'll have this exact command in the description below for you. We could say status line, I want to visualize the model in use, the directory, the work tree, current context window size, 5-hour, 7-day

  7. 12:22 , obre el vídeo en una pestanya nova

    context usage limits. And so, what this command is going to do is it's going to actually set this up for you that you can see at the bottom, where we're able to actually see in real time how much of our stuff, you know, our context window like token allocations we're actually using, and like where we actually are inside of the system. So, I like to like keep a track on the model that I'm using, the specific branch that I'm on, making sure that I like I know I'm in the correct branch, and then I keep a laser focus on the exact size of my session that I'm working in right now. These two I typically don't really have to keep track of because I don't come anywhere close to them unless I'm using things like fable. That's the only time I think that I've I've realistically come close to like, "Oh, I need to pay attention to like my 7-day usage." And so, the the second command that we can run here is {slash} context. And so, this is going to give you a an understanding of the usage of your session. So, in this case, we can see as things grow, where is our usage actually going? So, if we think back to earlier with that doctor command and we are trying to think through like where are skills taking up too much of a budget and like where is our budget actually going? This is how we can visualize this and I think they built this because so many people were trying to build their own like open source libraries to help us handle this type of stuff that they just decided to do it themselves. And so, we can see like how much is going to our system prompt, the tools that we're using, custom agents, memory files, skills, the messages that we're sending, like where is our context actually being used? And so, between the status line and this context command, you get like two really powerful insights. Number one, in the course of my conversations, am I using tokens in a really stupid way that I'm not even aware of? And number two, am I losing the battle before it even starts? If you load this thing up and you're already at like a a ton of tokens being used, you have problems, right? You have way too many skills being loaded up. Maybe have way too many like agent

  8. 14:34 , obre el vídeo en una pestanya nova

    definitions, memory files, things that are just consuming tokens potentially for no reason at all. And that is a huge waste. And so, if we were to pop back into that gold chat, this thing is still running, right? So, it's still out there. It is interacting automatically with this simulator, testing all of the things, logging exactly what is happening, interacting with it. It's really awesome. But now, this can also create like a different problem for us. And so, if we're doing all of this stuff in like three, four, sometimes like five different agent sessions all at once, and then you need to like step away and go somewhere, that can create a big problem for a few different reasons and I don't want to go deep into the philosophical rabbit hole, but human beings have a a really hard time managing cognitive load when there's a ton of open loops. So, if you've opened up like five of these things and then you have to go somewhere, you've now just generated a ton of context that hasn't necessarily been addressed. It hasn't necessarily been tied off and it can be very difficult to load back up on that context when you step back to your computer. And so, this next command can actually help us manage a bit of that cognitive load. So, let's say for example, like I called it quits last night at 8:00 p.m. and now I'm coming back to my machine in the morning and I have like a bunch of these different terminal windows, right all across here and I'm working on a bunch of different stuff. I'm working on like automated topic sourcing systems for my social media stuff. I'm building like workflows that can just generate things autonomously all by themselves, which is, yes, redundant to say. I'm debugging a bunch of other skills that I have. Like I have like three, four, five different things going on at the same time. And now I want to come in and check on like, what dude, what was I like actually working on here yesterday? What I can do is I can come through here now and I can type in recap. And so, what this is going to do is this is going to generate like a one-line

  9. 16:36 , obre el vídeo en una pestanya nova

    recap of exactly what you were working on in this project. So, in my case, I have this project called Topic Genie and what were we doing? I was trying to import my last year of videos and the different outliers for my channel. And then I wanted to add in a reminder to me every week when I run this that I need to update it with new data from both myself and my competitors. And so, it went through and it built everything and the next action is mine. So, there's nothing much to do here. That one is good to go. And so, this is really important because you absolutely will build a habit of half building things and like never getting things truly to the finish line because you're constantly getting this like whiplash between a growing pile of half-done stuff. And that's bad for like very obvious reasons. And so a command like this helps us rein that type of stuff in. And so the last thing I want to show you is a command that I I also really really really appreciate. Like when you need it, it's awesome. And that command is called by the way. So if you were to come down here and you were to type in w, this allows you to have a quick like side conversation with the model without flooding that context into this main window. So right here, this goal thing is still running through and like testing our app. So if we were to pop over here again, it's searching through the library. It's trying to interact. It's like it's doing all of that stuff. But I might be on a train of thought where like I want to have a conversation or ask something about this. But I again, I don't want to interrupt that main process. So we can use this by the way command to get something off our chest. So an example of this in the context of this project, uh the way that this like model like agent loop is working since this is a a mobile app and we don't have like a server necessarily on the back end is that we're using Superbase's edge functions to call the language model APIs and like run this loop that we have. And so something that I'm I'm thinking of as this is going is like did we actually like modify those functions properly and because we like changed a few of like the inner workings

  10. 18:41 , obre el vídeo en una pestanya nova

    of things, I want to make sure that that's the case. And so we can come down and we could type in by the way and then we could ask it some sort of uh question. So we might ask something and we could use like a really basic example, where are all of the reports being output to? And so now we can see we have this directory called smoke results. And now the reason I wanted to show this to you is that we have this option to actually fork the chat. So if we were to type in F in here, we can now actually like continue this conversation from this specific point. So, this is almost like we've now forked off a completely different chat where we can now basically operate within our own sub-agent to continue this line of reasoning. So, an example here might be something like start prioritizing and investigating root causes of everything that's failed so far. Now again, this is going to happen inside of a sub-agent. It's going to go out. It's going to start responding to like whatever this command was, and then we still have all of like our main work being done with the actual like testing taking place inside of that main thread. So, I really love this like by the way and forking functionality so that you can like interject when you need to, and then if for whatever reason like you want to continue down that thread right now, you can do that here, and you're not going to again like just get lost in the context of everything that is happening. So, collecting like tools and knowledge like this like can be valuable, but it doesn't really mean anything if you're not like deploying it into building things that actually work that you either use for yourself, you use in the workplace, you're packaging it into like an app or SaaS, and you're trying to sell it. Don't be the guy that just lets skills grow dusty on a shelf. So, if you want help with implementing any of that stuff, you can check out the links in the description below, but that is it for this video. I will see you in the next one.