Comments
Code comments and annotations
prs-awaiting-maintainer
by dyoshikawa
List open pull requests where the ball is in the maintainer's court: CI is green and the PR is ready for a maintainer to review, re-review, or merge. Use when the user wants to see PRs awaiting maintainer action.
merge-pr
by dyoshikawa
Merge a pull request using gh pr merge --admin
approve
by dyoshikawa
Approve a pull request using gh pr review --approve
explain-pr
by dyoshikawa
"Explain a PR: the background problem and the proposed solution"
batch-review-prs-awaiting-maintainer
by dyoshikawa
Batch-triage open pull requests: list PRs with prs-awaiting-maintainer, review each with review-pr, then post-review-comments when there are merge-blocker findings, or create-scrap-issue for non-blocking findings and merge-pr when there are none. Use when the user wants to review and resolve a batch of PRs in one pass.
code-review
by vectorize-io
Review changed code against project standards. Checks for missing tests, dead code, type safety, lint issues, and coding conventions. Run after completing any implementation work.
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.
vercel-composition-patterns
by supabase
React composition patterns that scale. Use when refactoring components with
nature-response
by Yuan1z0825
Draft, audit, or revise Nature-style revision correspondence packages: point-by-point reviewer-separated response letters, rebuttal letters, revision cover letters, LaTeX cover/response templates, and red-marked revised-manuscript excerpts. Keep mutually blind reviewers isolated so no reviewer-facing response reveals another reviewer's comments, numbering, recommendation, or author response. Prevent reviewer-driven manuscript accretion by preferring replacement, compression, or SI relocation over appending non-central defense prose. Use for reviewer comments, editor decision letters, pasted editorial emails, response drafts, cover letters, response to reviewers, rebuttal, 修回信, 返修邮件, 编辑邮件, 返修 cover letter, 审稿意见回复, 逐点回复, 大修回复, 小修回复, 回复审稿人, 修改稿回复, 写rebuttal, 回应审稿意见, 标红修改, or LaTeX 模板.
triage
by mattpocock
Move issues and external PRs through a state machine of triage roles, categorise, verify, grill if needed, and write agent-ready briefs.
humanizer
by blader
Remove signs of AI-generated writing from text. Use when editing or reviewing text to make it sound more natural and human-written. Based on Wikipedia's comprehensive "Signs of AI writing" guide. Detects and fixes patterns including: inflated symbolism, promotional language, superficial -ing analyses, vague attributions, em dash overuse, rule of three, AI vocabulary words, passive voice, negative parallelisms, and filler phrases.
code-review-and-quality
by addyosmani
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
api-and-interface-design
by addyosmani
Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
documentation-and-adrs
by addyosmani
Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.
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.
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).
pr-polish
by Significant-Gravitas
Alternate /pr-review and /pr-address on a PR until the PR is truly mergeable — no new review findings, zero unresolved inline threads, zero unaddressed top-level reviews or issue comments, all CI checks green, and two consecutive quiet polls after CI settles. Use when the user wants a PR polished to merge-ready without setting a fixed number of rounds.
housekeeping
by langfuse
Triage an engineer's work queue across Linear, Pylon, and GitHub. Use for assigned, urgent, waiting, or stale issues, support follow-ups, and PR reviews.
git-workflow
by langfuse
Langfuse repo Git, GitHub, commit, branch, pull request, issue search, release, and production-promotion workflow. Use when staging, committing, pushing, opening PRs, choosing a Linear git branch name, handling Claude, Greptile, or Codex review comments, searching GitHub issues, or changing release/promotion behavior.
langfuse-previews
by langfuse
Use Langfuse's disposable per-PR previews at pr-N.preview.langfuse.com (synthetic data only). Use for preview access, failed deployments, test-data seeding, kubectl debugging, or waking sleeping previews.
vercel-composition-patterns
by langfuse
React composition patterns that scale. Use when refactoring components with
weekly-production-review
by langfuse
Prepare Langfuse weekly production reviews covering failures, fixes, open issues, and tracking gaps. Use for "what broke last week," production bugs, Datadog alerts or error patterns, incident.io activity, or pager load.
linear-bug-triage
by langfuse
Use this skill after a bug or regression candidate has measured evidence to document them within linear.