posthog
- 183 skills
- 0 followers
- last month last updated
- ▌ Pixel Grid Draw · posthog bundleDraw 2D shapes (filled rectangles, outlined frames, ASCII bitmaps) on the 32×32 MCP pixel grid. Use this skill whenever the user asks to draw a square, rectangle, box, frame, outline, border, sprite, or other 2D shape on the pixel grid, or when the task involves placing a block or bitmap at specific grid coordinates. The pixel-grid MCP server only exposes a 1D `write(offset, bits)` primitive; this skill compiles a 2D drawing into the sequence of `write` calls that implements it.
- ▌ Merging Prs 2 · posthogMerge a PR into main through the Trunk merge queue and babysit it until it lands. Enqueue with a "/trunk merge" comment, then poll the "Trunk Merge Queue" check run and the PR state until it is MERGED or FAILED, reporting the Trunk bot's failure reason if the PR is kicked out. Use when asked to merge a PR, "merge when ready", "land it", "ship it", or to babysit/watch a PR through the queue. Never use `gh pr merge` in this repo -- the queue is the only path into main.
- ▌ Building React Quill Canvases · posthog bundleAuthor the React + Quill implementation of a PostHog canvas: the single-component contract, the allowed imports, Quill (PostHog's design system) component and composition rules, theme-aware design tokens, loading skeletons, and the in-canvas date picker. Use after building-canvases has routed a canvas request to a React implementation — dashboards, data boards, forms, tools, or any canvas that should look native to PostHog.
- ▌ Django Migrations 2 · posthogDjango 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.
- ▌ Authoring CI Workflows 2 · posthogUse 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).
- ▌ Building Canvases 2 · posthogCreate or edit a PostHog freeform canvas — a sandboxed browser application (data board, document, form, small tool, graphics experiment) stored in PostHog and rendered by the desktop/web app. Use when a task asks to build, generate, update, or fix a standalone canvas app, or when a freeform canvas id is given as the publish target. For grid/home canvases, widget placements, or reusable components, use composing-grid-canvases instead. Covers resolving or creating the target canvas, choosing an implementation approach (React + Quill vs plain HTML/browser APIs), the read → edit → validate → publish → build loop, and which companion canvas skills to load for the details.
- ▌ Validating And Publishing Canvases 2 · posthogValidate and publish a canvas source project safely: the source-project shape, declared capabilities, reading the current version pointer, iterating on validation diagnostics, guarded publishing with expected_current_version_id, staging a draft build and promoting it, waiting out the queued build, and recovering from a 409 version_conflict or a 429 capacity limit without overwriting concurrent work. Use whenever a canvas edit is ready to save, a draft build is wanted, a canvas publish or build returns diagnostics or a conflict, or a task needs to understand canvas version history.
- ▌ Add Resource · posthogAdd support for a new PostHog resource type (feature flag, cohort, action, survey, annotation, alert, …) to posthog-definitions. Walks through the eight files that must change, the tag-based identity convention, the load/diff/execute pipeline wiring, and the non-negotiable safety invariant. Use when the user wants to extend posthog-definitions beyond dashboards and insights.
- ▌ Result Vs Exceptions · posthogCode review guide for choosing between Result types and thrown exceptions. Recoverable, expected failures should be returned as Result values; only unrecoverable bugs and broken invariants should throw. Use when reviewing code that introduces a new error class, a new `throw`, a new `try/catch`, or a function whose failure path the caller is expected to handle.
- ▌
- ▌ Ducklake Test · posthogStart duckgres with DuckLake (S3-backed storage with PostgreSQL metadata) for local testing. Use when testing duckgres against DuckLake or reproducing Fivetran sync issues.
- ▌ Multitenant Up · posthogBuild, deploy, and port-forward the multi-tenant control plane on local Kubernetes. Use when you need to test duckgres in multi-tenant mode with per-team worker pools.
- ▌ Promote To Prod · posthogPromote the duckgres control-plane image to prod from the CLI — resolve the built image ref from the charts state file, fire the charts Promote-to-Prod workflow, and watch it through the approval gate. Use when the user says "promote duckgres", "ship the CP to prod", "roll prod", or asks which image ref to promote.
- ▌ Multitenant Down · posthogTear down the multi-tenant K8s stack, kill port-forwards, and clean up worker pods. Use when done testing multi-tenant mode.
- ▌ Openspec Explore · posthogEnter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
- ▌ Openspec Propose · posthogPropose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
- ▌ Openspec Apply Change · posthogImplement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
- ▌ Openspec Archive Change · posthogArchive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
- ▌ Ink Tui · posthog bundleBuild or modify the PostHog wizard's Ink screens, primitives, keyboard interactions, and session-driven screen flow. Use for TUI work in this repository.
- ▌ Wizard Development · posthog bundleArchitectural guidance for changes to the PostHog Wizard: program and framework boundaries, agent routing, gateway admission, security, and TUI state. Read before structural changes, then load the relevant procedural skill.
- ▌ Adding Skill Program · posthogAdd a PostHog wizard capability backed by context-mill content. Choose a skill command or native program, configure an orchestrator flow, and wire any required CLI, screens, or prerequisites.
- ▌ Exploring The Wizard · posthogDrive the PostHog wizard headlessly against a throwaway app through wizard-ci MCP tools, inspect decisions, and capture the real TUI. Use for detection checks and end-to-end exploration.
- ▌ Adding Framework Support · posthogAdd or extend language and framework support in the PostHog wizard, including detection, framework configuration, registration, and matching context-mill content.
- ▌ Make Pr · posthogCreate a GitHub pull request for the current branch using the gh CLI. Use when a user wants to open a PR and have the title, body, template, and assignee handled for them, following the repo's conventions and keeping public PRs free of PII.
- ▌ MCP Data Warehouse · posthog bundleBuild and run a curated layer of PostHog data-warehouse views (saved queries) with the view-* MCP tools. Covers the tool contracts (query JSON shape, edited_history_id, incremental settings, sync_frequency buckets), write-path mechanics (timeouts that still commit, inference limits, rename semantics), how to tier a layer (materialized bases, grain spines, live tops, naming, join keys, materialization order, declared vs effective cadence, staleness), HogQL traps that give wrong numbers silently (LEFT JOIN type defaults, NULL NOT IN, JSON nulls, the 100-row default limit), workflows (create, change, add or rename a column, rename a view, change cadence, debug staleness, retire), and a template for documenting a layer as its own skill. Use when creating or materializing views over MCP, structuring views into a layer, debugging a stale view or a wrong number, or changing a schedule. Trigger on 'create a view', 'materialize', 'saved query', 'view is stale', 'sync_frequency', 'warehouse view layer'.
- ▌ My Inbox · posthog bundleDaily driver for the PostHog Self-driving Inbox: a live in-flight table of the reports you are a suggested reviewer on, each mapped to its GitHub PR and issues with age, review and CI signals, and one next action; a ranked list of reports ready for Create PR; and a small working set of the reports you own. Covers picking up a report (claiming it, attaching its PR), checking a linked PR, drafting PostHog tasks that push a stalled PR over the line, closing reports out, and keeping HANDOVER.md current between sessions. Use when someone says "my inbox", "inbox triage", "what inbox reports need me", "check my inbox PRs", "pick up this report", or at the start of a session touching in-flight inbox reports. Companion: the inbox-exploration skill that ships with the PostHog MCP (report mechanics; load it when acting on a report).
- ▌ Skills Spec · posthogReference for the Agent Skills format specification (agentskills.io) — the open SKILL.md format used by Claude Code, Codex, Copilot, and other agents. Covers required frontmatter (name, description), optional fields (license, compatibility, allowed-tools, metadata), directory layout (scripts/, references/, assets/), progressive disclosure (~100-token metadata → <5000-token body → on-demand resources), description-writing rules, and links to the canonical source pages so you can re-check for spec evolutions. Use when authoring a new skill, reviewing or refactoring an existing SKILL.md, deciding what belongs in the body vs. a reference file, troubleshooting a skill that won't trigger, or any question about the agentskills.io spec, Anthropic's open skills format, or 'how do I write a SKILL.md'.
- ▌ Repo Dashboard · posthogSummarize what needs attention in one GitHub repository: open pull requests, the review queue, failing checks, stale work, and what merged recently. Use at the start of a work session to decide what to pick up next.
- ▌ Project Template · posthog bundleA starter kit for running one area of ongoing work as a living skill that agents and people share across sessions: a numbered issues/ backlog with an index, ideas/, open-prs.md, a sectioned HANDOVER.md each session overwrites, environment-notes.md for durable gotchas, field-feedback.md, roadmap.md, and a rolling-window CHANGELOG.md. It is the layout PostHog uses internally for its own scouts and self-driving backlogs, with a walkthrough of how those hubs are worked. Install it once per workstream (bind the project name and the changelog window), then use the installed skill to log an issue or idea, record or clear a PR, resume work in a fresh session, or triage the backlog. Trigger on 'log an issue for <project>', 'what is the state of <project>', 'resume <project> work', 'track this for <project>', 'end of session handover'.
- ▌ Skills Best Practices · posthog bundleHouse style and refactoring playbook for PostHog skills-store skills, layered on the Agent Skills spec (agentskills.io) and Anthropic authoring best practices. Covers the compliance floor (spec-checklist.md: frontmatter, name format, description under 1024 chars, body budget, single responsibility, link hygiene, no secrets), 16 house patterns (trigger-rich descriptions, thin index bodies, progressive-disclosure file maps, gotchas up front, HANDOVER.md clobber files, rolling-window CHANGELOG.md, where a fact belongs, references/, investigations/, issues/, recipes/, companions, posture, maintenance contracts), a smell checklist with an audit-to-log refactoring workflow, and reliable write mechanics (smallest edit primitive, base_version chaining, round-trip checks). Use when refactoring or auditing a store skill, creating one, splitting a bloated body into files, or fixing a changelog that grew unbounded. Trigger on 'clean up this skill', 'audit my skill', 'new skill', 'rotate the changelog'.
- ▌ Web Analytics Triage · posthog bundleInvestigate a sudden change in web traffic. Use when a user reports a spike or drop in pageviews, sessions, or conversion and wants to find the likely cause (channel, device, referrer, or release) before escalating.
- ▌ Dynamic Workflows · posthogHow to write JavaScript workflow scripts for the `workflow` tool - fanning work out across many isolated subagents with agent(), parallel(), and pipeline(), then synthesizing one result. Use when a task decomposes into several independent investigations or changes (codebase audits, many-file analysis, wide research, multi-perspective review, applying the same edit across many independent files).
- ▌ Subagent Orchestration · posthogHow and when to delegate work to subagents via the `subagent` tool (Explore, Plan, General). Use when a task involves codebase recon, implementation planning, or actual code changes that would benefit from an isolated context window instead of doing it all inline.
- ▌ Quill Code · posthogEdit the @posthog/quill design system locally and consume the change in this repo (posthog-code) before it is published to npm. Use when changing quill components/primitives/tokens, when a quill change must be tested inside the Code app, or when the user mentions quill, the design system, the .local-quill tarball, or the @posthog/quill pnpm override.
- ▌ Canvas Templates · posthogHow PostHog "canvas" dashboards work end-to-end — the two rendering tiers (json-render vs freeform React-in-iframe), the agent system prompts that steer each, and the RIGHT way to fetch PostHog data (typed query nodes through ph.query, not hand-rolled HogQL). Use when changing canvas templates, the freeform sandbox, the ph.* data shim, canvas data fetching, or the agent prompts that build dashboards / web-analytics boards.
- ▌ Onboarding Videos · posthogAdd, replace, and optimize the looping demo videos in the onboarding "welcome" bento grid (packages/ui/src/features/onboarding). Covers the ffmpeg compression workflow (the scripts/optimize-onboarding-videos.mjs wrapper), the faststart + right-size best practices that keep playback smooth, the first-frame poster convention, and how to wire a new clip into WelcomeScreen. Use when onboarding demo clips feel laggy, when a clip is being added/swapped/re-recorded, or when posters and videos drift out of sync.
- ▌ Storybook Stories · posthogWrite Storybook stories for PostHog UI components. Covers the provider stack stories run inside, the key gotcha that tRPC/useHostTRPC queries never resolve in Storybook (so data-fetching components render empty), and the pure-presentational split that makes a component storyable. Use when adding or fixing a *.stories.tsx file under packages/ui.
- ▌ Test Electron App · posthogDrive the real running PostHog Electron app (live tRPC, workspace-server, real data) over CDP with agent-browser. Connect to the running app on port 9222, snapshot the accessibility tree to verify changes, click/type/navigate, and screenshot the actual desktop app only when explicitly asked. Use when asked to test, verify, dogfood, screenshot or interact with the running app. For regression specs use the Playwright E2E suite.
- ▌ MCP Servers · posthogInstall, configure, authenticate, and troubleshoot MCP (Model Context Protocol) servers for this agent. Use when the user asks to add/install/remove an MCP server, connect a tool like Linear/Sentry/Supabase/GitHub via MCP, set up mcp.json, or when MCP tools are failing or need OAuth login.
- ▌ Announcing Behavior Changes · posthogDecides 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`).
- ▌ Visualizing Change Over Time · posthogHelps PostHog engineers and agents pick the right chart when a request is about visualizing change over time, before/after comparisons, or period-over-period movement while building UI with @posthog/quill-charts (dashboards, reports, the mcp_analytics frontend, custom visualizations). Use when a user asks how something "changed", "moved", "grew", "dropped", "improved", or "regressed" between two points or periods, or mentions "before/after", "period over period", "week over week", "delta", "slope graph", "slopegraph", or comparing many series across two snapshots. Surfaces both the `SlopeChart` quill component and the native `ChartDisplayType.SlopeGraph` insight display as options.
- ▌ Querying Canvas Data · posthog bundleGet PostHog data into a canvas correctly: the host-injected `ph` SDK (loadInsight, query, capture, state, connectors, 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, live third-party data through the viewer's own connections (ph.connectors), and event capture from a canvas. Use whenever a canvas shows metrics, charts, tables, any PostHog data, or data from GitHub or an MCP server, or needs to send analytics events.
- ▌ Checking Member Access · posthogExplains what a member or a role can do in a PostHog project, using the access control MCP tools. Use when the user asks what someone can see or edit, who can edit dashboards or feature flags, why a member can or cannot open a dashboard, notebook or table, what a role grants, which properties are hidden from someone, or how the project's default access is set. Covers what each level means, how the stored rule, the enforced level and the inherited access relate, what the null values mean, which tool answers which question, and when the answer needs the role tools too.
- ▌ Cleaning Up Stale Feature Flags · posthogIdentify stale feature flags in a PostHog project and clean up the code that checks them. Use when the user wants to find, audit, or remove unused, fully rolled out, or abandoned feature flags. When the agent can read and edit a repository it performs the code cleanup itself: tested local changes, and one draft PR per flag when the user authorizes publishing. Agents without repository access generate a tailored cleanup prompt instead. Covers staleness detection, dependency checking, retained-path rules, and the code-first ordering. This skill does not archive or otherwise change a flag in PostHog.
- ▌ Scanning Experiments With Replay Vision · posthogProvisions a Replay Vision scanner scoped to one experiment's exposed sessions: sets `experiment_targeting` so the API derives the person-scoped exposure filter server-side, templates a prompt that stays comparable across variants, sizes credit spend against the experiment's own population, and creates the scanner disabled so its prompt can be previewed on real sessions before it sweeps. TRIGGER when: user wants Replay Vision to watch an experiment, asks to scan or analyze an experiment's recordings with AI, asks "what are users actually doing in the test variant", or wants a scanner scoped to an experiment's exposed sessions. DO NOT TRIGGER when: creating a general-purpose scanner not tied to an experiment (use creating-replay-vision-scanners), reading observations a scanner already produced (use exploring-replay-vision-observations), or manually browsing an experiment's recordings without AI analysis (use analyzing-experiment-session-replays).
- ▌ X Article · posthogConvert a posthog.com blog or newsletter post into a markdown file formatted for posting as an X (Twitter) Article. Strips frontmatter, promotes the title to an H1, remaps headings to X's two heading levels (subheadings + bold), downloads all post images into a numbered folder, and appends a subscribe CTA for newsletters. Use when the user wants to copy a post from contents/blog/ or contents/newsletter/ into X Article format.
- ▌ Post Newsletter · posthogConvert a Substack newsletter post into a native posthog.com newsletter file. Fetches the content from a Substack URL, formats it with correct frontmatter and markdown, applies internal links, and re-hosts its images on Cloudinary. Omits Substack-specific sections (byline, related texts, job posts). Use when the user provides a newsletter.posthog.com URL and asks to post it natively.
- ▌ Speaker Expertise · posthogTurn a person's PostHog PR history into tech-talk prep. Given a GitHub handle, produces a brief outline of their work, concrete talk topics with supporting detail, and a talk-worthiness score out of 10 for each topic. Use when someone asks "what should X give a tech talk on", "what is X an expert in", or wants speaker prep / topic ideas grounded in what a person actually shipped.
- ▌
- ▌ Competitor Data Verifier · posthog bundleVerify and update competitor product data by scraping competitor websites using WebFetch/WebSearch. Use when the user asks to verify, check, or update competitor information in competitorData files (like amplitude.tsx, mixpanel.tsx), or when they want to ensure competitor feature data is accurate and current. This skill systematically checks product features, pricing, platform details, and generates update recommendations with source URLs for verification.
- ▌ Signals Scout Your Scout · posthog bundleWhat this scout watches and the condition under which it files a report.
- ▌ Signals Scout Flag Debt · posthog bundleFinds feature flags whose decision is over but which are still evaluated in production – terminal rollouts left in place, or keys that no longer appear in any connected repo.
- ▌ Posthog Lead Scoring · posthog bundleScore CRM leads (HubSpot/Salesforce) by recent product usage and surface the warmest leads sales hasn't contacted yet, a product-qualified-lead list saved as a reusable PostHog insight. Use this whenever someone wants product-qualified leads (PQLs), a lead score based on product usage, the warmest leads to prioritize, engaged signups sales should call, or a usage-based ranking of leads joined to the CRM. Triggers on phrasings like 'which leads should sales call', 'product qualified leads', 'score my leads by usage', 'hottest leads we have not contacted', 'PQL list', or 'which signups are sales-ready'. Boundary: this ranks individual leads to action now. For analyzing which onboarding STEPS drive trial-to-paid conversion in aggregate, use posthog-onboarding-conversion. It sets up the HubSpot/Salesforce source if needed and builds the insight end-to-end.
- ▌ Signals Scout AI Cost · posthog bundleWatches cost per conversation for AI features and reports when it breaks from its recent norm while volume holds steady, attributing the change to a model, prompt, cache, or retry cause.
- ▌ Modeling Revenue Metrics · posthog bundleBuild reusable revenue models — MRR, ARR, gross revenue, new/expansion/contraction/churn, ARPU, LTV, and per-customer/per-account revenue — on either PostHog data-warehouse views (HogQL) or an external dbt project. Use when the user wants to model, define, or compute recurring revenue, monthly/annual recurring revenue, churn or retention of revenue, lifetime value, average revenue per user, or revenue by customer, cohort, product, or currency. On PostHog, build on the managed revenue_analytics_* views (revenue_item, mrr, customer, subscription, charge, product) fed by Stripe or custom revenue events — not raw Stripe tables — and normalize money with convertCurrency(). In dbt, stage the payment source and compute fct_mrr / fct_revenue_item / dim_customer marts with tests. Covers picking the right source, the subscription-config gotcha that leaves MRR empty, currency handling, and linking revenue to persons/groups. Read modeling-warehouse-foundations first for the view-vs-dbt mechanics.
- ▌ Signals Scout Dead End Pages · posthog bundleCustom Signals scout for state traps in gated flows. Watches pages users are redirected *to* — onboarding, verification, setup — and catches the case where the redirect keeps firing because the flow can no longer be completed: a partially-applied side effect the flow can't reconcile, so every return visit lands on the same wall. Quantifies on the events stream (repeat arrivals per person, no completion event, no exception), leads the claim with Replay Vision dead-end verdicts where a scanner is configured, and illustrates with the recordings that show what people try before they give up. Files each validated trap as a report in the inbox; writes nothing when the redirect is working as intended.
- ▌ Posthog Value Vs Engagement · posthog bundleCompare each account's ARR (from Salesforce/HubSpot) against its PostHog engagement score and flag the high-ARR, low-engagement accounts, saved as a reusable PostHog insight. Use this whenever someone asks whether their biggest accounts are actually engaged or happy, wants to compare account value against product usage, find at-risk revenue, spot big accounts that barely use the product, or map ARR against engagement. Triggers on phrasings like 'are our biggest customers actually using us', 'ARR vs engagement', 'which big accounts are at risk', 'high value low usage accounts', 'value-engagement matrix', or 'are our biggest accounts our happiest'. Boundary: this measures CRM-ARR versus engagement health. For expansion/upsell based on usage against PLAN LIMITS, use posthog-upsell-ready-accounts. It sets up the Salesforce/HubSpot source if needed and builds the insight end-to-end.
- ▌ Session Replay Masking · posthog bundleSet up Session Replay masking on the mask-first, allow-explicitly pattern. Masks everything by default, then proposes candidates to reveal and waits for explicit approval on each one. Never unmasks anything without being told to.
- ▌ Posthog Onboarding Conversion · posthog bundleRank the onboarding and activation steps that best predict a trial becomes a paying customer: build the onboarding funnel, flag who reached a first Stripe payment, and compare payers versus non-payers, saved as a reusable PostHog insight. Use this whenever someone asks which onboarding or activation steps lead to paid conversion, what converting trials do differently, which signup steps predict revenue, or where trials stall before paying. Triggers on phrasings like 'what makes trials convert', 'onboarding steps that lead to payment', 'activation actions that predict conversion', 'compare payers vs non-payers by onboarding', or 'where do trials stall'. Boundary: this analyzes the onboarding PATH to first payment in aggregate. For scoring and prioritizing which individual LEADS sales should contact, use posthog-lead-scoring. It sets up the Stripe source if needed and builds the insight end-to-end.
- ▌ Posthog Support Tickets Churn · posthog bundleTest whether support tickets predict churn with a three-way join of PostHog engagement, Zendesk/Intercom tickets and topics, and Stripe churn, ranking the support issues that precede the most lost revenue, saved as a reusable PostHog insight. Use this whenever someone asks whether support contact or tickets predict churn, which ticket topics lead to cancellations, which support issues cost the most revenue, or how tickets correlate with retention. Triggers on phrasings like 'do tickets predict churn', 'which support issues cause churn', 'tickets vs retention', 'support topics that lose revenue', or 'does contacting support mean they will leave'. Boundary: this requires support-tool data (Zendesk/Intercom). For churn warning signs from PRODUCT USAGE alone with no tickets, use posthog-pre-cancellation-behavior. It sets up the Zendesk/Intercom and Stripe sources if needed and builds the insight end-to-end.
- ▌ Posthog Upsell Ready Accounts · posthog bundleFind expansion-ready accounts by comparing each account's real product usage against its current Stripe plan limits and flagging accounts consistently near or over their limits while still on a lower plan, saved as a reusable PostHog insight. Use this whenever someone asks who to upsell, which accounts are outgrowing their plan, which accounts are hitting usage limits, upgrade or expansion candidates, or accounts on the wrong (too-small) plan. Triggers on phrasings like 'who should we upsell', 'which accounts are hitting their limits', 'expansion candidates', 'accounts on the wrong plan', 'usage vs plan limit', or 'accounts ready to upgrade'. Boundary: this flags expansion by usage-versus-plan-limits. For account health measured as ARR versus engagement (big accounts that barely use the product), use posthog-value-vs-engagement. It sets up the Stripe source if needed and builds the insight end-to-end.
- ▌ Modeling Warehouse Foundations · posthog bundleShared foundations for building reusable data models in PostHog, on either of two stacks: PostHog-native data-warehouse views / materialized views (HogQL, via the view-* MCP tools), or an external dbt project (sources.yml + staging/marts + schema tests) run against your own or PostHog's managed warehouse. Read before authoring any specific business model — covers the PostHog-vs-dbt decision, the view-create → view-materialize → sync_frequency workflow and the HogQL column-aliasing rule, the dbt project skeleton and the honest "no native dbt integration" picture, warehouse joins and star-schema dimensions, currency conversion with convertCurrency(), and checking/registering models in the data catalog for reuse. Companion to the domain skills modeling-revenue-metrics, modeling-conversion-metrics, modeling-activation-metrics, modeling-product-usage-metrics, and modeling-dimension-tables. Use when the user asks how to build a view, materialized view, or dbt model in PostHog, or which of the two stacks to use.
- ▌ Signals Scout Silent Failure · posthog bundleWatches the completion rate of one named core action for breaks from its own norm, and reports the likely cause – with swallowed exceptions as the first thing it looks for.
- ▌ Posthog Feature Revenue Impact · posthog bundleMeasure whether a specific feature rollout moved revenue: split users on feature-flag or experiment exposure and compare downstream Stripe revenue and retention between the exposed cohort and control, saved as a reusable PostHog insight. Use this whenever someone wants the revenue impact of an experiment or a feature they shipped, wants to tie a feature flag or A/B test to revenue and retention, or asks whether a rollout paid off. Triggers on phrasings like 'did the feature we shipped move revenue', 'revenue impact of our experiment', 'did the rollout pay off', 'compare exposed vs control on revenue', 'feature flag revenue lift', or 'A/B test revenue'. Boundary: this is a before/after causal test tied to a specific flag or experiment. For ranking which EXISTING features high-revenue customers already use, use posthog-features-drive-revenue. It sets up the Stripe source if needed and builds the insight end-to-end.
- ▌ Posthog Features Drive Revenue · posthog bundleRank a PostHog user's product features by the revenue of the customers who use them (joins Stripe MRR/invoices to feature-usage events) and save it as a reusable PostHog insight. Use this whenever someone asks which features their highest-revenue or best customers use most, wants revenue-weighted feature adoption, wants to tie existing feature usage to MRR/ARR, or wants to decide which features to invest in based on paying customers. Triggers on phrasings like 'which features drive revenue', 'what do our best customers use', 'revenue by feature', 'connect Stripe revenue to feature usage', or 'which features should we double down on'. Boundary: this ranks EXISTING features by adopter revenue, it is not a before/after test. For whether a specific rollout, experiment, or feature flag moved revenue use posthog-feature-revenue-impact; for revenue by acquisition channel or ad spend use posthog-acquisition-channels-retention. It sets up the Stripe warehouse source if needed and builds the insight end-to-end.
- ▌ Posthog Pre Cancellation Behavior · posthog bundleFind the shared product-usage warning pattern before churn: pull cancellation dates from Stripe or Chargebee and examine the roughly 30 days of activity before each one, saved as a reusable PostHog insight. Use this whenever someone wants an early-warning churn signal from behavior, asks what churning customers do (or stop doing) before they leave, how usage or activity changes before cancellation, or the usage drop that precedes churn. Triggers on phrasings like 'what do customers do before they cancel', 'pre-cancellation behavior', 'churn warning signs', 'how does usage change before churn', or 'leading indicators of churn'. Boundary: this is behavioral/usage-based churn prediction with no support data. If the question is specifically about SUPPORT TICKETS or Zendesk/Intercom predicting churn, use posthog-support-tickets-churn. It sets up the Stripe/Chargebee source if needed and builds the insight end-to-end.
- ▌ Posthog Acquisition Channels Retention · posthog bundleRank a PostHog user's first-touch acquisition channels by retained Stripe revenue and CAC payback, using ad spend from Google/Meta, saved as a reusable PostHog insight. Use this whenever someone asks which marketing channels or sources bring customers who retain, wants channel ROI by retained revenue, CAC or payback by channel, wants to decide where to shift ad budget, or which UTMs/campaigns bring lasting customers. Triggers on phrasings like 'which channels bring the best customers', 'channel ROI', 'CAC payback by source', 'retained revenue by channel', 'where should we spend ad budget', or 'which UTMs convert to lasting customers'. Boundary: this is about acquisition source and marketing spend, not in-product feature revenue (use posthog-features-drive-revenue) or experiment impact (use posthog-feature-revenue-impact). It sets up the Stripe and ad sources if needed and builds the insight end-to-end.
- ▌ Author Stepwise Skill · posthogScaffold a new context-mill skill that walks an agent through an ordered series of narrowly-scoped reference files. Works for any number of steps. Use when the user wants to add a docs-only skill where the agent must read each step in strict order, one at a time, with each step isolated, with clear endpoints, and no prefetching.
- ▌ Depot CI · posthog bundleConfigures 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.
- ▌ Skills Store · posthogDiscover and use shared team skills stored in PostHog. Use when the user asks to list, browse, load, or manage "shared skills", "team skills", or references the "skills store" / "skill store".
- ▌ Instrument Logs · posthog bundleAdd PostHog log capture to track application logs. Use after implementing features or reviewing PRs to ensure meaningful log events are captured with structured properties. Also handles initial OTLP exporter setup if not yet configured.
- ▌ Authoring Scouts · posthog bundleHow to author, edit, and adapt PostHog Signals scouts — the scheduled agents that scan a project and write reports into the Signals inbox. Use to customize a canonical scout (narrow its scope, retune thresholds, add disqualifiers), tweak a scout's schedule or dry-run posture, write a new scout for a surface the fleet doesn't cover, build a measurement scout that records structured output (an LLM-judge scoring a sample on a schedule — a custom metric no query can compute), or steer a scout without editing it by leaving it a note. Covers the scout SKILL.md anatomy, the report contract, the structured-output channel, the dedupe + scratchpad-memory conventions, scout notes, the per-team skills-store path vs the canonical in-repo path, and the test loop. Trigger on "write/edit/customize a signals scout", "new scout for X", "tune my scout schedule", "make a scout that watches <event>", "score/judge/measure X with a scout", "structured output from a scout", "leave a note for / give feedback to a scout".
- ▌ Exploring Scouts · posthog bundleHow to explore and make sense of PostHog Signals scouts — the scheduled agents that scan a project and write reports into the Signals inbox. Use when a user wants to understand what scouts they have, how each one is behaving, and whether the fleet is actually working. Covers surveying the fleet and its schedules, reading recent scout runs and drilling into a single run's reasoning, inspecting the durable scratchpad memory the fleet has built up, tracing a run to the reports it wrote or edited, and assessing a scout's health and performance over time (cadence, success rate, report rate, signal-to-noise). Read-only and exploratory — to write or tune a scout, use `authoring-scouts` instead. Trigger on "what are my scouts doing", "how is my <x> scout performing", "show me recent scout runs", "why did this scout find/report nothing", "what has the fleet learned", "explore scout run <id>", "is my scout working".
- ▌ Building Canvases · posthogCreate or edit a PostHog freeform canvas — a sandboxed browser application (data board, document, form, small tool, graphics experiment) stored in PostHog and rendered by the desktop/web app. Use when a task asks to build, generate, update, or fix a standalone canvas app, or when a freeform canvas id is given as the publish target. For grid/home canvases, widget placements, or reusable components, use composing-grid-canvases instead. Covers resolving or creating the target canvas, choosing an implementation approach (React + Quill vs plain HTML/browser APIs), the read → edit → validate → publish → build loop, and which companion canvas skills to load for the details.
- ▌ Debugging Surveys · posthog bundleDebug, support, and build PostHog Surveys across the backend and all five SDKs (web/posthog-js, iOS, Android, Flutter, React Native). Use whenever a Surveys support ticket is pasted ("survey not showing", "fewer responses than expected", "responses disappeared", "responses are incomplete", "only the first question was answered", "the user says they didn't mean to submit", "survey shows on wrong platform"), when diagnosing why a survey does or doesn't display, or when doing survey feature work that must ship across SDKs. Covers the eligibility pipeline, how a response actually gets stored (partial responses, branching, optional questions, auto-submit), cross-SDK feature parity, the known-cause catalog, read-only diagnostic queries, staff access, and the customer-reply style guide.
- ▌ Inbox Exploration · posthogExplore PostHog's Inbox and act on what it surfaces — the place where signal reports cluster into actionable issues and trends. Use when the user asks "what's in my inbox?", "what should I look at?", "which reports are actionable?", "what's PostHog flagged recently?", asks about a specific report by ID or title, wants to act on / fix / implement a report (turn it into a PR), wants to resolve, dismiss, or snooze a report, or wants to see which signal sources are configured. Covers listing, filtering, drilling into, and acting on reports, plus pointers to the deeper `signals` skill when raw signals or semantic search are needed.
- ▌ Signals Scout Apm · posthogSignals scout for PostHog distributed tracing (APM / OpenTelemetry spans). Watches per-service RED metrics for error-rate and latency regressions, new error signatures, and traffic cliffs.
- ▌ Instrument Metrics · posthog bundleAdd PostHog metric capture to track counters, gauges, and histograms. Use after implementing features or reviewing PRs to ensure key operations are measured, or when asked to add metrics, counters, or track a value over time. Also handles mirroring existing Prometheus/StatsD/OpenTelemetry metrics into PostHog and initial OTLP exporter setup.
- ▌ Signals Scout Logs · posthogSignals scout for PostHog logs. Watches for emerging and rate-shifted message patterns, volume bursts, severity-distribution shifts, service silence, and trace-correlated bursts.
- ▌ Analyzing Task Runs · posthog bundleAnalyze a completed PostHog task run for inefficiencies — environment failures, missing CLI tools, verbose commands, redundant work, wasted retries — and file evidence-backed findings through the report_insight tool. Use when a task asks to analyze a run, produce run insights or a task analysis, or review a run's efficiency from an attached run log. Covers the log query protocol (bounded jq queries over the raw JSONL), both log schemas, the finding taxonomy, and evidence verification.
- ▌ Signals Scout Tasks · posthog bundleSignals scout for PostHog Tasks. Watches delivery health — failing runs clustered by repository and error class, retry storms — and, on a slower rotation, recurring demand across human-authored tasks. Skips the scout fleet's own runs.
- ▌ Working With Skills · posthogBest practices for agents managing PostHog skills via the MCP `skill-*` tools — how to discover, read, create, update, and refactor skills efficiently, especially large skills with many bundled files. Use whenever you are about to call any `skill-*` tool, asked to author or edit a shared skill, or troubleshoot why a skill write was rejected. Pairs with `skills-store` (which covers the raw tool surface) by adding the decision-tree, efficiency, and pitfall guidance.
- ▌ Exploring Apm Traces · posthog bundleInvestigates distributed application performance using PostHog APM (OpenTelemetry span) data via MCP. Use when the user asks about service traces, slow HTTP/database spans, error spans, error-rate trends or spikes, latency distributions, trace IDs, or span attributes — not AI observability traces or product logs. Uses posthog:query-apm-spans, posthog:apm-trace-get, posthog:apm-spans-sparkline, posthog:apm-services-list, posthog:apm-attributes-list, and posthog:apm-attribute-values-list.
- ▌ Investigating Replay · posthogInvestigates a session recording by gathering metadata, person profile, same-session events, and linked error tracking issues in one pass. Use when a user provides a recording or session ID and wants to understand what happened — who the user was, what they did, what errors occurred, and whether there are related error tracking issues. Replaces the manual chain of session-recording-get, persons-retrieve, execute-sql, and query-error-tracking-issues-list.
- ▌ Filtering Bot Traffic · posthogIdentify, measure, and exclude bot / crawler / AI-agent traffic in PostHog web and product analytics using the traffic classification surface (the isLikelyBot / getTrafficType HogQL functions and the $virt_* virtual properties). Use when the user asks to "exclude bots", "filter out crawlers", "remove bot traffic from my numbers", "how much of my traffic is bots / AI crawlers", "is GPTBot / ChatGPT / Claude hitting my site", "break down traffic by human vs bot", or wants clean human-only counts in an insight or dashboard. For the real-time Live tab bot tiles, use exploring-live-traffic instead.
- ▌ Querying Posthog Data · posthog bundleRequired reading before writing any HogQL/SQL or calling execute-sql against PostHog. Use whenever the user wants to search, find, or do complex aggregations PostHog entities (insights, dashboards, cohorts, feature flags, experiments, surveys, hog flows, data warehouse, persons, etc.) and query analytics data (trends, funnels, retention, lifecycle, paths, stickiness, web analytics, error tracking, logs, sessions, LLM traces). Also the first stop for a governed business or telemetry measure (MRR, activation, billable usage, active organizations, failure rates): check the semantic layer (canonical metrics in system.information_schema.metrics) before deriving from raw events or a typed domain tool. Covers HogQL syntax differences from ClickHouse SQL, system table schemas (system.*), available functions, query examples, and the schema-discovery workflow.
- ▌ Signals Scout Surveys · posthog bundleSignals scout for PostHog surveys. Watches active surveys for score regressions, response- volume drops, abandonment spikes, and targeting drift, and aggregates open-text responses into recurring themes.
- ▌ Building HTML Canvases · posthogAuthor a PostHog canvas with semantic HTML, CSS, and direct browser APIs — documents, articles, generative graphics, 2D canvas and WebGL experiences, and focused experiments where React components add no useful structure. Use after building-canvases has routed a canvas request to a plain-HTML/browser-API implementation. Covers the thin component wrapper the current runtime requires, styling and theming without Quill, drawing surfaces, and animation/cleanup patterns.
- ▌ Instrument Integration · posthog bundleAdd PostHog SDK integration to your application. Use when setting up PostHog for the first time or reviewing PRs that need PostHog initialization. Covers SDK installation, provider setup, and basic configuration for any framework.
- ▌ Writing Streamlit Apps · posthogWrite Streamlit app source code that runs well in a PostHog sandbox — the posthog_apps.query() bridge for reading PostHog data, the packages baked into the sandbox image, caching and session state across Streamlit reruns, layout and chart patterns, and single-file app.py structure. Use when authoring or debugging the Python source of a PostHog Streamlit app, when a query inside an app fails, or when asked to "write a streamlit app that shows PostHog data".
- ▌ Debugging MCP Analytics · posthog bundleDebug, support, and build PostHog MCP Analytics — product analytics for MCP servers (the `@posthog/mcp` and `posthog.mcp` SDKs plus the mcp_analytics product). Use when MCP analytics data looks wrong or missing ("events aren't showing", "intent clusters are empty", "sessions are missing", "per-tool numbers look wrong"), when writing queries over `$mcp_*` events by hand, or when doing feature work on the SDKs, the dashboard and its query runners, the self-instrumented MCP server, the `wizard mcp-analytics` install command, or the in-app onboarding. Covers the repo map, the `$mcp_*` vocabulary and where each property comes from, the rules that silently corrupt metrics when ignored, the end-to-end pipeline and where each stage breaks, and which repo to change. For reading the data rather than fixing it, prefer the `exploring-mcp-*` and `improving-mcp-tools` skills.
- ▌ Managing Streamlit Apps · posthogCreate, deploy, and operate Streamlit apps in PostHog via the streamlit-apps MCP tools — create an app, set its source, start and stop its sandbox, poll status, list versions, delete, and share the app with humans via its PostHog URL. Use when asked to "create a streamlit app", "deploy a data app", "ship a dashboard app", "restart/stop my app", "why is my app not running", or "give me a link to the app".
- ▌ Setting Up Data Catalog · posthogPopulates and maintains a project's data catalog (semantic layer): canonical metrics, trust marks (certifications) on warehouse tables/views, and reviewed table relationships. Use when asked to set up / seed / bootstrap the data catalog or semantic layer, to catalog a project's metrics, to certify or deprecate data sources, to propose or review table joins, or to work through the proposal review queue. To *use* an existing catalog to answer a business-number question, see querying-posthog-data instead. Trigger terms: data catalog, semantic layer, canonical metric, certify table, deprecate source, relationship proposal, metric drift, review queue.
- ▌ Exploring MCP Tool Usage · posthogStarting point for exploring how a PostHog MCP server's tools are used — routes a broad question to the typed tool that answers it. Use when the user asks "how is my MCP doing?", "what should I look at?", "explore my tool calls", "who uses my MCP tools?", "what are agents doing with the MCP?", or pastes an MCP analytics URL without a specific question. Offers a menu of questions, each backed by a query tool, then hands off to the focused skill.
- ▌ Instrument Feature Flags · posthog bundleAdd PostHog feature flags to gate new functionality. Use after implementing features or reviewing PRs to ensure safe rollouts with feature flag controls. Also handles initial PostHog SDK setup if not yet installed.
- ▌ Instrument LLM Analytics · posthog bundleAdd PostHog LLM analytics to trace AI model usage. Use after implementing LLM features or reviewing PRs to ensure all generations are captured with token counts, latency, and costs. Also handles initial PostHog SDK setup if not yet installed.
- ▌ Signals Scout Web Vitals · posthog bundleSignals scout for Core Web Vitals (`$web_vitals`). Watches each page's p75 LCP / INP / CLS / FCP against Google's thresholds and its own history — poor-band pages, band crossings, sharp regressions — and dates each regression against deploys and flag rollouts.
- ▌ Exploring LLM Evaluations · posthogInvestigate AI observability evaluations — `hog` (deterministic code-based), `llm_judge` (LLM-prompt-based), and `sentiment` (user-message sentiment). Find existing evaluations, inspect their configuration, run them against specific generations, query individual results, and set up scheduled reports on an evaluation. Use when the user asks to debug why an evaluation is failing, surface common failure modes, compare results across filters, dry-run a Hog evaluator, prototype a new LLM-judge prompt, inspect sentiment classifications, or manage the evaluation lifecycle.
- ▌ Instrument Error Tracking · posthog bundleAdd PostHog error tracking to capture and monitor exceptions. Use after implementing features or reviewing PRs to ensure errors are tracked with stack traces and source maps. Also handles initial PostHog SDK setup if not yet installed.
- ▌ Signals Scout Experiments · posthogSignals scout for PostHog A/B experiments. Watches running experiments for validity threats — sample ratio mismatch, contamination, exposure stalls, mid-run flag mutations — and lifecycle drift.