Comments
Code comments and annotations
Uses and selection guide
Use these skills to document behavior and maintain explanations alongside code. Check which source files the workflow reads, whether examples are executable and how it keeps terminology consistent across languages.
unit-test-caching
by giuseppe-trisciuoglio
Provides patterns for unit testing caching behavior using Spring Cache annotations (@Cacheable, @CachePut, @CacheEvict). Use when validating cache configuration and cache hit/miss scenarios.
sphinx
by vamseeachanta
Generate comprehensive Python documentation with Sphinx. Covers autodoc for API extraction, Napoleon for Google/NumPy docstrings, intersphinx for cross-references, and multiple output formats including HTML, PDF, and ePub.
pr-reviewer
by SpillwaveSolutions
Comprehensive GitHub Pull Request code review skill. Use when asked to "review this PR", "code review", "review pull request", "check this PR", or when a GitHub PR URL is provided. Fetches PR metadata, diff, comments, commits, and related issues using gh CLI. Creates organized review workspace, analyzes code against industry-standard criteria, and optionally adds inline comments to the PR.
babysit-pr
by openai
Babysit a GitHub pull request after creation by continuously polling review comments, CI checks/workflow runs, and mergeability state until the PR is merged/closed or user help is required. Diagnose failures, retry likely flaky failures up to 3 times, auto-fix/push branch-related issues when appropriate, and keep watching open PRs so fresh review feedback is surfaced promptly. Use when the user asks Codex to monitor a PR, watch CI, handle review comments, or keep an eye on failures and feedback on an open PR.
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.
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 via the stamphog label, 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.
query-clickhouse-via-metabase
by PostHog
Run ClickHouse system.query_log analysis via the internal Metabase API. Use when investigating slow queries, materialization candidates, per-team query performance, ClickHouse cost or memory issues, or any system.query_log question. Covers prod-us and prod-eu, SSO-gated cookie auth via hogli, and ready-to-run query patterns.
qa-frontend
by PostHog
Internal PostHog developer frontend/browser QA skill. Use only when a PostHog developer explicitly asks to run frontend QA, browser-test a PR, verify a UI flow against the local PostHog stack, use qa-frontend, or QA current frontend changes with browser/runtime evidence. Do not use for generic code review, PR review, "check my changes", CI debugging, or security audit; use qa-team, debugging-ci-failures, or security-audit instead. Runs in PR mode or local mode, plans adaptive browser and visual checks, drives browser MCP/tooling such as Playwright MCP or Chrome DevTools MCP, captures evidence, and applies only approved/narrow fixes.
writing-code-comments
by PostHog
Gates whether a code comment should exist and forces the ones that stay to explain why, not what. Use ALWAYS before writing or editing a comment in any language (Python, TypeScript, Go, Rust, SQL), and when reviewing a diff that adds comments. Removes the comment types that clutter the codebase: narration that restates the code, change-history and chat-context notes ("previously did X", "per PR #123", "AI:"), perishable measurements and current-state stamps ("~20 min build", "currently", "today"), commented-out code, and redundant docstrings. Keeps the ones that earn their place: a non-obvious why, a warning about a non-local consequence, a pointer to context a future reader can't reconstruct. Not for user-facing copy (see /writing-user-facing-copy) or commit messages.
splitting-oversized-modules
by PostHog
Split an oversized Python module (a thousand-plus-line logic.py, models.py, api.py, or its test file) into a package of one module per concern, mechanically and provably without changing behavior. Use on a request to split / break up / decompose a god module or move functions out of one, once a human has agreed to split one before some other change, or before restructuring code inside a module already over roughly a thousand lines — breaking up a long function or extracting helpers in place leaves everything in the same file, so check the worth-it gate and propose the split first. Covers that gate, assigning symbols to concerns with an acyclic dependency graph, the AST plus tokenize move script, and proving the result is a pure move. Python only — for frontend files use writing-ui-components. Not for extracting a shared helper into common/, and not for moving code between products, which is isolating-product-facade-contracts.
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.
autoresolving-pr-conflicts
by PostHog
Operating procedure for the conflict-autoresolver agent: sweep open PostHog/posthog PRs that conflict with master, resolve the trivial conflicts (generated artifacts deterministically, source conflicts with judgment), land one merge commit on the PR head, and flag everything else for a human. Use when running as the scheduled conflict autoresolver, when asked to sweep or auto-resolve merge conflicts against master, or when asked to bring a conflicting PR up to date without rewriting its history. Trigger terms: conflict sweep, autoresolve, merge conflicts, conflicting PRs, bring PR up to date, restack. Operators setting up the automation itself: see references/routine-setup.md.
writing-user-facing-copy
by PostHog
Sets the voice and word choices for any text a person reads in PostHog: UI labels, buttons, tooltips, empty and error states, notifications, in-app messages, onboarding, docs, and support replies. Use ALWAYS before writing or editing user-facing copy, and whenever a code change adds or changes a string a user will see. Enforces a humane, neutral tone: no editorializing, no sales-y or edgy one-liners, no em-dashes (use hyphens or rewrite), sentence case, plain language. Also carries feature-naming rules that are easy to get wrong, most importantly how to talk about the Wizard (name it "Wizard" once, then call it "the setup agent" / "the agent"). Not for internal code comments, commit messages, or variable names.
triaging-web-analytics-support
by PostHog
Triage web analytics support tickets end to end: enumerate open tickets from the in-app conversations product and their Zendesk mirrors, classify each into a diagnostic shape (frontend crash, "two numbers don't match", traffic count drop, tracker not loading / undercounting vs a competitor, ad-platform integration error, channel type misclassification), run the matching playbook, and produce reply drafts plus fix PRs where warranted. Use when asked to triage the web analytics support channel, investigate a web analytics Zendesk or conversations ticket, or explain metric discrepancies a customer reported. Internal-only: queries cross-customer support and usage data; never copy customer names or their traffic numbers into public artifacts (PRs, issues, commits).
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.
project-artifact
by anthropics
Generate and publish a project status artifact — an opinionated, tabbed status page for a project too big for one update (overview & success criteria, the workstream sequence, next steps, plus background, plan, risks & open questions, and decisions/FAQ when they earn a tab) — published with the built-in Artifact tool to a default-private claude.ai page the user can share with teammates. Use when a piece of work spans several workstreams and you want a shareable overview kept current. Each artifact is backed by a small per-project config in the plugin data dir, so refreshing it re-gathers live state, redeploys the same URL, and reports only the delta. For software projects whose workstreams are PRs, also read swe.md (the X.Y PR-numbering convention; pulling PR state with gh/git; a per-PR detail block). Needs the built-in Artifact tool (claude.ai login). Not for single-PR changes or public docs.
r-econometrics
by brycewang-stanford
Run IV, DiD, and RDD analyses in R with proper diagnostics
peer-review
by brycewang-stanford
"Systematic peer review toolkit. Evaluate methodology, statistics, design, reproducibility, ethics, figure integrity, reporting standards, for manuscript and grant review across disciplines."
stata-data-cleaning
by brycewang-stanford
Clean and transform messy data in Stata with reproducible workflows
stat-writing
by brycewang-stanford
End-to-end statistical writing assistant for LaTeX - draft title/abstract/keywords, expand outlines into sections, audit manuscripts, write reviewer reports and response letters, and scaffold book manuscripts.
review-paper
by brycewang-stanford
Comprehensive manuscript review covering argument structure, econometric specification, citation completeness, and potential referee objections
submission-guide
by brycewang-stanford
This skill covers academic journal submission, referee responses, and revision management. Use when the user is preparing a manuscript for submission, formatting for a specific journal, responding to referees, or managing revisions. Triggers on "submit", "referee", "revision", "R&R", "response letter", "journal", "formatting", "submission", "resubmit", "cover letter", "referee report", "revise and resubmit".