What Claude Code Can Do That You Haven't Tried - Gui Ferreira - NDC Oslo 2026

9,444 words · about 38 min to read · YouTube’s automatic captions

0:11 Hello. So, based on the number of people in this room, I think it's safe to say that Cloud Code is quite popular. But also, it's safe to say that things keep changing too fast and it's hard to keep up. And that's the point of this talk. So, if I ask how many features do you think Cloud has, I'll get many different numbers for sure, big numbers. And I couldn't get the number, but I could get the number for the number of slash commands, those that you start with a slash and you write something, that are available on Cloud Code by default.

0:48 And on Friday, they were 104 slash commands. Since then, I didn't check X or whatever we want to call it. So, maybe they're already 105 or 106 because it's really hard to keep up with these things, okay? And in the past few months, I've been teaching this thing about Cloud, and I've noticed one common thing.

1:14 You pick Cloud for the first time, you start Cloud, you ask to build something, and in a couple of minutes, you are so much more productive than you used to be. Okay? It's doing a ton of things for you. It's writing tests. It's doing reviews. It's finding bugs. And you just learn 10 to 20% of it. Personally, I believe that if you learn all the types of things, you might find some important details that improve your workflow, your quality of life. And that's the point of this talk. So, what I want to share with you, and this comes from someone that is not affiliated to Anthropic at all, is just someone that uses the tool every day and that feels that the tool is helping him a lot. So, every single thing that I will share today are actually things that I use in my day-to-day, okay? And I will organize those in four different buckets.

2:04 Stuff that you can do once and take advantage of it forever, okay? You configure it, you take advantage of it, either you and your team or you alone. Also, we'll talk about daily workflow things. So, stuff that you can use in your day-to-day in certain scenarios. They can be quite useful. And during the process, we'll talk about also things that you can customize, you can extend Clojure during your day-to-day. But, I want to focus not on the things that are available, but because those became quite popular if you have ever used Clojure. I want to talk about some scenarios that we tend to ignore. And finally, I want to leave this room by sharing with you a couple of other scenarios where you can use Clojure code, okay? Things that don't involve code at all, okay? That's the goal for this session.

2:52 Warning. This is a session for those that once run Clojure. Okay? So, that's the idea. And uh I will not be doing uh demos like intro demos, that's not the point. This is a rapid-fire style of talk. So, during the next hour, we'll go through roughly 40 different things that I want to share with you. So, we are going fast, okay? So, bear with me and watch the recording afterwards if needed. My point here is the following, and that's my mission for today, and I want to do that today. If you leave this room and you have the feeling that on Monday you need to open Clojure and run two or three of those things that I will share with you, for me is a huge success.

3:36 Because some of the things that I will share with you, you might be familiar with them, they are old things but good ones, others are new things uh and great ones as well. So, to start, we need to first talk about where we run Clojure. You can run Clojure inside of your terminal, you can run Clojure inside of uh your editor as an extension. You can run Clojure as a desktop application. Personally, I like to use the terminal.

4:03 I feel that it's faster. Also, usually the experimental features come there first. That's the reason why I use it. So, I will be sharing print screens from the terminal, but most of the things that I will share with you work wherever is the environment that you prefer.

Migrating configurations and securing sensitive settings

4:18 Just uh to share that with you. So, let's start. First pillar, um set up type of stuff. So, let's say that in the past few months you used Claude in the past and you changed to something like Codex or Cursor. And after this session you are too excited to go back to Claude. What you can do, slash import and the name of the product where you want to get your stuff. Basically, this will pick your MCP servers, configuration files, uh sub agents, all of that and bring it to Claude. So, you don't need to do that manually. Why does this happen?

4:55 For a simple reason. Unfortunately, the standards that we have with coding agents are not that great standards. So, everyone is doing things differently. At least they are putting the files inside of different folders. But the worst of them is actually the Claude.md. That is one of the most important files

Optimizing claude.md files based on empirical research

5:13 that you have in your project. But if you work with other thing, you will be naming that thing as agents.md. And this file is so important, um but I believe that we have created some misconceptions in the industry. Also, if I would come here to be honest last year and I talked about the

1 Highlight · Keep claude.md lean to prevent performance drops

5:32 Claude.md, I would be saying, "Put there every single thing that you can think about that can be helpful." Write it a document as most complete that you that you can. You can have every single thing there. That's actually wrong, okay? Finally, we have studies that prove that that's not the way of doing it. ETH Zurich ran the a study and proved that we have some problems. So, we need to have some techniques. And one of them is this problem of the typical duplication.

