Menu
Write a playwright test, make sure it runs, and is not flaky.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 version declaration, dispatch, pinning semantics, deprecation metadata, and migration scripts.
Implement and extend PostHog Data warehouse import sources. Use when adding a new source under products/warehouse_sources/backend/temporal/data_imports/sources, adding datasets/endpoints to an existing source, or adding incremental sync, resumable imports, webhook ingestion, pagination, credentials validation, and source tests.
Converts engineering analytics (PR / CI) data into saved PostHog insights, dashboards, and subscriptions, and explains what data the product reads so it can be queried directly with SQL. The engineering analytics dashboard and MCP tools run curated HogQL privately over per-team GitHub warehouse tables; this skill teaches discovering those tables via engineering-analytics-sources, replicating the curated column semantics in HogQL, reading the exposed engineering_analytics_* warehouse views where product logic is involved (CI cost, fingerprinted failure lines, commit attribution), saving the query with insight-create, and scheduling delivery with subscriptions-create. Use when asked to "save this as an insight", "put CI health / merge times on a dashboard", "email me PR throughput weekly", "chart CI cost", "track time to first review", "subscribe to these numbers", "alert on CI success rate", or "what data/tables/views does engineering analytics read". For ad-hoc CI and merge questions use diagnosing-ci-and-mer
How to add a new ingestion warning type to the event ingestion pipeline. Use when emitting a new warning from nodejs ingestion code (emitIngestionWarning, captureIngestionWarning, pipeline `warnings` arrays, `drop()` with warnings), when adding a warning type, category, or severity, or when a typecheck error says a string is not assignable to IngestionWarningType. Covers the INGESTION_WARNING_TYPES registry (the single source of truth for type, category, and severity), the details-key conventions that ClickHouse v2 materializes into columns, debouncing, and the downstream surfaces to keep in sync (v1 UI map, docs, v2 API).
Signals scout for PostHog web traffic. Watches per-channel session volume, attribution breakage, and landing-page health (bounce / 404 steps) against the site's own baseline, and files each validated divergence as a report in the inbox. Per-page web vitals have their own dedicated `signals-scout-web-vitals`.
Recommended repo-engineering guide when adding alerting to a PostHog product or extending the shared alerts platform. Routes lifecycle state machines, AlertPolicy, destinations, HogFunction dispatch, email, fixed-cadence scheduling, insight evaluation, and the AlertWizard. Use for product alert implementations, shared destination types, lifecycle or scheduling options, advanced alert settings, and platform alert infrastructure. Not for configuring alerts in an existing product.
| name | playwright-test |
| description | Write a playwright test, make sure it runs, and is not flaky. |
| allowed-tools | Bash, Read, Edit, Write, Glob, Grep, Agent, mcp__playwright__* |
Read @playwright/README.md for best practices, gotchas, and how to run tests.
You are to plan an end to end playwright test for a feature.
Use the Playwright MCP tools (e.g., mcp__playwright__browser_navigate, mcp__playwright__browser_click, mcp__playwright__browser_screenshot) to interact with the browser and plan your tests.
After your exploration, present the plan to me for confirmation or any changes.
BASE_URL='http://localhost:8010' pnpm --filter=@posthog/playwright exec playwright test <file name> --retries 0 --workers 3After all tests pass in the file, run with --repeat-each 10 added to the command. This will surface any flaky tests.
If any test fails across the 10 runs, treat it as a real failure: go back to Step 2, debug, fix, and re-run Step 3. Do not proceed to Step 4 until every run of every test passes.
Once all tests pass, output a single line: Testing Complete