Review an agent skill like a software dependency

Put changes to shared agent skills through code review. Include the supporting files and configuration in the change, and make the reviewer identify what can execute before anyone installs it.

A skill packages instructions for a recurring task and may include scripts. In Claude Code, the allowed-tools field can pre-approve tool use for the turn that invokes a skill. It does not restrict the agent to those tools. Other permission settings still apply, and other clients may interpret the files differently.

Follow the files the skill relies on

Take a fictional code-review skill that asks an agent to inspect a pull request. Its accompanying configuration starts a Model Context Protocol (MCP) server, a program that exposes tools to the agent. The package has no version specified. A reviewer reading only the instructions could miss that the setup also introduces executable code whose version is not fixed by that configuration.

A September 7 study found unpinned MCP packages in 9.8% of 2,660 public agent setups. The authors also identified broad execution grants. They examined configuration files, without running exploits, and confirmed no credential-exfiltration path. Their sample favors publicly advertised tooling; validation used same-team implementations and model adjudication. The figures describe that corpus and method. They cannot estimate your team's likelihood of a breach.

Our recommendation is to review the complete setup being proposed. Trace the skill's references into bundled scripts and startup configuration, then record the dependencies and access needed for its stated job. A version pin identifies a selected release; it still needs review.

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 versions or digests of executable dependencies.

• Executable files

  Inspect bundled scripts, startup hooks, and any command that fetches or launches another program.

• Access

  Explain required credentials and destinations. Check what tool grants mean in the client the team uses.

• Expected result

  Define the review output and permitted side effects before trying the skill.

Try the reviewed version on a bounded task

For this example, use a disposable repository with a deliberately introduced bug and synthetic content. Give the skill only the access needed for that test. Expect a local review identifying the bug, with no posted comment or changed source file. Inspect the commands and network requests as well as the answer. These are proposed acceptance checks; no results have been measured.

A broad permission may be justified for another task. The reviewer should be able to explain why it is needed and how the surrounding environment limits its consequences. A read-through cannot establish that a skill is useful, either. Compare its result with a run without the skill before making it a team default.

Keep the accepted configuration beside the trial record. When a dependency or permission changes, review that difference and repeat the affected checks. Otherwise, the team can keep invoking the same skill name while relying on a setup nobody has examined.

For the code-review skill, the adoption decision should point to the exact files reviewed and the observed trial result. Assign an owner to maintain that record so the next person updating the package can see what the team actually accepted.