Short version: As of August 7, 2026, a Claude Managed Agents session that mounts a GitHub repository automatically loads any skills in that repo's root .claude/skills directory — no upload to the Skills API, no entry in the agent's skills array. The scan runs once, at session start, so a mid-session git push won't be seen until you start a new session. And because repo skills are agent instructions loaded with no review step, a mounted repo is now part of your agent's trust boundary — mount only repos you trust.
The one rule that matters#
Discovery finds skills at exactly this path, one directory level deep at the repository root:
your-repo/
├── .claude/
│ └── skills/
│ ├── code-review/
│ │ └── SKILL.md
│ └── release-process/
│ ├── SKILL.md
│ └── scripts/
│ └── run_checks.sh
└── src/
Get the layout wrong and the skill simply isn't announced when the session starts. Three near-misses that do not get discovered:
.claude/skills/SKILL.md— aSKILL.mdwith no skill directory around it..claude/skills/tools/code-review/SKILL.md— nested more than one directory level deep.skills/code-review/SKILL.md— askillsdirectory outside.claude.
A .claude/skills folder buried inside a package subdirectory isn't announced at session start either. (The agent can still stumble onto it later by reading files under that subtree — but don't rely on that; put the skills at the root.)
How to mount the repo#
Repo skills ride in on the github_repository resource. Create a session that mounts the repository, and the scan happens for you:
curl -sS https://api.anthropic.com/v1/sessions \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: managed-agents-2026-04-01" \
--json @- <<'EOF'
{
"agent": "agent_01J8XkN5uT3vHpLqRfWdY2",
"environment_id": "env_01K2mPsT7hNwR4jXuLvCqD8",
"resources": [
{
"type": "github_repository",
"url": "https://github.com/org/repo",
"authorization_token": "ghp_your_github_token"
}
]
}
EOF
For a private repo, the resource's authorization_token needs access to that repository — the same personal-access-token flow as any repo mount. Discovery uses the agent's read tool (on by default in the agent toolset); an agent with read disabled won't pick up repository skills.
Once mounted, the agent sees each discovered skill's name, description, and sandbox path, and reads its SKILL.md — along with any scripts and resources it ships — when a task actually matches. Nothing to attach, nothing to upload.
The catch: the scan runs once#
Discovery follows the checked-out state of the repo — the checkout branch or commit if the resource sets one, otherwise the default branch — and it runs exactly once, when the session starts. Commits pushed mid-session are not picked up. If you edit a skill and want the agent to use the new version, start a new session. This is the single most common way teams get surprised: they fix a skill, push, and wonder why the running agent still behaves the old way. It's not caching a stale copy — it never re-scans.
The part you can't skip: trust#
Repository skills are agent instructions, and the platform loads them at session start with no review step. That makes the mounted repo part of your agent's trust boundary in a way an uploaded, workspace-controlled skill is not:
Anyone who can commit to the repository — a merged external pull request, a compromised dependency, a contributor — can add or change a skill, the platform loads it at session start without a review step, and session tools such asbashandweb_fetchgive those instructions real reach.
Two practical guardrails:
- Mount only repositories you trust. A repo that accepts outside contributions is a repo where a stranger can, in effect, edit your agent's instructions.
- Review
.claude/skillsbefore mounting anything with an open contribution model — and treat changes to that directory in code review the way you'd treat changes to a productionDockerfileor CI config.
Repo-mounted vs. uploaded: which to reach for#
Both paths coexist — repo skills are discovered on top of whatever you attach through the agent's skills array. The decision is about where the skill's source of truth should live:
- Mount from the repo when the skill is the codebase's own convention — a release process, a code-review checklist, a deploy runbook — and should version and travel with the code. Editing the skill is just a normal commit.
- Upload to the Skills API when you want an explicitly pinned version, reuse across projects, or a run on a self-hosted sandbox (repo resources are cloud-sandbox-only). Uploaded skills also stay inside your workspace's trust boundary, which matters for compliance-sensitive runs.
If a repo skill and an attached skill share a name, both stay available — each is announced with its own path, so nothing silently shadows anything else.
The 60-second version#
- Put each skill at
.claude/skills/<name>/SKILL.mdin your repo root. - Create a session with a
github_repositoryresource pointing at the repo. - The agent auto-discovers the skills at start — no upload, no
skillsarray. - Changed a skill? Start a new session — the scan runs once.
- Only mount repos you trust; the repo is now part of the agent's instructions.
For the neighboring decisions, see Skills vs. Subagents vs. MCP for which extension mechanism to reach for, how to publish and install an agent skill for the upload path in depth, and how to seed a Managed Agents session with initial events and per-session overrides for the rest of the session-shaping toolkit.