6:02 So, it's quite common that you'll see things moving around between your projects and eventually you have information in the readme and another and the same information in your cloud.md. Eventually, your agent is absorbing all of that those files and becomes confused. So, tries one way, doesn't work, it needs to go through another one. Actually, cloud supports this import type of thing. So, you do the at and the path to the file and you can bring that file with the cloud.md. So, if you have something like team rules or a given schema that is super important for that API and you want to have it as part of your cloud.md, you can do it. Whatever is the extension that you want. So, avoid the duplication that can lead to some problems. As I was saying, ETH Zurich proved that the performance when you have a long and descriptive cloud.md, it tends to drop in 3% and your costs will increase in 20%.

7:01 And they run the study based on cloud.md, agents.md. So, cloud, codex and so on. And they did the the study with groups that were handcrafting the cloud.md, groups that were generating the cloud.md and groups that had no cloud.md at all. And they proved that a good cloud.md, one that is efficient, is actually one that is lean enough.

7:27 Okay? So, that you throw away things that are useless. So, I usually ask three questions to clean my cloud.md and I challenge you to do the same. So, I go for each instruction that I have there and I will ask the following. The first one is do I need this thing for every single task? Okay? If I imagine every type of

7:48 iteration that I have with cloud, is this actually useful? So, if it might be useful, let's keep it there. If it's something so specific that I only do that once in a while, like running my performance tests, maybe let's move that to something like a skill. Or if it's something like the rule for your team for JavaScript or for C# or for whatever, you can create rule files inside of Cloud.

8:14 .cloud/rules and you can create files there that are specific to languages or specific to uh file extensions. And finally, I'd like to ask if um the agent could figure out this thing alone. I used to add to my cloud.md things like the folder structure, like here we are using vertical slices and you will find the controllers here, the endpoints here, the models there.

8:40 That information, your agent can't find it alone. And if you write it once, eventually it will drift from the reality, so it can lead to problems. The good news is that is that you are the lucky ones and quite recently uh Anthropic decided to add to the slash doctor exactly these type of things, so this cleanup. The slash doctor can uh uh check the state of your current installation of Cloud, if you have something that is misconfigured, but also when run inside of a given project, it will go through your cloud.md and apply those three questions to the duplicate stuff, to move things to skills, okay? It can do that for you.

9:21 So, at least do that one. And remember that cloud.md is a file that is so much more than that file that you usually create in the context of a project. Because otherwise, what will happen is that you'll have your own preferences, things that you want Cloud to do that way. For example, for a long time I was doing test-driven development, but I don't want to force other people to do it. So, what's my option here? You can actually create a cloud.local.md, Git ignore that file, and have your own stuff there, okay? It doesn't impact anyone else.

9:55 The things that are shared with your team go to the traditional cloud.md, but there's one more that we tend to ignore. There's a user profile folder named .cloud where you can find the cloud.md and where you can find things like your settings. But, they are things that apply to every single session. So, if you have something like I want you to talk with me, let's say I'm Portuguese. So, let's say that I would prefer Claude to talk with me in Portuguese. I could go to my user profile, so I know that every single session that I start with Claude Code will follow that instruction. I don't need to keep copying it to the many different projects that I work with.

10:35 This is the things about Claude Code, but there's another important file inside of your project under dot Claude that is the settings. And there, um, please promise me that you'll do the following. And for that, let's use an example. Imagine that you are trying to fix a database connection issue that happens only once in a while. And you ask Claude to do it, and what Claude will do is that it will say, "Yeah, you are right. That's really an important issue. Let's address it." And will try his best to find the solution.

11:06 And will try and try and try, and to finally be able to help you, will read things like your secrets, your settings, your environment variables. And it will do that unless you deny it. You might say, "Okay, but no one puts production keys on the the settings files. You are lying. Uh, if it's not you, because we are all perfect, someone in your team will do it one day when it's actually needed. And in that moment, your keys are going over the wire to Anthropic.

11:42 So, this is a small thing that you can do. Go to the settings.json, permissions deny is a collection of extensions that you want to exclude or bash commands that you don't want to run. That way, you guarantee that those files or those commands are not never executed or seen by Claude Code. It's a small thing to do that is quite important. But now, let's talk about the things that you said to help that we actually like. So, we are developers, we are super proud of the setup that we have on VS or Visual Studio, right? So, one thing that has been missing for a long time was themes. And we all like to pick a different theme or create our own theme. Now you can do it, okay? You will pick the theme. Obviously, if you are in the context of the terminal, you you will need to deal with the theme of the terminal plus the theme of uh Claude code. But for the things like the font, the way that you see the source code, you can actually do it. It's quite simple and you can do it once.

12:40 And the other thing that is even more important than theme, and this one you should do it, is to create your own status line. I like to see the status line as a dashboard that I have over uh my current session. Why? When I'm working, I need to know where I'm working, what's the project. I need to know, for example, I like to know the branch. I like to know the current model that I'm using. I like to know things like the percentage of the context window that I'm using. That type of information is useful after a few minutes, I promise. And it's quite simple to create your own status line, something like that. You just need to chat with Claude code using the {slash} status line and Claude can tell you what is available. And then, that will create a script for you that will be uh running on your behalf and you uh have always visibility on the things that are happening.

