Comments
Code comments and annotations
label-core-bugs
by mastra-ai
Review open mastra-ai/mastra GitHub issues, identify direct @mastra/core bugs, and apply the @mastra/core label. Use when auditing issues for core ownership, labeling direct core bugs, or periodically reconciling the @mastra/core issue label.
factory-rereview
by mastra-ai
Re-review a pull request after a push — reconcile the previous review against the new commits, look for new defects the push introduced, then a fresh pass over the whole PR, and finish with a verdict on the PR
vercel-composition-patterns
by supabase
React composition patterns that scale. Use when refactoring components with
document-public-apis
by pytorch
Document undocumented public APIs in PyTorch by removing functions from coverage_ignore_functions and coverage_ignore_classes in docs/source/conf.py, running Sphinx coverage, and adding the appropriate autodoc directives to the correct .md or .rst doc files. Use when a user asks to remove functions from conf.py ignore lists.
review-pr
by nrwl
Deep code review of a single open PR in nrwl/nx. Checks the PR out only inside an isolated sandbox, then runs four fixed reviewers: implementation (correctness, errors, types, performance), verification (tests, ticket grounding, comments, and docs), approach, and security. A reproduce-verifier executes a runnable repro only when verification identifies one. The skill saves a GitHub-flavored draft to ~/.nx-pr-reviews/<NUMBER>.md and never posts it. Claude reads/executes PR code only through the sandbox CLI; credentials never enter the sandbox.
author-migration
by nrwl
Author or scope a first-party Nx migration. Use whenever code removes, renames, or deprecates an option/flag/executor/generator-schema field, changes a default, or bumps a dependency, and someone asks whether existing workspaces need a migration so they don't break on nx migrate/upgrade. Covers writing the colocated update-VER/NAME.{ts,spec.ts,md} set, the migrations.json entry (version, requires, implementation, prompt, documentation) or packageJsonUpdates group, and the AI-agent prompt/runbook .md for prompt-only or hybrid (generator + prompt) migrations. Also covers porting an upstream framework's own migrations into Nx. Invoke BEFORE writing, fixing, or editing any migration, migration prompt/runbook, or packageJsonUpdates group, and before concluding a breaking change needs no migration at all.
multi-version-compliance
by nrwl
Apply or review multi-version support compliance for first-party Nx plugins. Primary entry point: a Linear task ID (NXC-XXXX) from the "Multi-version supported across plugins" milestone — the task carries the resolved support window, findings, and "Needs human decision" items. Falls back to self-discovery when no task exists. Use when asked to "fix multi-version compliance for @nx/X", "do NXC-XXXX", "review this compliance PR", or when working on a branch / PR titled "multi-version support compliance for @nx/X". Covers the canonical shape (assertSupportedPackageVersion, all-generators-enforce-floor.spec.ts, peer dep alignment, requires-gate auditing, user-pin preservation, executor / inferred-plugin feature gating).
clojure-write
by metabase
Guide Clojure and ClojureScript development using REPL-driven workflow, coding conventions, and best practices. Use when writing, developing, or refactoring Clojure/ClojureScript code.
reviewing-before-pr
by PostHog
Run one local Greptile review of a branch before its PR opens, with hogli review. Opt-in: it needs a seat on PostHog's Greptile workspace, which most people do not have yet, so use it only when someone asks for a local Greptile review by name. Trigger terms: hogli review, greptile, local review, pre-PR review.
triaging-merge-queue-failures
by PostHog
Decision procedure for a PR that failed or was removed from the Trunk merge queue: classify the kick (superseded by a newer commit, not mergeable, a gate that failed on a cancelled run, real failure, one-off flake, or repo-wide flaky/infra issue) and take the matching action (wait, hold and fix, requeue once, or escalate instead of spam-retrying). Use when a PR is kicked from the queue, Trunk reports a failed queue attempt on a PR, someone asks "why was my PR removed from the queue" or "should I requeue", or when running as the scheduled merge queue triage sweep. Trigger terms: merge queue kicked, removed from queue, queue failure, requeue, trunk merge failed. Operators setting up the automation itself: see references/routine-setup.md.
voting-status
by pollinations
Create and post ASCII art voting status diagrams to GitHub issues and Discord. Use when asked to update voting, show voting results, or announce voting status.
issue-maker
by pollinations
Create GitHub issues following Pollinations team conventions. Use when asked to create issues, track work, or plan features.
pyrefly-type-coverage
by pytorch
Migrate a file to use stricter Pyrefly type checking with annotations required for all functions, classes, and attributes.
docstring
by pytorch
Write docstrings for PyTorch functions and methods following PyTorch conventions. Use when writing or updating docstrings in PyTorch code.
write-the-docs
by supabase
Draft new or updated Supabase docs content for a feature or launch, grounded in Linear (the ticket plus its product/PM context), a read of the actual code, and the docs style guide once one exists. Use when asked to write docs for a new feature, a launch (e.g. Select 2026), or a Linear ticket that needs net-new content rather than a bug fix. Not for implementing existing docs bug reports — use work-linear-issue for that.
review-the-docs
by supabase
Review Supabase docs changes locally in ~/GitHub/supabase/supabase — either an open PR (triage, classify, verify) or your own branch before opening a PR (local self-review). Covers markdown pipeline, MDX content, tutorials, examples, Studio links, and docs tooling. Use when asked to review docs PRs, self-review a draft branch, check who has approved, verify build output, or evaluate supabase/supabase documentation changes.
write-guides
by remix-run
Write, rewrite, or audit Remix guide chapters in the voice of docs/guides/app/actions/docs/chapters/01-start-here.md. Use when drafting app guides, revising generated-sounding prose, tightening guide examples, preserving doc anchors, or reviewing Markdown chapters under docs/guides/app/actions/docs/chapters/.
flaky-test-investigator
by elastic
Investigate Scout and FTR flaky test failures in Kibana. Use when triaging a failed-test issue, a Buildkite-reported failure, a test path that has been failing intermittently, or any time the user asks to look at a flaky test, deflake a test, or stabilize a test.
scout-best-practices-reviewer
by elastic
Review Scout UI/API tests (including Scout test migrations) for best practices, reuse, parity, and server config hygiene.
kibana-otel-instrumentation
by elastic
Implement and quality-check OpenTelemetry metric instrumentation in Kibana code that uses @kbn/metrics. Use whenever the user wants to add, change, or review OTel metrics — including any call to metrics.getMeter, meter.createCounter/createUpDownCounter/createGauge/createHistogram/createObservable*/addBatchObservableCallback, edits to kibana.yml telemetry.metrics config, or questions like "is this metric well-designed?", "what should I name this counter?", or "which instrument type is right here?". Trigger this skill even when the user does not say "OTel" or "OpenTelemetry" but is clearly adding observability to Kibana server code and already knows what they want to measure.
kbn-github
by elastic
GitHub interactions via gh CLI for the Kibana repo. Use when performing any GitHub interaction — creating, viewing, or modifying PRs or issues, posting comments or reviews, checking CI status, applying labels, creating releases, or making any gh/API call.
finalizing-pr
by streamlit
Finalizes branch changes for merging by simplifying code, running checks, reviewing changes, and creating a PR if needed. Use when ready to merge changes into the target branch.
pull-requests
by coder
Guidelines for creating and managing Pull Requests in this repo
pr-finalize
by dotnet
Finalizes any PR for merge by verifying title/description match implementation AND performing code review for best practices. Use when asked to "finalize PR", "check PR description", "review commit message", before merging any PR, or when PR implementation changed during review. Do NOT use for extracting lessons (use learn-from-pr), writing tests (use write-tests-agent), or investigating build failures (use azdo-build-investigator and ci-analysis).