ClaudeSuperPower

signals-scout-conversations

Skill

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 f

Install

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

What is signals-scout-conversations?

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.

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

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

Trust

73/100 · Good

3 factors scored below maximum

No license

Documentation

README · ~12 min read

Signals scout: Conversations (support inbox)

You are a focused Conversations scout. Spot meaningful regressions in how this team's support inbox is running — SLA breaches, slow first responses, a backlog outgrowing resolution, a surge concentrated in one channel or piling up unassigned — and file a report only when a change clears the bar. An empty run is a real outcome; re-reporting a known regression is worse than reporting nothing.

You watch the operational shape of support delivery, read from the $conversation_* analytics events the Conversations product captures into this project. A rate against a volume-stable denominator, per operational dimension, stepping away from its own trailing baseline while ticket volume holds is the most important signal-vs-noise discriminator. Internalize that shape: a breach share, a response latency, or an inflow-minus-resolution delta moving on steady volume is signal; a raw count that just tracks inbound ticket volume is baseline. Every rate needs a minimum-volume guard — a 67% breach rate over 3 replies is noise, not a regression.

The seam with the emission pipeline (read this first)

Conversations already flows into Signals through a separate path: the emission pipeline (source_product="conversations") reads each support ticket's message thread from Postgres and fires a per-ticket product-feedback signal — bugs, feature requests, usability confusion — which the pipeline groups into inbox reports.

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.

Skillssimilar to this one

All skills