Catalog Mcp

Skills and Agents Library

Skills that make Claude Code more capable. Install one with a single command.

Browse the live catalog at skillsandagents.co · Built and maintained by Skills and Agents Co

Each skill adds a specific capability to Claude: check your business cashflow, see where your brand shows up in ChatGPT, fix your Ghost site's Google indexing, walk through filing an unemployment claim. One install, and Claude instantly knows how to do the job.

This repo is the source of truth for every skill we publish. Each is MIT-licensed, version-tagged, and ready to drop into Claude Code, Claude Desktop, or any Anthropic-compatible runtime that loads SKILL.md files.

Install the plugin marketplace

Add the marketplace once, then install any plugin from it:

/plugin marketplace add skills-agents-co/skills-and-agents-library

/plugin install financial-pulse@skills-and-agents

Swap financial-pulse for any plugin listed in .claude-plugin/marketplace.json. financial-pulse connects to Mercury, Ramp, and Grasshopper for a cashflow pulse. product-builder bundles code review, PR summaries, research briefs, competitor intel, and document drafting.

Who this is for

• End users who want Claude to handle a specific task end-to-end — no prompting tricks, no glue code. Pick a skill, install it, ask Claude.
• Product managers evaluating what Claude skills look like in the wild — real-world scope, packaging, and triggers worth borrowing.
• Developers building their own skills and agents — every folder here is a working reference you can fork, study, or PR against.

What's inside

Find a skill by what you want to do

More skills land here regularly. Star or watch this repo or follow the catalog to catch new releases.

Install in 30 seconds

Every skill installs the same way: download one pinned tarball, extract the skill's whole folder into ~/.claude/skills/, then restart Claude Code. Extracting the folder, not just SKILL.md, is what brings along the scripts/ and references/ files a skill's own instructions actually run.

(  set -e  skill="resume-tailor"   # <-- change me to the skill's folder (see note below)  ref="v1.42.0"            # pinned release; matches index.json's skillFileUrl
  # The install removes "$HOME/.claude/skills/$skill" before it copies. If  # $skill were empty or a path, that line would delete the wrong directory —  # every skill you have installed — so refuse anything but a plain name.  # The last arm rejects any character outside a folder name, which also keeps  # a glob like "*" out: bsdtar treats a member pattern as a glob, so "*" would  # extract the entire repository instead of one skill.  case "$skill" in    ""|.|..|*/*|-*|*[!A-Za-z0-9._-]*)      echo "Set skill to a plain folder name, e.g. resume-tailor" >&2; exit 1 ;;  esac
  work="$(mktemp -d)"  trap 'rm -rf "$work"' EXIT
  curl -fsSL --connect-timeout 10 --max-time 120 --retry 3 --retry-delay 2 \    --retry-connrefused --retry-max-time 120 -o "$work/repo.tgz" \    "https://codeload.github.com/skills-agents-co/skills-and-agents-library/tar.gz/$ref"
  mkdir -p "$work/staged"  topdir="$(tar -tzf "$work/repo.tgz" | grep -m1 '/' | cut -d/ -f1)"  tar -xzf "$work/repo.tgz" --strip-components=2 --no-same-owner --no-same-permissions \    -C "$work/staged" "$topdir/$skill"
  dest="$HOME/.claude/skills/$skill"  rm -rf "$dest"  mkdir -p "$(dirname "$dest")"  cp -R "$work/staged" "$dest"
  echo "Installed to $dest")

The block runs in a subshell (the parens) so skill, ref, and the other variables it sets do not leak into your shell, and set -e inside it means a failed download or a bad skill name stops the install instead of leaving a half-populated directory that looks successful. It downloads and unpacks into a scratch directory first and only touches ~/.claude/skills/ once the extraction has succeeded, so a failed install leaves nothing behind: no empty skill folder for Claude Code to find, and no stray tarball. Re-running it replaces the install rather than merging into it, so a file dropped from a later release does not survive as a stale leftover.

