I have run more AI tools this year than I am willing to admit in front of an audience. Most of them are the same two or three models with slightly different wrappers. The category I underestimated was Claude skills (plain Markdown prompt files that tell Claude how to approach a specific task, loaded into a project’s CLAUDE.md or a .claude/skills/ directory). The collection that landed in my workflow came out of a TechPP roundup I read this week, and I have spent the last few days picking through it to figure out which ones survive contact with a real codebase.
A skill is not a model. It is a Markdown file with structured instructions. You write name, description, and a body that explains when to use the skill and what to do when it fires. Anthropic’s own docs cover the format, and the community has filled the gap with thousands of examples. Most of them are noise. A few are not. This is the short version of what I kept, what I dropped, and what surprised me.
Why I cared enough to try them
The pitch for Claude skills, in the words of the TechPP writeup, is that “skills are just specific instructions created by an experienced professional to get the best output for a specific task.” That is the honest version. The hyped version is that skills turn Claude into an expert. The honest version is closer to a checklist with a context window. Either way, when the checklist is good, the model follows it. When the checklist is bad, the model follows it anyway, which is the failure mode you want to know about.
I went in skeptical. Skills are a Markdown file. A good prompt is also a Markdown file. The difference has to be in the structure, the trigger conditions, and the explicit guardrails. The TechPP piece walks through 14 of them across frontend design, documents, presentations, code review, test-driven development, and project memory. I tested the ones that mapped to work I was already doing.
Frontend design skills
The frontend design skill, in the source’s framing, exists because AI models produce “a generic design pattern” when left alone. Purple gradients, then color strips, then all-caps subheadings that look like every other AI site on the internet. I have shipped enough of these to be embarrassed about it.
The skill moves you toward something less generic by front-loading principles: typography hierarchy, whitespace rules, button spacing, dark-mode contrast, and the small list of components that make a site look designed rather than generated. The catch is that the model still produces generic output on the first attempt. The source is honest about this. You optimize, you reprompt, you iterate. The skill makes the iteration cheaper, but it does not skip it.
Feeding the model a real UI image first (a Figma export, a screenshot from Dribbble, a Pinterest board) and asking it to match is what actually moves the needle. That worked for me. The skill gave Claude the language to critique its own work; the image gave it a target. Without one or the other, the output drifted back toward generic.
Documents and presentations
The document skill was the one I expected to dismiss and the one I kept. AI-generated documents have a recognizable smell: broken table formatting, inconsistent heading levels, fake citations, and prose that reads like a corporate memo. The skill exists to fix all of that. It packages the same rules a careful technical writer uses (heading levels, table column widths, citation handling, list consistency) into instructions Claude follows automatically.
I tested it on a project proposal that would normally take me an afternoon of formatting. The first draft was 80% there. The second draft, after one round of edits, was good enough to send. The “what I gave up” here is that the skill still needs a human review pass on citations. If you publish without checking, you will end up citing a paper that does not exist. That is true of every AI writing tool, and a skill does not change it.
The presentation skill followed the same pattern. The source recommends pulling the design first (Dribbble or a wireframe), then switching to Claude’s design-tuned model, then feeding it the brand fonts and palette. I tried it on a 10-slide deck. The output was cleaner than what I would have produced in PowerPoint by hand, but I had to spend 20 minutes on font weights and image placement. The skill earns its keep on the second deck you make, not the first.
Code review and test-driven development
The code-side skills are where the source gets strongest. Two of them, the Karpathy-style core prompt and the TDD skill, change how Claude behaves when it is writing code.
The Karpathy prompt is four instructions. No frameworks, no elaborate system message, just four rules about how to think before you suggest code. The source credits Andrej Karpathy with the four lines and notes that the result is “fewer hallucinations and unnecessary complexity.” I have not measured hallucinations formally, but I have watched Claude stop padding a code block with boilerplate it would have included before. That is the practical win.
TDD is the skill that asks Claude to write the test first, run it, watch it fail, write the code, and only report the work as done when the test passes. The source frames this as the fix for AI’s habit of marking incomplete work complete. It is. I ran it on a small Python module and caught two edge cases I would have shipped without the test-first loop. The “what I gave up” is that the test-driven loop adds 10 to 15 minutes to a task that would normally take two. For one-off scripts, that is too much. For production code, it is the right spend.
Verification, challenge, and panel discussion
Three of the skills cluster around the same problem: AI models agree with whatever you say, then sometimes reverse themselves later. The Grill Me skill, the Challenger skill, and the Panel Discussion skill all attack this from different angles.
Grill Me tells Claude to interrogate you before it starts work. Long prompts, clarifying questions, the kind of friction a senior engineer adds when you describe a vague task. Challenger tells Claude to suggest a different approach if it thinks you are wrong. Panel Discussion simulates three personas arguing about your idea, then produces a defended final answer. None of these are magic. All three are useful on a decision you cannot easily reverse.
I tested Panel Discussion on a refactor proposal for a small service. The three-persona walkthrough caught a sequencing problem I had missed (the migration order mattered for a downstream consumer). The catch is that the skill takes 20 to 30 seconds longer than a normal answer and produces a transcript you have to read. For a quick decision, it is overhead. For a decision that locks in for six months, the overhead is cheap.
Project memory and the bottom of the stack
Project memory is the unglamorous skill and the one that has done the most to change my workflow. The pattern is simple: at the end of every session, write a project_summary.md that captures what got done, what is still open, and what the next session should pick up. The skill gives Claude the structure to generate this file automatically before you close the session.
This is the kind of thing you would expect to be in every AI tool by now. Most of them still do not do it. The skill turns a session into a recoverable artifact. The next session reads the summary, picks up the open items, and does not start from zero. I have been using it for a week and the amount of context I have recovered on reopen is the difference between continuing and restarting.
The remaining skills in the source (PDF, CSV, presentations with brand assets, and a few smaller workflow files) follow the same pattern. Each one packages a small set of instructions that close a specific failure mode in Claude’s defaults. None of them are required. The list you actually need is probably four to six of them, not fourteen.
Trade-offs
Skills cost time before they save time. Each skill you add is a file Claude reads on every relevant request, and the context window cost is real. I landed on five skills in my main workflow (frontend design, document creation, TDD, project memory, and Grill Me for decisions). Adding more did not improve output and slowed the first response by a noticeable margin.
The other cost is curation. A skill that is wrong for your project is worse than no skill at all, because Claude will follow it confidently. The TechPP piece treats all 14 skills as wins. That is a roundup’s job, not yours. The real test is which ones survive a week of real work, and the honest answer for me is that six did and eight did not.
The third cost is the trap of treating skills as static. Claude updates, your codebase updates, the failure modes you care about change. A skill that was the right call six months ago may now produce output that is actively wrong. The discipline is to revisit the skill list every few months and drop the ones that no longer pay for themselves. Most people will not do this, and most people’s skill directories will become a junk drawer by the end of the year.
What I would tell past me
A few practical lessons from the week of testing:
- Start with the skills that match work you already do. Trying a frontend design skill when you do not build frontends is a waste of a week. Pick the two or three skills that close a failure mode you have actually hit.
- Skip the all-caps subheading habit by writing a “do not do this” section in each skill. A list of anti-patterns in the skill body is more useful than a list of patterns. Claude will pattern-match; tell it what to avoid as well as what to do.
- Treat the test-driven loop as a habit, not a skill toggle. The TDD skill is most useful when you turn it on for a whole project and leave it on. Switching it on and off per task adds friction without adding value.
- The project memory file is the highest-value skill on the list. Everything else is a productivity tweak. Project memory is the difference between AI as a tool you use and AI as a tool that knows your work.
Skills are not a substitute for knowing what you want. They are a way of writing down what you want, in a form the model can read. The best skills I tested are short, opinionated, and aimed at a specific failure mode. The worst skills on the list were long, generic, and aimed at a category of work I do not do. Pick the short ones. Drop the rest.