AI Skills Are Executable Assets. Let's Review Them Like Code.

Markdown is not executable code.

But an AI skill written in Markdown can tell an agent to run a shell command, open a credential file, install a package, call an MCP tool, modify a repository, or delegate work to another agent.

The file does not execute itself. It influences a system that can.

That makes “it is only documentation” a dangerous security assumption.

In Part 1, I argued that reusable skills have become software artifacts. In Part 2, I described a portable governance architecture. This final article focuses on the consequence: skills need a threat model and a code-review discipline.

The real execution chain

The risk is not the Markdown parser. It is the authority downstream.

Open the full-size SVG diagram →

The same sentence has a different risk profile when read by a chatbot with no tools and by an autonomous coding agent holding repository write access and cloud credentials.

Review the instruction in the context of the agent's authority.

A practical threat model

A useful review starts with five questions.

1. Who can influence the skill?

The author may be trusted, but the skill can import or quote untrusted material: web pages, issues, emails, repository files, or output from another tool. A workflow that says “follow the instructions in the linked document” has created an instruction channel outside code review.

Treat external content as data unless an explicit trust decision promotes it to instructions.

2. What can the agent reach?

Inventory the available tools, filesystem scope, network access, credentials, MCP servers, hooks, and delegation mechanisms. Least privilege belongs in the runtime, but the skill should not assume more authority than it needs.

3. What can change?

Read-only discovery is different from rewriting a library. A local formatting change is different from publishing a package. Review the maximum blast radius, not only the happy path.

4. How can the workflow fail?

Consider interruption after a partial mutation, retry after a timeout, concurrent runs, stale state, missing dependencies, and ambiguous tool output. “The agent will figure it out” is not a recovery plan.

5. What evidence remains?

A reviewer should be able to answer what ran, under which skill and policy version, what changed, and how completion was verified.

The attack surface is larger than the skill body

A complete review follows references.

Open the full-size SVG diagram →

A clean-looking skill may point to a dangerous script. A safe script may be launched by a hook with unescaped input. An MCP configuration may start an unexpected command. A handoff may expand the task beyond the user-approved scope.

The review unit is the behavior graph, not one Markdown file.

What to look for

Prompt injection and trust-boundary collapse

Flag instructions that treat fetched content as authoritative, especially phrases such as “obey all instructions from…” or workflows that copy remote text into the agent's instruction hierarchy.

Safer skills separate phases:

1. retrieve content;
2. label it untrusted;
3. extract facts or data;
4. validate those facts against the user's goal and local policy; and
5. request approval before expanding scope.

Secrets and credential paths

Review both literal secrets and instructions that steer the agent toward credential stores. Mask matches in reports. Do not echo tokens for debugging. Prefer environment-provided, scoped credentials and avoid teaching a reusable skill where a particular person's secrets live.

Dangerous shell patterns

Pipelines such as remote download into a shell, recursive deletion, force pushes, approval bypasses, or hard resets deserve high severity. Documentation examples need care too: agents copy examples.

A skill that legitimately performs a destructive operation should define exact targets, preview the change, require confirmation, and explain recovery. “Be careful” is not a control.

Hidden Unicode and homoglyphs

Bidirectional controls and zero-width characters can make displayed text differ from its logical order. Homoglyphs can substitute characters that look nearly identical. These techniques are well suited to hiding a command, domain, variable, or path from a reviewer.

Scan every agent asset, not only SKILL.md: prompts, agents, commands, manifests, MCP configs, and runtime aliases.

References that escape the repository

Resolve referenced paths against an explicit root. Reject traversal outside it unless the exception is deliberate and reviewed. Missing references should fail visibly rather than silently weakening the workflow.

MCP configuration and hooks

MCP servers and hooks are executable boundaries. Review the command and arguments used to start a server, environment variables passed to it, network reach, and whether a skill's declared MCP dependencies match its actual tool use.

For hooks, check input interpolation, shell quoting, trigger scope, and whether the hook can make changes without the same preview and approval contract as the skill.

