Which Claude Code Skills and Plugins Do You Actually Need?

Choose by the job you repeat

For the next change, identify which step you keep doing by hand or forgetting. A requirements skill should leave a decision you can review. A build skill should leave a focused test and patch. A verification skill should leave the command, exit status, and findings that support a decision.

Claude Code’s skills guide describes a skill as instructions in a SKILL.md file, with optional supporting files. A project skill can live at .claude/skills/<skill-name>/SKILL.md. Keep ordinary repository conventions in project instructions and use the skill for the sequence you want to repeat.

The Claude Code plugin guide describes packages that can add skills, agents, hooks, and MCP servers. Inspect what a plugin includes and select a scope in /plugin when installing it. The Installed tab and claude plugin list show which plugins and scopes are active. Start with a plain checklist when that covers the job.

Pick the output you need

Use this table to choose the smallest addition that would change the next task. The skill names point to upstream projects, with dependencies and usage checked against the linked source revisions.

Inspect the skills and their dependencies

The linked Grill Me definition invokes grilling. The Grill with Docs definition invokes both grilling and domain-modeling. Check that the setup includes those skills before trying either entry point. Grill with Docs is useful when an answer needs to become a lasting change to an ADR or glossary.

The linked Superpowers test-driven-development skill prescribes observing an expected failure before implementing a change. Its verification-before-completion skill calls for fresh command output before reporting a result. You can use the same discipline with repository commands and a written checklist.

Use the names and installed components shown by your Claude Code session. The Claude Code skills guide explains how project skills are named and how plugin commands get a plugin prefix. The plugin guide covers installing a bundle and checking its scope.

Apply it to the retry example

A standard partner should get three retries after a transient failure. A fictional ADR keeps automatic retries at zero for the manual-recovery partner, and permanent failures still receive zero. The existing code retries standard transient failures once.

If the exemption is unclear, use a question list or a requirements skill to ask whether it still applies. Record the answer as an acceptance check. Add a durable note only if the decision or terminology actually changes. When the ADR lives in approved work history outside the repo, a Shifu lookup can help locate the source for the engineer to inspect.

The setup guide contains the full script and run commands. Its baseline failed on the standard limit, with 1 where 3 was expected. The blanket patch failed the exemption check, with 3 where 0 was expected. The revised policy passed all three checks. Those are Python fixture results. The example shows where you could use a skill at each step.

Evaluate one skill on a real change

Pick one repeatable gap. For a missed exemption, start with the original decision, the patch, and the checks. Try a requirements or verification skill on the same kind of task and inspect the artifact it produces. Keep it if the artifact is easier to review and you can still trace each conclusion to a source or command.

A local review can flag a mismatch in the diff. Run the actual tests and decide what needs human review. If your current process already asks the right question and preserves the test receipt, you have a working baseline.

Recurring gap
Expected artifact
Source or command that can verify it
What changed in the artifact
Decision to keep, revise, or skip the skill