13:33 So, do those things once and you'll take advantage of them forever. Now let's go to the uh uh

Mastering interactive planning, rewinds, and effort levels

13:40 most extensive part of the talk. So, the daily minor things that you want to do in your day-to-day. And I've learned during the World Cup that is important to have an hydration break. So, sorry for this. Thank you. So, you have been using Claude code and one of the things that you you might came uh to to the conclusion is that it is a good idea to first plan the changes that you are about to do instead of doing them right away. That's why we have the plan mode. You can do the shift uh tab and you navigate through the different modes and eventually you get to the plan mode. What will happen is that Claude will do a research to understand the best way to implement something.

14:26 Sometimes it comes back to you with a a description of how you going to do the thing that you want. But you there's something that is wrong. What I used to do is that I would have a conversation. I would keep going like, "Okay, but I don't want implementation this way. I want that way. Please change that thing, okay?" But eventually we were just discussing details. Just one line that was wrong or something that I could write myself. And it's not that productive to keep chatting and having Claude refining that

2 Highlight · Collaborate on plans using Ctrl+G markdown editing

14:57 plan. You can actually do something different. Once you see the plan, you can do control G and that will open your plan as a markdown file in your editor. You do your changes, you save it, and Claude recognizes all of those things and keep going. Okay? Looks like magic. It's like a shared Google Doc with Claude, okay? You are collaborating with Claude and Claude is using that file. So, it's a pretty cool and pretty useful tool.

15:26 Another thing that happens with plans is that I came to love this idea of having

15:34 Claude interviewing me. Because quite often you ask for a plan, but by the end the plan has a ton of assumptions that you don't think about them. We have been building software for a long time and we have learned that usually the understanding of the problem will come weeks later when we are writing a line of code and finally we have to write that if statement that reveals that no one discussed the given topic. And Claude can assume a ton of things for you because it wants to be productive. And if you have a prompt that is not descriptive enough, a ton of a ton of assumptions will be there.

16:08 So, what you can do is that you can take advantage of those questions that usually pop up from Claude saying, "Do you prefer option A or option B?" But you can force Claude to do that. There's this thing inside of Claude named the ask user question tool. So, you can simply say, "Hey Claude, interview me and don't stop until we clarify every single thing." Okay? And we'll keep going, keep going, keep going, and improving the plan. That way, you will realize that things were not as clear as you thought in the first place.

16:37 And you can be involved in the decisions instead of only finding only finding them once the thing is implemented. Okay? Do that uh is super useful as well. During this process, when you are planning, sometimes you might realize that Claude comes back to you with questions like, "Hey, um I know we need to build this API, but do you prefer to use something like MVC pattern or something like uh minimal APIs?" And you think about it, you might ask, "What do you recommend?" And Claude says, "Okay, I recommend MVC pattern."

17:13 You say, "Okay, let's do it." And now you we start implementing, and eventually, you start looking into the code, and you don't like it. You think, "That was too much for this problem. I want to go back to the other thing." So, what do you usually do? You prompt again, and you ask Claude, "Okay, let's refactor this thing, and let's move away from MVC and go to minimal APIs." By doing that, you are basically taking steps forward towards the thing that you want.

17:42 However, by doing that, there's a problem. All the past directions, all the past code that was generated will stay in the context window. By staying there, once your context window is big enough, it might have a negative impact in the future iterations. So, what can you do instead? You can take advantage of an amazing feature that feels like time traveling. That is the rewind. If at a a given point, you want to go one step back, you can do double escape or {slash} rewind, and then you can take the direction that you want. It's like taking one step back to then take two steps forward. Okay? That's the idea.

18:21 Looks like uh reverting something with Git, but Claude is doing that for you, okay? And you can always navigate to the proper message, the proper prompt, and adjust that prompt during the process. Talking about uh plans and implementing those plans, there's a common recommendation that is you need them a powerful model to uh plan and a cheaper model to execute.

18:48 That's a a common saying in the industry. So, one thing that you can do is in the middle of a conversation run {slash} model and pick the model that you want. So, once you do this, you will want to have that status line, so you know which model you are using. But, what most ignore is that this is not only about Sonnet, Opus, Fable, Haiku. Inside of each model, you have different levels of efforts, different different levels of reasoning. They will cost more or fewer um tokens. So, you can actually change for that thread the effort level. You can say, "I want to use to the to the planning Opus, and to implement, I also want to use Opus, but with a a small level of effort, for example, okay?" And you can change that for the whole thread.

19:40 One of the problems of changing that for the whole conversation is that eventually you will forget it, okay? At least I do. So, sometimes you are fixing a bug and you want to run the a prompt and you say, "Okay, let's fix this thing." But, it is a hard thing to fix. So, you don't want to change the effort level. What you can do is to take advantage of ultra think. So, you just write ultra think, and what is happening is that Claude is running that specific prompt in max effort level for you, and then going back to the past one.

