Skill packs from git

A pack is a GitHub repository that carries SKILL.md files — yours, or one somebody published. Registering it does not import anything: it shows you the plan first, and you import from that.

Register a pack

Skills → Packs → Register a pack (an owner or admin) walks four steps:

1. Access — a public repository, or a private one read through one of the account's GitHub connections. No connection yet? Add GitHub connection takes you through the connection flow and brings you back.
2. Repository — Select the repo to import: with a connection, pick from its repositories (the default branch is filled in); otherwise enter https://github.com/<owner>/<repo> and a branch, tag or commit.
3. Options — Pinned (we tell you when upstream moves and you import) or Tracked (upstream changes are imported automatically every 15 minutes); Internal for your own repository, Third-party for anyone else's; where the skills land (the account, or one project).
4. Only these — optional: include only some folders, skip some, and map the repository's frontmatter field names onto ours.

Registering fetches the plan and opens the pack page.

Finding skills in a registry

Skills → Registry searches three places at once:

Registry	What you get	What the badge means
ClawHub	published skills with a version; downloads and stars	Verified by registry — ClawHub's scan allowed it; Needs a look — ClawHub flagged something (the reasons are shown; Import anyway to accept them); Refused by registry — moderation removed it, not importable
GitHub	repositories tagged agent-skills / claude-skills, by stars	Not scanned — nobody has checked it; the plan is your review
A site	type a domain (acme.dev) to read its published /.well-known/agent-skills index	Not scanned; each file's digest is verified on import

Import registers the hit as a pack and imports it in one step — the same plan, the same exclusions, the same provenance line. A GitHub-backed registry skill becomes a GitHub pack (only that skill selected); a hosted one becomes a registry pack that checks the registry for new versions like any pinned pack. With a GitHub connection on the account, GitHub search returns more (and finds SKILL.md files in untagged repositories).

The plan

Fetch the plan resolves the ref to a commit and reads the tree. Every SKILL.md is listed under one of two headings:

• Eligible — it would import. Each row shows the path, whether the skill writes (side effects) and how many secrets it references.
• Excluded, with the reason:

Reason	Why
Personal scope	its frontmatter says scope: personal (or similar) — a pack imports team skills only
Private / agent-only	marked private, or the body carries THE-AGENT-ONLY
Name already taken	a skill with that name already resolves in the target scope; a pack never overwrites
Binary sidecar	a binary file in the skill's directory could not be fetched with its bytes
Malformed SKILL.md	the frontmatter does not parse, or a required field cannot be derived
Needs a binding	kind: mcp_tool, composition, integration_action or model_call — those need a binding a pack cannot carry
Over the size cap	the body or the sidecars exceed the limits
Denylisted here	the name is on this account's skill denylist
Screened	the screener found something in the skill's files (below)

Nothing is silently dropped. Tick the eligible skills you want and Import selected, or Import all.

Internal and third-party packs

A pack's trust is proven, never chosen. It is internal only when the repository belongs to one of the account's verified GitHub organisations and is private. Every other pack is third-party. The pack's page says which one it is, and why.

To verify an organisation, an owner or admin opens Settings → Skills → Packs → Verified GitHub organisations, types the organisation name and picks their own GitHub connection. The check passes only when that GitHub account is an owner of the organisation. Being a member is not enough, because anyone can be invited.

The tier is checked again every time the pack is fetched. When a repository turns public, or its organisation is removed from the list, the pack becomes third-party from that fetch on, and the change is recorded in the account's audit log.

Screening

Every skill is screened before anything is written. That covers its SKILL.md and every file under its directory (references/, scripts/, assets/ and the rest). The plan names each finding with its file and line.

• Critical: the skill is held back in every pack, internal or third-party. The findings are hidden characters (bidi controls, zero-width or tag characters), a private key or access token, an instruction that tries to override the agent ("ignore previous instructions"), or an instruction to send the environment, the conversation or credentials to a URL. Fix the line in the repository and fetch the plan again.
• Warning: a curl … | sh style install, or an executable binary. A third-party pack holds the skill back. An owner or admin can choose Accept the warnings to let the next import bring it in. The acceptance covers that exact file set: a changed file is screened again. An internal pack imports it with the warning shown.
• Note: a link to another site, or a SKILL.md over 500 lines. It is shown for review and never holds a skill back.

When an update is held back, the skill keeps the revision it already has. Nothing is archived.

What we read from their frontmatter

Packs are written for many tools, so the importer understands a few dialects. Their key → ours:

Theirs	Ours
when-to-use, usage, triggers	when_to_use
visibility	scope
agent_only, agent-only	private
side_effects, readonly	effects
declared_creds, declaredCreds	env
required_capabilities, requiredCapabilities	capabilities
allowed-tools	allowed_tools

A missing description is taken from the first line of prose; a missing name from the directory. $UPPER_SNAKE references in the body are recorded as the secrets the skill expects. The skill's file is stored exactly as written, so keys we do not recognise are kept in it and listed as warnings on the skill page, never enforced. A body that is exactly one fenced typescript or python block with kind: script imports as a script skill; everything else is a prompt skill.

After import

Each imported skill is a normal skill of the account or project: it resolves, forks and archives like any other, and its page carries a provenance line — From pack … @ commit · path — linking the file in the repository. Re-importing the same commit changes nothing; a changed file becomes a new revision (the old one is kept); a file removed upstream archives the skill.

A skill edited in connect0 is never overwritten by a sync. connect0 remembers the version the repository and connect0 last agreed on, and compares both sides with it:

• Only git changed: git's version comes in as a new revision, through review when the account requires it.
• Only connect0 changed: connect0's version stays. With write-back on, it is written to the repository.
• Both changed: connect0's version stays in production and git's waits as a draft. The skill page shows the conflict, a link to compare the two, and two choices: Use git's version or Keep connect0's version. Nothing is written to the repository until a person picks one.

Updates

• Pinned: the sync checks the ref every 15 minutes and marks the pack update available when upstream moved; the pack page names both commits. Fetch the plan, review, import.
• Tracked: upstream changes are imported at the next sync; the skills' revisions record which commit each came from.

A fetch that fails (a revoked credential, a deleted repository) is recorded on the pack — nothing is archived on an error.

Write changes back to the repository

A tracked GitHub pack can keep the repository current too. On the pack's page, under Sync with git, pick one:

• Off: connect0 reads from git. This is the default.
• Commit to the branch: each version published in connect0 is committed to the skill's folder on the pack's branch. The commit names the version, its author and its reviewer.
• Open a pull request: each skill gets one pull request on a connect0/skills/<skill> branch. Merging it makes the repository match connect0; closing it keeps the repository's version, and Push again on the skill page opens a new one.

The pack's GitHub connection or token needs write access to the repository (and permission to open pull requests for the second mode); connect0 checks it before saving. connect0 only commits on top of the branch head it read, so a commit someone else pushed in between is never overwritten: the push waits for the next sync to compare again. A skill whose SKILL.md sits at the root of the repository is not written back; move it into its own folder.

Private repositories

Add a GitHub connection under Connections and pick it as the pack's credential. The token never leaves our fetch path and is never shown in an error.

Removing a pack

Remove pack archives every skill the pack imported and keeps their revisions; agents stop resolving them at once. Registering the same repository again brings them back on the next import.