Review an agent skill like a software dependency

Send changes to a shared agent skill through code review, with its supporting files included. Before anyone installs it, the reviewer should be able to say what it can run.

A skill packages instructions for a repeated task, and it can include scripts. In Claude Code, the allowed-tools field (opens in a new tab) lets a skill pre-approve tools for the turn that invokes it. It does not limit the agent to those tools. Other permission settings still apply, and other clients may read the same files differently.

Follow the files the skill relies on

Take a fictional code-review skill. Its configuration starts a Model Context Protocol (MCP) server, a program that gives the agent extra tools, without fixing the package version. A reviewer who reads only the instructions would miss that the skill brings in code whose version can change after the review.

A September 7 study (opens in a new tab) of 2,660 public agent setups found unpinned MCP packages in 9.8% of them. The authors also flagged broad permission to run commands. They read configuration files and did not run attacks, so the figures describe that sample and cannot predict a breach on your team.

Trace the skill's references into its bundled scripts and startup configuration, and write down the dependencies and access its job needs. A pinned version tells you which release you get, and someone still has to review that release.

What belongs in the review

Review the instructions together with the programs and permissions they bring into the setup.

• Source and version

  Record the skill's repository revision and the exact versions of anything it runs.

• Executable files

  Read bundled scripts, startup hooks, and any command that downloads or starts another program.

• Access

  List the credentials and destinations it needs. Check what its tool grants mean in the client your team uses.

• Expected result

  Decide what a good review looks like, and which side effects are allowed, before trying it.

Try the reviewed version on a small task

Use a throwaway repository with one planted bug and made-up content, and give the skill only the access that test needs. A good result is a local review that finds the bug, with no posted comment and no changed file. Check the commands it ran and the network requests it made as well as its answer.

A broad permission may be fine for another job if the reviewer can explain why it is needed and what limits the damage. Reading the files also cannot show that the skill helps. Compare its output with a run without it before making it a team default.

Keep the approved configuration with the trial record and give that record an owner. When a dependency or permission changes, review the difference and repeat the affected checks. The review is finished when someone can point to the exact files that were read and the trial result the team accepted.