As I’ve mentioned some time ago, I’ve been using Claude Code for some time now.
Now, a disclaimer is in place. I’m still a bit skeptical about the current “AI” hype – in particular, I really avoid using the term “AI”. I consider it a very misleading marketing gimmick. When non-technical people hear the phrase “artificial intelligence”, a computational model capable of generating more or less random sequence of letters which sometimes create a semblance of “understanding” or “intelligence” is probably not what they think. Well, I am really a layman, too – I have some extremely vague understanding what happens inside these “chatbots”, but other than that they seem a bit magical to me as well – but my point is, they are really closer to a giant spreadsheet with billions (or even more) of cells than to Skynet.
Anyway – even I have to admit that what Claude Code is able to do is pretty impressive. However, I quickly discovered that the OOTB experience is less than ideal. One of the easier ways to enhance Claude (and other LLMs, apparently) is by writing skills, which are basically reusable prompts or procedures for performing some tasks, written in natural language.
Compared to classic programming, writing skills is, well, a slightly different skill. Unlike hooks, they are not deterministic, and even though Claude has a way to “invoke” a skill directly, by typing a slash followed by the skill’s name, they can be invoked by a prompt which Claude interprets as suggesting using a skill, which is cool but much less certain.
From what I have learned so far, one of the biggest challenges when using LLMs in general and agentic coding in particular is “context management”. LLMs have very limited “attention span”, and giving them too much data makes them work worse. From skills perspective, this means that they should be as concise as possible. Two nice tricks that can help with that are: skill descriptions and dividing skills into several files. First of all, every skill file has a “description” field. All installed skills’ descriptions are preloaded at the beginning of the session, so providing concise descriptions clearly describing when Claude should use a skill is a crucial step. Besides, if a skill is really large – or has substantial parts which are needed really seldom – it may make sense to move these parts to separate files, and link to them from the main skill file. (Apparently, it is enough to tell Claude something along the lines of “When the user requests …, read the … file”.)
One problem with guidelines like this is that it is very difficult to know whether they are genuinely useful tips or just superstitions. The fact they are officially recommended gives some hope. Interestingly, Anthropic released a tool which helps with developing and evaluating skills. Reading through the files in its repo is a mind-blowing experience: the tool is itself a skill, and I have to say that the fact that it works (and I tried it out!) seems magical.
After all that intro, let me share one of the first skills I created (with help from Claude itself, of course). It is very simple in the sense that it only consists of one SKILL.md file, but it already proved itself to be very useful a few times on the first day I installed it!
It is often said that LLMs are generally very agreeable – they tend to flatter the user more than criticize them. Connected with the fact that the normal workflow is to tell the “agent” what you want done and expect obedience, there is a real danger that the only thing your coding agent will help you achieve is writing bad code faster. On the other hand, since LLMs were trained on a lot of written material, in particular describing good and bad practices, gotchas and pitfalls, it seems worthwhile to ask them if your idea is any good before implementing it and learning that it’s not the hard way.
So, here is the complete SKILL.md file for my assess skill.
--- name: assess description: > Assesses pros and cons of a user's idea, with a focus on weaknesses. Use when user asks to assess an idea. --- # Idea Critique Skill Before applying this framework, say: "Applying /assess framework". When asked to assess, evaluate, or critique an idea, apply this framework: ## Stance Default to skeptical. Assume the idea may have a fatal flaw and actively hunt for it before concluding it doesn't exist. This is not about being negative — it's about stress-testing so weak points surface early. ## Process 1. **Steelman first** — articulate the idea's best possible form before critiquing it 2. **Pros** — list genuine strengths with brief reasoning 3. **Cons** — list weaknesses; spend more effort here than on pros 4. **Weak points deep-dive** — pick the 1–3 most dangerous weaknesses and stress-test them hard. Ask: what would have to be true for this to fail? 5. **Verdict** — a honest one-line summary of where the idea stands 6. **Suggested pivots** — if flaws exist, propose concrete ways to address them ## Weighting Score each pro/con 1–3 for significance. Call out any single con scored 3 as a potential deal-breaker. Mark the scores as `[★☆☆]`, `[★★☆]` and `[★★★]`. ## Tone Direct and honest. Avoid hedging language that softens real concerns. The user wants signal, not comfort. --- Now apply this framework to the following idea: $ARGUMENTS
Note the use of $ARGUMENTS at the end – this ensures that I can tell Claude to invoke this explicitly, by saying /assess <my idea>.
I think the most astonishing thing about this skill is that it works really well despite being so short. At 220 words it takes up about 300 tokens, which is way smaller than, say, the aforementioned skill-creator (roughly 20k tokens!) – but is really useful.
Also, this is just the beginning. As of now, I have quite a few custom skills, and this one is one of the smallest (in terms of the word count). And despite the problems with the fact that they are, well, more what you’d call “guidelines” than actual rules, they are genuinely useful.