20:12 But, if you don't use this for this reason, use it just to see the rainbow that they will uh do. It's a nice animation, okay? Talking about um this type of thing. So, you let's say that I'm now implementing my feature with uh X high level. So, it might end hopeless or fable, and it will take some time. While it takes that time, what do I do? Do I stare at the computer?

20:39 Many of us start writing the next prompt. Okay, so we think, okay, what's the next step once this one is finished? So, I used to start writing that one, uh but eventually sometimes Claude will stop during the process saying, "Hey, on this problem, what should we do?" So, I would need to copy that prompt to a notepad, and then get it back there, uh and that was a mess. But actually, it's as simple as doing control S. That will stash the current prompt. So, it's like putting that uh current prompt on another place, like another file, for a moment, and once you click it again, you will get back to the conversation. So, let's say that you are writing a long prompt, you do control S, it goes there, you answer Claude, you bring the the other one back, and you keep going. You don't need to be using notepad and so on uh for that. So, this one uh saves a a ton of time.

21:31 If what you actually have is a question, is not the next prompt, is something that you want answered uh right away, you can use the by the way. Why? If you write your next prompt, it will wait until the previous one finished to answer you back. But let's say that I'm working on the key feature, is implementing the feature, and in the middle, I think, okay, did we discuss this aspect? Uh how are we going to do this thing? Is with this pattern or with that pattern? So, what I can do is that I run the slash BTW, that is by the way, and it will run that as kind of like a a side

Managing token costs and context window pollution

22:07 type of thing, doesn't pollute the context window, and will get back to me while it's working on the main execution. So, you don't need to keep waiting on that. Let's talk about the most important aspect of being a developer nowadays. That is money. Uh in the past, we were super concerned about uh cost when we got the decisions in terms of infrastructure. What's the database that I'm using? Am I using a cloud platform for for something? What's the idea that we have here? Or maybe I have a routine that is too inefficient for my data set.

22:42 Nowadays, we need to think about the tokens that we consume to write a small endpoint that just does CRUD with a database. So, it's important to have an idea of how much each session is costing us. I like I like to bring that information to my status line. But also, you can do that through the terminal as well. If you run status, you can find not only your most used model, but also for by the end of a session, you can see all the models that were involved because sometimes Claude will start models that you don't expect. Why? It starts using sub-agents with different types of models, so you can have a clear picture on much does it cost to implement a given feature if you were paying each token. Okay? That can be quite useful, and besides that, by the end of the year, it makes a great print for X.

23:30 Okay? So, that's the idea. Cost, we are talking about context. You can check the context window by running

3 Highlight · Diagnose context bloat and proactively compact sessions

23:39 {slash} context. But the idea is not that. Why I'm talking about this? This one is super useful when you are in an empty session. So, you start Claude, it's empty, and you run {slash} context. Why? Because this way, you can actually diagnose what is happening. You can see what types of things go to your context window without you asking for it. You can see the types of things that you have configured in your project that might be there and you don't need it.

24:09 Because it's quite cool nowadays, you go to LinkedIn and you see uh someone posting uh my top 10 agent skills. So, let me download them all and put them in my project. But each skill has a small footprint. So, you need to do your own maintenance. So, running the {slash} context when the session is empty, and if you see that it's taking 8% for example, do something. Go and try to understand what is there, okay? Because each token that you are consuming will have an impact in the future.

24:40 That relates to a concept that is is based on opinions, okay? By the way, it's based on opinions of many different people. I'm not aware of any study that proves this, but there's this idea that once you get to the 40% of the context window, you get into the danger zone. What does it mean? It means that once you reach that limit, your um quality, the quality that you get out of each token is not as good. So, each dollar that you invest in a token doesn't return the same amount of money to your pocket, okay? That's the idea.

25:14 So, what can you do? First, you avoid that you bring to bring things to the context window that that you don't need, but also, you can do uh another important thing. That is taking care of the compaction. Compaction will run automatically when you are reaching the 100%. So, Claude will go, summarize your history, replace that history with a summary, and you can keep going. Why not doing it yourself?

25:40 So, when you start seeing that Claude is always doing trial and error, so you are trying to fix something and it's trying, okay, doesn't work, and you are basically asking, "Are you stupid? Why you don't you get this?" Okay? Try again. This time try harder. When you're doing that, it is it means something. It means that you need to clear something from your context window usually. In that moment, be proactive and run the slash compact yourself.

26:08 Personally, when I'm working on a feature, I split implementation in multiple parts. Let's say that first I do the data model, then I will do the the domain model, then I will do the UI. Let's say that was something like this. So, by the end of each one of these sections, what I like to do, instead of starting a new conversation, if I know that the context of this one might be useful, I compact and I keep going. Because that information took some time to build it and the agent will appreciate it. So, it will be useful.

26:38 Inside of your contacts, you will see many different things popping out.

