All skills / Best practices

Claude Code best practices: verify the work and the skills behind it

Tested and written by Fred at SkillsTested · Published 2026-07-23 · Updated 2026-10-10

Give Claude Code a clear task, a way to check the result, and only the tools and skills that task needs. Below is a short working loop from Anthropic's guidance, followed by eight lessons from our July tests of 21 skills across eight packages.

A practical loop for any Claude Code task

State the outcome and constraints. Name the file, feature, or artifact you need, along with the environment and a concrete pass condition. Anthropic's Claude Code best practices recommend specific context and a way for Claude to verify its work.
Inspect before changing. For a nontrivial job, ask Claude to read the relevant code and propose a plan before it edits. Keep standing repository rules in a concise CLAUDE.md; put repeatable task instructions in a skill.
Run a real check. Use a test, build, screenshot, or output inspection that can fail. When a skill is involved, test the result of one representative task, not just the installation. Our video test caught render failures that an install check could not.
Review the boundary. Ask what the check actually proved, what still needs human judgment, and whether the skill needs a desktop app, external service, or paid runtime. The tested skills directory labels those limits per package.

Eight lessons from installing and using skills

1. Learn the installer used by the package

Most packages in our batch installed through the community skills CLI; GSD Core used its own installer. Read the package's current instructions before running either:

npx skills add owner/repo -a claude-code -y

In our July environment, most subsequent installs took a few seconds. The CLI's -s flag selected skills from multi-packs, -g chose user scope, and -l previewed a repository without installing. Those timings describe our runs, not every future machine or release.

2. Test use, not only installation

Across all eight packages we hit zero install failures — and three real use-time failures, all in the Remotion render pipeline. The pattern generalizes: installs are file copies; usage is where browsers, desktop apps, and render stacks live. Budget your validation time accordingly: a green install proves almost nothing. Run one minimal real task before you rely on a skill.

3. Check the upstream before adopting

The loudest lesson of our first batch: the 64.7k-star GSD repo is archived, with development moved — and the listings hadn't noticed. Thirty seconds on the repo page (archived banner? last push? open redirect notice?) before npx skills add protects you from building on a museum piece.

4. Inspect what the package can execute

Instruction-only skills such as hallmark and obsidian-markdown have a smaller runtime surface, but their instructions still deserve review. Script-carrying skills such as kill-ai-slop add code to inspect. Runtime-backed packages such as CodeDrobe and GSD Core install more software and files. Check dependencies, permissions, and the uninstall path before relying on them.

5. Mind the weight

Skills install per-project by default, and installs are full copies: video-shotcraft is 51.1MB in the current test — per project. For heavy skills, install globally (-g) or accept the disk math knowingly. Check with du -sh .claude/skills/* once in a while; ours totaled a quarter gigabyte after one enthusiastic session.

6. Keep overlapping skills under control

By session end we had three anti-slop skills installed simultaneously — and generic design requests could plausibly match any of them. Their descriptions may compete for the same request. Pick one skill per job where possible, remove unused copies (npx skills remove), and check which one Claude actually loaded (more on activation).

7. Record what you tested

Skills ecosystems move weekly — two repos in our batch gained stars measurably during the day we tested them, and one moved orgs entirely within two months. Record the commit you installed. Our full package records name the installed commit; narrower trials name the source commit and disclose any install steps not run. When a skill matters to production workflows, re-run your minimal task after updating rather than assuming compatibility.

8. State the environment

Half the pain in public skill discussions is Mac-authored skills meeting Linux servers and vice versa. The good packages state their requirements plainly (obsidian-cli: "Requires Obsidian to be open"; CodeDrobe: platform-stamped adapter registry). When you publish, say what you tested on; when you adopt, check the gap between the author's environment and yours — that gap is where our only unresolvable test limits lived (CodeDrobe on headless Linux).

The site-specific results above link to test records; the general working loop links to Anthropic's documentation. As retests accumulate, rules get revised in place and the changelog says what changed.

Need to choose a package before applying these rules? See our task-based picks from the skills we tested.