skills/creating-ai-subscription/SKILL.md
Create a recurring AI-generated PostHog report — schedule a free-text prompt to run on a cron, with the LLM-synthesized markdown delivered to email or Slack on each tick. Use when the user wants a recurring AI summary of X on any cadence (daily, weekly, monthly, yearly) rather than a one-off report. (To attach an AI summary to an existing insight/dashboard subscription instead of a free-text prompt, see `managing-subscriptions` and its `summary_enabled` option.)
npx skillsauth add posthog/ai-plugin creating-ai-subscriptionInstall 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.
A subscription delivers a PostHog report to email or Slack on a recurring
schedule. There are three kinds, distinguished by which field you set — the kind is
derived and returned as the read-only resource_type:
insight — periodic snapshots of one existing insight (resource_type: "insight")dashboard — periodic snapshots of a dashboard's tiles (resource_type: "dashboard")prompt — a recurring AI-generated report from a free-text prompt: an LLM
plans and runs HogQL over the project's data and synthesizes a fresh markdown report
each tick (resource_type: "ai_prompt")Use this skill for the prompt kind — i.e. when the user wants a recurring AI
summary of X (on any cadence — daily, weekly, monthly, yearly) rather than a recurring
snapshot of one existing insight/dashboard, or a single one-off report. Pick a prompt subscription when the
value is the analysis itself (the LLM deciding what to query and writing it up),
not a fixed chart they already built. For an insight/dashboard subscription, set
insight/dashboard instead of prompt and the AI gates below don't apply.
This skill covers creating the subscription. Once it exists you manage its
lifecycle with the same subscriptions-* tools (see below): list it, edit/disable/
re-enable it, send a test delivery, or delete it.
| Tool | Purpose |
| -------------------------------------------- | --------------------------------------------------- |
| posthog:subscriptions-create | Create the recurring prompt subscription |
| posthog:subscriptions-list | Confirm it landed; inspect existing subscriptions |
| posthog:subscriptions-partial-update | Edit, disable (enabled: false), or re-enable it |
| posthog:subscriptions-test-delivery-create | Send an immediate test delivery to its target(s) |
| posthog:subscriptions-delete | Soft-delete it (stops all future deliveries) |
| posthog:integrations-list | Find a Slack integration_id (filter kind=slack) |
| posthog:integrations-channels-retrieve | List a Slack integration's channels (id + name) |
The endpoint enforces three create-time gates and will return 400 if any fails:
DEBUG=true — self-hosted production deployments are not
eligible (the LLM call routes through a PostHog-managed key).Org settings → Data → AI data processing. The user must opt in to AI features
for the organization first.If any of the three is missing, stop and tell the user which one to fix — re-calling the tool will not help.
Your access token also needs the query:read scope in addition to
subscription:write: a prompt subscription runs LLM-generated HogQL over the project's
data, so the backend requires query access to create, edit/re-enable, test-deliver,
or delete one. A subscription:write-only token is rejected with a 403.
prompt: "..." # ≤4000 chars; setting this (with no insight/dashboard) makes it a prompt sub → resource_type "ai_prompt"
target_type: "email" | "slack" # webhook is rejected for prompt subs
target_value: "..." # comma-separated emails, or "<channel_id>|<channel_name>"
frequency: "daily" | "weekly" | "monthly" | "yearly"
interval: 1 # 1 = every tick; 2 = every other tick; etc.
start_date: "2026-09-15T09:00:00Z" # anchors the recurrence + time-of-day; need not be in the future — the scheduler delivers the next occurrence
title: "..." # display name in the subscriptions list
There is no resource_type argument to send — the kind is derived
from which field you set (prompt ⇒ AI report) and returned as the read-only resource_type.
byweekday: ['monday', 'wednesday'] # weekly only — days the rrule fires
bysetpos: 1 # most useful with monthly; requires byweekday — e.g. byweekday:['monday']+bysetpos:-1 = last Monday
count: 10 # cap total deliveries
until_date: '2026-12-31T00:00:00Z' # stop on/before this date
integration_id: 42 # Slack only — required; from integrations-list (see "Slack target")
target_value must be <channel_id>|<channel_name> (the format the integration
returns). Build it in three steps:
posthog:integrations-list filtered by kind=slack → pick the Slack
integration's id.posthog:integrations-channels-retrieve with that id → pick a channel; it
returns each channel's id and name, which you assemble into target_value
as <id>|<name>.id as integration_id — the subscription is pinned
to one specific Slack integration so reconnections elsewhere don't accidentally
re-route deliveries.prompt: 'Top events week over week, with the biggest drops and any new failure modes called out.'
target_type: email
target_value: [email protected]
frequency: weekly
interval: 1
byweekday: ['monday']
start_date: '2026-09-14T08:00:00Z'
title: 'Weekly product pulse'
prompt: "Yesterday's sign-ups, where they came from, and any errors they hit during onboarding."
target_type: slack
target_value: 'C0123456789|growth-updates' # <channel_id>|<channel_name>; only the channel id is used, the name is cosmetic
integration_id: 42
frequency: daily
interval: 1
start_date: '2026-09-15T09:00:00Z'
title: 'Daily onboarding watch'
prompt to an insight sub is rejected. Pick the right kind at create time.prompt — already persisted on the row, or a
new one in the PATCH body (so bare {"enabled": true} works when the stored prompt
is still valid, but is rejected when the disable cause was an invalid prompt until
you supply a good one); and (2) the original creator is still an active user —
if that account was deactivated the sub cannot be re-enabled at all (no prompt will
help; re-create it instead).next_delivery_date is server-computed from the rrule. Don't try to set it
manually — it's read-only. The first delivery fires at the first start_date
occurrence that is at least a short buffer (currently ~15 minutes) in the future,
so a start_date only seconds ahead rolls to the next occurrence.subscriptions-list will return the new row. Confirm resource_type: "ai_prompt",
enabled: true, next_delivery_date is in the future, and prompt matches what
you sent. The first scheduled tick will run the planner → HogQL → synthesis
pipeline and email/Slack the rendered markdown.
data-ai
Signals scout for PostHog Tasks, the agent work items a project runs. Two lenses: delivery health (runs failing, clustered by repository and error class, and retry storms) every run, and on a slower rotation demand (recurring asks across human-authored tasks that point at a product gap). Skips the scout fleet's own run rows.
devops
Signals scout for the PostHog Conversations (support inbox) product. Watches the `$conversation_*` ticket-lifecycle events for support-delivery regressions — SLA breach-rate steps, first-response latency blowouts, backlog inflow-vs-resolution imbalance, and channel / assignment concentration — and files each dated regression as a report. Complements the per-ticket product-feedback signals the emission pipeline already fires; does not re-surface individual ticket content.
development
Populates 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.
tools
Investigate logs in a PostHog project: verify a service or deployment is healthy, explain an error spike, triage an incident, or understand what a log stream is saying. Use when the user asks to "check the logs", asks whether a service, deploy, release, or change is working or broke anything, asks why errors are up or what changed, or wants the root cause of failures visible in logs. Routes the logs MCP tools (services overview, pattern mining, before/after pattern diffing, bucketed counts, facets, raw rows) so investigations start from summaries instead of raw rows or hand-written SQL over the logs table.