Comments
Code comments and annotations
code-review
by open-metadata
Use to review code changes with a two-stage process - first checking spec/requirements compliance, then code quality. Works on staged changes, branches, or PRs.
issue-maker
by pollinations
Create GitHub issues following Pollinations team conventions. Use when asked to create issues, track work, or plan features.
dogfood
by coder
Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to "dogfood", "QA", "exploratory test", "find issues", "bug hunt", "test this app/site/platform", or review the quality of a web application. Produces a structured report with full reproduction evidence -- step-by-step screenshots, repro videos, and detailed repro steps for every issue -- so findings can be handed directly to the responsible teams.
screenpipe-api
by screenpipe
Query the user's data via the local screenpipe REST API at localhost:3030 — screen recordings, audio, UI elements, usage analytics, meetings, connected services, and the user's persistent memory store. Use for questions about screen activity, meetings, apps, productivity, media export, retranscription, connections, OR to save / remember / store information for later (POST /memories — survives across sessions, queryable by external agents).
vercel-composition-patterns
by zebbern
React composition patterns that scale. Use when refactoring components with
code-documenter
by zebbern
Use when adding docstrings, creating API documentation, or building documentation sites. Invoke for OpenAPI/Swagger specs, JSDoc, doc portals, tutorials, user guides.
kilocode-merge-minimizer
by Kilo-Org
Use when changing shared upstream-owned files to add Kilo-specific behavior, editing kilocode_change markers in shared code, or moving additive behavior out of shared code to reduce upstream merge conflicts. Do not use for changes confined to Kilo-owned paths such as packages/kilo-vscode/ or packages/kilo-ui/.
n8n:linear-issue
by n8n-io
Fetch and analyze Linear issue with all related context. Use when starting work on a Linear ticket, analyzing issues, or gathering context about a Linear issue.
n8n:protect-endpoints
by n8n-io
Applies n8n's RBAC scope decorators to REST endpoints. Use when creating a new @RestController, adding any @Get/@Post/@Put/@Patch/@Delete route to an existing controller, or reviewing endpoint authorization. Every authenticated endpoint must be gated by @ProjectScope or @GlobalScope.
n8n:community-pr-readiness-check
by n8n-io
Checks if a community pull request is ready for human review. Verifies CLA signature, PR title format, description completeness, test coverage, and cubic-dev-ai issues, then triages to the right Linear team or recommends a close. Use when given a PR number or branch name to review, or when the user says /community-pr-readiness-check, or asks to check if a PR is ready for review.
n8n:human-like-code-review
by n8n-io
Reviews a GitHub pull request like a thoughtful human reviewer and writes the feedback to a markdown file. Prioritizes context, architecture fit, solution complexity, bugs, security edge cases, and missing tests. Use when given a PR URL to review, or when the user says /human-like-code-review.
n8n:db-migrations
by n8n-io
Authors n8n database migrations. Use when creating or modifying files under packages/@n8n/db/src/migrations/, when the user asks to add a column, table, index, foreign key, or backfill, or when the user mentions DB migrations or TypeORM migrations.
update-screenshots
by microsoft
Update the committed blocks-ci screenshot hashes after the "Screenshots & Tests" check fails, or investigate a screenshot diff reported on a PR. Use when asked to update, accept, or refresh component screenshot baselines from CI. This skill should be run as a subagent.
act-on-feedback
by microsoft
Act on user feedback attached to the current session. Use when the user submits feedback on the session's changes via the Submit Feedback button.
code-review
by microsoft
Perform a code review of the current session's changes. Use when the user requests a code review via the Run Code Review button in the Changes toolbar.
pull-requests
by coder
Guidelines for creating and managing Pull Requests in this repo
docs-review
by metabase
Review documentation changes for compliance with the Metabase writing style guide. Use when reviewing pull requests, files, or diffs containing documentation markdown files.
announcing-behavior-changes
by PostHog
Decides whether a behavior-changing fix needs an in-app notice, then builds one that reaches only the affected users and can be removed later. Use when a change alters what an existing user sees without them doing anything — a metric moves, a chart shifts, a count drops, a date range resolves differently, a matcher matches differently — and when adding, reviewing, or removing such a notice. Trigger terms: behavior change, breaking change, semantics change, "results may differ", change notice, deprecation banner, migration banner. Carries the gate (narrow to the affected users with a tested predicate, or do not ship a notice at all), the pattern from SqlInsightDateFilterNotice, where to anchor the notice, and the flag-based removal path. Not for new features (use the changelog), not for permanent per-object warnings computed by the backend, and not for the wording itself (see /writing-user-facing-copy).
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.
querying-canvas-data
by PostHog
Get PostHog data into a canvas correctly: the host-injected ph SDK (loadInsight, query, capture, state, openExternal, navigate), the data hierarchy (saved insights first, typed query nodes second, inline HogQL last), verifiability (insight-backed metrics link their saved insight in PostHog; ad-hoc queries expose the exact query that ran), per-insight-type result shapes, progressive per-query loading, date-range wiring, and event capture from a canvas. Use whenever a canvas shows metrics, charts, tables, or any PostHog data, or needs to send analytics events.
sending-notifications
by PostHog
'How to send real-time in-app notifications from PostHog backend code. Use when integrating notifications into a new feature, wiring up a notification source (alerts, comments, approvals, pipelines, issues), or choosing the right target type and priority for a notification.'
composing-grid-canvases
by PostHog
Compose PostHog grid canvases — widget grids (including the user's home canvas) built from reusable component canvases. Use when a task asks to add, fill, move, resize, or remove a widget on a grid or home canvas, to compose a whole canvas of widgets from one ask, to build a reusable widget/component, or when a placement id or grid canvas id is the target. Covers the component store search → configure → fork → build ladder, the component placement contract (size, configSchema), the placement lifecycle (pending/generating/live/failed), the guarded layout patch loop, and reading the canvas's comment threads.
merging-prs
by PostHog
Merge a PR into master through the Trunk merge queue and babysit it until it lands. Enqueue with a /trunk merge comment, then watch trunk merge status and the PR state until it is MERGED or the queue kicks it out, reporting Trunk's own reason for the terminal transition. Use when asked to merge a PR, "merge when ready", "land it", "ship it", to merge a whole stack (comment on the top PR — the queue merges it and every layer below atomically), to get a PR approved by stamphog (MCP review request first, stamphog label as the fallback), or to babysit/watch a PR through the queue. Never use gh pr merge in this repo — the queue is the only path into master.