Skills
Your workspace's skill library — every agent skill your team has codified, indexed across repos and searchable from the dashboard chat and from every agentic editor through the Atmos Pro MCP.
Atmos Pro turns your team's agent skills into a workspace skill library. Every
SKILL.md your team has codified — across your infra repo, your docs repo, your internal handbook — is pulled into one searchable catalog. Connect each repo as a skill source (pick the ref, pick the subdirectory), and the library shows up wherever your team works: in the dashboard chat and in every agentic editor through the Atmos Pro MCP. Type /postmortem and the agent applies your team's postmortem voice and structure. Type /triage and it walks through failing runs, drift, and pending approvals the way your team has decided to.This page is about why Skills exist and how they fit together. For step-by-step instructions on creating, importing, enabling, and disabling them, see Skills configuration.
A skill bundles three things: a slug (the slash command, like
/postmortem), a description (so agents know when to load it), and a prompt body (the voice, structure, output expectations, and any artifact-creation rules the skill enforces). When a user invokes the slash command — or an agent decides the skill matches the question — the prompt body is appended to the chat's system context and the rest of the turn proceeds with that voice.The slug is the user-visible handle. The description is what an agent reads to decide whether to load the skill. The prompt body is the actual instructions.
A skill library only helps if the right skill surfaces at the right moment. Without an index, every agent has to load every skill's name and description at startup just to know what's on the shelf — fine for a handful of skills, expensive once a team has dozens across multiple repos.
The Atmos Pro MCP acts as a librarian. Instead of memorizing the whole catalog, an agent asks the librarian for what it needs —
search_skills for a topic, get_skill for the prompt body, list_skill_references and get_skill_reference for supporting docs — and only the matching content lands in context. Fewer tokens, sharper focus.SKILL.md is an open standard, but every agent tool — Claude Code, Cursor, GitHub Copilot, Codex, Goose — has its own way to import and configure skills. The one thing they all agree on is MCP. Configure Atmos Pro as an MCP server once in your tool of choice, and the whole library comes with it. Add a new source on the Atmos Pro side, and every developer's tools find it the next time they connect. It's the same pattern MDM platforms like Jamf use to push software to corporate endpoints — central registration, governed distribution — applied to agent skills.A workspace's catalog is the union of several sources.
- Native system skills. Atmos Pro ships a small set, starting with
/postmortem, that every workspace sees by default. Workspace admins can clone them to customize the voice without losing the upgrade path on the original. - Workspace-authored skills. A workspace admin writes a prompt directly in Settings. These are private to that workspace.
- Imported skills from a skill repository. A workspace admin registers an external GitHub repository as a skill source. Atmos Pro syncs the repository on a schedule and exposes every
SKILL.mdit finds as a workspace-visible skill. The official Atmos skills (/atmos-ci,/atmos-stacks,/atmos-introspection, and so on) ship as a pre-installed source pinned to cloudposse/atmos.
A skill repository is a GitHub repo (or subpath of one) that contains a tree of
SKILL.md files. The shape Atmos Pro expects is:<github_path>/
atmos-ci/
SKILL.md
references/
github-actions.md
spacelift.md
atmos-stacks/
SKILL.md
...
Each subdirectory becomes one skill. The
SKILL.md body becomes the prompt, frontmatter (name, description, metadata.version) becomes the routing metadata, and markdown files under a sibling references/ directory become supporting examples and notes the agent can list with list_skill_references and load on demand with get_skill_reference.If the repository follows the Claude Code plugin manifest convention (
.claude-plugin/plugin.json at the plugin root), Atmos Pro picks up the author, license, and description from the manifest and surfaces them in the Settings UI.You can expose any skill repository this way, provided either the Atmos Pro GitHub App is installed on that exact repository for the workspace or the repository is public.
- Private repositories require the App. When the App is installed on the repository and linked to the workspace, Atmos Pro mints a short-lived installation token to read that repository's content. This is the only path that works for private sources.
- Public repositories work without the App. When no workspace-linked installation exists, Atmos Pro can still read public GitHub repositories without borrowing another workspace's installation.
The built-in Atmos source is pinned to a reviewed
cloudposse/atmos commit and is public, so it works for every workspace out of the box. Adding your own public source works without installing the App; adding your own private source requires installing the App on that exact repository for the workspace first.Distribution is centralized; curation stays local. Adding a source doesn't mean exposing every skill in it. Two layers of control:
- Per-source visibility. A workspace can hide an entire source without losing the per-skill choices they've already made. Toggle it back on and prior enablement state restores.
- Per-skill enablement. A workspace can disable individual skills they don't want their team using. Disabled skills disappear from the slash menu and from MCP
list_skills— but stay visible in Settings for editing and history.
Per the opt-out default, every skill under a built-in source is enabled for every workspace by default. Workspaces opt out, not in.
A skill often produces something worth keeping — a postmortem document, a drift summary, an investigation handoff. Chats are good for the investigation; artifacts are how the output survives the chat session.
Skills can call MCP tools like
create_pdf to persist their output as a workspace artifact attributed to the originating skill. Teammates find the result in the artifacts inbox later instead of losing it in someone's chat history. See Chat artifacts for the operational details.- Skills configuration — create, import, enable, disable, sync.
- MCP Server — the delivery mechanism that puts skills in every editor.
- Workspaces — the tenancy boundary skills live in.