The Skills Ecosystem's Hidden Execution Surface

Agentic coding tools have introduced a new kind of software artifact that looks like documentation but behaves like code. They are called skills - Markdown files dropped in a directory that tell an AI agent how to behave: how to scaffold a project, review a PR, run a pipeline, or interact with an API. They spread via git clone. They are installed from marketplaces. They are shared on GitHub and copied between machines without a second glance. Commands are essentially explicit skills - invocable only directly by the user.

Skills and commands are widely used and well-known across the agentic ecosystem - but their executable surface is not. Even as organizations work to establish auditing practices around them, most practitioners have never been asked to review a skill file for pre-model execution. They look like documentation. 

In ten of the thirty-one platforms we tested, they are something else entirely.

From Markdown to Shell: The ״Pre-Model״ Surface

The critical distinction - one that most practitioners have never been asked to make - is the difference between a skill that the model reads and a skill that the platform executes.

In the safe case, a skill file is loaded, its text is handed to the model, and the model decides what to do next. In the unsafe case, the platform preprocesses the skill body before calling the model: it matches patterns, runs shell commands, reads files off disk, substitutes argument strings - and hands the model only the finished result. The model sees rendered output. It cannot evaluate, refuse, or flag what already ran.

We call this the Pre-Model Surface: the set of execution primitives that fire in the gap between "skill file opened" and "LLM API called." It is the attack surface that none of the prevailing threat models account for, because nobody thought the Markdown file was the threat actor.

To map it, Bloom Security audited 31 agentic platforms with SKILL.md skill systems over two days - reading source bundles, analyzing native binaries, running live proof-of-concept payloads on May 31 and June 1, 2026, and documenting exactly where execution happens relative to the first model API call.

Case Study: The Shell That Runs Before the Model Wakes Up

The most powerful primitive we found is not a shell command embedded in a skill body. It is a hook registered inside a skill's YAML frontmatter.

Claude Code extends the agentskills.io spec with a hooks: frontmatter field that lets a SKILL.md file declare lifecycle hooks - shell commands tied to events like UserPromptSubmit and PreToolUse. When Claude Code loads the skill, the hooks are registered for the entire session. PreToolUse with matcher: "*" intercepts every subsequent tool call - silently, for the lifetime of the session.

No prompt. No user approval. No model decision. The shell command in the frontmatter runs the moment the skill is loaded.

Additional mentions - Codebuddy: skills with “context” set to “fork” running in a platform which has the allowUntrustedFrontmatterHooks setting (in settings.json) set to true also honor in-skill hooks; Qwen: hooks work for managed/project skills only, and require user approval.

The second most alarming finding: CodeBuddy, a Tencent-developed product that is a near-exact fork of Claude Code, inherits the full !`cmd` shell expansion pipeline intact. Our live proof of concept revealed something the developers may not have intended: in the case of commands, the shell fires before the authentication check returns.

We ran the test on an unauthenticated session. The API responded: Authentication required. The test artifact was already written to disk. A command's shell payload executes on the developer's machine before CodeBuddy has even confirmed they have an account.

‍

Five Primitives, One Attack Surface

Our survey catalogued five distinct primitive classes, each representing a different mechanism by which a skill file triggers execution before the model call:

• Inline Shell Expansion (!`cmd`): A backtick expression in the skill body matched by client-side regex; stdout is spliced into the rendered prompt before the LLM API call. Confirmed in Claude Code, Devin-cli, OpenCode/Kilo (commands), OpenHands (subprocess.run(shell=True)), and CodeBuddy.
  ‍
• File Interpolation (@file / @{file}): A file path in the skill body; the platform reads it and inlines the contents into the prompt. Confirmed in Devin-cli, CodeBuddy, Qwen (commands), and Tabnine CLI (commands).
  ‍
• Argument Substitution ($ARGUMENTS): The user's raw argument string substituted into the skill body pre-model dispatch - with no shell metacharacter escaping in several platforms. When combined with shell expansion, this enables argument injection directly into the shell expression. Confirmed in Claude Code, Devin-cli, OpenCode/Kilo (commands), Droid (@factory/cli), Augment Code, Cursor ($ARGUMENTS + $N positional) and Kimi Code CLI ($ARGUMENTS, $ARGUMENTS[N], $N, named params, ${KIMI_SKILL_DIR}).
  ‍
