Installing a skill answers one question: is it available? It does not tell you whether the agent loaded it, followed it, or produced a better result.
Those are separate checks. Mixing them makes it easy to delete a useful skill because it was quiet for a week, or keep a popular one that repeatedly produces work you have to repair.
Separate availability, loading and results
Claude Code lets you invoke a skill directly with /skill-name, and can select eligible skills itself. The skill's body loads when it is used. Its description helps determine when that happens. See the Claude Code skills documentation.
A useful review asks three questions:
| Question | Evidence to look for |
|---|---|
| Was the skill available? | The skill configuration and the session's available skills |
| Was it loaded? | A recorded invocation or instruction read |
| Was it followed successfully? | The resulting actions, artifacts and checks |
The second row does not establish the third. Loading a deployment checklist does not prove that the deployment checks ran.
Start with a small experiment
Pick a workflow you already understand. Write down what a satisfactory result requires before changing its instructions.
For a review skill, that might mean finding a known defect, explaining its effect, and avoiding unrelated edits. For a documentation skill, it might mean accurate commands and links that resolve.
Use a disposable branch or sample project. Keep the task prompt and starting state. Run the task, inspect the output, and record:
- whether you explicitly requested the skill;
- whether there is evidence it loaded;
- which required checks actually happened;
- what you had to correct afterward.
Repeat after one focused change to the skill. A few runs can expose a problem; they do not establish a universal success rate. Model, permissions and repository state can all change the outcome.
Read activity as a lead for investigation
I build ccdeck. Its Skill activity guide documents a local view of recorded skill loads for Claude Code and Codex, separating agent selection from commands you typed.
The view can show counts, recent uses and projects, with session links while those sessions remain on the canvas. Repeated identical commands in a session are excluded from the use count. A skill merely mentioned in a message is not a use.
Treat those records as leads for inspection. They are not quality scores or proof that instructions were obeyed. The guide also documents capture prerequisites and missing historical coverage: older sessions are not retroactively added. An absent row does not establish that a skill was never useful.
Decide what to change
If you repeatedly type a skill that you expected the agent to select, inspect its description and invocation settings.
If a skill loads but misses a required step, inspect the instruction and the actual run together. Make the requirement concrete, then test it again.
If it rarely loads, first ask how often the relevant task occurred. A migration checklist can be valuable even when migrations are infrequent.
Keep a short record of the task, observed behavior and correction. That gives the next edit a reason beyond “this skill feels better.”
Top comments (0)