Claude Skills
The open format is called Agent Skills and works in Claude Code, Codex, Cursor and other agents — most people know it as Claude Skills.
Every Agent Skill we could find on GitHub, deduplicated by content. 79 404 files from 1 741 authors, of which 61 763 are unique — the rest is the same skill repackaged into someone else's repository. For each one: what it weighs in tokens, whether it ships runnable scripts, and which MCP servers it needs.
> Generate a Markdown triage report for open, non-draft pull requests in microsoft/ebpf-for-windows, including CI, freshness, sign-offs, and next-owner routing.
> Perform a deep adversarial review of C/C++ changes between an active branch and a baseline branch in ebpf-for-windows. Produce both a detailed review report and a point-by-point fix list.
> Build and test the PREVAIL verifier (external/ebpf-verifier) standalone. Use this skill when asked to build, test, or iterate on the PREVAIL verifier, run YAML verification tests, or work with the verifier's cmake build system.
> Build and verify eBPF programs for the ebpf-for-windows project. Use this skill when asked to compile a .c BPF source to .o, verify a .o ELF file with bpf2c, or diagnose verification failures. Covers the full clang→bpf2c pipeline.
> Diagnose eBPF program verification failures from the PREVAIL verifier. Use this skill for linux-compatible eBPF programs verified in the standalone PREVAIL repo (external/ebpf-verifier). For programs using Windows-specific features (bpf2c pipeline, Windows helpers, ebpf-for-windows headers), use the 'verify-bpf' skill instead.
Generate weekly telemetry reports and customer adoption reports for Azure Backup MCP tools. Runs KQL queries against the Kusto telemetry cluster, analyzes error patterns with 3-way classification (Customer/Azure Service/MCP Tool Bug), identifies customers via P360/C360 cross-cluster joins, compares week-over-week metrics, correlates with merged PRs and releases, and produces an Outlook-compatible HTML report. USE WHEN: weekly telemetry report, Azure Backup MCP telemetry, error analysis, telemetry bugs, weekly report, MCP tool success rate, backup telemetry, error classification, customer usage report, who is using Azure Backup MCP, backup adoption, customer report.
Add a new tool/command to any Azure MCP toolset. Full lifecycle from scaffolding through PR submission. USE WHEN: add new command, create tool, new MCP tool, scaffold command, implement operation, add azure service tool, create new toolset.
Add a new tool/command to the Azure Backup MCP toolset. Covers the full lifecycle: command implementation, option definitions, service layer, input validation, unit tests, live tests, recorded test playback, CI validation, spell check, changelog entry, tool description evaluation, and PR checklist. USE WHEN: add new backup command, create backup tool, implement backup operation, new azurebackup command, add MCP tool for backup, new vault operation, new policy command, new governance command.
Run the mandatory verification stack when changes affect runtime code, tests, or build/test behavior in the OpenAI Agents JS monorepo.
Perform a release-readiness review by locating the previous release tag from remote tags and auditing the diff (for example, v1.2.3...TARGET) for breaking changes, regressions, improvement opportunities, and risks before releasing openai-agents-js.
Run examples:start-all in auto mode with parallel execution, per-script logs, and start/stop helpers.
Run the integration-tests pipeline that depends on a local npm registry (Verdaccio). Use when asked to execute integration tests or local publish workflows in this repo.
Perform a risk-tiered zero-base final review for implementations before completion. Use only when the user explicitly invokes $implementation-final-review or repository instructions authorize automatic invocation after implementation. Audit the complete merge-base diff for requirement fit, contract-surface coverage, await-boundary and lifecycle gaps, released compatibility, package and runtime boundaries, security and persistence, unnecessary complexity, generated types, and adversarial coverage; use self-contained reviewer briefs and concurrent independent reviewers for elevated-risk changes, overlap non-mutating final repository verification with reviewer waits on the same frozen fingerprint, require evidence-bearing clean results, preserve clean evidence for unchanged review components, fix actionable findings, reset expanding designs, and escalate non-convergence after at most six review rounds.
Choose compatibility-aware scope for runtime and API changes in openai-agents-js. Use before initial implementation and each review-feedback batch to decide whether to patch, reset the design, preserve compatibility, or reject unsupported cases.
Review a GitHub issue or pull request URL as an openai-agents-js maintainer, with a staged assessment of whether the claim is real, practically important, already solvable with supported functionality, correctly scoped, better served by another design, and worth maintainer and contributor effort. Use when assessing issue validity or severity, deciding whether an issue should be prioritized or closed, determining whether a requested feature represents an unmet need rather than a discoverability or usage gap, judging whether a PR is worth bringing to mergeable quality, comparing open PRs or alternative designs, separating code quality from repository readiness, or drafting a concise maintainer assessment. When closure, additional evidence, or code changes should be requested, also produce a polite, concise, complete, copy-paste-ready maintainer comment.
Analyze main branch implementation and configuration to find missing, incorrect, or outdated documentation in docs/. Use when asked to audit doc coverage, sync docs with code, or propose doc updates/structure changes. Only update English docs (docs/src/content/docs/**) and never touch translated docs under docs/src/content/docs/ja, ko, or zh. Provide a report and ask for approval before editing docs.
Use when working with the OpenAI API (Responses API) or OpenAI platform features (tools, streaming, Realtime API, auth, models, rate limits, MCP) and you need authoritative, up-to-date documentation (schemas, examples, limits, edge cases). Prefer the OpenAI Developer Documentation MCP server tools when available; otherwise guide the user to enable `openaiDeveloperDocs`.
Create the required PR-ready summary block, branch suggestion, title, and draft description for openai-agents-js. Must be used before the final response whenever the actual task diff includes runtime code, tests, examples, build/test configuration, or docs with behavior impact, regardless of perceived change size. Skip only when no eligible files changed, every change is repo-meta or docs-only without behavior impact, the task is conversation-only, or the user explicitly opts out.
Plan and execute runtime-behavior investigations with temporary TypeScript probe scripts, validation matrices, state controls, and findings-first reports. Use only when the user explicitly invokes this skill to verify actual runtime behavior beyond normal code-level checks, especially to uncover edge cases, undocumented behavior, or common failure modes in local or live integrations. A baseline smoke check is fine as an entry point, but do not stop at happy-path confirmation.
Audit and fix model or tool input/output exposure through runtime logging in openai-agents-js. Use when reviewing logger or console calls, checking OPENAI_AGENTS_DONT_LOG_MODEL_DATA or OPENAI_AGENTS_DONT_LOG_TOOL_DATA coverage, investigating exceptions or payloads that may reveal model inputs and outputs, tool arguments and results, Realtime events, MCP data, session history, or arbitrary thrown values, while distinguishing those payloads from operational names, identifiers, counts, and statuses.
Improve test coverage in the OpenAI Agents JS monorepo: run `pnpm test:coverage`, inspect coverage artifacts, identify low-coverage files and branches, propose high-impact tests, and confirm with the user before writing tests.
Validate changesets in openai-agents-js using LLM judgment against git diffs (including uncommitted local changes). Use when packages/ or .changeset/ are modified, or when verifying PR changeset compliance and bump level.
Keep pnpm current: preflight the published package and pnpm/action-setup self-installer, update pnpm locally, align packageManager in package.json, and refresh CI pins. Use this when refreshing the pnpm toolchain manually or in automation.
Use when adding or migrating non-thumbnail images for a Hugging Face Blog post. Uploads body images to the Hugging Face documentation-images dataset, updates the Markdown, and verifies the new links.
'Force-push a branch and all its downstream branches to origin. Auto-detects push downstream, push chain, push all branches.'
'Audit and fix best practices docs for stale references, duplicates, obsolete docs, audit bp docs.'
'Implement review feedback on a PR. Checks out the branch, applies impl-review, implement review, implement review feedback, address review comments.'
'Add a new best practice to the appropriate doc. Checks for duplicates, practice, new best practice, add bp, new bp.'
"Check if a failing test is a known upstream flake in Chromium's LUCI Analysis database. Provides flakiness statistics, verdict, and recommendation for upstream, check luci flakiness, upstream flake check."
'Re-run failed CI jobs for a brave/brave-core PR. Detects failure stage and retry ci, rerun ci, fix ci, re-run failed jobs, retrigger ci.'
For an external contributor's open PRs to brave/brave-core, ensure the `sync-and-rebase-pr-from-fork.yml` workflow has been dispatched for each PR's latest commit SHA — so a `contributor-*` draft PR exists inside brave/brave-core and CI can run. Invoke when the user says something like "create contributor PRs for <user>", "sync contributor PRs <list>", "run the rebase-from-fork workflow for these PRs", or passes a GitHub username / list of PR URLs/numbers.
'Delete local branches whose PRs have been merged upstream. Checks GitHub PR prune branches, branch cleanup.'
Create a pull request for the current branch using `gh`.
'Run all preflight checks (format, gn_check, presubmit, build, tests) to make sure the current work is ready for review.'
"Create a Plaster (`rewrite/*.yaml`) config for an existing Brave-core Chromium `.patch`, authoring an intent-conveying regex match per the Plaster Dos and Don'ts, then verifying it by running `plaster.py apply` and diffing the regenerated patch against the original. Does not modify sources or create plasterize, make a plaster."
'Review PRs in the configured PR repository for best practices violations. Supports single PR (#12345), state filter (open/closed/all), and auto mode for best practices.'
'Get PRs a user reviewed on brave/brave-core. Shows PR number, title, author, what did I review, review history.'
"Get top crashers from Brave's Backtrace crash reporting. Shows crash signatures, stacks, platforms, versions, channel breakdown, code origin, and crashing, top crashes, crash analysis, regression crashers, new crashes."
'Review code for quality, root cause analysis, and fix confidence. Supports PR review and local review of uncommitted/branch changes. Default mode is local /review <pr_url>, /review local, /review, check bot pr quality.'
'Rebase a tree of dependent branches (including siblings) after upstream changes. Auto-detects downstream branches and rebases each in order. Triggers
Create an uplift PR that cherry-picks merged PRs from a contributor into a target branch (beta or release). Defaults to broad eligibility; the scope can be narrowed via a free-form description (e.g. 'only automated test and crash fixes'). Triggers on: /uplift, create uplift, uplift PRs.
>- Activate for changes to project positioning, release communication, community-facing artifacts, or breaking-change decisions in microsoft/apm. Triggers on README, MANIFESTO, PRD, CHANGELOG, release workflows, and issue templates.
>- Use this skill to triage a single newly opened, reopened, or `status/needs-triage`-labelled issue in microsoft/apm. Emit one synthesized comment with a triage decision, label set, milestone, and suggested next action.
> Use this skill when editing or creating CLI output, logging, warnings, error messages, progress indicators, or diagnostic summaries in the APM codebase. Activate whenever code touches console helpers (_rich_success, _rich_warning, _rich_error, _rich_info, _rich_echo), DiagnosticCollector, STATUS_SYMBOLS, CommandLogger, or any user-facing terminal output — even if the user doesn't mention "logging" or "UX" explicitly.
>- Use this skill to drive any open microsoft/apm issue (bug, feature, docs, refactor, perf) from raw intake to a mergeable PR with triage as the central, paramount gate. Run the apm-triage-panel rubric per issue first, then present ONE consolidated triage review for the whole batch and escalate to the maintainer BY DEFAULT on any doubt (needs-design, decline, duplicate, defer, auto-handle, breaking- change, auth/security/governance surface, low arbiter confidence, unbounded scope, or a missing brief); only auto-implement clear, bounded, high-confidence accepts the maintainer approved. Then drive each accepted PR to mergeability batch-bug- follow-ups by default, watch CI green, iterate under a bounded cap. Invoke MANUALLY, in-session, on an issue list or queue -- never by label or event. Activate when the maintainer asks to auto-tackle the issue queue, clear the backlog to PRs, or run issues to merge -- even if "autopilot" is not named.
> Activate when code touches token management, credential resolution, git auth flows, GITHUB_APM_PAT, ADO_APM_PAT, AuthResolver, HostInfo, AuthContext, or any remote host authentication -- even if 'auth' isn't mentioned explicitly.
>- Use this skill to drive a batch of suspected bugs in microsoft/apm from raw issue list to mergeable PR queue. Fan out one triage subagent per issue (LEGIT / UNCLEAR / FIXED-AT-HEAD), gate every legit bug against PRINCIPLES.md via an apm-ceo strategic-alignment pass, cross-reference legit issues against open PRs, then open a fix PR (TDD + mutation-break gate) for greenfield bugs. Drive every PR -- community in-flight and own fix alike -- to mergeable by review panel, folds non-blocking recommendations, pushes (preserving author), and watches CI to green. Re-probe mergeability and resolve conflicts via shepherd-driver. Maintain a plan.md ground-truth table as canonical state. Activate when the maintainer asks to triage issues, sweep the bug queue, shepherd bug-flagged issues, run a weekly community sweep, or drive in-flight community PRs to merge -- even if "shepherd" or "batch" is not named.
>- Use this skill to run a four-panel adversarial advisory review on any pull request that touches the OpenAPM specification artifact (docs/src/content/docs/specs/openapm-*.md), its inline / sidecar JSON Schemas (docs/src/content/docs/specs/schemas/*.schema.json), or the conformance fixture seed (tests/fixtures/spec-conformance/**). The panel fans out to four spec-ecosystem reviewers (swagger-openapi-editor, oci-distribution-editor, pkgmgr-registry-contract-editor, w3c-tag-architect), each running in its own agent thread, and a spec-editor synthesizer that produces a fold-now / defer-v0.1.1 / defer-v0.2 / reject list plus a ship decision keyed off a 1..10 shocked_meter scale. The orchestrator is labels, no merge gating. The panel is advisory -- it surfaces findings, prioritizes folds, and renders a ship recommendation that the maintainer weighs.
>- Use this skill to run a multi-persona expert advisory review on a labelled pull request in microsoft/apm. The panel fans out to five mandatory specialists plus a test-coverage specialist (active on every PR that touches src/) plus three conditional specialists (auth, doc-writer, performance-expert), all running in their own agent threads, and a CEO recommendation comment, no verdict labels, no merge gating. The panel is advisory -- it surfaces findings, prioritizes follow-ups, and renders a ship-recommendation that the maintainer and author weigh. Activate when a non-trivial PR needs a cross-cutting recommendation (architecture, CLI logging, DevX UX, supply-chain security, growth/positioning, optionally auth, docs, perf, and test coverage, with CEO arbitration).
Use this skill to verify CLAIM-LEVEL grounding of a documentation page (or set of pages) against the source code. Activate when you have specific pages to check for factual accuracy -- not when sweeping a whole corpus (use docs-corpus-audit for that) and not when triaging a PR diff (use docs-sync for that). Trigger nouns: "is this doc accurate", "verify the page against the code", "fact-check this section", "any claims that drifted from source", "fact-checking", "grounding audit", "drift hunt", "claim verification". Returns per-claim verdicts (GROUNDED | PARTIAL | CONTRADICTED | UNSUPPORTED) with file:line evidence citations. Catches paragraph-level inaccuracies that page-level audit averages over -- e.g. a paragraph with 5 claims where 4 are grounded and 1 is fabricated. Does NOT modify files (returns advisory only); does NOT re-architect the docs; does NOT triage PRs.
>- assess whether the cycle since the last tag warrants a patch or minor bump (semver discipline against the merged-since-last-tag diff), sanitize the [Unreleased] CHANGELOG block into a dated version block with one concise "so what" entry per merged PR (drop internal-only churn, consolidate duplicates), bump pyproject.toml + uv.lock, run the CI-mirror lint chain, and open the release PR. Activate on "ship a release", "cut v0.x", "release prep", "bump and PR", "open release PR", "what kind of release do we need", or any phrasing that ends in opening a release PR -- even when the user does not say "skill". Stops BEFORE tagging; tagging stays a human gate that triggers the release workflow. Refuses to bump to a major (>= 1.0.0) version without explicit operator confirmation.
>- Use this skill to run a holistic regrounding pass on the entire microsoft/apm documentation corpus against current source code, page-by-page, and emit surgical fixes for stale claims. Activate when the maintainer wants a WHOLE-CORPUS audit (not per-PR review) -- typical triggers include "audit the docs", "reground the corpus", "check every page against code", "pre-release docs sweep", "the docs have drifted everywhere", or "we just reshaped the TOC, find dead links". Wave-batched and S7-verified; scales to the full ~112-page corpus in ~10 minutes wall-time. This is a (triggered by a diff); this skill is per-corpus (triggered by a maintainer ask). They share agent personas, schemas, and the docs index, but their triggers MUST NOT collide. Does NOT auto-merge, does NOT push without maintainer review, and does NOT replace per-PR drift detection.
>- Use this skill to classify the documentation impact of a pull request diff, returning one of three verdicts -- no-change, in-place edit, or structural change -- with bounded LLM cost. Activate as a sibling skill of docs-sync; the orchestrator calls this first, before any panel spawn, to keep cost floor at 1 LLM call when no docs work is needed. Reads .apm/docs-index.yml as the corpus map; never reads the full corpus.
>- Activate when designing or modifying CLI command surfaces, command help text, install/init/run flows, error wording, or first-run experience in the APM CLI -- even when the user does not say "UX" explicitly.
>- Use this skill to translate a classifier's in-place verdict into a precise, page-by-page work plan for the docs-sync panel. Activate after docs-impact-classifier returns verdict in_place; reads the candidate page list, fetches the actual page contents, narrows scope to specific sections within each page, and emits the per-page task brief the panel fans out against.
>- Use this skill when the docs-impact-classifier returns a structural verdict, signalling that the documentation TOC must change to accommodate the PR. Proposes TOC deltas (new pages, moves, merges) and emits new-page outline stubs that the doc-sync panel later fleshes out. Holds the 3-promise narrative (consume / produce / govern) and the persona ramps as hard constraints.
>- Use this skill whenever a pull request is opened, reopened, or synchronized in microsoft/apm to assess whether and how the documentation corpus must change to stay truthful with the proposed code change. Activate even when the PR title or body says nothing about docs -- the skill must run on every PR to detect silent drift between code and docs. Classifies impact as no-change, in-place edit (one to a few paragraphs), or structural change (new page or TOC reshape), then orchestrates a CDO + doc-writer + python-architect + editorial-owner + growth-hacker loop to produce a patch-ready advisory. Does NOT review code quality, security, or test coverage. Does NOT auto-merge or auto-push doc edits.
>- Use only as the composed drive-to-merge stage of an APM batch orchestrator (batch-bug-shepherd, apm-issue-autopilot) that has already selected ONE open pull request in microsoft/apm. Do NOT use for user-facing requests to triage issues, sweep a queue, or open PRs -- the parent orchestrator owns those. Spawn one shepherd-driver inline review, runs the apm-review-panel, folds (by default) every recommendation inside the PR's stated scope, pushes to the head branch or a superseding PR that preserves authorship via commit trailers, watches CI to green, and iterates under fixed caps until ready-to-merge, advisory-with-deferred, superseded, or blocked. Also provides the cross-PR conflict-resolution and mergeability-gate phase. This is NOT a standalone entrypoint.
>- Use this skill to write the PR description (PR body) for any pull request opened against microsoft/apm. Produces one self-sufficient (WHAT), Implementation (HOW), 1-3 validated mermaid diagrams, explicit trade-offs, validation evidence, and a How-to-test section -- with every WHY-claim backed by a verbatim quote from PROSE or Agent Skills. Activate when the user asks to "write a PR description", "draft a PR body", "open a PR", "fill in the PR template", or any equivalent.
>- Activate for changes to project positioning, release communication, community-facing artifacts, or breaking-change decisions in microsoft/apm. Triggers on README, MANIFESTO, PRD, CHANGELOG, release workflows, and issue templates.
Claude Skills — questions
Answers built from the skills we actually parsed.