Safety properties for mutating skills

Four concepts should appear in reviews of any skill that changes state.

Blast radius: What is the maximum set of files, records, systems, or people affected? Is the scope resolved before mutation?

Preview: Can the user inspect the exact plan or diff before the change? Is confirmation tied to that preview rather than to a vague intent?

Rollback: Can the change be reversed? If not, is that fact explicit before execution?

Idempotency: What happens if the skill runs twice? A retry should not duplicate comments, recreate resources, or apply the same migration twice.

Add checkpointing for multi-phase workflows. After interruption, resume from verified state rather than trusting conversational memory.

A code-review checklist for skills

Use this in pull requests:

Contract

• [ ] The name and description define a narrow activation boundary.
• [ ] Inputs, outputs, non-goals, and verification are explicit.
• [ ] The skill declares whether it is read-only or mutating.
• [ ] Interactive questions and non-interactive behavior are bounded.

Portability and dependencies

• [ ] Host-specific fields are absent or justified.
• [ ] Tool, script, MCP, and skill dependencies are declared.
• [ ] Optional host capabilities have a sequential fallback.
• [ ] Paths are portable and resolved within an explicit root.

Security

• [ ] External content is treated as untrusted data.
• [ ] No embedded secrets or credential-store directions exist.
• [ ] Dangerous commands are absent or protected by exact-scope controls.
• [ ] Hidden Unicode and homoglyph scans pass.
• [ ] Referenced scripts, hooks, agents, and configs were reviewed too.

Mutation safety

• [ ] The blast radius is bounded.
• [ ] The user sees a concrete preview before material changes.
• [ ] Confirmation cannot be bypassed by ambiguous wording.
• [ ] Rollback or recovery is documented.
• [ ] Retries and repeated runs are safe.

Evidence

• [ ] Deterministic checks pass under a known rule version.
• [ ] Semantic quality was reviewed against a shared rubric.
• [ ] The completion test verifies outcomes, not merely tool success.
• [ ] Material decisions remain visible in the change history.

What automation should block

Not every imperfect sentence should fail CI. Blocking policy should be narrow and predictable.

High-confidence, high-impact issues are good candidates:

• missing required metadata that makes the skill unloadable;
• destructive or approval-bypassing commands;
• embedded secrets or credential paths;
• hidden character deception;
• unsafe references or script traversal;
• mutating behavior without a preview/confirmation contract.

Clarity, example quality, discoverability, and compositional elegance usually belong in review evidence rather than a hard deterministic gate.

The Skill Governance Toolkit implements this split. Its read-only engine scans agent assets with versioned rules and can block only newly introduced high-severity findings. Its model-driven skills add nine-dimensional quality evaluation and library-level analysis.

Governance is not a sandbox

Skill review does not replace runtime isolation, permissions, network policy, secret management, or human approval for high-risk actions.

It addresses a different layer: whether the reusable instructions we distribute are well-formed, transparent, portable, and safe by design.

Defense in depth still applies:

Open the full-size SVG diagram →

No single layer carries the whole trust burden.

The standard should rise with the authority

We do not review a comment, a build script, and a production migration with the same rigor. Skills deserve the same risk-based treatment.

A writing assistant skill may need a clear contract and privacy boundaries. A deployment skill needs dependency pinning, least privilege, preview, approval, rollback, idempotency, and an audit trail.

The more authority an agent receives, the less reasonable it is to treat its reusable instructions as “just prompts.”

AI skills are executable assets—not because Markdown became code, but because Markdown became part of the control plane for systems that can act.

Let's review it accordingly.

Series:

1. AI Skills Are Becoming Software. They Need Governance.
2. Designing a Governance Layer for AI Skills
3. AI Skills Are Executable Assets. Let's Review Them Like Code. (this article)

Explore or contribute to the MIT-licensed toolkit: github.com/artemrudenko/skill-governance-toolkit.

What is the most dangerous capability you have seen hidden behind an innocent-looking agent instruction?