最高评分
社区最喜爱的高星技能，质量有保障。
authenticating-to-clickhouse
PostHog
Authenticate a new or changed service to ClickHouse with the rotating ch-podauth ServiceAccount token instead of a static password. Use when adding a service, sidecar, or container that reads or writes ClickHouse, adding a new ClickHouseUser, or hand-building a ClickHouse pool or client for a custom timeout or setting. Covers the token-aware default path (sync_execute, get_client), the rule that a custom pool must pass credential_provider or it silently stays on the static password, wiring the username so the user does not fall back to the default user, and the deploy-side companion in the charts repo. Not for converting an already-deployed user off a static password.
setting-up-support-slack-locally
PostHog
Connect a real Slack workspace to local PostHog Conversations (the SupportHog Slack app) so Slack messages become support tickets and replies post back. Use when the user wants to test the conversations Slack integration locally, hits "Support Slack OAuth client ID is not configured", gets a white screen or "Network error" on the OAuth callback, or asks how to set SUPPORT_SLACK_APP_CLIENT_ID / a tunnel for supporthog Slack events. Covers the Slack app + scopes, the SUPPORT_SLACK_* dynamic settings, and the key split: localhost for OAuth and the UI, a public tunnel only for inbound events.
depot-ci
PostHog
Configures and manages Depot CI, a drop-in replacement for GitHub Actions that runs workflows entirely within Depot. Use when migrating GitHub Actions workflows to Depot CI, running depot ci migrate, managing Depot CI secrets and variables, running workflows with depot ci run, debugging Depot CI runs with depot ci run list, depot ci status, depot ci logs, depot ci diagnose, or depot ci ssh, inspecting test results with depot tests or run artifacts with depot ci artifacts, checking workflow compatibility, or understanding Depot CI capabilities. Also use when the user mentions .depot/ directory, depot ci commands, or asks about running GitHub Actions workflows on Depot's infrastructure without GitHub-hosted runners. Also use when comparing what Depot CI and GitHub Actions report for a skipped, empty-matrix or continue-on-error job, or when working out whether a check run satisfies a required status check or a merge queue.
debugging-local-replay
PostHog
Debugs why session recordings aren't appearing in the local dev environment. Use when a developer reports that local replay ingestion isn't working, recordings aren't showing up despite /s calls, or the replay pipeline seems broken after hogli start. Covers the full local pipeline: SDK capture, Caddy proxy, capture-replay (Rust), Kafka, ingestion-sessionreplay (Node), recording-api (Node), SeaweedFS, and common failure modes like orphaned processes, stuck phrocs workers, and trigger misconfiguration.
integrating-with-posthog-ai
PostHog
'Wire a PostHog product surface into the PostHog AI agent from the frontend. Use when attaching scene or entity context, injecting instructions to steer the agent, reacting to the agent calling a tool, applying an agent edit back into an open form, or rendering a product tool card in a thread.'
working-with-charts
PostHog
Guides consumers of @posthog/quill-charts through chart selection, data, themes, sizing, and composition. Use when adding or changing a chart built with the package, including its axes, tooltips, legend, overlays, or interactions. Links to package examples and API docs. Does not cover product integration or library internals.
profiling-slow-api-endpoints
PostHog
Profiles slow PostHog API endpoints when the main cost is in Postgres or Python. Use when a screen, picker, or list is slow; a Django endpoint has high tail latency; a query plan changes with tenant size; or a proposed database fix needs production evidence. Covers APM traces, safe production EXPLAIN, representative measurements, implementation choices, tests, rollout, and post-deploy verification. For ClickHouse or HogQL latency, use optimizing-clickhouse-and-hogql-queries instead.
analyzing-experiment-precompute-canary
PostHog
Analyze the experiment precompute result-consistency canary across prod-US and prod-EU, deep-dive any issues, and produce an actionable report. Sweeps the canary's Prometheus health gauges in both regions, and when anything is unhealthy pulls the structured divergence/failure logs from Loki to reconstruct exactly which (team, experiment, metric) went wrong, by how much, and which class of divergence it is (stability vs correctness, and for correctness whether exposure counts or only values differ). Mechanism-level root cause needs ClickHouse and is out of scope — the skill hands off with precise drill-down steps. Use when the user asks to check / analyze / verify the experiment precompute canary, investigate a canary divergence or alert, or confirm precomputed experiment results are consistent in production. All data comes through the Grafana MCP (Prometheus + Loki) — no payload decryption, no ClickHouse.
adding-activity-logging
PostHog
Adds or changes activity logging (the audit trail) for a Django model in PostHog. Use when a model's writes must show in the Activity side panel or the advanced activity logs, when adding ModelActivityMixin, an ActivityScope, a model_activity_signal receiver, an activity describer, or field exclusions, when auditing which write paths of a model are logged, or when a change is missing from the activity log. Covers the receiver-module convention, writes the signal cannot see (QuerySet.update, bulk_create), the actor outside requests, and product models on a separate database. Trigger terms - activity log, audit log, audit trail, ModelActivityMixin, log_activity, changes_between, activity describer, who changed this.
cmux-cua
manaflow-ai
"Use only after the user explicitly asks for cmux Computer Use through the cmux-cua skill: drive real macOS apps from a cmux agent session via the bundled engine (accessibility tree + screenshots, click/type/scroll/drag, branded cursor), or explain its user-directed permission setup. Reading or discovering this skill is not consent."
organizing-conversations-code
PostHog
File layout for the conversations product. Use when adding, moving, renaming, or reviewing files under products/conversations/ — especially frontend components, scenes, helpers, and tests. Conversations React components live in their own folder under products/conversations/frontend/components/, never as loose files in components/ or at the frontend root. Expand this skill as more conversations layout rules land.
setting-up-devbox
PostHog
Starts, connects to, and troubleshoots a PostHog devbox, a remote Coder workspace for PostHog development that can also run the full stack, through hogli devbox:* commands. Use when asked to spin up or resume a devbox, open a shell or editor on it, run a command on it, mirror a local checkout to it (devbox:sync), run the PostHog app on it and share a link, clone, update, share, or free disk on a devbox, store gh or Claude Code tokens for it, or diagnose a failing devbox command (tailnet, DNS, Coder CLI version, SSH). Not for running the stack on the local machine or for changing the Coder template in posthog-cloud-infra.
adding-project-secret-api-key-auth
PostHog
'How to gate a PostHog API endpoint with project secret API key (PSAK) auth — a project-scoped, user-less service credential. Use when adding PSAK support to a viewset action, allowing a new scope for PSAKs, handling synthetic users (ProjectSecretAPIKeyUser), or choosing PSAK-aware rate throttles. Trigger terms: PSAK, ProjectSecretAPIKey, project secret API key, phs_ token, service auth, programmatic endpoint auth.'
running-ci-preflight
PostHog
Catch the deterministic CI failures reachable from your diff before pushing, with hogli ci:preflight. Use when the pre-push hook blocks a push, before reporting a task done, or after editing Python, serializers, migrations, workflows, or dependency manifests — to avoid burning a CI matrix on a failure you could catch locally (formatting, lint, broken lockfiles, OpenAPI drift, migration conflict, stale branch). Trigger terms: ci:preflight, preflight, pre-push checks, pre-push hook failed, "will this break CI".
using-kea-disposables
PostHog
'Use when adding timers (setInterval, setTimeout), event listeners (window.addEventListener, document.addEventListener, MediaQueryList.addEventListener), or any other resource that needs cleanup inside a kea logic. Every logic has cache.disposables.add(setup, key?, options?) and cache.disposables.dispose(key) available via the globally registered disposablesPlugin from the kea-disposables package. Replaces the bare cache.foo = setInterval(...) + beforeUnmount: clearInterval(cache.foo) pattern and auto-pauses background work when the tab is hidden.'
clickhouse-migrations
PostHog
ClickHouse migration patterns and rules. Use when creating or modifying ClickHouse migrations.
cmux-cloud-vm
manaflow-ai
"Operate cmux Cloud machines, run durable remote commands or agents, and present their workspaces or services. Use for cmux vm/cloud tasks; backend implementation belongs to cmux-backend."
extending-hobby-smoke-tests
PostHog
Design, extend, review, or debug PostHog Hobby end-to-end smoke tests in bin/hobby-ci.py and .github/workflows/ci-hobby.yml. Use when adding an ingestion round trip, deciding whether a product belongs in Hobby CI, changing the CI Hobby service topology or API-key scopes, or diagnosing a smoke test that captures data but cannot query it.
qa-frontend
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.
establishing-code-ownership
PostHog
Determine which PostHog team owns a file, directory, or code path, or enumerate all code a team owns (via distributed owners.yaml, products/*/product.yaml, and .github/CODEOWNERS). Use when assigning a reviewer, attributing a bug or slow query to a team, routing work, scoping a team-wide audit, or answering "who owns X" / "what does team Y own".
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.