What to put in skill. For almost every entry it is the folder name shown in the table above (resume-tailor, ceo-todo, and so on) — which is also the slug. It is not the slug for the four agents that ship inside another skill's folder: ceo-todo-daily installs as skill="ceo-todo", and financial-pulse-grasshopper, financial-pulse-mercury, and financial-pulse-ramp all install as skill="financial-pulse". Installing one of those pulls in the whole parent skill (including its other agents), which is expected — the agent file itself is the payload you actually run.

Installing an agent takes one more step. Claude Code loads subagents from ~/.claude/agents/, not from inside a skill folder, so the four agent entries above need their markdown copied out after the install block runs. Otherwise the file is on disk and the agent still does not register:

(  set -e  agent="ceo-todo-daily"   # <-- or financial-pulse-grasshopper / -mercury / -ramp  skill="ceo-todo"         # <-- the folder it ships in, per the paragraph above
  # Each name is checked on its own. Testing "$agent$skill" would only catch an  # empty value when BOTH were empty, so an empty $agent with a real $skill  # sailed through.  for name in "$agent" "$skill"; do    case "$name" in      ""|.|..|*/*|-*|*[!A-Za-z0-9._-]*)        echo "Set agent and skill to plain names, e.g. ceo-todo-daily / ceo-todo" >&2; exit 1 ;;    esac  done
  mkdir -p "$HOME/.claude/agents"  cp "$HOME/.claude/skills/$skill/agents/$agent.md" "$HOME/.claude/agents/$agent.md"  echo "Installed agent to $HOME/.claude/agents/$agent.md")

The fastest path is skillsandagents.co — every skill's catalog page will generate this exact pinned command for you, copy-paste ready, once the catalog site adopts the manifest this repo now publishes. Until then it still generates the older single-file command, so the command above is the one to use by hand in the meantime.

Two skills nest their SKILL.md one level deeper: ads-copilot and financial-pulse. The command above still extracts their whole folder correctly, but SKILL.md lands at $dest/skills/<skill-name>/SKILL.md instead of at the top, where Claude Code looks for it. Run this once more, right after the block above, for those two:

bash

