The skills-repository pattern, and this repo's own version of it
Claude Code's Agent Skills format (grounded above) is also the format Claude Tag uses in Slack, per docs/docs/claude.com/docs/claude-tag/admins/skills-repo.md ("Set up a skills repository Claude can update"): "Claude Tag uses the same skills format as Claude Code." That doc describes a specific, higher-leverage pattern for maintaining skills at scale: put them in a git repository instead of uploading one at a time, so Claude can propose improvements as pull requests instead of a human re-uploading a file by hand.
How updates propagate, per the doc
| Stage | What happens |
|---|---|
| Claude works in a channel | Using the skills currently attached to that scope |
| Claude proposes an update | Opens a pull request against the skills repository, under the Claude GitHub App identity, linked back to the thread that prompted it |
| You review and merge | The PR is yours to approve, edit, or close, like any contributor's |
| The marketplace syncs | On push to the default branch, the updated plugin syncs to your organization automatically |
| New threads pick it up | The next thread in any covered channel uses the updated skill. Threads already running keep what they started with. |
-- skills-repo.md, "How updates propagate." Every skill change reaches channels only after a human approves the merge; Claude opens the PR, you merge it.
This repo's own real version of the same pattern
This is not a hypothetical for this codebase -- it's exactly how every skill this site catalogs got here. plugins/*/skills/*/SKILL.md live in this same git repository, .claude-plugin/marketplace.json is the plugin-marketplace registration skills-repo.md describes ("register the repository as a plugin marketplace"), and every one of this repo's real commits touching a SKILL.md went through the same review-then-merge step the doc requires, not an unreviewed auto-apply. The one structural difference: skills-repo.md describes Claude opening the PR from something it learned in a live Slack channel, whereas this repo's skill authorship happens directly in a Cowork/Claude Code session -- the review gate is the same, the trigger for the proposed change is different.
What belongs in the repo vs. somewhere else
| Put in the skills repo | Put in channel memory instead |
|---|---|
| How to call a specific API correctly | This channel's preferred output format |
| A runbook that any team would reuse | A one-off decision this channel made |
| Tool-specific gotchas (auth headers, pagination, rate limits) | Who owns what in this team |
-- skills-repo.md, "What belongs in the repository." The left column is exactly what this site's rows are: deploy-playbook is a reusable wrangler/D1 runbook, data-playbook is API-call gotchas for the warehouse, and so on across the whole catalog -- none of them are one-off decisions scoped to a single session, which is precisely why they're durable plugin skills instead of session-local instructions.
Source: docs/docs/claude.com/docs/claude-tag/admins/skills-repo.md, mirrored verbatim on subagentcowork.com/claude-tag/admins/skills-repo.