The Claude Skills Catalog

Repository: github.com/anthropics/skills/tree/main/skills/skill-creator

Intent

Guide Claude through creating, validating, and optimizing new SKILL.md files for any domain.

Motivating Problem

Writing a good SKILL.md is harder than it looks. The description field is a classifier prompt that determines whether Claude reaches for the skill; getting it wrong means the skill never fires or fires constantly on the wrong tasks. The body should stay under 500 lines, organize references by domain when it covers multiple frameworks, and avoid burning context with information that should live in lazily-loaded reference files. There are enough sharp edges that a skill that codifies the conventions earns its place in the catalog.

How It Works

The skill walks Claude through the lifecycle of producing a skill: gather requirements, draft the SKILL.md, write evaluation queries that distinguish should-trigger from should-not-trigger cases, run the queries against the draft, refine the description until activation accuracy crosses a threshold, then test the body on representative tasks. It enforces structural conventions --- the 500-line ceiling, the references/ subdirectory pattern for multi-domain skills, the explicit reference instructions in the body, the prohibition on bundling executable code that would surprise the user.

The skill is unusually self-aware about its own role: it includes an explicit instruction that descriptions should be “pushy” --- enumerating the specific phrases and contexts that should trigger the skill, even when those triggers are obvious from the skill name. The stated reason is that Claude tends to undertrigger skills, not using them when they would help, so the description has to list the trigger contexts explicitly.

When to Use It

Whenever creating a new skill, especially the first time. The skill is fast to use and the lessons it encodes apply across domains. Community repositories such as posit-dev/skills point contributors to skill-creator. The skill now also ships grader, comparator and analyzer agents and an eval viewer for reviewing test runs.

Sources

• github.com/anthropics/skills/tree/main/skills/skill-creator

• Anthropic, Equipping agents for the real world with Agent Skills (October 2025)

Example

You want a skill that handles invoice-parsing tasks. You invoke skill-creator with that goal; it asks clarifying questions about the input formats, the desired output schema, and which related tasks should and shouldn’t trigger the skill. It produces a draft SKILL.md plus a JSON file of twenty test queries (“parse this invoice PDF” should trigger; “write a marketing email about invoices” should not). You run the tests, refine the description, iterate.

Example artifacts

Invocation.

# Activate skill-creator in any agent that has it installed.

"I want to create a skill for parsing scanned invoices into
structured JSON.

The skill should trigger on uploads of invoice-like PDFs/images and
ignore

general document-processing requests. Walk me through it."

SKILL.md sketch.

---

name: invoice-parser

description: "Parse scanned invoices, receipts, and bills into a
normalized

JSON schema. TRIGGER when: user uploads a PDF or image of an invoice/

receipt/bill; user asks to 'extract line items' or 'parse this
invoice';

request mentions vendor, amount, line items, tax, total. SKIP:
general

document OCR not specifically asking for invoice structure;
data-entry

for forms that aren't invoices."

---

# invoice-parser

## When to use this skill

[generated by skill-creator from clarifying questions]

## Recipe

1. ...

## References

- references/schema.md --- the canonical output JSON schema

- references/vendors.md --- known per-vendor quirks (loaded only on
demand)

Repository: github.com/anthropics/skills/tree/main/skills/claude-api

Intent

Build, debug, and optimize Claude API and Anthropic SDK applications, including migration between model versions and adoption of features like prompt caching, tool use, thinking, and Managed Agents.

Motivating Problem

SDK signatures, beta headers, and model strings change over the life of any Claude project. A model trained six months ago will hallucinate import paths, miss prompt-caching opportunities, mix Anthropic-flavored SDK calls with OpenAI-flavored shims, and recommend deprecated patterns. The claude-api skill exists to bind the model’s code generation to the current SDK surface, with explicit per-language references and a directive to web-fetch the SDK documentation when in doubt.

How It Works

