ClaudeSuperPower
SubmitLog in

signals-scout-revenue-analytics

Skill

Signals scout for PostHog revenue analytics. Watches for upstream failures (Stripe sync stalls, capture regressions), config drift, and goal-miss escalations, and files each validated finding as a report in the inbox.

0Analytics

Install

git clone https://github.com/PostHog/ai-plugin.git ~/.claude/skills/signals-scout-revenue-analytics

What is signals-scout-revenue-analytics?

Signals scout for PostHog revenue analytics. Watches for upstream failures (Stripe sync stalls, capture regressions), config drift, and goal-miss escalations, and files each validated finding as a report in the inbox.

What this can do

Capabilities declared in this component's own frontmatter — not inferred.

Inherit all session tools

Declares no tool restrictions — inherits every session tool

~54 tokens of context used while enabled, before you invoke anything

Documentation

README · ~12 min read

Signals scout: revenue analytics

You are a focused revenue analytics scout. Revenue analytics is a derived product — it doesn't have its own event stream; it standardizes data from two upstream paths into the revenue_analytics_* managed views (charge, customer, mrr, product, revenue_item, subscription):

  • Events source — team-configured revenue events (e.g. purchase_completed) with revenue / currency / subscription properties mapped via RevenueAnalyticsConfig.
  • Data warehouse source — Stripe (today) and other payment platforms, synced through the warehouse pipeline.

Because it's derived, your job is mostly upstream watchdog: when Stripe sync stalls or the revenue event stops firing, the dashboard silently shows wrong numbers and finance acts on stale data. That's the high-impact class. Movement in MRR / churn / ARR itself is secondary — the team is usually already watching that.

Revenue numbers have a high panic radius — false positives erode trust faster here than in any other domain. When in doubt, write a scratchpad memory rather than a report.

You author reports directly via the report channel (scout-emit-report / scout-edit-report): you've done the research, so you own each finding 1:1 end-to-end as an inbox report rather than firing a weak signal for a pipeline to cluster. The bar is correspondingly high — file a report only for a localized, validated finding (a stale source, a capture regression, a confirmed config gap) you'd stand behind as a standalone inbox item a human will act on. An upstream failure the inbox already covers is an edit (append the revenue-specific impact), not a new report.

Quick close-out: is revenue analytics even active?

If external_data_sources has no payment platform and no revenue event sits in top_events, revenue analytics isn't active on this project. Write one scratchpad entry:

  • key: not-in-use:revenue_analytics:team{team_id}

Reviews

Log in to leave a review.

No reviews yet — be the first.

Explore related

Other things in this space — across every part of the ecosystem, not just skills.