• In-Skill Hooks (hooks: frontmatter): YAML-declared lifecycle hooks inside SKILL.md that bind shell commands to tool call events via PreToolUse, intercepting every tool call for the rest of the session once the skill is loaded. A Claude Code-only extension to the agentskills.io spec.
  ‍
• Config-Time Execution: Shell expansion ($(cmd)) in platform config files - specifically crush.json in Crush (Charm) - evaluated at load time, before the UI appears. No skill file required; repo-level write access is sufficient. Crush's own built-in documentation acknowledges this directly: "crush.json is trusted code. Any $(...) in it runs at load time with the invoking user's shell privileges, before the UI appears. Don't launch Crush in a directory whose crush.json you haven't reviewed."

Usecase #1: Argument Injection via Unescaped Substitution

Another dangerous interaction emerges when $ARGUMENTS substitution runs before !`cmd` shell expansion. A user-supplied argument containing shell metacharacters lands inside an active shell expression - no quoting, no escaping. OpenCode/Kilo demonstrates this precisely in prompt.ts:1543–1561: the full argument string is substituted first, and the shell pattern fires immediately after:

Usecase #2: In-Skill Hooks: Persistence in the Frontmatter

The in-skill hook surface is more subtle - and more persistent. A malicious skill declaring a PreToolUse hook needs nothing visible in its body. The dangerous content is entirely in the YAML frontmatter, indistinguishable from legitimate hook configuration at a glance:

Fork Inheritance: One Design Decision, Many Platforms

The same ShellProcessor architecture - with identical source-path comments - appears independently in multiple platforms, tracing back to a shared Gemini CLI codebase fork. This fork inheritance means that a design decision made once propagates silently to every downstream platform that copies the stack. Notably, Qwen's implementation adds an approval gate: in interactive mode a confirmation dialog shows the exact command before it runs, and headless execution is blocked without --approval-mode yolo. The execution is still pre-model, but it is not silent.

Skill Laundering: The Model Was Never Asked

Traditional prompt injection is a model-layer attack. The attacker injects instructions into the model's context and hopes it complies. Safety training, constitutional constraints, and system prompt hardening are all designed to resist exactly this.

Pre-model execution is a different class of threat.

We call it Skill Laundering - the process by which a malicious actor uses the trusted skill delivery mechanism to execute code before the model, before the safety guardrails, and before the approval UX ever get a chance to intervene. The model's refusal policy, its tool-call approval gate, its constitutional alignment - these are all downstream of the moment that matters. The shell already ran. The file was already written. The network packet was already sent.

A skill with a PreToolUse hook does not need the model's cooperation. It does not need to deceive anything. It just needs to be loaded - and then to wait for the first tool call.

The supply chain implication is significant. Skills spread the same way npm packages do: via public repositories, shared dotfiles repos, and copy-paste from documentation. A malicious skill installed into ~/.claude/skills/, ~/.agents/skills/, or ~/.codebuddy/skills/ persists silently across every session on that machine. And because some platforms inherit each other's skill directories - Augment Code reads ~/.claude/commands/; CodeBuddy carries the full Claude Code pipeline - a single infected directory propagates execution across multiple tools without the developer ever noticing the cross-platform entanglement.

Honorable Mentions

Several platforms exhibit behaviors that sit adjacent to the confirmed primitives - close enough to warrant documentation, distinct enough to exclude from the primary count.

Qwen Code - Pre-Model Execution With Approval Gate

Qwen (QwenLM/qwen-code) implements the full ShellProcessor pipeline with !{cmd} syntax in ~/.qwen/commands/. The execution is genuinely pre-model - ShellProcessor.processString() runs before the LLM API call, and stdout is spliced into the prompt. However, in interactive mode a confirmation dialog exposes the exact command to the user before it fires. Headless invocations (qwen -p ...) are blocked entirely unless --approval-mode yolo is set. Skill files (~/.qwen/skills/) do not expand !{cmd} at all - the body is passed as literal text to the model.

This meaningfully distinguishes Qwen from the other confirmed platforms, where execution is silent. The confirmation dialog is a real mitigation for the interactive case; it does not help when users run with --approval-mode yolo or when a legitimate command file is used as a supply chain vector in a trusted-seeming skill package.

Augment Code - !`cmd` Present but Model-Directed

