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). You give:

Field	What it does
Repository URL	https://github.com/<owner>/<repo> — github.com only for now
Branch, tag or commit	what to import (main by default)
Updates	Pinned — we tell you when upstream moves and you import; Tracked — upstream changes are imported automatically every 15 minutes
Trust	Internal for your own repository, Third-party for anyone else's
Credential	none for a public repository; a GitHub connection of this account for a private one
Advanced	skill_globs (only these directories), exclude (never these), field_overrides (map their frontmatter keys onto ours)

A pack registered from a project page lands its skills in that project; from the account settings, in the account.

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 file next to SKILL.md is not text; sidecars are text only
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

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

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. Keys we do not recognise are kept and shown 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.

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.

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.