Audit code for memory leaks and disposable issues. Use when reviewing event listeners, DOM handlers, lifecycle callbacks, or fixing leak reports. Covers addDisposableListener, Event.once, MutableDisposable, DisposableStore, and onWillDispose patterns.
Steady+17 stars this week
8 projects use a version of this
195k13d agoReviewMountCreate a free account to mount
Writes and reviews the JSDoc on `@Env(...)` config properties. The docs team extracts these comments from source into the public environment variable reference, so they are user documentation, not code comments. Use when adding or changing an `@Env` property, a config class, or reviewing a PR that touches one.
Surging+18 stars this week
1 project uses a version of this
210k13d agoReviewMountCreate a free account to mount
Plan a VS Code Sweeper agent-ready issue with the maintainer — fetch the sweeper's review record from its state repo, put the review's open decisions to the maintainer, and write a plan file (.sweeper/plans/issue-<n>.md) for them to edit in their editor; it writes no code and ends there — the sweeper-implement skill implements the approved plan. Use ONLY when the request explicitly asks for the sweeper plan — "sweeper-plan", "plan … with the sweeper", a sweeper record or agent-ready issue to plan first. Do NOT use for a plain planning request that doesn't mention the sweeper.
195k13d agoReviewMountCreate a free account to mount
When to delegate to `cavecrew-investigator` (locate code), `cavecrew-builder` (1-2 file edit) or `cavecrew-reviewer` (diff review) instead of working inline or using `Explore`. Their output is compressed, so main context lasts longer.
Steady22 mentions in 2 weeks
43 projects use a version of this
118k7mo agoReviewMountCreate a free account to mount
Implement a VS Code Sweeper agent-ready issue — fetch the sweeper's review record from its state repo, implement the change in the current vscode checkout from the review's brief (an implement-ready record) or from an approved sweeper-plan file, validate the diff against it, and — after the maintainer has reviewed the changes in their editor — open a draft PR. Use ONLY when the request explicitly asks for the sweeper — "sweeper-implement", "sweeper", "vscodesweeper", a sweeper record, an agent-ready issue, or a sweeper brief — or asks to implement a sweeper plan ("implement plan <n>", a `.sweeper/plans/issue-<n>.md` file). Do NOT use for a plain "fix this issue" request that doesn't mention the sweeper; fix those directly with your normal tools instead.
Steady+17 stars this week
No other project uses it yet
195k13d agoReviewMountCreate a free account to mount
Use when writing, changing, or reviewing Cucumber and Playwright tests under `e2e/`, including feature files, step definitions, support code, scenario tags, locators, and assertions. Do not use for Vitest, React Testing Library, backend tests, or generic browser automation outside the E2E suite.
2 projects use a version of this
161k17d agoReviewMountCreate a free account to mount
Answer questions about the Supabase docs app (apps/docs) using documented architecture, build pipeline, and review-pattern notes, and apply feature-design principles (codebase reuse, coding minimalism) when proposing or critiquing changes. Use when the user asks "how does X work in the docs app?", "where does Y live?", "is this approach OK for the docs app?", or before writing non-trivial changes under apps/docs/ — especially anything touching the MDX pipeline, markdown generation, content components, federated docs, or contributor-facing authoring patterns, or feature flags and experiments. Can answer architecture questions with Mermaid diagrams when helpful.
No other project uses it yet
115k48d agoReviewMountCreate a free account to mount
Use when auditing or fixing prose that reads like a leaked reasoning transcript — dead design-session citations such as (decision N), audit item codes, or §N of uncommitted drafts; change narration such as "used to", "no longer", "this cut"; stack or review vantage ("a later PR in this stack", "rejected in review"); reviewer-addressed justifications; control-flow narration; or hedged planning residue in comments, JSDoc, docs, or Agent Notes.
Use when writing, reviewing, restoring, trimming, or auditing prose in the deepseek-harness repo, including deciding where documentation or comments are required across Markdown, JSDoc, code and test comments, prompts, descriptions, diagnostics, and CLI or UI strings.
The VS Code design philosophy — a shared Values→Principles→Moves vocabulary for reasoning about UI in design terms instead of raw pixels. Use when designing, building, reviewing, or giving feedback on any visual surface; when deciding a radius, spacing, type role, icon size, border, color, or motion; or when translating a "this feels off" observation into a concrete, principled fix.
195k13d agoReviewMountCreate a free account to mount
Guides adding, changing, and reviewing telemetry through the `@n8n/telemetry` event registry. Use when working on telemetry, analytics, tracking, product events, `track()` calls, or RudderStack/PostHog product events, in frontend or backend code — and whenever you need to find which registered telemetry events exist, what an event means, or what properties it carries.
210k13d agoReviewMountCreate a free account to mount
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, splitting uncommitted work in a messy working tree into clean atomic commits, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump, tagging, or writing a changelog. Use when asked to write a commit message or a changelog entry for a change, or to split a change into commits, even when the diff is pasted inline and the message seems easy to write from it.
After you give a substantive answer or draft that the user may act on — advice or recommendations, drafted artifacts such as goals, plans, pitches, proposals, or emails, estimates or projections, analysis or interpretation of data, factual claims they may rely on, or a multi-step argument — invoke this skill BEFORE finalizing your reply and then, if it applies, append 2-3 short follow-up questions, each tied to something specific in what you just produced, that help the user check key facts, probe the reasoning or assumptions, and notice missing context. Do this at most once per conversation. Skip it when the user asked a trivial how-to or simple lookup, wants a purely educational explanation, asked you only to format, convert, or assemble a file from content they provided, is writing code they will run, is doing creative writing or casual chat, or already asked you to double-check, cite, or review — the skill file explains these boundaries and the exact output format.
189k3mo agoReviewMountCreate a free account to mount
Quality audit of a whole repo: bugs, security holes, what breaks under real load, risky code without tests, slow paths, and what to delete, merge or split. Ranked, each finding explained in plain English. One-shot report, changes nothing. Use for "audit this codebase", "review the whole repo", "find bloat", "what can I delete", /ponytail-audit.
Rising19 mentions in 2 weeks
64 projects use a version of this
182k5mo agoReviewMountCreate a free account to mount
Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when you want every assumption cross-examined before proceeding, when stress-testing a plan for hidden failure modes, when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production auth, security-sensitive logic, a high-stakes migration, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later.
Add, change, or review user-facing text in the Langflow frontend using the i18n system (i18next / react-i18next). Use whenever a change adds or edits UI strings — labels, buttons, tooltips, modals, toasts, error messages, empty states — or when reviewing a diff that contains user-facing text. Every user-facing string must go through the translation system and every new key must exist in ALL locale files. Do NOT use for backend strings, log messages, or code identifiers.
2 projects use a version of this
156k21d agoReviewMountCreate a free account to mount
Use whenever adding, modifying, or reviewing any Copilot, agent, LLM, AI, tool, permission, sandbox, MCP, model, telemetry, feature-gate, setting, configuration, or enterprise control—especially anything an organization or administrator may need to manage. Start here to decide whether it belongs in runtime managed settings, a typed SDK contract, VS Code configuration policy, extension policy, or a split implementation. Run on every new Copilot/agent/LLM control and ANY change that adds a `policy:` field.
Steady+17 stars this week
1 project uses a version of this
195k13d agoReviewMountCreate a free account to mount
Audit REA CI and test suites for correctness, fixture drift, false passes, and measured performance; use for suite or workflow investigations and efficiency changes, rather than ordinary feature testing or a single test failure.
A folder with a SKILL.md file: a name, a description of when to use it, and instructions. Claude loads a skill only when the task matches its description.
How do I use one I find here?
Copy the folder into your project's .claude/skills/ directory, or into your own skills folder to use it everywhere.
What do the warnings mean?
We read each file for commands that read secrets, delete things or pipe downloads into a shell, and say so before you copy it. No warning is not a promise that a file is safe.
Which skills worked for people?
Open a skill to see its discussion. Reports from people and their agents are coming.