(  set -e  skill="ads-copilot"   # or "financial-pulse"  mv "$HOME/.claude/skills/$skill/skills/$skill/SKILL.md" "$HOME/.claude/skills/$skill/SKILL.md")

references/ and scripts/ are already siblings of the moved SKILL.md, which is where its own text expects them. Every other skill in this repo is flat and needs no extra step.

Install via skills.sh

These skills are also installable through skills.sh, the open skills registry. Install the whole catalog at once:

npx skills add skills-agents-co/skills-and-agents-library

Or pull a single skill by its slug:

npx skills add skills-agents-co/skills-and-agents-library --skill <slug>

Available skills and their slugs:

• learn-quiz (make Claude teach you the work until you actually understand it)
• ghost-seo-agent (diagnose and fix Ghost Google indexing)
• office-tells (strip the AI tells from .pptx/.docx/.xlsx)
• buy-side-diligence (run buy-side due diligence on a private company)
• llm-visibility-agent (see where your brand shows up across ChatGPT, Perplexity, and Claude)
• financial-pulse (weekly cashflow pulse across Mercury, Ramp, and Grasshopper)
• ads-copilot (chat with your ad and analytics data for ranked optimization moves)
• meeting-scribe (turn a meeting transcript into structured meeting memory, inspired by USV)
• calendar-agent (prep briefs for upcoming meetings against your tracked people/companies, inspired by USV)
• news-monitor (news digests on your tracked people/companies filtered against your own entity files, inspired by USV)
• librarian (recurring themes from your meeting notes drafted into short posts, inspired by USV)
• email-agent (log an email thread's deal-flow or portfolio update against your tracked people/companies, inspired by USV)

The full catalog, with per-skill pages and pinned install commands, lives at skillsandagents.co. Skills surface on skills.sh automatically through install telemetry, so there is no registration step on our end.

Why these skills exist

Every skill in this repo solves a problem we actually had running our own companies — then we generalized it so anyone can use it. We pin every install URL to a tagged release (never main), so the skill you install today behaves the same way next month.

For skill authors

This repo doubles as a working reference for how we package skills:

• SKILL.md with rich YAML frontmatter — name, description, and trigger phrases that Claude actually matches against
• One folder per skill, supporting files in references/, agents/, scripts/
• Tagged releases — v1.0.0, v1.1.0, etc. — with a generated index.json the catalog consumes
• Contribution path in CONTRIBUTING.md: new skill = new top-level folder, one PR

A skill that ships both standalone and bundled inside a plugin (e.g. local-lead-prospector and its plugin copy plugins/eta-searcher) can end up with the same supporting file committed twice. For requirements.txt, exactly one copy is human-edited — the top-level skill's — and every plugin-nested copy is generated from it via scripts/plugin-file-map.json. After editing a canonical requirements.txt, run node scripts/generate-plugin-files.mjs and commit the regenerated copy alongside your change. CI's scripts/check-plugin-files-fresh.mjs step fails the build if a plugin-nested copy has drifted from its source, so a forgotten regeneration cannot merge silently.

Cutting a release:

The index is committed before the tag is placed, not after. Tagging first would leave the tag's own tarball carrying the previous release's index.json, so the manifest a user downloads would never describe the download it came in.

A release commit does not go through a pull request. It is the one commit in this repo that pushes straight to main, with the tag created and pushed in the same motion. The reason is mechanical, not stylistic: a release commit bumps index.json and the ref="…" line above to a tag that does not exist yet, and scripts/check-index-additive.mjs and scripts/test-install.sh both resolve that ref. Opened as a PR, the release commit is red by construction, and there is no green state to merge — the ref only becomes resolvable once the tag is pushed, which happens after the merge. So: land the content changes through PRs as usual, then cut the release as a direct push. Nothing else in this repo is allowed to bypass review this way.

1. Bump version in frontmatter for any changed SKILL.md. This is normal PR work, reviewed like anything else, and it lands before the release commit.
2. On an up-to-date main, rebuild the index for the tag you are about to cut: node scripts/build-index.mjs --tag v1.x.0 --worktree. --worktree is required here and only here — the tag does not exist yet, so there is no ref to read content from, and the working tree is what is about to become that tag.
3. In the same commit, bump the ref="v1.x.0" line in the install block above to the new tag. scripts/check-index-additive.mjs fails the build if the README's ref and index.json's ref disagree, so this is not optional and CI will say so.
4. Commit the regenerated index.json and the README together, directly on main.
5. Tag that commit and push both in one command: git tag v1.x.0 && git push --atomic origin main v1.x.0. --atomic is what makes this one command: either the commit and the tag both land or neither does. Without it, a partial push leaves main briefly pinned to a ref nobody can resolve, which is exactly the red state this step exists to avoid.
6. Only now do the ref-resolving local checks mean anything. Run node scripts/check-index-additive.mjs, bash scripts/test-install.sh, and bash scripts/test-readme-install.sh against the pushed tag. Running them between steps 2 and 5 is expected to fail and tells you nothing.

Because the tag lands on the commit that already holds the matching index.json, the tag-push build checks the tag against its own manifest rather than against the last release's, and re-running node scripts/build-index.mjs --tag v1.x.0 afterwards reproduces the committed file byte for byte.

On a normal pull request none of this bites. A PR does not touch the pinned ref, so the ref index.json names is the last release's tag, which resolves fine, and every check runs for real. The only PR that would go red by construction is one that bumps the ref — and that is precisely the commit the note above says not to open as a PR.

index.json describes the tagged release, not your checkout: build-index.mjs --tag v1.x.0 reads the repo's contents at that tag, and scripts/test-install.sh verifies the published files manifest against that same tag's tarball. That is why a pull request adding a file inside a skill folder does not need to regenerate index.json — the new file joins the manifest at the next release, and until then both checks are looking at the same snapshot. If the tag is not in your clone the build fails rather than quietly reading your working tree instead; run git fetch --tags, or pass --worktree when reading the working tree is what you actually want.

License

MIT — see LICENSE. Individual skill folders may carry their own license file if imported from a separately-licensed source.

Questions, bug reports, or skill ideas? Open an issue or PR. We read every one.