26:42 And one of them is quite curious. Because sometimes you don't ask for it. There's this concept named memories. And memories became auto loaders in many applications. One of the interesting most interest interesting stories of my utilization of ChatGPT has been the day where I realized that ChatGPT was always calling me Emily.

27:10 But that didn't make sense to me because I never asked to be called Emily. So, I went to the memories folder and I realized that back in the days I asked Claude to parse a given blog post to summarize and Claude no, ChatGPT. And ChatGPT he concluded that since the blog post had a sentence like my name is Emily, that I would be Emily. So, it will capture things that you don't imagine sometimes. So, you need to be proactive maintaining those things.

27:41 But it's not only about throwing away things that are useless. It's because sometimes Claude will spot your preferences and you don't notice it. So, it might understand from a simple prompt that you prefer things being done this way and never this way. So, we'll create a memory inside of the memory file. So, what you want to do is to run {slash} memory, go to your folder of the memories and there audit them. And some of them you will want to promote them to your Claude.md. Because they are actually rules that are useful to have a better outcome. So, if you do that as a diagnosing tool, you will by the end enrich your Claude.md and improve the experience for every single person in your team.

28:24 There's another thing that I like to do to avoid polluting the context, that is the following. I think we all have done this, that is we get to the end the implementation of something and we need to do a commit. We all know how to do a commit, so get commit {slash} m write a message, right? But we say, "Hey Claude, commit this for me." I personally do that because the usually the message is so much better than the one that I would write, okay? I would say, "Fixed."

28:52 or something like that. And Claude does a better job on that one. What you don't need is to have Claude reasoning about this step. What you can do in certain types of commands, those that are quite simple and you know how to do it, is to use the exclamation mark. Once you type the exclamation mark, every single thing that comes after will be treated as a bash command. So, if I want to do an LS or a dot net test, npm test, npm run, something like that, I don't need to have Claude thinking about the process. What is this thing? How do I run this that thing?

29:27 You just write it. But keep in mind that result will go back to the context window. So, if you run something that brings sensitive information in, don't do it. Talking about Git, um recently they released one feature that I've been using a lot because I used to do this in another terminal, that is a slash diff. So, if during the process you want to see what Claude is changing, the files, the different changes in each line, you can actually open a pane that will contain that information, okay? On the side see all the files being changed and you can click there and see what changed, okay?

30:06 It's a new feature uh that I really like.

Unlocking remote control, voice input, and parallel git work trees

30:09 So, these type of things are things that come to help us with many of the things that we used to use for a long time. But the ones that I like the most are the ones that change the way that I work. The ones that change my lifestyle, I would say. And the one that impact me the most was the remote control. If you've never tried remote control, you should. Remote control is something uh quite cool. Then let me uh share with you a an example. So, a few months ago I was working on um something that I had to deliver on the the next day and I was running late and my father called me asking if I could go pick him at the hospital tell because he had an appointment. Um so, I was thinking, "Okay, uh I'm screwed. I have to deliver this thing. I want to stay, but I won't say no to my father."

30:58 So, what I've done is that I start remote control. I asked Claude to implement a complex stuff um that will take a couple of minutes. Then, I pick my phone, my pocket. I go to the hospital. Uh and while I was waiting for my uh father I used the Claude code application to keep working. Okay, let's discuss uh work-life balance.

31:27 On the other side, there's another scenario where this is quite helpful. Sometimes I'm working the plan at my desk for a for a long time. I'm refining the plan. I know what I want to do and I know that the plan will take a couple of hours to be um executed. So, what I like to do is that I start remote control. I send Claude on that journey of implementing that thing and I go for a walk because I know that during that time I might receive a uh a pop-up notification message, a push notification saying, "Okay, you need to prove this thing or I need feedback on this thing." And I also know once it's finished.

32:01 So, while on one hand we have a problem because now we can keep spending our tokens wherever we are on the other hand, it uh creates this opportunity to work in a different way. If you don't like this one, try the next one. Next one is voice and I know that many of you won't agree with me uh but I really like this one. So, before the pandemic uh we would go to the office 5 days a week and you would sit in your computer and eventually you'll find a problem. You would spend 4, 6, 7 hours looking online trying to find that thing. There was nothing on Stack Overflow. There was no AI agent to fix it. So, we would go to your colleague in the other side of the office and you would start explaining the thing that you were facing.

32:49 And eventually, in the middle of a sentence, he would say, "Ignore it. I know what it is." And you would go back to your computer and you would fix it in just a couple of minutes. Why? You were explaining it out loud. And for some reason, when you speak, your brain works in a different way. At least with me, it happens. So, I came to the conclusion that when I'm using voice, I start understanding better the things that I'm building. Okay? I know it's not for everyone. I don't advise anyone to be doing this in an open office. It might feel strange.

