What does installing a SKILL.md actually change?
Three things change the moment a skill folder lands somewhere your host reads. The agent gains a short description that tells it when to reach for the skill, a body of instructions it can load mid task, and on some hosts a list of tools it may use without stopping to ask you.
A plain-text instruction can still ask the agent to run code, contact a website or delete files. The file format does not make the action harmless. Check both the written procedure and any scripts it asks the agent to run.
Stage the package before the agent can see it
mkdir -p ~/skill-review && cd ~/skill-review
git clone --depth 1 https://example.com/some-skill.git candidate
# every file, not just the one the listing advertised
find candidate -type f | sort
du -sh candidate
head -40 candidate/SKILL.mdStart by listing the files. If the package includes scripts or programs you did not expect, find out what they do before continuing. Ask a technical reviewer to inspect code you cannot assess yourself.
Look for actions beyond the stated task: contacting an unfamiliar service, reading account keys or proceeding without an expected approval. These need an explanation before installation.
- Network calls: curl, wget, fetch, and any hardcoded host or webhook
- Credential reads: env files, keychains, token paths, cloud metadata addresses
- Consequential verbs: send, publish, deploy, delete, purchase, spend
- Language that tells the agent to skip confirmation or act without asking
- Base64 blobs, minified scripts, and any file that is not readable text
grep -rniE 'curl|wget|https?://' candidate/
grep -rniE 'API_KEY|SECRET|TOKEN|\.env|credential' candidate/
grep -rniE 'rm -rf|sudo|chmod|eval|base64 -d' candidate/
grep -rniE 'without asking|do not confirm|skip approval|auto-approve' candidate/What in the frontmatter can bypass your approval?
Frontmatter is the short settings block at the top of SKILL.md. Some settings influence when the skill runs and how tools are approved. Read these alongside the host permission settings; behavior depends on the product and version.
| Field | What it changes | Ask before you accept it |
|---|---|---|
| allowed-tools | Grants the listed tools with no prompt, for the turn that invokes the skill | Would you approve every one of these by hand? |
| disallowed-tools | Removes tools from the pool while the skill is active | Does the skill fence itself in, or leave everything open? |
| disable-model-invocation | Only you can trigger it; the model cannot start it | Should anything with side effects fire on its own? |
| description | Decides when the model reaches for the skill unprompted | Is the trigger narrow, or will it fire on half your prompts? |
Where does each host put the files?
The install folder controls where the skill is available. A project folder may limit it to one project, while a shared location may make it available more broadly. Confirm the intended location before copying the files.
| Host | Where the reviewed folder goes | Removal |
|---|---|---|
| Claude Code | Project scope in the repo, or personal scope in your home directory | Delete the skill directory |
| Hermes | One skills directory in your home folder, grouped by category | Remove the folder, then start a new session |
| OpenClaw | Workspace skills first, then project agent skills, then a global directory | Uninstall, then confirm no copy remains higher in precedence |
# Claude Code: project scope travels with the repo and gets reviewed with it
cp -r candidate .claude/skills/some-skill
# personal scope loads in every project on this machine
cp -r candidate ~/.claude/skills/some-skill
# Hermes: install by identifier, or copy the folder you already read
hermes skills install official/research/arxiv
cp -r candidate ~/.hermes/skills/some-skill
# OpenClaw: workspace wins over the project agents directory
openclaw skills install ./candidate
ls <workspace>/skills .agents/skills
# confirm what the host now sees
hermes skills list
openclaw skills listFlags move between releases, so the commands above are the bare forms. Check your host's current documentation before adding options, and list the directory afterward to confirm where the install landed. On Hermes a new skill takes effect in the next session, so one that appears to do nothing may simply not be loaded yet.
How do you rehearse a new skill without risking client work?
Use a separate test folder with a few fictional records. Ask for a task the skill should handle, then inspect the resulting files and activity. Check the actual actions, not only the agent's summary.
- Run the trigger once and read the full tool log, not the closing summary
- Confirm it stopped at every gate that would send, publish, deploy, or spend
- Check that nothing left the machine: no surprise request, no upload, no draft
- Delete the folder and confirm the skill drops out of the skill list
Is a SKILL.md safe because it is only Markdown?
No. Plain text can instruct an agent to run code or use connected accounts. Review the instructions alongside the permissions available to the agent.
How do I know a skill has not changed since I reviewed it?
Keep the reviewed version and record its release or commit identifier. Compare the changed files before accepting an update. A trust badge is useful context, not a substitute for checking the package.
Should skills be installed per project or for the whole machine?
A project-specific install is a useful starting point when the instructions apply to one client or project. Use a shared installation only when its wider availability is intentional and reviewed.
Review the setup before installing
Use the install review above before adding any unfamiliar skill. If you need help, bring the package source, the host you use, and the permissions you expect it to need. Keep credentials out of the inquiry.