Registry Resources

The Registry is the org-level catalog every Agent Profile draws from. A registry resource is a versioned, named asset of one of these types:

Type	What it is	Referenced from a profile as
SKILL	A Markdown document giving Claude domain knowledge/procedure for a task (materialized to resources/{key}.md in the workspace).	resources.skills[].ref
HOOK	A Claude Code native lifecycle manifest (hooks.json) — declares an event (Stop, SessionStart, UserPromptSubmit, ...), a matcher, and a handler (command/http/mcp_tool/prompt/agent).	resources.hooks[].ref
PLUGIN	Bundles an MCP server config and/or a Claude marketplace-installed plugin with a connection binding — gives the agent tool access to an external system.	resources.plugins[].ref
MCP	A standalone MCP server declaration (an external reference to a vendor-hosted server, or a local stdio command).	resources.mcp_servers[].ref
KNOWLEDGE	A reference document mounted into the run (team conventions, a glossary, an architecture doc).	resources.knowledge[].ref
PROMPT	Reusable prompt guidance materialized for the agent.	resources.prompts[].ref
PERMISSION_PRESET	A named, versioned {allow: [...], deny: [...]} policy — composable across profiles.	top-level permission_presets: ["key@version"]
MEMORY_POLICY	A reusable memory policy stored in the registry.	Reserved for memory-policy integrations; not selected by the current profile form.

Every resource is uniquely keyed by (organization, type, resourceKey) — so SKILL java-spring-boot and HOOK java-spring-boot can coexist, but you can't have two SKILLs both keyed java-spring-boot in the same org.

Versions

Creating a resource only creates its identity (type, key, name, description), at version 0. The actual content is added by publishing a version, which bumps the version by 1 and stores an immutable snapshot. A resource can have many published versions; profiles reference one explicitly by key@version (or key@latest).

Source types

How a version's content is delivered varies by sourceType:

• INLINE — you paste the content directly (most skills, hooks, permission presets, knowledge docs).
• UPLOAD — uploaded content or a packaged bundle. Plugin folders are packaged with their directory structure intact.
• EXTERNAL_REFERENCE — a pointer to a vendor-hosted service, not content you own (e.g. a real MCP server URL like https://mcp.sentry.dev/mcp).
• CLAUDE_MARKETPLACE — a reference to a plugin published on a Claude Code marketplace (e.g. frontend-design@claude-plugins-official). The worker resolves or installs the selected version when package installation is enabled; otherwise the plugin must already be available.
• AGENT_SKILLS — a pointer to a skill living in a real GitHub repo (e.g. Anthropic's own anthropics/skills repo).
• GIT_BACKED, CATALOG_PACKAGE, BUILT_IN_PROVIDER, PLATFORM_MANAGED, PACKAGE_INSTALLER — less common variants for git-tracked content, vendored packages, and provider-native or platform-managed capabilities.

For AGENT_SKILLS and CLAUDE_MARKETPLACE, always click Check availability before publishing — it fetches the real source repository and confirms the skill/plugin actually exists there, without creating anything. See Create a Registry Resource.

Hook validation

HOOK content is validated strictly against Claude Code's real event/handler model: only known event names (SessionStart, Stop, PreToolUse, UserPromptSubmit, ...) and only the handler types that event actually supports (a SessionStart hook can be command or mcp_tool, not prompt). Publishing a hook with an unsupported combination is rejected with a clear 400, before it ever reaches a run.