33:21 But, if you want to try it at home, run {slash} voice to enable voice mode and from that point on, just press your space key without leaving it and start talking and it will write the prompt for you. Okay? That's the big idea. If you like this idea of working with different types of mediums, we call this multimodal. So, text, voice, and you also have image.

33:47 If any of you is a front-end developer or works with the web, using images and print screens is awesome. Screenshots. So, often I'm building something and I'll shopping for inspiration online. So, I find a website that I like or I'll go to Figma and I see something that I like. I take a screenshot. I paste it on my terminal and I explain what I want on my own website. And Claude will use not only the text, but also the image as a visual representation.

34:19 The cool thing is that you can actually do this in the terminal. You You can paste it or drag and drop images to your terminal and Claude will recognize it. If you use a Mac, it's actually control V as well. The command V doesn't work. Oh. One of the big problems of the being a developer in 2026 is the fact that we are sitting waiting for our code to be written and we need to do other thing, right?

34:51 So, you start working in things in parallel. And sometimes it might be things inside of the same project. So, how do you do it? Because you are working on that branch, how do I fix something on on a place where I'm actually working on the feature? Do I need to wait? Do I need to commit and move around? Nowadays we use this thing named work trees that is older than Claude code, okay? It stayed in Git Git for a long time, but we are now taking advantage of this. It's like a virtual folder that you have inside of your repo in your computer and you can keep working things in parallel. That means that I can be building a new feature, doing a code review, and fixing a bug on the same project at the same time, no problem.

35:39 Actually, there's a problem. How do I know where I'm doing each of those things? Because it's hard to maintain that context when you are always shifting around between tabs or different windows. So, one thing that I like to do is to use the slash color and the slash rename. For example, I can apply red to a bug fix, orange to refactor, blue to a new feature. And also, I can rename the the conversation so I know that that is the issue 123 from GitHub.

36:13 And this way, when I'm moving around, I always have a reference, a visual reference where I'm looking at, okay? That can be quite helpful. Since you are waiting for Claude, you actually want to wait for a long time. You don't want to babysit Claude. How do you do it? One of my favorite features, slash goal. Instead of writing a prompt, write a goal. A goal is like a journey that Claude should go, the thing that needs to be built, but also a way to verify that we achieve the goal.

36:45 How do we stop? When the test pass? When I have a specific type of test that will go through? When I go to the browser and click this button and something goes to the database? So, if you define that, Claude can iterate as a loop until finally it can verify that the thing that you are asking for is there. Example, you want to build an invoice generator, an API for that. You explain that and you say, "Okay, to verify this thing, create a test that should pass and that test will call the API and by the end you should call another API that will give you a PDF and the PDF should look like this one." Okay? If you do something like this, Claude will take his time, but eventually he'll get back to to you saying, "Okay, it's done. Give me feedback." It's better than staying there just babysitting in every single step. Okay?

37:36 One thing that happens is that you send it on that journey and you are doing this for five, six, seven, eight, nine projects in parallel eventually. Okay? It's natural that it will happen. Um and when you are always jumping around between different tasks, seeing all of those logs from Claude is not that useful because many of those things are just details while he's implementing. It's like when you come for the first time to to a stage and you start doing demos or doing live coding, one thing that they teach you is that you shouldn't uh be quiet at any moment. And that's the thing that Claude is doing. But if you are not there looking at what is happening, why bothering? So, the thing that I like to use is {slash} focus.

38:23 {slash} focus uh will basically say to Claude, "From this point on, I don't care about those intermediary messages. I just want to see my initial prompt and the final result." So, when I go to that conversation, I always see, "Okay, this was what I asked. This is what Claude is is telling me." Just that. It simplifies the whole process. Working with different agents, uh many different agents, is hard because you need to keep up with many different things.

38:52 What do I recommend? You either use the Claude desktop application that is a bit easier to do that. Or if you are like me and you really like the terminal, you can actually start Claude with Claude space agents instead of doing doing only Claude. And basically what will happen is that you have access to the agents view. The agents view gives you access to a quick overview of who is running, okay? Who needs my attention? Who's the the next thing that I should do? Who has finished? And I can quickly navigate and jump between each agent and control it that way. Okay? It's one way of doing it.

Automating workflows with hooks, skills, and headless mode

39:33 Let's now go to our second iteration break and talk about platform layer. What do I mean with this? We all have heard about skills or sub agents and things like that. But the thing is that sometimes we don't

4 Highlight · Use post-tool hooks for automated test feedback

39:51 take advantage of those techniques in certain scenarios. And one of them that I like to use a lot is hooks. I used to do a ton of test driven development and one thing that changed me during the process of doing test driven development is that I like to have my feedback as soon as possible. Okay? When something is wrong, I want to know it.

40:16 And Claude wants to know it as well. So why not building a hook that once Claude thinks that okay, this thing is done, runs your tests and uses that tests those tests as information to correct the path. You can do that. The benefit of doing such a thing is that now you are also saving tokens. Why? Because running this instruction, this bash command, yourself doesn't cost anything in terms of tokens.

