Comentaris
Comentaris i anotacions del codi
deslop
openclaw
"Diff-scoped AI-slop cleanup pass: strip comment slop, defensive-check slop, type-laundering, and style drift from the current branch diff before autoreview."
openclaw-secret-scanning-maintainer
openclaw
Triage, redact, clean up, and resolve OpenClaw GitHub Secret Scanning alerts in issues or PRs.
github
openclaw
Use gh for GitHub issues, PR status, CI/logs, comments, reviews, releases, and API queries.
security-triage
openclaw
"Triage OpenClaw security advisories, drafts, and GHSA reports with shipped-tag and trust-model proof."
ha-pr-comment-audit
home-assistant
Audits the review comment threads on a Home Assistant GitHub pull request, flagging unaddressed comments and requests for clarification. Use when checking whether PR feedback has been handled, either standalone or as part of a full PR review.
ha-pr-reviewer
home-assistant
Reviews Home Assistant GitHub pull requests and provides feedback comments. This is the top skill to use for reviewing Pull Requests from GitHub.
ha-review
home-assistant
Reviews Home Assistant code changes and provides constructive feedback. Should be used when a review is requested to provide a consistent review behavior and output format. This skill can be used for code reviews in general, not just for GitHub pull requests.
xhs-interact
autoclaw-cc
小红书社交互动技能。发表评论、回复评论、点赞、收藏。 当用户要求评论、回复、点赞或收藏小红书帖子时触发。
trello
elizaOS
Manages Trello boards, lists, and cards via the Trello REST API. Use when the user wants to create cards, move tasks between lists, list boards, add comments, archive cards, or check what is on a Trello board. Handles authentication, pagination, and rate-limit awareness for all Trello REST endpoints.
contribute-to-eliza
elizaOS
"Finish and prove a scoped elizaOS GitHub issue, or independently review and repair an open elizaOS pull request. Use when contributing compute to elizaOS by selecting unclaimed work, implementing or reviewing changes, adding real tests and evidence, validating artifacts, or preparing a contribution for maintainer review."
next-cache-components-adoption
vercel
Turn on Cache Components in a Next.js app and resolve the blocking routes it surfaces. Use when the user wants to enable, adopt, or migrate to Cache Components, flip the cacheComponents flag, work through a flood of blocking-prerender / instant validation errors, run the cache-components-instant-false codemod, or decide between opting routes out with export const instant = false and fixing them in place.
pr-status-triage
vercel
Triage CI failures and PR review comments using scripts/pr-status.js. Use when investigating failing CI jobs, flaky tests, or PR review feedback. Covers blocker-first prioritization (build > lint > types > tests), CI env var matching for local reproduction, and the Known Flaky Tests distinction.
kbn-github
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.
flaky-test-investigator
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
elastic
Review Scout UI/API tests (including Scout test migrations) for best practices, reuse, parity, and server config hygiene.
kibana-otel-instrumentation
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.
pr-polish
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.
contributing
apache
Guides the contribution workflow for Apache Beam, including creating PRs, issue management, code review process, and release cycles. Use when contributing code, creating PRs, or understanding the contribution process.
license-compliance
apache
Ensures all new files include proper Apache 2.0 license headers. Use when creating any new file in the Apache Beam repository.
pr-governance-review
hushh-labs
Use when reviewing an incoming pull request for north-star alignment, trust-boundary regressions, malicious or low-signal degradation, stale-vs-current CI interpretation, and true merge readiness beyond a green gate. Also owns PR train planning, merge queue cohorts, maintainer patch-then-merge, contributor harvest decisions, and backlog review waves.
civitai-mcp-ultimate
timoncool
Ultimate MCP server for Civitai — search models, browse top images with prompts, download LoRAs/Checkpoints, analyze trends. Use when user asks about AI models, LoRAs, checkpoints, Stable Diffusion, Flux, image generation prompts, or Civitai.
write-guides
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/.
code-compaction
dotnet
Use when a code/test/comment diff is called bloated, slop, LLM slop, bullshit, WTF, crap, rubbish, embarrassing, overengineered, adhoc, or "not paid by LOC"; or when symptoms include bloated comments, superfluous planning .md / .tools / one-time setup / phase-or-sprint tags, huge-file growth instead of new-file extraction, 5 copy-pasted tests that should be 1 parametrized test, duplicated test setup, reinvented helpers, near-duplicate logic across files, low reuse, 4+ new module-level helpers for one bugfix, fresh whole-AST/IR/syntax-tree walkers, or 150+ added LOC for one bugfix. Also use proactively before opening a PR whose diff smells like any of the above.
pr-description
dotnet
Use when drafting, proposing, creating, or editing prose for a dotnet/fsharp GitHub PR or issue — body, title, comment, review summary, edits — including bare asks like "open a PR", "ship this", "write up what I did", "summarise the change", "reply on the PR", "edit the issue body", "gh pr create", "gh pr comment", "gh pr edit --body", "gh issue comment", "gh pr review --body". Primary use case is PR descriptions; same rules apply to PR/issue comments and review summaries. Not for labels, reviewers, merging, or code-review findings (just the prose write-up of them).