skills/downloading-batch-export-files/SKILL.md
Export PostHog events, persons, or sessions on demand and download the resulting files. Use when the user asks to download/export raw PostHog data, create a one-off file export, fetch a Parquet or JSONLines export, or use the file_download_batch_exports API. Covers starting the export with MCP, polling completion, and downloading via the existing REST redirect endpoint.
npx skillsauth add posthog/ai-plugin downloading-batch-export-filesInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Use this skill when a user wants a one-off downloadable export of PostHog data. The export is started and monitored through MCP, but the final file download uses the existing REST endpoint directly.
| Tool | Purpose |
| ---------------------------------------------- | -------------------------------------------------------- |
| posthog:file-download-batch-exports-create | Start an on-demand export and return the run ID |
| posthog:file-download-batch-exports-retrieve | Poll the run status and return file IDs after completion |
Do not rely on a generated MCP tool for the /download/ endpoint.
That endpoint is a redirecting file download endpoint, so raw HTTP/download handling is the right interface until MCP has explicit redirect support.
Ask a short clarifying question if the user did not specify the required inputs:
model: one of events, persons, or sessionsdata_interval_start and data_interval_end: ISO 8601 datetimes; the range must be at most one weekfile.format: Parquet or JSONLines; prefer Parquet for compact analytics exports and JSONLines for line-oriented text processingfile.compression: optional, one of zstd, gzip, brotli, lz4, or snappy. If JSONLines was chosen as format, only gzip and brotli are supported.file.max_size_mb: optional maximum part size in MB; set this when the user wants multiple smaller files instead of a single (potentially large) file.For events, include and exclude are optional event-name filters.
Use them only when the user asks for specific events or wants to omit specific events.
Call posthog:file-download-batch-exports-create with the selected shape.
The response contains an id for the export run.
Example request:
{
"model": "events",
"file": {
"format": "JSONLines",
"compression": "gzip"
},
"include": ["$pageview"],
"data_interval_start": "2026-05-25T00:00:00Z",
"data_interval_end": "2026-05-26T00:00:00Z"
}
Call posthog:file-download-batch-exports-retrieve with the returned id.
Status handling:
| Status | Action |
| ------------------------------------------------------------------------- | --------------------------------------------- |
| Starting or Running | Wait briefly and poll again |
| Completed | Read the files array and download each file |
| Cancelled | Stop and report that the run was cancelled |
| Failed, FailedRetryable, FailedBilling, Terminated, or TimedOut | Stop and report the error field |
When Completed, the files array contains file UUIDs.
For single-file exports it usually contains one UUID.
For split exports, download every UUID unless the user asked for a specific part.
If required by the user, a running export can be cancelled by calling posthog:file-download-batch-exports-cancel-create with the returned id.
An export that has already finished or has already failed may not be cancelled.
After cancelling an export, the id may not be used anymore and the export must start again from the beginning. However, you may still use the id to retrieve the export status (which will always be Cancelled).
Use a direct authenticated HTTP request to the existing endpoint:
GET /api/projects/{project_id}/file_download_batch_exports/{run_id}/download/{part}/
part can be either:
files array returned by file-download-batch-exports-retrieveIf there is only one file, this also works without part:
GET /api/projects/{project_id}/file_download_batch_exports/{run_id}/download/
Let the HTTP client follow the redirect, or inspect the Location header if you need the temporary signed URL.
Use the same PostHog authentication context as other API calls.
Treat the result as a file download, not a chat response. Parquet is binary and must be written as bytes. JSONLines may still be large; save it to a file rather than pasting the contents unless the user explicitly asks for a tiny sample.
Use a filename that includes the model, run ID, and part identifier when possible, for example:
posthog-events-<run_id>-<part>.jsonl.gz
posthog-persons-<run_id>-<part>.parquet
Running after completion while file records are being created. Poll again instead of failing immediately.files; do not assume part 0 is enough.tools
Focused Signals scout for PostHog projects with web traffic. Watches the acquisition and site-health layer the web analytics product reports on: per-channel session volume diverging from the site's own rhythm (an acquisition source silently collapsing or surging), attribution breakage (paid/campaign traffic reclassifying into Direct or Unknown when tagging breaks), landing pages that break (bounce-rate steps, 404 spikes, entry-path cliffs), and page-performance regressions (web vitals p75 steps). Emits findings only when they clear the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet.
tools
Focused Signals scout for PostHog projects using session replay. Watches two promises the replay product makes: that sessions are actually being recorded (capture integrity — recording volume vanishing while site traffic doesn't), and that the friction evidence inside recordings gets seen (rage-click / dead-click clusters concentrating on a page or element, error-after-interaction cohorts, recurring replay vision themes nobody aggregates). Emits findings only when they clear the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet.
tools
Focused Signals scout for PostHog setup health. Reads the project's active health issues — the deterministic findings of PostHog's own health checks (no live events, outdated SDKs, missing reverse proxy, absent web vitals, ingestion warnings, failing data-warehouse models, and more) — and decides which are genuinely worth surfacing. Unlike a one-signal-per-issue push, it bundles kind-clusters into a single finding, weights by real blast radius (cross-referencing actual event volume and reach), and prioritizes issues an agent can resolve via the MCP. Emits only above the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet — no dependencies on other skills.
tools
Focused Signals scout for PostHog projects using feature flags. Watches the flag roster and the `$feature_flag_called` evaluation stream for contradictions between a flag's configured state and its real traffic: evaluation cliffs on healthy flags, ghost flags (code calling keys that no longer exist), response-distribution shifts with no corresponding flag edit, and flag debt (stale, fully-rolled-out, or dead flags still burning evaluations). Emits findings only when they clear the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet — no dependencies on other skills.