最高评分
社区最喜爱的高星技能，质量有保障。
placing-product-frontend-code
PostHog
Decide which tree a frontend file belongs in — products/<name>/frontend/ or frontend/src/scenes/<name>/ — and explain why the boundary is real rather than stylistic. Use when adding a new scene, component, or logic file for a product; when creating a new directory under frontend/src/scenes/; when a product has UI in both trees and you need to know which side to extend; or when moving a scene into its product. Covers the merge-queue lane cost of the split, the measurement showing a dependency graph cannot substitute for the path signal, and a report script that shows how far each product's move has gone.
debugging-ci-failures
PostHog
Debugs failing GitHub Actions CI runs for PostHog PRs, commits, and branches, and answers broad CI-health questions ("is CI red?", "is master green today?", "what's broken right now?"). Use when the user asks why CI is red, asks for the current CI or master status, or mentions a failing check, GitHub Actions run, Depot runner, Depot CI run, workflow, job, shard, merge queue kick, flaky test, lint failure, typecheck failure, snapshot diff, migration check, generated types drift, or skills build failure. Interactive runs start with the hogli ci:insights digest (cross-run CI history from engineering analytics), then use read-only inspection, failure classification, the smallest local reproduction with hogli, and safe reporting without rerunning CI or posting to GitHub. Running unattended as the "Master-red diagnosis" workflow: see references/master-red-incident.md for its sandbox-compatible first step.
maintaining-python-tests
PostHog
Maintains existing pytest and Django test suites without weakening correctness. Use when asked to reduce Python test runtime or CI work, investigate slow pytest families, remove stale migration tests, consolidate repeated setup, improve Python test ownership, or measure whether a test optimization worked after merge. Ranks work by measured cost, applies the writing-tests value gate to existing coverage, preserves distinct behavior cases, validates isolation after shared-fixture changes, and separates testcase work from pytest-suite wall time. For an intermittent failure, use fixing-flaky-tests instead.
run-posthog
PostHog
Start, inspect, and drive the PostHog dev stack. Use for /run and /verify on this repo — when asked to launch PostHog, check whether the stack is healthy, inspect a running process, or verify a UI change against the live app.
depot-github-runners
PostHog
Configures Depot-managed GitHub Actions runners as a drop-in replacement for GitHub-hosted runners. Use when setting up or migrating GitHub Actions workflows to use Depot runners, choosing runner sizes (CPU/RAM), configuring runs-on labels, setting up ARM or Windows or macOS runners, troubleshooting GitHub Actions runner issues, configuring egress filtering, using Depot Cache with GitHub Actions, or running Dagger/Dependabot on Depot runners. Also use when the user mentions depot-ubuntu, depot-windows, depot-macos runner labels, or asks about faster/cheaper GitHub Actions runners. Not for Depot CI, the separate engine that reads .depot/workflows/ — that is the depot-ci skill.
auditing-llm-gateway-parity
PostHog
Audits services/llm-gateway against PostHog/ai-gateway and updates services/llm-gateway/PARITY.md from current implementation evidence. Use when either gateway changes auth, attribution, billing, endpoints, providers, models, routing, or metadata; when reviewing a Python gateway change; or when asked to refresh, verify, or report gateway parity. This skill updates the parity record but does not migrate callers.
managing-github-actions-secrets
PostHog
Creates and updates GitHub Actions secrets for PostHog workflows. Use when adding a new CI secret, rotating an existing secret, wiring a workflow to an API token, package registry credential, deploy key, or any value referenced via ${{ secrets.* }} in .github/workflows/.
triaging-merge-queue-failures
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.
announcing-behavior-changes
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).
triaging-web-analytics-support
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).
hogli
PostHog
PostHog developer CLI and repo tooling reference. Use when the user mentions hogli, asks about repo CLI tools, bin scripts, Makefiles, how to run/build/test/lint, or any dev environment commands.
improving-drf-endpoints
PostHog
Use when editing, reviewing, or auditing DRF viewsets and serializers in PostHog. Triggers on files in posthog/api/, products//backend/api/, products//backend/presentation/, or any file importing rest_framework. Covers field typing, schema annotations, enum collision fixes, and OpenAPI spec quality — everything that flows downstream into generated TypeScript types and MCP tools.
isolating-product-facade-contracts
PostHog
Plan and execute product isolation migrations to a facade plus contract layer in PostHog, following the Visual review architecture. Use when a product still exposes internals (models/logic/views) across boundaries and needs migration toward contracts.py + facade/api.py + presentation separation, with a PR strategy that minimizes review latency and conflicts with parallel work.
merging-prs
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.
django-migrations
PostHog
Django migration patterns and safety workflow for PostHog. Use when creating, adjusting, or reviewing Django/Postgres migrations, including non-blocking index/constraint changes, multi-phase schema changes, data backfills, migration conflict rebasing, and product model moves that require SeparateDatabaseAndState. Also use for any deletion or removal of a model, table, column, product, or app — including deleting migration files or retiring a feature — even when no migration is written.
building-product-empty-states
PostHog
Guide for adding a product setup empty state — the skippable first-run screen a product scene shows until real data arrives, built on the shared ProductEmptyState component. Use when adding an empty state or first-run/setup screen to a product scene, declaring emptyState on a SceneExport, writing a product setup-status detection logic, building an animated example-data preview widget, or deciding between the scene-level ProductEmptyState gate and an inline ProductIntroduction panel. Covers the productSetupStatusLogic single-layer contract, real-data detection rules, local-only skip semantics, wizard commands, and design tokens.
authoring-ci-workflows
PostHog
Use when adding or editing a GitHub Actions workflow, composite action, or reusable workflow under .github/ — new CI jobs, triggers, matrices, checkout/clone tuning, action pinning, GitHub App token auth, concurrency groups, timeout-minutes, paths filters, caching, or runner choice. Covers PostHog's workflow-authoring conventions and the reasons behind them: the 500-runs/10s dispatch cap, shallow vs full clone, per-SHA push concurrency, dedicated App-token rate-limit buckets, and fork-safe secrets on a public repo. Points to the linters (bin/hogli lint:workflows, actionlint) that enforce the mechanical rules, and to the narrower skills for production deploys, secrets, and Depot runners. Not for debugging red CI (use debugging-ci-failures) or wiring a new secret end to end (use managing-github-actions-secrets).
django-startup-time
PostHog
Keep heavy imports off the django.setup() path that every process (web, celery, temporal, migrate, shell, CI) pays for. Use when touching AppConfig.ready(), wiring signal receivers, editing the lazy API router (posthog/api/rest_router.py or its init.py shim), deferring a heavy import or profiling import time (importtime, hothog), when the startup-import-budget guard fails, or when merging master into a long-lived branch that made the router lazy.
implementing-mcp-tools
PostHog
'Guide for exposing PostHog product endpoints as MCP tools. Use when creating new or updating API endpoints, adding MCP tool definitions, scaffolding YAML configs, or writing serializers with good descriptions. Covers the full pipeline from Django serializer to generated TypeScript tool handler.'
optimizing-clickhouse-and-hogql-queries
PostHog
Workflow for optimizing ClickHouse and HogQL queries. Use when a HogQL query, query runner, insight, or report is too slow; when a hand-written ClickHouse query (via sync_execute or in a migration) is too slow; when ClickHouse times out or hits memory limits; when investigating a slow system.query_log row; or when reviewing a proposed HogQL printer change for performance. Covers extracting the ClickHouse SQL, common smells (FROM ... FINAL, JSONExtract over properties, missing skip indexes, self-joins, CTE blow-up), measuring against a real cluster, and applying the fix at the right layer (printer, query runner, or migration). Does NOT cover Postgres / Django ORM / app-database queries; for those use profiling-slow-api-endpoints.
warehouse-source-new-version
PostHog
Add support for a new vendor API version to an existing Data warehouse import source, or deprecate an old one. Use when a vendor ships a new API version (Stripe date versions, Shopify quarterly versions, header-pinned revisions, /vN/ URL bumps), when implementing a version-update or deprecation task for a source under products/warehouse_sources/backend/temporal/data_imports/sources, or when repinning an ExternalDataSource to a different version. Covers deciding whether a newly announced version needs supporting at all, version declaration, dispatch, pinning semantics, deprecation metadata, and migration scripts.
fixing-flaky-tests
PostHog
Guides an agent through reproducing, root-causing, fixing, and validating flaky tests in the PostHog monorepo. Use when a test fails intermittently in CI but passes on rerun or locally, when hogli ci:insights or the debugging-ci-failures skill classifies a failure as a flaky test, when given a GitHub Actions URL for a flaky job, when asked to check Trunk Flaky Tests for a test, PR, or master, or when asked to deflake, stabilize, or fix a flaky Jest, pytest, or Playwright test. Core discipline: reproduce locally before changing anything, fix the root cause (never mask it with sleeps, retries, or bigger timeouts), and prove the fix with an N-run validation loop sized to the observed failure rate. Stabilizing is not the only valid outcome — the skill also gates whether the test should exist, so deleting a test that catches nothing real, or re-leveling one that flakes because of the level it runs at, are first-class endings.
adding-personhog-rpc
PostHog
Guide for adding a new RPC to personhog-replica and personhog-router. Covers eligibility checks, proto definition, code generation for Python and Node.js clients, Rust implementation (storage trait, postgres queries, service handler, router wiring), and index compatibility validation. Use when adding a new gRPC endpoint to personhog, migrating a Django ORM query to personhog, or extending the personhog service API.
analyzing-experiment-query-performance
PostHog
Pull and interpret production experiment query-performance data from the staff-only /api/debug_ch_queries endpoints backing the /experiments/staff scene: slowest experiment queries, precompute read/build health, and preaggregation cache footprint. Covers prod-US and prod-EU via a query_performance:read personal API key, all query params, and response field semantics (exception codes, exposure paths, precompute skip reasons, job states). Use when investigating slow or failing experiment queries, precompute regressions, 307/159/241 errors, preaggregation table growth, or when asked how experiment query performance or the precompute rollout is doing in production.