40:47 But if you decide to go to your Claude MD and write things like always run the tests by the end or respect this naming convention, always name tests this way. If you do things that way, actually it's Claude that needs to take the decision, that needs to reason about that, and sometimes won't do it. You are not sure that he's always doing it. But, if you create a post tool use hook and you let run your linter, your tests, and all of that, Claude will ask to run it. It will run it, and the feedback goes back into the conversation. So, if something is wrong, Claude can fix it before saying, "Okay,

41:25 I'm done." Okay? That's one of the big benefits. The other one is skills. Skills is one of our favorites, okay? It looks like putting a prompt inside of a file that we call once in a while. They look like small recipes that we have. But, I think we are missing one important aspect of skills. Skills are more like packaging small features, small capabilities inside of a folder.

41:52 Because a skill is so much more than a skill.md. The skill.md is just entry point. You can put there things like scripts, like a Python script, PowerShell script. You can bring all of that inside of that folder. You can bring markdowns explaining how to use that script. So, if your team has a Confluence page with scripts that you run once in a while to fix a given problem, you can package those scripts as skills. So, next time that you need them, you can just call Claude, and Claude will do it for you. Okay? It can run all of those things for you.

42:29 Whatever is the language. If it runs on your machine, Claude can can do it. Talking about skills, I see often people creating their own code review skill or skills to for example do refactorings. A ton of skills that become quite repetitive, or we shop around online for them. But, actually, our friends from Anthropic exposed some um skills inside of the product by default. Skills that they use to build Cloud Code.

43:01 One of them that I really like is the uh {slash} patch. What does this one does? Imagine that you want to do a a huge migration, like a huge refactoring, renaming a ton of things, you can run a {slash} patch, and it will parallelize the work for you. Okay? We'll split that in multiple agents and work separate agents and do the work for you. So, it's quite simple, you can take advantage. But, my favorite one is the {slash} simplify. Why it's my favorite one?

43:27 I love simplicity, and the second thing is that many of [clears throat] us create this skill on its own, named something like refactor or something like that. {slash} simplify will try to fix things and to avoid duplication, the common problems that will lead to code hard to maintain. So, use that one before creating another one. Try that one. Play with it and see how it goes. It's the one that they use to build the product.

43:54 There's also the {slash} loop. If you ever had the experience of uh creating a pull request that should be deployed to somewhere, and then you are going to, let's say, GitHub actions, and you are refreshing, waiting for the thing go green and to know that it's already on Azure or something like that, you can actually ask Cloud to do it. You say {slash} loop, every 5 minutes, go check if this thing is deployed.

44:21 And it'll be doing for that for you. This is just a skill that they have built. As I told you, we also uh often shop around for um skills, but also we shop around for things like MCP servers. When you get to the tool, likely, you go online and you'll see, "Okay, which MCP servers exist?" Okay, in my company, I use this technology, that technology, and that technology, so let me install all of them.

44:48 What is happening is that all of those different MCPs will be installed on your user profile. What you actually want to do is to go to your project, create a .mcp.json, and describe there all the MCPs that you use. Why? Next time that someone in your team opens the the project with Claude, Claude can go and make available those MCPs, and now you can also audit the ones that are used in your day-to-day because you'll be committing this file.

45:18 Okay? Do that instead of having an instruction somewhere saying, "To work with this project, install these MCPs." It's one way to help your uh team as well.

45:30 [clears throat]

45:31 Do you know that you don't need to run Claude and wait for Claude to ask you a a question? There's actually an headless mode. You can use Claude to in this way. Claude space write the prompt {dash} {dash} print or {dash} p. What is happening is that instead of going to that uh typical user experience of asking for the first prompt, it'll run that thing and get back to you and hence the session.

45:59 That means that you can do things like this. You can start changing your scripts, your partial scripts, your shell scripts, whatever, to have reasoning in place. To use Claude as one element of it. You can do piping, for example, send things to Claude, Claude analyze them, and then outputting the result to another place. You can do all of that with your uh Claude subscription.

46:27 Let's go to the final one. Okay? Um this one is uh quite important to me

Expanding Claude Code into personal life and productivity workflows

46:34 because I often see people using uh think about Claude since we say Claude code as just one thing to write code. But personally, I have tried to use Claude for other things as well, and uh actually it's helping me in my day-to-day uh improving my life. So, I decided, "Why not sharing with you?" So, some of those things might work as inspiration for the types of things that you can do in your day-to-day with Cloud.

