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 Privacy Impact Assessment in house format for a new feature, product, or processing activity, using the structure learned from your seed PIA. Use when the user says "write a PIA", "privacy impact assessment for", "do we need a PIA for this", "privacy review this feature", or describes a new data processing activity.
> Guided customization of your privacy practice profile — change one thing without re-running the whole cold-start interview. Adjust risk posture, escalation contacts, DPA playbook, privacy policy commitments, PIA house style, DSAR process, or matter workspace paths. Use when the user says "change my [thing]", "update my profile", "edit my playbook", or "customize".
> Review a Data Processing Agreement against your DPA playbook — auto-detects whether you're processor or controller and applies the right half of the playbook. Use when the user says "review this DPA", "check this data processing addendum", "customer sent their DPA", "is this DPA okay", or attaches a DPA.
> Walk through a Data Subject Access Request (or deletion, portability, correction request) and draft the response — verify identity, locate data system-by-system, assess exemptions, draft the acknowledgment and substantive response letters. Use when a DSAR comes in, the user pastes an access/deletion/portability/correction request, or says "DSAR came in", "access request", "right to be forgotten", or "someone wants their data".
> PIAs, DPA reviews, and triage results to find policy drift; or direct query for a proposed new practice. Use when the user asks "does our policy cover this", "we want to start doing X — does the policy need updating", "run the policy monitor", "policy sweep", or wants to find where the privacy policy no longer matches what the team actually does.
> Manage matter workspaces — create, list, switch, close, or detach (practice-level). Keeps one client or engagement's context separate from every other for multi-client practitioners. Use when the user wants to open a new matter, switch matters, list matters, close/archive a matter, or work at practice-level only.
> Diff a new or changed regulation against current privacy policy and practice — outputs a gap list and a remediation plan with owners and dates. Use when a new reg drops, the user asks "does [regulation] affect us", "gap analysis for [state privacy law]", "compliance check against [reg]", or pastes regulatory text.
> Quickly determine whether a processing activity needs a PIA, a mandatory GDPR DPIA, or can proceed — surfaces privacy policy conflicts and routes to the right next step. Use when the user asks "does this need a PIA", "triage this feature", "privacy check on X", "is this okay from a privacy perspective", or describes a new data processing activity, product feature, or vendor relationship.
> Fast "is this a problem?" answer for the quick Slack question — pattern-matches against your calibration. Use when the user says "is this a problem", "quick question", "can we do X", "do I need legal review for", "sanity check", or pastes a PM's question that needs a same-minute fine / needs a look / hold call.
> Cold-start interview — connects to your launch tracker, reads past reviews, learns your risk calibration. Use on fresh install, when onboarding product counsel, or when the plugin config has placeholders. Run with --redo to re-interview, or --check-integrations to re-probe connectors only.
> Deeper risk assessment for a single feature or product area when the launch what could go wrong, how likely, how bad, what mitigates it. Use when user says "deep dive on this risk", "risk assessment for [feature]", "what could go wrong with", or when launch-review flags a novel issue.
> Guided customization of your product counsel practice profile — change one thing without re-running the whole cold-start interview. Adjust risk calibration, escalation contacts, launch review framework, marketing claims posture, or matter workspace paths. Use when the user says "change my [thing]", "update my profile", "edit my framework", "retune my calibration", or "customize".
> Review marketing copy for claims that need substantiation, reframing, or cutting. Use when the user says "review this marketing copy", "check these claims", "can we say this", "is this puffery or a problem", or pastes marketing content (landing pages, emails, ads, taglines).
> Full launch review against your framework and risk calibration. Use when the user says "review this launch", "legal review for [feature]", "can we ship this", "what are the legal issues with [product]", or references a launch tracker ticket or PRD that needs a category-by-category review memo.
> Manage matter workspaces — new, list, switch, close, or detach (practice-level). Use when working across multiple clients or matters in private practice and you need to create, list, switch, close, or detach the active matter so context from one engagement doesn't leak into another.
Review open NPRM comment periods, log decisions, track deadlines. Use when an NPRM has a comment window open and you need to surface deadlines, decide whether to file, or record a filing / not-filing / waived decision (--decide CMT-ID).
> ingests gaps from policy-diff, surfaces what's open and aging, routes to owners, and notifies gap owners via Slack with per-send confirmation. Loaded by the gaps and comments skills before doing substantive work.
> Guided customization of your regulatory practice profile — change one thing without re-running the whole cold-start interview. Adjust watched regulators, policy library index, materiality threshold, gap response process, feed configuration, or matter workspace paths. Use when the user says "change my [thing]", "add a regulator", "update my watchlist", "edit my threshold", or "customize".
Cold-start interview — builds your watchlist, indexes the policy library, and learns your materiality threshold so the monitor surfaces signal instead of noise. Use on fresh install, when reconfiguring (--redo), or when re-checking what connectors are actually responding (--check-integrations).
Open gaps tracker — what's flagged and not yet closed. Use when the user asks "what gaps are open", "gap tracker", "remediation status", or wants to close (--close GAP-ID) or risk-accept (--accept GAP-ID) a tracked gap.
Manage matter workspaces — create, list, switch, close, or detach the active matter (practice-level). Use when working across multiple clients or matters and you need to keep one engagement's context separate from another, or when a substantive skill needs to know which matter it's working in.
Diff a specific regulatory change against the indexed policy library. Use when a reg has changed and you need to know which policies it touches and what the gap is, when the user says "diff this reg against our policies", "which policy does this affect", or "gap analysis", or when reg-feed-watcher hands off a material item.
Produce a proposed marked-up policy redraft that closes a gap found by /regulatory-legal:gaps or /regulatory-legal:policy-diff. A first draft for internal review — not for direct application to approved policy documents. Use when the user says "redraft the policy", "draft the policy fix", "mark up the policy", or when gap-surfacer hands off a gap for drafting.
Check regulatory feeds now and report what's new since the last check, filtered by your materiality threshold. Use when the user says "check the feeds", "what's new", "regulatory update", when running from the scheduled agent, or when manually pasting a regulatory development for classification and diff.
Create polished, validated architecture, workflow, sequence, data-flow, and lifecycle/state diagrams as explorable standalone HTML with inline SVG, dark/light themes, optional trace motion, and PNG/JPEG/WebP/SVG/WebM export. Accept plain-language requirements or pasted Mermaid flowchart, sequenceDiagram, and stateDiagram input; inspect repository evidence when the diagram must reflect real code. Use when the user asks to visualize system architecture, infrastructure, cloud/security/network topology, technical workflows, API call sequences, request lifecycles, data pipelines, ETL/ELT, data lineage, state machines, or to convert/beautify Mermaid.
>- component folder structure, styled-components, hooks, named exports, barrel files, layout components, and theme usage. Use when editing any file under redisinsight/ui/**, writing or modifying React components, Redux slices, styled-components, custom hooks, or when the user mentions UI, frontend, React, Redux, or styled-components.
>- module structure, services, controllers, DTOs, dependency injection, and error handling. Use when editing any file under redisinsight/api/**, writing or modifying NestJS modules, controllers, services, DTOs, providers, or when the user mentions the backend, API, or NestJS.
>- Generate commit messages following Conventional Commits format. Use when creating commits, writing commit messages, or the user asks to commit changes.
>- Create and name git branches following project conventions. Use when creating branches, checking out new branches, or the user mentions branch naming.
>- Find and safely remove unused ("dead") npm dependencies in RedisInsight using a grep + leaf-check + build-gate recipe. Use when cleaning up dependencies, investigating whether a package is still used, removing a suspected leftover, or when the user mentions dead deps, unused dependencies, dependency cleanup, leftover packages, or "is this safe to remove". Complements the weekly vulnerability audit (`scripts/dependency-audit-report.mjs`), which only reports vulnerabilities.
>- object models, test structure, fixtures, navigation patterns, and flaky-test prevention. Use when editing files under tests/e2e-playwright/**, writing Playwright tests, adding page objects, or when the user mentions Playwright, E2E tests, page objects, or end-to-end testing.
>- Create, modify, and remove feature flags in RedisInsight. Use when adding a new feature flag, introducing a dev flag, promoting a dev flag to regular, cleaning up old flags, or the user mentions feature flags, feature toggles, or gating features.
>- naming conventions (camelCase, PascalCase, UPPER_SNAKE_CASE), linting rules, no `any` without reason, no `!important` in styles, and constant extraction. Use when writing or refactoring any TypeScript/JavaScript code in this repo, when ESLint or Prettier issues come up, or when the user mentions code style, lint, naming conventions, or general code quality.
>- push, or force-push directly to main, latest, or release branches; no destructive history rewrites without explicit user approval. Use before any git operation that touches protected branches, before force-push, reset --hard, history rewrite, or branch deletion, or whenever the user asks about merging, pushing, or release branches.
>- Run, refresh, or recover from RedisInsight's per-project TypeScript error baselines (.tscheck.rec.json). Use when CI reports "baseline is outdated" or "more TS errors than previously recorded", when the user mentions tscheck / type-check / .tscheck.rec.json, when introducing or fixing TS errors, or when reviewing PRs that touch baseline files.
>- Create and review pull requests following project standards including title format, description template, and review checklist. Use when creating PRs, writing PR descriptions, or reviewing pull requests.
Use when creating, modifying, debugging, deploying, or testing Redis Insight Workbench visualization plugins, plugin manifests, package.json visualizations, activationMethod functions, redisinsight-plugin-sdk usage, Parcel/Vite plugin builds, iframe rendering, Redis command parsing, Docker RedisInsight deployment, /api/plugins verification, or Playwright plugin validation.
>- Internationalization conventions for the RedisInsight UI (i18next). Use when adding or changing user-facing strings under redisinsight/ui/**, editing the locale files (en.json/bg.json), translating API errors or notifications, or when the user mentions i18n, translations, locales, i18next, or <Trans>.
>- Locate and modify TypeScript configuration in RedisInsight. Use when adding path aliases, introducing a new TS area, debugging webpack/ts-node/ESLint path resolution, or the user asks about tsconfig, path mappings, or where TypeScript is configured.
>- Unit/integration testing standards for RedisInsight using Jest and for test data, mocking patterns, and `waitFor` instead of fixed time waits. Use when writing or modifying any `*.spec.ts` or `*.spec.tsx` file, when adding component or slice tests, when debugging flaky tests, or when the user mentions jest, testing library, faker, or test patterns.
Migrates Next.js projects to vinext (Vite-based Next.js reimplementation). Load when asked to migrate, convert, or switch from Next.js to vinext. Handles compatibility scanning, package replacement, Vite config generation, ESM conversion, and deployment setup (Cloudflare Workers natively, other platforms via Nitro).
Use when the user asks for a security review of a pull request, commit, branch diff, working-tree patch, or other Git-backed change set.
Use for a standard, single-pass security audit of an entire repository or a scoped path, package, folder, or submodule with no diff to review. This is the default repository scan. Do not use for PR, commit, branch, or working-tree diffs, or for deep, multi-pass scans.
Use when Codex is already in the finding-discovery phase of a security scan or the user explicitly asks to discover candidate security findings in a repository or code change. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.
Use when Codex is already in the attack-path-analysis phase of a security scan or the user explicitly asks to trace a security finding from source to sink and calibrate severity. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.
Define, review, or update SECURITY.md guidance for a repository or component. Use when the user wants to clarify what Codex Security should review, what is out of scope, which security properties must hold, or whether existing guidance still matches the code.
Use when the user asks for a deep, exhaustive, multi-pass, or variance-reducing repository-wide or scoped-path Codex Security scan. Run repeated independent discovery with the Codex Security deep-scan tool, then synthesize one canonical validation threat model and run validation, attack-path analysis, canonical JSON completion, and generated reporting once. Do not use for PRs, commits, branch diffs, or working-tree diffs.
Use when Codex is already in the validation phase of a security scan or the user explicitly asks to determine whether one or more candidate security findings are valid. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.
Step-by-step guide for adding a new compatibility flag to workerd, including capnp schema, C++ usage, testing, and documentation requirements.
Commit categorization rules for changelogs and "what's new" summaries. MUST be loaded before categorizing commits in changelog or whats-new commands. Provides the canonical path-based category table used to group commits by area.
How to find, build, and run tests in workerd. Covers wd-test, kj_test target naming, bazel query patterns, and common flags. Also covers parent project integration tests if workerd is used as a submodule. Load this skill when you need to locate or run a test and aren't sure of the exact target name or invocation.
Step-by-step guide for adding a new autogate to workerd for gradual rollout of risky changes, including enum registration, string mapping, usage pattern, and testing.
After completing any task that took more than ~5 tool calls, or after long-running builds/tests finish, load this skill and deliver a dad joke to lighten the mood. Also load before any user-requested joke, pun, or limerick. Never improvise jokes without loading this skill first.
Structured scratch tracking document for investigation state during bug hunts - prevents re-reading code, losing context, and rabbit holes; maintains external memory so you don't re-derive conclusions
Identifies the local user's GitHub account and git identity before performing code reviews. Load this skill at the start of any PR review, code review, or commit log analysis so findings can be framed relative to the user's own prior comments, commits, and approval status.
Mandatory rules for running bazel tests during development. Load this skill before running any bazel test command, especially when validating fixes or verifying regression tests. Prevents false confidence from cached results, filter flags that silently match nothing, and partial test runs that miss breakage.
Answers built from the skills we actually parsed.