The description field is the part that works without you doing anything. While a skill is installed, that line sits in the context of every session, and it is what the model reads when it decides on its own whether to pick the skill up [4]. The opt-out is a single frontmatter key, `disable-model-invocation: true`, and the author has to set it explicitly [5]. Across the 364 skills in the largest repository the write-up examined, it was set zero times [3].
Then the body. A line like `` !`git diff` `` is not a proposal the model evaluates. Claude Code runs the command first, puts the output into the text where the command sat, and by the time inference starts, the shell has already run [6].
`allowed-tools` is the field most likely to be misread. It does not constrain a skill; it grants, and the tools listed run for that turn with no confirmation prompt [7]. The documentation is direct about the consequence: workspace trust does not gate the field, and "a skill can grant itself broad tool access, so review the `allowed-tools` of skills checked into a repository before you run Claude Code there" [8]. In a curated marketplace from a well-known audit firm, all 31 skills set the field, and 24 of them list a bare `Bash` with no pattern [9]. That is 77% of the marketplace where invoking a skill buys a turn of unconfirmed shell [16]. The author's reading, which I share, is convenience rather than malice: a fuzzing skill has to run the fuzzer [10].
Now the scope, because these counts are claims about someone else's tree. The checks were done on Claude Code 2.1.223 against five cloned popular repositories, none of them malicious [14]. These numbers only tell you something about your own machine if a few conditions hold. You install by name and star count without opening the folder, which is how the author says people do it on registries where the top skill reports three million installs [2]. You run `claude -p` or the SDK, where there is no trust dialog and no permission prompt, the folder counts as trusted, and hooks from a cloned `.claude/settings.json` execute [12]. And nobody reads the diff when a skill updates. In an interactive session without `allowed-tools`, that same body command would have stopped and asked [17]. Install counts describe popularity, not what is actually in the folder.
The honest row is the fourth one in the author's own test. Four skills, an empty project, `claude -p` in the default permission mode; the marker each skill leaves is a line with the author's username and a timestamp, which is how you know the command ran as the user [13]. The fourth did not fire, because auto-invocation stays the model's decision and this time the model passed on the skill [13].
In my context the workable rule is vendoring: copy the skill folder into the repository, review `allowed-tools` in the pull request that adds it, and update it deliberately. That costs real reviewer time. It is the same cost we already accept for anything else that runs with our own credentials in CI.