47:03 You might be aware that Cloud nowadays offers three different products: Cloud Code, Cloud Co-work, and cloud.com. Cloud Co-work is like a hybrid between um Cloud Code and the Cloud because it has access to the same things on your machine, but it tends to be a bit more friendly. But, we are developers. We don't need friendly things, right? Uh so, you can use Cloud Code to automate many different things, and it opens many different possibilities. One common use case that I see is when you have those quarter reviews where you'll be evaluated, and you need to go to your manager and say, "You know, this uh year I have implemented this thing, that thing, and that thing. I had this contribution on this project and on that project." The problem is that doing that after three, four, or six months is hard. You need to go back to your uh email or calendar to understand the meetings you were involved and all of those things.

48:03 But, if those objectives were related to were related to uh code, ask Cloud. If you have been building those things with Cloud, Cloud can tell you what you have been building. Okay? It can share with you the things that you have been doing. And also, that means that you can go to your user profile, create a skill to do this every quarter whenever your manager asks for it. So, you don't need to go back and research your email once again or calendar. You can actually ask Cloud to help you during the process.

48:37 Let's use another example. I have a huge problem with my downloads folder. Anyone can relate? Okay? I think I'm not alone. Uh every single thing that goes to my downloads folder will only disappear from there in the day that I get that message saying you don't have enough space on your disk. Okay? So, that's the day when I decide to take actions. I'm always afraid of losing something that matters, but I know that there's nothing value inside of that folder. But, I'm in fear. So, what I've decided to do is that recently I have 1,626 items inside of that folder. I know that some of those were actually folders, so they were even more. And what I decided to do was the following. A cloud, can you help me with this thing? Organize those things into uh uh folders. So, then it becomes easy to me to take decisions. Because now what I'm seeing is a couple of folders, and I know that if it's code, it will be on GitHub, so I don't care. Let's drop that

49:37 one. If it's a screenshot, I don't care. Let's drop that one. Installers as well. But for things like documents, okay, let's take some time and look at it. It's those small things that you used to take a ton of time or writing a Python script that you can use cloud to help in your day-to-day in just a couple of minutes instead of wasting your time. While I'm quite disorganized with my downloads folder, I'm absolutely obsessed with productivity.

50:06 Uh maybe that's the reason why I'm doing this talk now that I think about it. Uh But one of the things that I really like is uh note taking. But for a long time I struggle I struggle to find the tool that I like, the tool that I would use, that I would commit to it. So, I tried

5 Highlight · Integrating Claude Code with Obsidian for non-code workflows

50:22 OneNote, Evernote, Apple Notes, whatever you you know Notion, whatever you know uh I tried it. And I tried one thing named Obsidian. Obsidian works with markdowns. Uh it can create connections between those markdowns. But the way that I see it is like a client on top of your a folder with markdowns that you can use as note taking. And eventually I start thinking, okay. Obsidian loves markdowns.

50:49 Cloud code loves markdowns on my machine. Why not using both together? So, nowadays I can use Cloud Code to help me in my day-to-day type of things. It can help me to surface things that I would need to do next month. It can help me with summarizing a given meeting. It can help me with things like understanding when I'm running late, when I'm not. It can help me to create connections between different notes that I'm researching.

51:19 And nothing here is code. It's just text. Text on my machine. And now I have a folder that I control and I use the tool that I want. And if the day that I want to use Code X or Cursor or whatever, I can do it as well because I move those technologies to my own control. Why that is cool? Because now I can run Claude inside of my Obsidian and I can have those cool mesh diagrams over there that they are pretty cool for a slide. Actually, they are useless.

51:52 Uh but they are pretty cool. So, these types of things you can do. Let me share with you one more example before we get to the end. So, I I have a a chronic disease. So, uh maybe 10 years ago or more, I was told that I couldn't run, okay? Um yes, because of the problems that I have with that disease. And I accept that fact and for a long time I didn't want to go for a run.

52:21 Eventually, I was stubborn enough that I started running. And one thing that I learned during the process is that the problem was not the fact that I was running. Was the fact that I was running in an unstable way. I would I might be running today 5 km and next week I will try 20 km, okay? And um that was not structured. I didn't have anyone advising me. So, what I decided to do eventually is that I record my all my runs using Strava. So, I said, "Okay, let's build a skill that goes to Strava every single day, pulls my runs into my Obsidian vault. So, now all of my history from every single year since I've been using Strava is inside of my Obsidian vault.

53:08 Then, I have a second skill that I run every week that that I uh ask, "Hey, help me build this um um program, so the next week plan, and guarantee that we don't get to the point that we were before where I had to stop because of my disease." And now, I have every week a stable way of keep running, and I have been uh more healthy because of that. Just using two skills and a set of files on my own machine.

53:37 So, any type of things like those, you can do it with just a set of files and Clojure. I hope you have learned at least one or

53:46 two things with me. I told you that was the goal. But, if you haven't learned anything with me, promise me one thing. Next uh week, once you get to your desk and you start Clojure, type {slash}insights. Because if I couldn't tell you anything new, {slash}insights will tell you a lot about the way that you use Clojure. I hope you like this session, and I hope you enjoy the rest of the conference, and I will see you around. Thank you.