How specifically does this feature differ in security terms from manually uploading a Skill?
A manually uploaded Skill (added to an agent's skills array via the Skills API or settings interface) is typically something a user actively selects and confirms — even if it comes from a third party, at minimum the user made a conscious decision to install that specific content. A skill loaded from a GitHub repo works differently: as soon as a repo is mounted, anything under its root .claude/skills directory is automatically scanned and made available to the agent, and this loading process itself doesn't require the user to reconfirm each discovered skill individually.
This means the point where risk gets decided shifts earlier — from "the moment of installing a skill" to "the decision of whether to mount this repo, and who has permission to commit to it." If a repo's contribution permissions are loosely managed, that effectively lowers the bar for skill installation indirectly.
Why did Anthropic choose an "auto-scan, no review" design instead of requiring users to confirm each discovered Skill individually?
The logic behind this design choice ties directly to what the GitHub-repo Skill loading feature is meant to do: its value lies in automatically staying in sync with the codebase. If every session start required manual user confirmation of newly discovered skills, it would directly undercut the feature's core purpose of eliminating manual sync overhead, making it essentially no different from manual uploading.
Seen another way, this design allocates responsibility clearly: Anthropic provides the auto-loading mechanism itself, while the judgment of whether a given repo is trustworthy is left to whoever decides to mount it. The official documentation's use of the term "trust boundary" is precisely drawing that line of responsibility — the act of mounting itself is a trust decision, not something that needs separate gating afterward.
What is the "only scans a fixed depth under the root .claude/skills" rule actually guarding against?
The official documentation explicitly lists several paths that won't be scanned: a .claude/skills folder in a subdirectory other than the repo root (such as inside a package subdirectory), paths nested more than one level deep, and skills folders named anything other than .claude. The purpose of this restriction is to make "exactly which skills this repo activates" a predictable, auditable thing — if the scanning logic recursively searched every folder at any depth throughout the entire repo, it would be far harder for a reviewer to confirm which skills get loaded when this repo is mounted, and malicious content could more easily hide in an obscure deep path without being noticed.
Worth noting: the documentation also mentions an exception — if a .claude/skills directory exists elsewhere in the repo (such as inside a package subdirectory), it won't be proactively announced at session start, but if the agent later reads a file within that subtree, the Skill content there could still be indirectly encountered. This means the fixed-depth scan restriction limits the scope of automatic announcement, not a complete guarantee against Skill content at other paths ever being read.
If my team is considering storing skills in a shared repo, how should we actually design permissions and process?
The most direct approach is folding changes to .claude/skills into the existing code review process — if the team already requires at least one approval before a PR can merge, this mechanism naturally covers Skill changes without needing a separate review workflow. The real risk lies in paths that bypass mandatory code review, such as a repo owner pushing directly to the main branch, or auto-merge rules with too broad a scope.
For repos that accept outside contributions (like open-source projects), the official recommendation to "review .claude/skills before mounting" effectively means: don't automatically treat a contributor's PR as safe. Especially if a PR touches this directory, it's worth spending extra time reviewing the instruction content even if the code itself looks harmless, since it will gain real execution access to tools like bash and web_fetch the next time someone mounts the repo — a risk level that isn't quite the same as an ordinary code change.
Anthropic's official documentation has recently been updated to reflect that Claude Managed Agents now support loading Skills directly from a mounted GitHub Repository: whenever a session mounts a repo, the system automatically scans that repo's root .claude/skills folder at session start, and every Skill found there becomes available to the agent automatically — no separate upload or manual listing in settings required.
The intent behind this design is straightforward: letting Skills travel with the codebase itself. A team's code review standards, release process, or internal tool usage can be stored as Skills right inside the repo, versioned alongside everything else. Anyone who clones or mounts that repo gives Claude automatic access to that domain knowledge, with no separate Skill list to keep in sync.
What's notable is that while explaining this feature, the official documentation states the corresponding risk in fairly explicit terms: a mounted repository itself becomes part of the agent's trust boundary. Anyone with commit access to that repo — including a merged external pull request, a compromised dependency, or a contributor — can add or modify a skill, and the platform loads these skills at session start with no review step. Once loaded, tools available in the session (such as bash and web_fetch) give these instructions real reach, not just passive reference text.
The documentation's recommendation is direct: only mount repositories you trust, and if you need to mount one that accepts outside contributions, review its .claude/skills directory before mounting. The scanning rule is also precisely defined: skills are only discovered at the exact path depth of .claude/skills/<skill-name>/SKILL.md at the repo root, the scan runs exactly once at session start, and any commits pushed mid-session are not automatically picked up — a new session is required to trigger a fresh scan.
If you're currently only using Claude Skills for personal workflows, this feature doesn't directly affect you, but it highlights something every skill user should be aware of: once a skill is loaded, it carries the same execution power as any other instruction, and the trustworthiness of its source directly determines the risk. For anyone evaluating whether to have their team store skills in a shared repo, this means the repo's access controls (who can merge a PR, whether code review is required) effectively become part of skill governance, not just a code-quality gate. Especially for repos that accept outside contributions or have multiple contributors with merge access, taking one extra look at whether a PR touches the .claude/skills directory before merging it is a low-cost habit worth building.