← All IntelClip / EducationWhen to use CLAUDE.md versus a skill
From Full Walkthrough: Writing & Using Skills — Nick Nisi and Zack Proser · ≈20:11
“the number one rule that you have to remember is that the skills sorry, the cloud.md or the agents.md, that is going to be loaded every time. When you kick off Claude, that's going to fill your context window. And if it's filling it with a bunch of nonsense that isn't actually applicable to what you're specifically doing, then you probably don't want it in there.”
“If it's only relevant to the repo like like specifically you know I'm tired of it using npm when I wanted to use pnpm for example. I'll put that in there like a single line that just says we use pnpm here.”
“anything else like if it's you know more specific about testing or anything like that I kind of leave that to skills so that it's only going to be loaded when I'm actually like writing tests”
“wait a week while working on it and then go back and ask Claude analyze my week's worth of work. And then what are the skills I should split out of that based on this?”
What’s in it
- A usable decision rule for a question every team hits: keep the always-loaded file tiny and repo-specific, push conditional knowledge into skills, and mine a week of work to find which skills to split out.
Clip transcript
>> Um, you talked a bit about this in the beginning. But I always wonder where to draw the line between encoding instructions in like rules, cloud.md, and so on, and creating a skill for something. So, I'm curious if you have like what's your mental model to making that decision? Like have you landed anywhere? Like do you always start with the rule and then you make a skill if you can make it specific enough? Or you do always start with a skill? Like how do you go about it? >> Yeah, great question. >> Great question. >> Uh, I usually Wait, like the the one the number one rule that you have to remember is that the skills sorry, the cloud.md or the agents.md, that is going to be loaded every time. When you kick off Claude, that's going to fill your context window. And if it's filling it with a bunch of nonsense that isn't actually applicable to what you're specifically doing, then you probably don't want it in there. Um, I can show an example of like my uh what is it? dot Claude Uh, and then I think Claude.md if I can spell. This is my Claude.md. It's extremely small. Uh it just tells it that I want things to be a little bit more terse. Don't blow the eight. I just want to know exactly what you're saying. Uh be extremely concise. And then I also like I have this plugin that I'm working on. It's a a skill actually called ideation. And I in here I put like some configuration for that so that all of the projects I I basically want them all to put like the ideation the artifacts that it's generating into my Obsidian vault. So it puts it all in there so I can more easily like find the connections between things. Um but otherwise it's like extremely tiny. And so that that's one thing that goes into it. If it's only relevant to the repo like like specifically you know I'm tired of it using npm when I wanted to use pnpm for example. I'll put that in there like a single line that just says we use pnpm here. Um and then anything else like if it's you know more specific about testing or anything like that I kind of leave that to skills so that it's only going to be loaded when I'm actually like writing tests. >> To to the second part of your question as well the and we'll talk about this a little bit later but the other thing that's really fun to do is basically wait a week while working on it and then go back and ask Claude analyze my week's worth of work. And then what are the skills I should split out of that based on this? >> Yeah. >> Um so again ask the system to kind of
Comments
Sign in to comment.
Loading comments…