The skill organizes its content by Anthropic surface (Claude API, Managed Agents, Skills API, Files API) and by language (Python, TypeScript, Java, Go, Ruby, C#, PHP, plus cURL for raw HTTP). The body has a decision matrix mapping use cases to surfaces: stateful long-running agent with file mounts → Managed Agents; bespoke tool runtime → Claude API with tool use; quick single-shot completion → Messages API.

It enforces two non-negotiables: use the official SDK for the project’s language (no falling back to raw requests/fetch when an SDK exists), and never use OpenAI-compatible shims to call Claude. The skill includes a shared/live-sources.md file listing canonical URLs for each SDK; when the binding the model needs is not in the skill’s reference files, the skill instructs Claude to fetch the SDK documentation rather than guess.

Migration is first-class: a shared/model-migration.md playbook covers breaking changes by source model and retired-model replacements, and separate modes handle SDK major-version upgrades. The skill triggers whenever Claude, Anthropic or an Anthropic package is mentioned, or the task is LLM-shaped with no provider named, and steps aside when the project uses another provider.

When to Use It

Any time code that calls the Claude API or Managed Agents is being authored, debugged, or migrated. The skill is essentially a guard against the model’s training-cutoff staleness in this specific narrow domain. Skip it for general programming, for code that calls other providers, and for provider-neutral abstractions.

Sources

• github.com/anthropics/skills/tree/main/skills/claude-api

Example

Migrating a Python codebase from claude-opus-4-6 to claude-opus-4-7 with prompt caching turned on. Without the skill, the model is likely to retain old beta-header names and miss the cache-control breakpoint syntax. With the skill, the migration follows the documented path and the resulting code passes the caching-correctness check the skill prescribes.

Example artifacts

Invocation.

# Trigger the skill by referencing the SDK in your file or prompt.

"Upgrade this Python module from claude-opus-4-6 to claude-opus-4-7
and

add prompt caching for the long system prompt."

# Claude reads the claude-api SKILL.md (already in context), follows
the

# migration recipe, and applies the cache-control pattern from
references/python.md.

Repository: github.com/anthropics/skills (skills/docx, skills/pdf, skills/pptx, skills/xlsx)

Intent

Create, edit, and analyze Microsoft Office and PDF documents from Claude, with full fidelity for tracked changes, comments, formulas, layouts, and binary attachments.

Motivating Problem

Generating Word, Excel, PowerPoint, and PDF documents correctly is a deep problem that the model cannot solve from training alone. The file formats are XML-in-ZIP archives with idiosyncratic namespacing; preserving comments, tracked changes, and complex formatting requires specific library calls that the model gets wrong without prompting. These four skills exist because they are what powers Claude’s own native document-generation in claude.ai and the Claude API --- they are not demos but production code with reference implementations.

How It Works

Each skill has a SKILL.md describing what it does and when. docx, pptx and xlsx share a scripts/office/ directory with the Python scripts that handle the heavy lifting (soffice.py for headless conversion, validate.py); pdf ships its own form-filling and extraction scripts plus forms.md and reference.md. The body tells Claude when to reach for a script vs. when to write inline code; for docx for example, text extraction with tracked-changes preservation goes through pandoc, while editing raw XML means unzipping the file, running merge_runs.py, editing word/document.xml and re-zipping. New documents are created with docx-js.

The skills explicitly delineate scope: docx triggers on requests for Word documents and explicitly says NOT to use it for PDFs, spreadsheets, or Google Docs. Same negative-trigger discipline for the other three. This prevents cross-activation that would degrade output quality.

Critical: the docx, pptx and xlsx skills carry their own validate.py and soffice.py utilities under scripts/office/, which the skill instructs Claude to use for round-trip validation before declaring the document complete. This catches a class of formatting errors that the model alone would miss.

When to Use It

Any request that produces or consumes a .docx, .pdf, .pptx, or .xlsx file. For Word: tracked-changes documents, formatted letters, multi-section reports, templates. For PDF: form filling, table/image extraction, merging or splitting. For PowerPoint: pitch decks, structured slide content. For Excel: spreadsheets with formulas, charts, or pivot tables. Not for general text content where Markdown or plain text is appropriate.

Sources

• github.com/anthropics/skills/tree/main/skills/docx

• github.com/anthropics/skills/tree/main/skills/pdf

• github.com/anthropics/skills/tree/main/skills/pptx

• github.com/anthropics/skills/tree/main/skills/xlsx

• License: source-available (proprietary). The skills are released as a snapshot reference; they are not actively maintained as open source.

Example

Generating a 50-page docx with embedded images, a table of contents that auto-populates on Update Fields, and a footer with page numbers. The skill’s recipe walks the model through using docx-js, the soffice.py round-trip validation, and the structural conventions for headings that the TOC field expects.

Example artifacts

Invocation.

# Skill activates automatically when the user asks for a Word, PDF,
PPT,

# or Excel deliverable.

"Produce a polished pitch deck as a .pptx with a title slide,
problem,

solution, market sizing, and team. Use a clean minimal style."

# Claude reads pptx/SKILL.md, consults pptx/scripts/office/ helpers,

# and writes the file with validate.py round-tripping it before
delivery.

Repository: github.com/anthropics/skills/tree/main/skills/frontend-design

Intent

Instruct Claude to avoid generic “AI slop” aesthetics and make distinctive, considered visual decisions when building new UI or reshaping an existing one.

Motivating Problem

A bare model asked to “make a beautiful landing page” produces a recognizable default --- gradient buttons, the same hero layout, the same overused stock icon set. The aesthetic is competent and indistinguishable from every other model’s default. frontend-design is the explicit countermeasure: a skill that loads design vocabulary, encourages bolder typographic decisions, and constrains the model toward distinctive rather than safe choices.

How It Works

The skill loads design principles around typography, color, and layout that nudge the model away from the lowest-common-denominator template. It pairs with the web-artifacts-builder skill (which knows the technical particulars of claude.ai artifacts: Tailwind, shadcn/ui, lucide-react, the available libraries and their import paths). frontend-design owns aesthetic judgment and is framework-neutral; web-artifacts-builder owns the technical surface.

The skill is one of the more frequently cited in community discussions because the contrast with the default is so visible. Public artifacts produced with frontend-design loaded tend to be identifiable on inspection.

When to Use It

Any artifact, component, or page where visual quality is an explicit goal. Particularly useful for landing pages, marketing pages, and design-sensitive React components. Less useful for purely functional internal tooling where defaults are fine.

Sources

• github.com/anthropics/skills/tree/main/skills/frontend-design

Example

Asked to design a pricing page, a vanilla Claude produces a three-column card layout with gradients and check-mark bullet lists. With frontend-design loaded, the same prompt is more likely to produce a typographic page with deliberate asymmetry, a curated palette, and varied content emphasis. The aesthetic difference is large enough to be visible without a side-by-side comparison.

Example artifacts

Invocation.

# frontend-design activates on UI/page-design requests.

"Design a pricing page for a developer tools product. Three tiers.
Make

it distinctive --- do not give me the default SaaS template."

Repository: github.com/anthropics/skills/tree/main/skills/mcp-builder

Intent

Guide Claude through producing high-quality MCP servers --- the integration layer between Claude (or any MCP-compatible agent) and external APIs or data sources.

Motivating Problem

Writing an MCP server end-to-end --- transport choice (stdio vs Streamable HTTP), tool schemas, capability negotiation, error handling, packaging --- has enough surface area that the model produces incomplete or subtly-wrong servers from a bare prompt. mcp-builder is the codification of the contract.

How It Works

The skill walks Claude through the MCP server lifecycle: pick the transport, define tools with input schemas, write resources if applicable, handle errors per the spec, package for distribution (npm or PyPI), document for the user. The skill includes reference guides for Node and Python servers, a checklist that catches the common mistakes (missing tool descriptions, schemas that don’t match handler signatures, capability flags omitted), and an evaluation harness (scripts/evaluation.py) for testing whether an agent can use the finished server.

It pairs naturally with the claude-api skill when the user wants to both consume Claude and expose tools to it; the two skills can be active concurrently.

When to Use It

Producing a new MCP server, especially the first time, or when integrating an unfamiliar third-party API as an MCP tool. Skip it for using existing MCP servers (which is a Claude API + tool use task, covered by claude-api).

Sources

• github.com/anthropics/skills/tree/main/skills/mcp-builder

• Model Context Protocol specification (modelcontextprotocol.io)

Example

Building an MCP server that exposes Linear issue search and creation as tools. The skill guides Claude through choosing stdio transport (since Linear is per-developer), defining search_issues and create_issue tools with strict input schemas, and packaging the result as a npm-installable binary.

Example artifacts

Invocation.

"Build an MCP server that exposes our internal time-tracking API as
tools.

Endpoints: list_entries, create_entry, summarize_week. Use stdio
transport."

Repository: github.com/anthropics/skills/tree/main/skills/webapp-testing

Intent

Test local web applications using Playwright for UI verification, debugging, and visual diffing.

Motivating Problem

When a coding agent produces a web application change, the loop “write code → see if it works in the browser → fix bugs” needs a reliable closing step. Without it the agent ships code that compiles and reads correctly but breaks in the browser. webapp-testing is the skill that closes the loop by giving Claude a Playwright-driven way to actually load the page, click through flows, and observe results.

How It Works

The skill scaffolds Playwright tests, manages the browser session, captures screenshots and console output, and feeds the observations back into Claude’s context. It pairs with the autonomous-agent pattern (Claude tries something, observes the browser result, revises) and with HITL checkpoints (“does this look right?” before merge).

When to Use It

Any frontend or full-stack change where the agent needs to verify end-user behavior rather than just compile-time correctness. Particularly valuable on UI bug-fix work and on accessibility/visual regression catches.

Sources

• github.com/anthropics/skills/tree/main/skills/webapp-testing

Example

Fixing a login flow bug where a redirect lands on the wrong page after authentication. The skill scripts Playwright to log in with test credentials, observe the resulting URL, capture a screenshot, and report back to Claude with the actual vs. expected URL. Claude revises, reruns the script, ships when the redirect is correct.

Example artifacts

Invocation.

"There's a bug where users land on /dashboard instead of /home after
login.

Reproduce it with the testing skill, fix it, and verify the fix with
a screenshot."

Repository: github.com/posit-dev/skills (posit-dev/critical-code-reviewer)

Intent

Conduct rigorous, adversarial code reviews that name security holes, lazy patterns, edge-case failures, and bad practices across Python, R, JavaScript/TypeScript, SQL, and front-end code.

Motivating Problem

Bare Claude on a code review tends toward agreeable, surface-level approval. It will note style issues and obvious bugs but will not push hard on architectural decisions, will not assume malicious inputs by default, and will accept lazy patterns (“this works”) without questioning whether they are correct. The critical-code-reviewer skill is an explicit instruction to take the opposing role: assume the code is wrong and look for proof.

How It Works

The skill loads an adversarial reviewer persona with explicit checklists per language: SQL injection and parameterization for SQL; XSS, CSRF, and input validation for front-end; race conditions and resource leaks for backend; correctness of error handling and idempotency for distributed code. It instructs Claude to list specific failure cases with line references rather than general comments. The output format is a list of findings ranked by severity, each with a concrete bad-input example that would trigger the failure.

The skill now also covers accessibility, sorts findings into Blocking and Verify tiers, and can prepare and submit the result as a GitHub PR review.

Critically, the skill includes a “lazy pattern” category: code that works but should not have been written that way. Catch-all error handlers, silent swallowing of exceptions, hardcoded secrets, ignored return values. These rarely produce visible bugs in development but cause incidents in production.

When to Use It

Pre-merge code review on any change that touches data handling, security boundaries, or production code. Particularly valuable as the second reviewer after the author’s self-review and before a human review --- it catches the categories a tired human reviewer is likely to miss.

Sources

• github.com/posit-dev/skills

Example

A SQL query string built with string concatenation passes a developer’s eyes; critical-code-reviewer flags it as parameterization-missing with a concrete injection payload that would exfiltrate other rows. A try/except: pass block in a Python data pipeline passes review; critical-code-reviewer flags it as silent-failure with the specific case where it would mask a corrupted batch.

Example artifacts

Invocation.

# In an agent with critical-code-reviewer installed:

"Run a critical review on the changes in this branch. Be
adversarial.

Assume malicious inputs and a tired human reviewer."

Repository: github.com/posit-dev/skills (posit-dev/describe-design)

Intent

Research a codebase and create architectural documentation describing how features or systems work, with Mermaid diagrams and stable code references.

Motivating Problem

Documenting an undocumented codebase is the canonical task no one wants to do. The model is more patient than a human and can read every file, but without structure it produces either bland prose summaries or low-value comments on individual functions. describe-design exists to give that work shape: it produces design documents at the right level of abstraction, with diagrams that survive refactors and references that survive renames.

How It Works

The skill instructs Claude to first survey the codebase structure (build files, entry points, module organization), then identify the feature or system to be documented, then trace its execution paths from inputs to outputs. The output is a Markdown document with sections for context, data flow, key abstractions, and known limitations.

Mermaid diagrams are first-class: the skill knows which Mermaid styles render well for sequence flows, component relationships, and state machines, and produces them inline in the document. References to code use stable identifiers (function names, module paths) rather than line numbers, so the document doesn’t rot after a refactor.

The output is explicitly written for two audiences: humans reading the document and AI agents loading it as context for future work. The latter is non-trivial: the document is shaped to be useful as a reference loaded into the next session’s prompt.

When to Use It

Onboarding to a new codebase, planning a refactor, writing the missing architecture document before a major change, or producing handoff documentation when transferring ownership.

Sources

• github.com/posit-dev/skills

Example

Inherited a Django monolith with no design docs and a handful of senior engineers leaving. Invoke describe-design on the order-fulfillment subsystem. The output is a markdown document with a Mermaid sequence diagram of the order → fulfillment → shipping flow, a component diagram of the modules involved, and named pointers into the code (“See fulfillment.workers.dispatcher”). The document becomes the canonical reference for the team.

Example artifacts

Invocation.

"Run describe-design on the order-fulfillment subsystem. The entry
point is

the dispatch_order task in workers/fulfillment.py. Document with
sequence

diagrams and component relationships."

Repository: github.com/posit-dev/skills (r-lib/r-testthat)

Intent

Write idiomatic R package tests using testthat 3+, with the appropriate use of fixtures, snapshots, mocking, and BDD-style describe/it blocks.

Motivating Problem

R’s package-testing conventions have evolved meaningfully across testthat versions, and Claude’s training data is biased toward older patterns. The skill encodes the current best practice as of testthat 3+: edition-3 semantics, snapshot tests for output-heavy functions, mocking via testthat::local_mocked_bindings(), and the BDD-style describe/it blocks that read as well in R as they do in JavaScript.

How It Works

The skill loads patterns and references for each testing scenario: testing a function with side effects (use mocking), testing console output (use snapshot tests), testing across a parameter grid (use parameterized expect_equal), testing internal helpers (use testthat::local_mocked_bindings). It pairs naturally with the r-cli skill (for testing functions that produce CLI output) and the r-lifecycle skill (for testing deprecation warnings).

When to Use It

Writing or updating tests in any R package, especially when adopting testthat 3 edition or migrating from older patterns. Not useful for non-R projects.

Sources

• github.com/posit-dev/skills (r-lib category)

Example

Adding tests to a CRAN package that previously had only basic expect_equal coverage. The skill restructures the tests into describe/it blocks, adds snapshot tests for the print methods, and converts file-system side-effect tests to use withr::local_tempdir().

Example artifacts

Invocation.

"Add testthat 3 edition tests to this R package. Use snapshots for
print

methods, withr for any tempdir setup, and BDD-style describe/it."

Repository: github.com/posit-dev/skills (open-source/release-post, open-source/create-release-checklist)

Intent

Streamline package releases: a changelog-driven release blog post for R or Python packages, and (for R packages) a per-release checklist filed as a GitHub issue.

Motivating Problem

Releasing a non-trivial open-source package is a multi-step ritual: write release notes, generate the changelog, write the announcement blog post, draft the social posts, run the release checks, tag the release, build artifacts, push to the registry, publish the post. Most of these steps are easy to forget; experienced maintainers maintain their own informal checklists. The skills codify the Tidyverse and Shiny blog conventions and Posit’s internal release checklists for community use.

How It Works

create-release-checklist (R packages only) generates a GitHub issue from a template, with version numbers calculated from the current version and the type of release (patch, minor, major). The checklist is a literal todo list that maintainers tick through during the release.

release-post takes the changelog as input and produces a blog post in the conventional structure: short opening, headline features with code examples, deprecations, breaking changes, contributors. It supports both R (Tidyverse style) and Python (Posit Python style).

When to Use It

Releasing any R or Python package, particularly if you want consistent post structure across releases. The checklist generator is written for R packages; for other ecosystems its template is a starting point to adapt.

Sources

• github.com/posit-dev/skills

Example

Releasing dplyr 1.2.0. Invoke create-release-checklist with the version bump type; it opens an issue with the 23 items to tick through. After the release, invoke release-post with the changelog; it produces a draft blog post that goes through standard editorial review and gets published.

Example artifacts

Invocation.

"Generate the release checklist for the next minor version of
{package}."

"Write a release post for {package} {version} following the
Tidyverse blog

format. The notable items are: {features}, {fixes}, {breaking
changes}."

Repository: github.com/posit-dev/skills (alt-text), listed in both the quarto and r-lib plugins

Intent

Generate accessible alt text for figures in Quarto documents, R packages and pkgdown sites using Amy Cesal’s three-part formula: chart type, data description, key insight.

Motivating Problem

Most chart alt text in published documents is either missing or inadequate (“figure 1”, “bar chart”). Writing good alt text requires naming the chart type, summarizing the data, and naming the insight --- a three-part discipline that takes a few sentences and benefits from a consistent template. The skill operationalizes that template.

How It Works

The skill triggers on Quarto chunks that produce figures (#| fig-alt: chunks) and on static image inclusions. It applies the Cesal three-part formula and produces alt text in the conventional structure: “A [chart type] showing [data]. [Key insight].” It handles both code-generated plots (where it can read the data and the plot specification) and static images (where it works from the image and surrounding context).

When to Use It

Authoring Quarto documents intended for publication, especially in accessibility-conscious contexts (academic publishing, government reports, large-organization internal documentation). Useful even outside Quarto for any chart-heavy markdown.

Sources

• github.com/posit-dev/skills (alt-text)

• Amy Cesal’s alt text guidelines (cited in the SKILL.md)

Example

A Quarto document has 23 figures and no alt text. Invoke alt-text on the document. It reads each figure, the surrounding context, and the chart specification, and writes alt text in the Cesal format for each one. Run accessibility checks; they pass.

Example artifacts

Invocation.

"Add Cesal-format alt text to all figures in this Quarto document.
Be

specific about chart type and data, and end each with one insight
sentence."

Repository: github.com/posit-dev/skills (r-lib/r-cli)

Intent

Use the cli R package well: semantic messaging, inline markup, progress indicators, theming.

Motivating Problem

The cli package has a rich API with idiomatic patterns that take time to learn: cli_inform vs cli_alert vs cli_warn, the {.field}, {.val}, {.cls} inline markup, progress bars and spinners, theme customization. A model writing R code reaches for message() and warning() by default --- functional but missing the experience the cli package was built to provide.

How It Works

The skill loads the cli idioms and instructs Claude to use the semantic functions (cli_alert_success, cli_inform, cli_warn, cli_abort) with inline markup for the relevant nouns. For long-running operations it prescribes the cli_progress_* functions with a clean teardown. The skill is named r-cli in the repository; a separate r-cli-app skill covers building command-line apps.

When to Use It

Writing R packages with command-line interfaces, or improving the user experience of existing R scripts. Particularly valuable for packages that produce user-facing messages --- which is most CLI-shaped R packages.

Sources

• github.com/posit-dev/skills (r-lib category)

Example

An R package was using message() and warning() everywhere. Run the r-cli skill on the package; it converts the messages to cli_inform with appropriate inline markup, adds a progress bar to the longest function, and the package immediately feels polished without changing its behavior.

Example artifacts

Invocation.

"Convert all the message()/warning() calls in this package to use
the cli

package idioms, with inline markup for filenames and values."

Repository: github.com/wshobson/agents (plugins/developer-essentials)

Intent

Optimize SQL by reading the query plan first --- parse EXPLAIN output, identify the actual bottleneck, then make targeted changes, rather than reaching for indexes or rewrites on instinct.

Motivating Problem

Bare Claude given a slow query tends to suggest “add an index on column X” as the universal answer, often without justification. Real query optimization is plan-driven: read the EXPLAIN output, find the dominant cost node, address that. The skill enforces this discipline.

How It Works

The skill instructs Claude to (a) run EXPLAIN (or EXPLAIN ANALYZE if a representative dataset is available) before proposing any change, (b) identify the dominant cost in the plan, and (c) make changes targeted at that cost. It works through PostgreSQL EXPLAIN and EXPLAIN ANALYZE output and the matching fixes (covering and partial indexes, query rewrites, materialized views); other engines get only a passing mention.

A good habit to add on top: ask for an updated EXPLAIN with every proposed change, so the improvement is shown rather than predicted.

When to Use It

Any database query slower than the team’s tolerance, particularly when the slowness is recent. Less useful when the schema itself is wrong (the skill optimizes within a schema; it doesn’t redesign one).

Sources

• github.com/wshobson/agents (plugins/developer-essentials/skills/sql-optimization-patterns)

Example

A report query has degraded from 80ms to 4 seconds over six months. With the skill loaded, the agent runs EXPLAIN ANALYZE, identifies a sequential scan over a join that used to use an index, finds that statistics are stale, runs ANALYZE on the relevant table, re-runs the query plan to confirm the index is now used, and reports back with the before/after plans.

Example artifacts

Invocation.

"This report query is slow. Use the sql-optimization-patterns skill:
run

EXPLAIN, identify the cost driver, propose a targeted change, and
show me

the updated plan."

Repository: github.com/wshobson/agents (plugins/payment-processing)

Intent

Integrate Stripe (or similar payment processors) with correct webhook validation and PCI-compliance discipline.

Motivating Problem

Payment integration is a category where common bare-model mistakes --- logging card numbers, missing webhook signature verification, naive retry without idempotency, storing tokens in the wrong place --- are not merely bugs but compliance violations. The skills enforce the patterns that keep an integration on the safe side of PCI scope.

How It Works

stripe-integration covers the Stripe-specific API: Customer/PaymentIntent creation, webhook signature verification via the Stripe library’s construct_event (not hand-rolled HMAC), error handling that surfaces user-friendly messages without leaking secrets. pci-compliance loads the broader PCI patterns: never log primary account numbers (PANs), never store them outside the processor’s scope, ensure cardholder data flows only through narrow controlled paths, use processor-tokenization for any persistence.

The two skills are designed to load together for payment-touching work. They impose a positive obligation: every webhook handler the agent writes includes signature verification, and every logging call near a payment path is checked for PAN exposure. Neither skill mentions idempotency keys; add that requirement yourself for payment mutations.

When to Use It

Implementing a payment flow --- either greenfield or adding a new payment method to an existing system. Reviewing existing payment code for compliance gaps. NOT for general invoicing or accounting code that doesn’t touch raw card data.

Sources

• github.com/wshobson/agents (plugins/payment-processing/skills)

• Stripe documentation (referenced from the SKILL.md)

• PCI DSS v4.0.1

Example

Adding ACH payments to an existing Stripe-Card integration. With both skills loaded, the implementation adds a new PaymentIntent flow with the correct payment_method_types, registers a webhook handler with Stripe signature verification using the official library, and (because the prompt asks for it) adds idempotency keys to every mutating call. A compliance review finds no PAN exposure in logs.

Example artifacts

Invocation.

"Add ACH support to our Stripe integration. Use the
stripe-integration

and pci-compliance skills --- verify all webhooks, key all mutations

idempotently, and don't put any PII in logs."

Repository: github.com/wshobson/agents (plugins/security-scanning)

Intent

Apply STRIDE threat modeling (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) to an architecture or design.

Motivating Problem

Security review is a category where bare Claude defaults to a generic checklist (“did you use HTTPS? did you validate inputs?”) that misses architecture-level threats. STRIDE is the standard threat modeling discipline at Microsoft and is broadly applicable, but applying it by hand is enough work that it tends to be skipped. The skill makes it cheap.

How It Works

The skill reads an architecture description (or one produced earlier, for example with posit-dev’s describe-design) and walks each component through STRIDE: for this component, what spoofing threats exist, what tampering threats, what repudiation threats, and so on. Each threat is logged with a severity, an exposure description, and a candidate mitigation. The output is a threat model document organized by component and category.

When to Use It

Pre-launch security review of a new system; periodic threat-model refresh; vendor onboarding where you need to assess third-party exposure. Useful in regulated industries (healthcare, finance) where threat modeling is expected as evidence of due diligence.

Sources

• github.com/wshobson/agents (plugins/security-scanning)

• Microsoft STRIDE methodology

Example

New SaaS product going to launch. Run stride-analysis-patterns on the architecture (API gateway → application → database → third-party payments). The output is a threat model document listing 47 specific threats across the six categories, ranked by severity, with proposed mitigations. The team works through them before launch.

Example artifacts

Invocation.

"Run a STRIDE threat model on our payment processing service. The
components

are: API gateway, payments-svc, transactions DB, and the Stripe
webhook handler.

Output the threat model document."

Repository: github.com/wshobson/agents (plugins/security-scanning)

Intent

Construct an attack tree for a target asset: the attacker’s goal as root, the strategies that achieve it as branches, the sub-steps as leaves, with cost/feasibility estimates per path.

Motivating Problem

STRIDE catalogs threats by component; attack trees catalog them by attacker objective. The two are complementary: one is bottom-up (“what can go wrong with this thing?”), the other top-down (“if I were trying to steal customer data, how would I do it?”). Doing attack trees by hand is even more tedious than STRIDE; the skill makes the model do the enumeration.

How It Works

The skill takes a target asset (“customer payment data”, “admin panel access”) and produces a tree: the goal at the root, the strategies (gain database access, intercept in transit, social-engineer an admin) as branches, and the concrete steps to achieve each strategy as leaves. Each leaf is annotated with cost, time, required skill and detection likelihood; intermediate nodes are OR (any child suffices) or AND (all children required). The result is a structured Markdown document with the tree as a Mermaid diagram and the leaf details below.

When to Use It

When defensive resources are limited and you need to prioritize --- attack trees surface which paths are cheapest for an attacker, which is where defenses pay off. Also useful in red-team planning and in regulatory contexts (some compliance frameworks require attack-tree-style analysis).

Sources

• github.com/wshobson/agents (plugins/security-scanning)

• Schneier, Attack Trees (1999)

Example

Build an attack tree for “unauthorized access to customer credit card data.” The skill enumerates 14 distinct attacker paths, from SQL injection through the public API to phishing a customer-support agent to exploiting the third-party payment processor. Each path has a cost estimate. The lowest-cost paths get the bulk of the defensive investment.

Example artifacts

Invocation.

"Build an attack tree for unauthorized access to our customer PII.
Annotate

each leaf with attacker cost and detection likelihood."

Repository: github.com/wshobson/agents (plugins/conductor), based on Google’s Conductor for Gemini CLI

Intent

Apply Context-Driven Development methodology: maintain product context, write specifications, and proceed in phased planning rather than ad-hoc code production.

Motivating Problem

Agents move fast. Without a methodology, that speed produces software that no human can maintain and that the agent itself can’t reason about across sessions. Context-Driven Development is one of several attempts --- alongside Spec-Kit, GSD, BMAD --- to give agentic coding a process that scales. wshobson’s implementation is opinionated and complete enough to use as a default.

How It Works

The skill keeps project context in a conductor/ directory: product.md (what the system is and who it serves), tech-stack.md, workflow.md and tracks.md. Each unit of work is a track with its own spec.md and phased plan.md. Spec drives plan, plan drives execution, execution updates the spec and the product context.

It is driven by the conductor plugin’s commands (/conductor:setup, /conductor:new-track, /conductor:implement) and pairs with HITL checkpoints between phases.

When to Use It

Long-running engineering work where multiple agent sessions need consistent context. Onboarding a new agent to an existing project. Codebases where the absence of methodology has already produced confusion.

Sources

• github.com/wshobson/agents (plugins/conductor)

Example

Starting a six-week migration project. The first session produces the product-context document; the second produces a per-phase plan; subsequent sessions consume both as context and proceed with focused changes. The output across the six weeks reads as if produced by one engineer following a single plan, even though it spans many sessions.

Example artifacts

Invocation.

"Apply context-driven-development to the database migration project.
Produce

the product context first, then the phased plan, then start phase
1."

Repository: github.com/numman-ali/openskills (npm: openskills)

Intent

Install, sync, and read SKILL.md folders across any AI coding agent that reads AGENTS.md, with progressive disclosure preserved.

Motivating Problem

Many teams use more than one agent: Claude Code for one developer, Cursor for another, Codex in CI. Each has its own plugin or skill system. Maintaining the same skill in three places --- with the same name, the same description, the same updates --- is friction the team is unlikely to sustain. openskills solves the friction by installing the same SKILL.md folder into whichever target the agent expects.

How It Works

The CLI has six commands: install (clone or copy a SKILL.md source into the target directory), read (load a skill’s body into the current session’s output), sync (regenerate the AGENTS.md skills table from the currently-installed skills), list (show what is currently installed and from where), update (refresh installed skills) and manage (interactive removal). Sources can be a GitHub org/repo (auto-clones), a local path, or a private git URL.

The CLI writes an <available_skills> XML block into AGENTS.md that AGENTS.md-reading agents pick up. Each entry has the skill’s name, description, and a location pointer; the body of the skill is loaded lazily when the agent runs openskills read <name>. This preserves the progressive-disclosure design of the original Anthropic skills system across agents that don’t implement progressive disclosure natively.

As of v1.5.0 (January 2026, the latest release; the repository has had no push since) installs default to project-local (.claude/skills/), with —global as opt-in for cross-project sharing. Symlink support enables a develop-locally pattern: clone a skill repo once, symlink the skills you want into the project, edit in place.

When to Use It

Whenever a team needs skills to work in more than one agent, or wants the install location to be the project rather than the user’s home directory (for version control of which skills are in use). Also for installing private or experimental skills before they’re ready for a public marketplace.

Sources

• github.com/numman-ali/openskills

• npmjs.com/package/openskills

Example

A team uses Cursor for development and Codex in CI. They install posit-dev/skills, anthropics/skills, and a private internal-skills repo via openskills into the project’s .agent/skills/. The AGENTS.md gets regenerated; both Cursor and Codex see the skills automatically. New team members get the same skills by cloning the repo.

Example artifacts

Invocation.

# Install Anthropic's skills, project-local, to .claude/skills/

npx openskills install anthropics/skills

# Install Posit's skills, universal target for non-Claude agents

npx openskills install posit-dev/skills --universal

# Install from a private repository

npx openskills install git@github.com:our-org/internal-skills.git

# Regenerate AGENTS.md skill table after manual changes

npx openskills sync

# Load a specific skill's body into the current session

npx openskills read pdf

Repository: github.com/vercel-labs/skills (npm: skills); directory at skills.sh

Intent

Install SKILL.md folders from any repository into whichever coding agents are present, with one command and a public directory for finding them.

Motivating Problem

The same problem openskills addresses: teams run several agents, each with its own skills directory, and keeping one skill in sync across all of them by hand does not last. A shared installer also needs a place to find skills; a GitHub search turns up thousands of folders with no signal about which ones people actually use.

How It Works

npx skills add <owner/repo> reads the repository, lets the user pick skills and target agents, and installs to the current project by default (add -g for a global install). The CLI detects installed agents; its README lists OpenCode, Claude Code, Codex, Cursor and 75 more. Other commands cover the rest of the lifecycle: find (search), list, check and update, remove, init (create a skill template), and use (run one skill without installing it, either printing the prompt or launching a supported agent with it). An experimental sync links skills that npm packages bundle alongside their code, so they update with the dependency.

skills.sh is the companion directory. Each repository page lists its skills with install counts (the mattpocock/skills page showed 55 skills and about 29 million total installs in October 2026) and the install command, and the site has a security-audits section. The CLI collects anonymous usage data; DISABLE_TELEMETRY=1 or DO_NOT_TRACK=1 turns it off.

When to Use It

Installing community skills into more than one agent, or into an agent other than Claude Code. Several repositories in this catalog (posit-dev/skills, mattpocock/skills) give npx skills add as their cross-agent install path. For Claude Code alone, a plugin marketplace (next entry) also handles updates and bundles commands and hooks with the skills.

Sources

• github.com/vercel-labs/skills

• skills.sh

Example

A team uses Claude Code and Cursor. One developer runs npx skills add posit-dev/skills, picks critical-code-reviewer and describe-design, and selects both agents; the skills land in the project, get committed, and every teammate has them on the next pull. A week later npx skills check reports an update and npx skills update applies it.

Example artifacts

Invocation.

# Pick skills and agents interactively, project-local

npx skills add posit-dev/skills

# One skill, one agent

npx skills add vercel-labs/agent-skills --skill web-design-guidelines
-a claude-code

# Search, then keep installed skills current

npx skills find review

npx skills check

npx skills update

Repository: code.claude.com/docs/en/plugin-marketplaces; Anthropic’s directory at github.com/anthropics/claude-plugins-official

Intent

Ship skills to Claude Code users as plugins listed in a marketplace.json catalog, so they install, update and uninstall as named units alongside the commands, agents, hooks and MCP servers that go with them.

Motivating Problem

Copying skill folders into ~/.claude/skills/ works once and then drifts: nobody knows which version is installed, updates are manual, and a skill that depends on a hook or a command arrives without it. Teams and authors need a way to publish a set of skills that users can add by name and keep current.

How It Works

A marketplace is a directory or git repository with a .claude-plugin/marketplace.json file that requires a name, an owner and a plugins array. Each plugin entry has a name (the install id, <entry-name>@<marketplace>) and a source: a relative path inside the marketplace, a GitHub repository, or a git-subdir path inside another repository, optionally pinned to a ref or sha. Users register a marketplace with /plugin marketplace add <owner/repo> and install with /plugin install <plugin>@<marketplace>; claude plugin validate checks the JSON and each entry before publishing.

Anthropic’s own directory, anthropics/claude-plugins-official, is a marketplace with Anthropic-maintained plugins under /plugins and reviewed third-party plugins under /external_plugins. Its README warns users to trust a plugin before installing it, since Anthropic does not control what a plugin contains. A repository that ships only SKILL.md files can still be listed: the marketplace entry sets strict: false and names the skill directories explicitly. Plugin names are permanent slugs; a renames map in marketplace.json migrates existing installs when a rename cannot be avoided.

Most collections in this catalog install this way: wshobson/agents (/plugin marketplace add wshobson/agents), posit-dev/skills, mattpocock/skills (from the official directory) and Rosetta (claude plugin marketplace add griddynamics/rosetta). Volume 18, Plugins, covers the plugin format itself; Volume 12 covers vetting third-party skills before install.

When to Use It

Publishing skills for Claude Code users, especially when skills depend on commands, hooks or MCP servers, or when a team wants a catalog it controls that members keep receiving updates from. For agents other than Claude Code, use a cross-agent installer (skills CLI or openskills) instead or as well.

Sources

• code.claude.com/docs/en/plugin-marketplaces

• github.com/anthropics/claude-plugins-official

Example

A platform team publishes acme/agent-plugins with a marketplace.json listing three plugins: a code-review plugin that bundles two skills and a slash command, a release plugin, and an entry that pulls skills from a monorepo with a git-subdir source pinned to a commit. Developers run /plugin marketplace add acme/agent-plugins once; new skills reach them when the team updates the catalog.

Example artifacts

Invocation.

# Install from Anthropic's official directory

/plugin install superpowers@claude-plugins-official

# Add a third-party marketplace, then install from it

/plugin marketplace add wshobson/agents

/plugin install <plugin-name>@<marketplace>

# Check a marketplace before sharing it

claude plugin validate ./my-marketplace

Repository: github.com/junghan0611/denotecli (CLI) and github.com/junghan0611/agent-config (skills/denotecli/SKILL.md)

Intent

Teach Claude the Denote file-naming convention and give it a CLI to search, read and traverse the link graph of a Denote vault, so it can navigate thousands of notes without reading them all.

Motivating Problem

Bare Claude given a vault of Denote-named files doesn’t know what the filenames encode. It reads filenames as opaque strings, misses the timestamp identity, can’t parse the tags, and breaks links because it can’t resolve denote:20251021T105353 references back to actual files. A 3,000-file vault also has a large graph of cross-references; without an index, each “what connects to this note?” question means re-reading many files.

How It Works

The skill encodes the Denote naming spec: timestamp YYYYMMDDTHHMMSS is the canonical identifier; — separates title; __ separates tags from title; tags are underscore-separated. The frontmatter mirrors this: #+title, #+date, #+filetags, #+identifier (the timestamp).

The denotecli binary (Go standard library only, JSON output) does the work. search finds notes by title, tag or ID; search-headings and search-content look inside files; read returns a note’s outline or a line range; graph returns a note’s outgoing and incoming links; day, timeline-journal and agenda cover date-based views. The skill tells Claude to use these commands for navigation and to load note bodies only when the question needs them.

When to Use It

Any vault that uses Denote naming, typically Emacs Org-mode users. Useful for discovery work in a large vault: finding notes on a topic, finding what links to a given note, or reviewing what was written on a given day.

Sources

• github.com/junghan0611/denotecli

• github.com/junghan0611/agent-config (skills/denotecli/SKILL.md)

• Protesilaos Stavrou, denote.el (the Emacs package that defined the convention)

Example

Asking Claude “find my notes about literate programming and show what links to the main one.” With the skill, Claude runs denotecli search with a tag filter, picks the main note’s ID from the JSON result, and runs denotecli graph on it, without opening any other file.

Example artifacts

Invocation.

"Find all my notes about literate programming and what links to
them."

# Skill runs denotecli:

denotecli search "literate" --tags emacs --max 20

denotecli graph 20251021T105353

Repository: github.com/mattpocock/skills (skills/engineering/tdd)

Intent

Enforce strict red-green TDD with vertical slicing only: one test, one slice of behavior, one piece of implementation at a time. No horizontal slicing.

Motivating Problem

The most common failure mode of agents doing TDD is horizontal slicing: write all the tests first, then write all the code. This produces tests that verify imagined behavior rather than real behavior --- the agent has already imagined the implementation, so its tests pass because they test what it imagined. Vertical slicing (one test, then one piece of implementation) prevents this. The tdd skill enforces it.

How It Works

The skill instructs the agent to: (1) agree the seams under test with the user before writing any test; (2) write exactly one test that describes the first behavior and verify it fails (red); (3) write the minimum implementation to make it pass (green); (4) repeat for the next behavior. Refactoring is not part of the loop; the skill moves it to the review stage (the code-review skill). Horizontal moves --- writing the next test before the current one passes --- are explicitly prohibited.

The skill is short (the SKILL.md is under 100 lines) but the discipline is load-bearing. With the skill loaded, the agent’s tests are visibly different: each test covers one behavior; each passes for a non-trivial reason; the implementation grows behavior-by-behavior rather than appearing fully-formed.

When to Use It

Any feature implementation where TDD is the right approach. Pocock’s explicit recommendation is to start with /tdd and only branch out as needed.

Sources

• github.com/mattpocock/skills

Example

Implementing a price-formatting function. Without the skill: agent writes 8 tests covering edge cases, then a 30-line function that passes them. With the skill: agent writes one test (“formats 100 cents as $1.00”), writes 3 lines to make it pass, then one test for negative amounts, adjusts the function by one line, then one test for currency rounding, adjusts again. The final function is the same size but every line of it was driven by a real test.

Example artifacts

Invocation.

# Install (Claude Code)

claude plugin install mattpocock-skills@claude-plugins-official

# Install (other agents)

npx skills@latest add mattpocock/skills

# Invoke

"Use the tdd skill to implement formatPriceCents. Start with a
single

vertical slice and grow behaviour by behaviour."

Repository: github.com/mattpocock/skills (skills/productivity/grilling; grill-me is an alias)

Intent

Force the agent to ask detailed clarifying questions before starting work, surfacing the misalignment between what the user said and what they meant.

Motivating Problem

The most expensive failure mode in software development is misalignment: the developer thinks they understand; they build something; the stakeholder sees it and realizes the developer didn’t understand at all. Pocock’s observation is that this failure mode is just as common with AI agents as with humans --- perhaps more so, because the agent is fast enough to deliver a wrong implementation before anyone has caught the misunderstanding. grill-me is the explicit fix: a structured interrogation phase before any code is written.

How It Works

The user invokes /grill-me; the skill sets disable-model-invocation, so the agent never starts it on its own. grill-me is now a one-line alias for the grilling skill. Instead of jumping to implementation, the agent maps the decisions as a design tree and asks, round by round, every question whose prerequisites are settled, each with a recommended answer: who is the user of this feature, what does success look like, what are the failure modes, what existing things are similar to it, what should it explicitly NOT do. Questions are concrete and follow from each other rather than being checklist-style.

The session continues until the user and the agent reach shared understanding of the scope. Implementation starts only after that.

When to Use It

Any non-trivial new feature or behavior change, especially when the user’s initial description is short or abstract. Skip for clear bug fixes (“this throws an exception, here’s the stack trace”) where the scope is unambiguous.

Sources

• github.com/mattpocock/skills

Example

User says “add a way for admins to see all users.” With grill-me: agent asks whether “see all users” means search, list with filters, or export; whether sensitive fields should be visible; whether the page should support bulk actions; what should happen with deleted users. The user clarifies; the implementation lands once on the right spec instead of three times on different misreadings.

Example artifacts

Invocation.

npx skills@latest add mattpocock/skills

"I want to add a feature to let admins see all users. Use grill-me
to make

sure we're aligned before you start writing code."

Repository: github.com/mattpocock/skills (skills/engineering/diagnosing-bugs), formerly diagnose

Intent

Run a structured debugging loop: first build a feedback loop that reproduces the bug deterministically, then minimise, form hypotheses, and fix behind that loop.

Motivating Problem

Agents debugging by patching tend to apply fixes that suppress symptoms rather than addressing causes. The diagnosing-bugs skill imposes the discipline of loop-first, hypothesis-driven debugging: don’t change code until a pass/fail check reproduces the bug, and don’t change it without first proposing what is wrong.

How It Works

Phase 1, which the skill calls the core of the method, is building a tight pass/fail feedback loop that goes red on this bug. Only then does the agent minimise the reproduction, articulate a hypothesis (“the bug is X because of Y”), design an experiment (“if I add logging here and run the failing case, I should see Z”), execute the experiment, observe the result, and either confirm the hypothesis or refine it. Only after the hypothesis is confirmed does the agent change code to fix the underlying cause, and the loop shows when the fix works. The skill also covers performance regressions and includes a step to redact secrets from logs and reproductions.

The structure also catches a failure mode where the agent gets distracted by adjacent issues: each hypothesis names a specific cause; tangential changes are deferred.

When to Use It

Any bug investigation that isn’t trivially obvious from the error message. Pairs naturally with /tdd: when a test reveals a bug, /diagnosing-bugs finds its cause; then the fix lands behind a new test.

Sources

• github.com/mattpocock/skills

Example

A flaky test fails one time in ten. Without /diagnosing-bugs: agent adds a retry and moves on. With it: agent first writes a loop that runs the test until it fails, then hypothesizes that the flake is due to a race condition between two async setup calls, designs an experiment to log timing, observes the race, and fixes by serializing the setup. The flake stops; the fix doesn’t mask future related issues.

Example artifacts

Invocation.

npx skills@latest add mattpocock/skills

"This test fails about 10% of the time. Use diagnosing-bugs: build a
loop that reproduces it, then hypothesis, experiment,

then fix the root cause."

Repository: github.com/mattpocock/skills (skills/engineering/improve-codebase-architecture)

Intent

Audit a codebase for architectural problems --- shallow modules, exposed complexity, drift from the ubiquitous language --- and recommend targeted refactors.

Motivating Problem

Agent-driven coding accelerates software entropy. Without explicit attention to architecture, a codebase rapidly accumulates shallow modules (lots of surface area, little capability), inconsistent vocabulary, and complexity exposed at boundaries that should hide it. Periodic architectural cleanup is part of the discipline; this skill makes it cheap.

How It Works

The skill loads Ousterhout-style architecture criteria: deep vs. shallow modules, interface design (information hiding), the cost of complexity at module boundaries. It is user-invoked only (disable-model-invocation). It scans recent hot spots from git log, presents “deepening opportunities” as a visual HTML report (Tailwind and Mermaid) with before/after diagrams, then grills the user through the candidate they pick. The audit itself changes no code.

Pocock’s recommendation: run it every few days during active development. The compounding value is significant: caught early, architectural decay is a small refactor; left for months, it becomes a rewrite.

When to Use It

Periodic codebase health check, particularly for projects with high agent-write volume. Before major new features, to clean up the foundation. After fixing a complex bug, to ensure the bug’s underlying cause was structural rather than incidental.

Sources

• github.com/mattpocock/skills

• Ousterhout, A Philosophy of Software Design (2018)

Example

After three months of feature work, run improve-codebase-architecture. It identifies six modules with exposed implementation details (private constants leaking into public types), three shallow-module candidates, and two places where the domain vocabulary has drifted (the same concept under three different names). Each is logged with a specific refactor proposal.

Example artifacts

Invocation.

npx skills@latest add mattpocock/skills

"Run improve-codebase-architecture over the src/ directory. Produce
a list of

shallow modules and vocabulary drift, with proposed refactors."

Repository: github.com/griddynamics/rosetta (ims-mcp-server)

Intent

Serve Rosetta’s instructions, skills, and workflows to any MCP-compatible agent on demand, with progressive disclosure and source-code isolation, for deployments that do not use the IDE plugins.

Sketch

Motivating Problem

Distributing SKILL.md folders by checking them into every project works for small organizations but breaks down at enterprise scale. Conventions drift across projects; updates require coordinating dozens or hundreds of pull requests; private standards leak into open repositories; new repositories get inconsistent starting conditions. Centralized delivery via MCP solves all four problems at once.

How It Works

Each developer’s IDE configures the Rosetta MCP server as a tool source (or, in the recommended setup, installs the Rosetta plugin, which carries the same instructions locally). When the agent starts work on a task, it consults Rosetta for the relevant guardrails and workflows. Rosetta returns just the instructions the agent asked for --- not the entire knowledge base.

The five-phase workflow is the contract: Prepare (the agent loads guardrails and project context), Research (the agent searches the Rosetta knowledge base for relevant instructions), Plan (the agent produces a reviewable plan that the user or another agent can approve), Act (the agent executes with the full loaded context), Validate (the agent checks completeness and reports remediation before closing).

Source code stays local. Rosetta never receives the project’s source; it only serves instructions back to the agent. This is the architectural property that makes Rosetta usable in environments where source-code exfiltration would be a problem.

Cross-project intelligence is opt-in. Organizations that want it can publish technical and business context from each project into a shared knowledge base; agents working in one project can see references to related work in others. Without opt-in, the per-project context stays local.

When to Use It

Enterprise deployment where AI coding standards must be consistent across many repositories and teams; environments where source code cannot leave the agent’s machine; organizations that need audit trails for what an agent was instructed to do; teams that want a single onboarding path for new repositories that bakes in best practices.

Sources

• github.com/griddynamics/rosetta

• github.com/griddynamics/rosetta/blob/main/INSTALLATION.md

• pypi.org/project/rosetta-mcp/ (the MCP server package; ims-mcp remains as a legacy alias)

Example

A 200-person engineering organization across 40 repositories deploys Rosetta. Each developer’s Cursor, Claude Code, or Codex points at the same Rosetta MCP endpoint. When any developer asks their agent to scaffold a new microservice, the agent consults Rosetta for the org’s microservice template, the security guardrails, the observability conventions, and the deployment pattern. The same agent on a different developer’s machine in a different repository gets exactly the same conventions.

Example artifacts

Invocation.

# Cursor: ~/.cursor/mcp.json or .cursor/mcp.json

{

"mcpServers": {

"Rosetta": {

"url": "<rosetta MCP production server URL>"

}

}

}

# Claude Code

claude mcp add --transport http Rosetta <rosetta MCP production
URL>

# Codex

codex mcp add Rosetta --url <rosetta MCP production URL>

codex mcp login Rosetta

# Then in any agent session:

"Initialize this repository using Rosetta."

Repository: github.com/griddynamics/rosetta (workflow defined in USAGE_GUIDE.md)

Intent

Impose a consistent five-phase structure on agent work: load context, search for guidance, produce a reviewable plan, execute, validate.

Motivating Problem

Agents left to their own structure produce inconsistent process. Sometimes they jump straight to code; sometimes they over-research and produce no code; sometimes they plan in private and the user has no opportunity to intervene. The five-phase workflow is the contract that prevents each of these failure modes.

How It Works

Prepare loads guardrails and project context: the relevant conventions, the security and approval policies, the project’s prior decisions. The agent reads these before any user request is processed.

Research uses the Rosetta MCP to search the knowledge base for instructions specifically relevant to the current task. This is progressive disclosure: only the instructions actually needed are loaded.

Plan produces a written plan with the steps the agent intends to take, the files it expects to modify, and the risks it has identified. The plan is reviewable; depending on the risk policy, it may require human approval before Act begins.

Act executes the plan with the full loaded context, with the guardrails enforcing any approval gates or audit hooks defined in the Prepare phase.

Validate checks the result against the plan for completeness and reports what still needs remediation before the work is closed.

The phases are not advisory: they are enforced by the Rosetta instructions the agent loads. An agent attempting to write code in the Research phase will be redirected to produce a plan first.

When to Use It

On any non-trivial change in a Rosetta-managed project. Trivial changes (typo fixes, formatting) may skip the Plan phase if the project policy allows. Higher-risk changes (production deployments, database migrations, security-sensitive code) typically require human approval at the Plan phase before Act.

Sources

• github.com/griddynamics/rosetta/blob/main/USAGE_GUIDE.md

Example

Developer says “add OAuth2 to the user service.” Prepare loads the org’s auth conventions and the security guardrails. Research consults Rosetta for the org’s OAuth implementation pattern; Rosetta returns the relevant guidance. Plan produces a 12-step plan with the specific files that will change, the libraries that will be added, and the migrations that will be required. The plan goes for human approval (the security guardrail requires it). After approval, Act executes the plan; each step is logged for audit. Validate then confirms every planned step landed.

Example artifacts

Invocation.

# The workflow is invoked implicitly by any Rosetta-mediated agent
session.

# To make it explicit:

"Use the five-phase workflow on this task. Show me the plan before
acting."

# Or to follow each phase explicitly:

"Prepare: load the relevant guardrails for the user-service repo."

"Research: find the org pattern for OAuth2 integration."

"Plan: produce the change plan and stop for review."

# (user approves)

"Act: execute the plan."

Repository: github.com/obra/superpowers

Intent

Give a coding agent a complete, enforced development method (brainstorm the design, plan in small tasks, execute with test-driven development and review, then finish the branch) as a set of skills that trigger on their own.

Motivating Problem

Single-purpose methodology skills help only when the agent or the user remembers to invoke them, and they do not connect: a good plan does not guarantee the tests come first, and good tests do not guarantee a review before merge. Agents left to themselves start writing code before the goal is clear and declare work done before verifying it. Superpowers chains the steps so each one hands off to the next.

How It Works

The basic workflow is a sequence of skills, each activating at its stage. brainstorming draws out what the user wants and plays it back; small changes are agreed in chat, larger ones get a written design document. using-git-worktrees creates an isolated branch and checks for a clean test baseline. writing-plans breaks the approved design into tasks of two to five minutes, each with exact file paths, complete code and verification steps. subagent-driven-development then dispatches a fresh subagent per task with a two-stage review after each (spec compliance, then code quality); executing-plans is the cheaper inline alternative with one review at the end. test-driven-development enforces red-green-refactor during implementation and deletes code written before its test. requesting-code-review runs between tasks, and critical issues block progress. finishing-a-development-branch verifies tests and offers merge, PR, keep or discard.

Supporting skills cover systematic-debugging (a four-phase root-cause process), verification-before-completion, dispatching-parallel-agents, receiving-code-review, writing-skills (creating new skills, with a testing method) and diagnosing-superpowers, which reads a session transcript to work out why a skill fired or did not.

When to Use It

Feature work long enough to benefit from a design, a plan and review gates, especially when the agent is expected to run for an hour or more without supervision. It is heavy for one-line fixes; the brainstorming skill itself keeps small changes to a short exchange in chat. Teams that want only one or two disciplines (TDD, structured debugging) may prefer the individual mattpocock/skills primitives in Section F.

Sources

• github.com/obra/superpowers

• Jesse Vincent, Superpowers release announcement (blog.fsck.com, 9 October 2025)

Example

A developer asks for CSV export on a reports page. brainstorming asks which columns, which filters apply and how large exports get, then writes a short design. writing-plans turns it into nine tasks. subagent-driven-development runs each task in a fresh subagent: a failing test first, the minimum code, then a spec review and a code-quality review. finishing-a-development-branch runs the full suite and opens a PR.

Example artifacts

Invocation.

# Claude Code: install from Anthropic's official directory

/plugin install superpowers@claude-plugins-official

# Then just describe the work; brainstorming activates first

"Add CSV export to the reports page."

# Ask why a session went wrong

"Figure out what went wrong with superpowers in this session."

Appendix A --- Integration Recipes

A few common ways to compose the repositories in this catalog:

Appendix B --- The Catalog’s Omissions

This catalog covers eight skill repositories and the main distribution channels. The skills ecosystem contains many thousands more. A non-exhaustive list of categories not covered:

• Scientific and biomedical skills (claude-scientific-skills, materials-simulation-skills, bioinformatics collections).

• WordPress, Rails, and other framework-specific repositories that bundle agent-friendly conventions for a single stack.

• Marketing and content-strategy skills (wondelai/skills, devmarketing-skills, the Composio marketing collections).

• Skill-discovery tooling beyond the skills CLI’s find command and the skills.sh directory (Section D).

• OpenClaw and similar agent-bundle distributions that package skills with broader runtime configurations.

The selection criteria for this catalog was reference-quality and architectural distinctiveness, not popularity. A v0.2 may broaden coverage; this draft holds to the anchor repositories that define the ecosystem’s shape.

Appendix C --- A Note on the Moving Target

Anthropic published the Skills feature in October 2025. The Agent Skills standard was opened in December 2025. As of October 2026 the ecosystem is a year old. Star counts, plugin counts, and skill counts in this catalog reflect snapshots taken in October 2026 (the first draft used May 2026 figures); they will be wrong by the time this is read. In those five months several skills were renamed or moved (diagnose became diagnosing-bugs, testing-r-packages became r-testthat, org-mode-skills became denotecli), install paths shifted from copied folders to plugin marketplaces and the skills CLI, and Rosetta moved from MCP-first to plugin-first. The architectural patterns are more stable than the names and paths. Treat this catalog as a map of an ecosystem still under rapid construction --- the shape of the landscape will hold even as individual landmarks shift.

Appendix D --- Further Reading

• anthropics/claude-cookbooks - Anthropic’s Jupyter notebooks for the Claude API (about 54k stars, October 2026): patterns/agents/basic_workflows.ipynb for the agent workflow patterns, skills/notebooks/ for using and creating skills, tool_use/memory_cookbook.ipynb, and newer claude_agent_sdk/ and managed_agents/ folders. Not a skill repository. github.com/anthropics/claude-cookbooks

• numman-ali/n-skills - a small curated marketplace of a handful of skills (orchestration, open-source-maintainer, dev-browser and others), inclusion by request and review, installable with openskills or /plugin marketplace add. github.com/numman-ali/n-skills

--- End of The Claude Skills Catalog v0.1 ---