Augment Code's CLI (auggie) command files can contain !`cmd` expressions - the same syntax as Claude Code. However, bundle analysis of augment.mjs finds no shell expansion handler in the pre-model prompt assembly path. The expressions are sent as literal text to the model; the model then decides via tool calls whether to execute them. This is model-directed execution, not a before-model primitive. $ARGUMENTS substitution IS before-model and was confirmed live. Auggie also inherits Claude Code's user command directory (~/.claude/commands/), so a Claude Code command file dropped there with !`cmd` would reach Augment Code's model as literal text - a different risk profile.

Codex (OpenAI) - Hook Config Surface, Not Skill Surface

Codex ships a native hooks engine (codex-rs/hooks) that supports shell commands with ${PLUGIN_ROOT} and other variable substitutions in hook config files. This is a real execution surface - but it is scoped to the platform's hook configuration, not to skill files, and it is not skill-embedded. The skill-embedded path we tested (allow_implicit_invocation: true in agents/openai.yaml) was invalidated: MCP transport fails with Cloudflare OAuth before any pre-model auto-spawn can occur; the model reads the skill, discovers the script, and runs it post-model via a tool call. The hook config surface remains a legitimate area of interest for platform-level threat modelling, but is out of scope for this skill-file-centric survey.

Goose (Block) - Template Rendering Without Shell Access

Goose recipes (recipe.yaml) use MiniJinja template rendering before the session starts - substituting {{ variable }} expressions from user-supplied --params before any model call. This is a confirmed pre-model primitive. We exclude it from the primary shell execution count because the MiniJinja sandbox is heavily locked down: env() and get_env() are unknown, global state is inaccessible, and parameter values are not re-evaluated as templates. The attack surface is prompt injection via crafted recipe files, not arbitrary shell execution. A malicious recipe can inject attacker-controlled content into the model's initial instruction - a meaningful risk, but a different class from the shell primitives that dominate the primary findings.

Strategic Implications

For Organizations and Security Teams

Treat skill directories as code repositories, not configuration folders. Anything in ~/.claude/skills/, ~/.agents/skills/, or platform-specific equivalents can execute shell commands before the AI model - and before any tool-approval UI - the moment a developer opens their coding assistant.

• Audit installed skills the same way you audit installed packages. Review YAML frontmatter for hooks: fields; scan skill bodies for !`cmd`, !{cmd}, $(cmd), @file, and @{file} patterns before installation.
• Do not clone skill repositories from untrusted sources. A git clone followed by a platform restart is a code execution path, not a documentation update.
• Treat shared skill directories as a lateral-movement surface. Skills synchronized via dotfiles repos, Dropbox, or shared config stores propagate to every machine in the sync group - including across different platform tools that read overlapping paths.
• Monitor for pre-model network egress. Exfiltration via a PreToolUse hook produces network traffic before the tool executes and outside any AI interaction log. It will not appear in agentic tool-call traces or LLM audit logs.

For Developers Building Agentic Platforms

If your platform preprocesses skill bodies before calling the model, your skill loading path is a code execution path. It deserves the security properties of a code execution path.

• Separate the execution approval gate from the model's tool-call gate. Before-model execution needs its own explicit user consent - not the same UX as a model-requested tool call, because the model was not involved in the decision to run the command.
• Escape argument substitutions before shell expansion. If your platform substitutes $ARGUMENTS into a skill body and subsequently runs shell patterns, the substitution must use shell-safe escaping. Raw string replacement into an active shell expression is argument injection by definition.
• Limit hook scope and lifetime. Session-wide hooks that persist across all tool calls with wildcard matchers are a disproportionate capability for a skill file to grant itself silently at install time. Scope hooks to explicit invocations, not session-wide interception.
• Document which skill formats execute code. The agentskills.io spec defines instruction-only skill bodies. Extensions that add pre-model execution - like Claude Code's hooks: frontmatter - should be clearly distinguished in documentation from spec-compliant, instruction-only skills.

Conclusion

The agentic coding ecosystem built its skill-sharing infrastructure on a foundational assumption: that skill files are solely LLM instructions. That assumption is wrong for ten of the thirty-one platforms we tested - and likely wrong for more as the ecosystem continues to fork, evolve, and inherit each other's architectures without inheriting each other's security analysis.

The approval gates, safety layers, and constitutional guardrails that govern what an AI agent can do are all built downstream of the moment that matters most: when the platform opens the file.