On the 1st: every feature shipped last month in Linear or Jira, the share of active accounts in PostHog that used it, and the support tickets it caused.
Reads
You get
The card on the right is a sample. Yours shows your own numbers and updates in place every run.
What lands on your board
Of 1,240 active accounts in October, 34% used Bulk export and 2% used Saved views. Slack alerts reached 15% in 9 days and drew 9 support tickets.
Linear shows the project marked complete. PostHog has an event for it somewhere. Support has a few tickets that mention it. A month later nobody can say whether the feature was worth building, because the answer sits in three tools that never meet in the same meeting.
This skill is for the product manager who writes the monthly product review. On the 1st the agent lists the features shipped last month, looks up each one's event in PostHog using a map you set once, works out the share of active accounts that used it, and counts the Zendesk or Intercom tickets that name it. The card puts adoption and support load side by side per feature, so the review starts with "this one landed, this one did not, this one hurts".
Whichever you plan in. Linear: projects(filter: { completedAt: { gte: "<month start>", lt: "<next month start>" } }) for name, completedAt and url, plus issues with your feature label whose completedAt falls in the month. Jira: GET /rest/api/3/project/{key}/versions, keep versions with released: true and a releaseDate in the month, then fixVersion = "<name>" for the features in each.
The key is the feature name, lowercased and trimmed, looked up in the map the person set once in the skill's settings (bulk export = export_completed, or a flag key such as flag:saved-views). A feature with no entry is listed as "not mapped" and asks for one; never guess an event from its name.
Through the query API, run HogQL for the month: active accounts are SELECT count(DISTINCT $group_0) FROM events WHERE timestamp >= '<month start>' AND timestamp < '<next month start>' AND $group_0 != '', and feature accounts the same with event = '<mapped event>' and timestamp >= '<ship date>'. Use the group index for your account group type, or person_id without group analytics. For a flag, count $feature_flag_called with properties.$feature_flag = '<key>' and label it exposure, not use.
Whichever you use. Zendesk: GET /api/v2/search.json?query=type:ticket created>=<month start> "<feature name>", or tags:<feature tag> if you tag by feature. Intercom: POST /conversations/search with source.body ~ the feature name and created_at in the month. A ticket that names two features counts for the one with the longer name.
Adopted: 20% of active accounts or more. Low: under 5% after at least 14 days live. Painful: 5 or more tickets, whatever the adoption. Features live under 14 days are marked early. Post the card with days live, accounts using it, adoption and tickets per feature.
With BRIEFKIN_TOKEN set, the agent sends the result as one card that updates in place every run. Without it, you get the report in the chat.
Pick your agent, where the data comes from and how to schedule it; the commands below follow.
One command. It puts the SKILL.md in ~/.claude/skills and in ~/.agents/skills, which Codex, Cursor, Gemini CLI, Copilot CLI and OpenCode read too.
shellcurl -fsSL https://briefkin.dev/skills/posthog-shipped-but-unused/install | shAsk Claude Code:
promptRun the posthog-shipped-but-unused skillOr paste the prompt instead of installing:
promptList the features we shipped last month: Linear projects completed in the month and issues with our feature label completed in it (or Jira fix versions released in the month). For each feature, use this map to its PostHog event: <feature = event, ...>; tell me which are not mapped instead of guessing. In PostHog, count active accounts in the month (distinct $group_0 with any event) and accounts that fired the feature's event since it shipped, and give adoption as a share of active accounts. Count Zendesk or Intercom tickets created in the month that mention the feature name. Give each feature a verdict: adopted at 20% or more, low under 5% after 14 days live, painful at 5 or more tickets, early under 14 days. Show a table and tell me the one thing to do first.1st of the month at 9:00, from cron on any machine where Claude Code is signed in:
crontab0 9 1 * * claude -p "Run the posthog-shipped-but-unused skill"Add it with crontab -e. A laptop asleep at that time runs it when it wakes if you use launchd or Task Scheduler instead; GitHub Actions works for the API route.
Connect Briefkin once with curl -fsSL https://briefkin.dev/install | sh and every run lands on your board as a report card. How setup works
SKILL.md---
name: posthog-shipped-but-unused
description: "On the 1st: every feature shipped last month in Linear or Jira, the share of active accounts in PostHog that used it, and the support tickets it caused. Use when the user asks for this, or when it runs on a schedule."
---
# Shipped but unused: Linear releases, PostHog usage and support
On the 1st: every feature shipped last month in Linear or Jira, the share of active accounts in PostHog that used it, and the support tickets it caused.
Linear shows the project marked complete. PostHog has an event for it somewhere. Support has a few tickets that mention it. A month later nobody can say whether the feature was worth building, because the answer sits in three tools that never meet in the same meeting.
This skill is for the product manager who writes the monthly product review. On the 1st the agent lists the features shipped last month, looks up each one's event in PostHog using a map you set once, works out the share of active accounts that used it, and counts the Zendesk or Intercom tickets that name it. The card puts adoption and support load side by side per feature, so the review starts with "this one landed, this one did not, this one hurts".
## Two ways to get the data
Use the API or MCP route when you have an MCP server, a CLI or an API token for the app. Otherwise, if you can drive a browser the user is signed in to (Claude in Chrome, a Playwright or Chrome DevTools MCP server), use the browser route. Say which one you used.
## Route A: API or MCP server
### What you need
- A one-time map from feature name to PostHog event or flag key, kept in the skill's settings: the join depends on it, and the event must fire when the feature is used, not when its page loads.
- A PostHog personal API key with `query:read` (or the PostHog MCP server), and group analytics if adoption should count accounts rather than people.
- Read access to Linear (MCP server or `LINEAR_API_KEY`) or Jira, and to Zendesk or Intercom tickets.
If something is missing, say what and stop; do not invent numbers.
### Steps
1. **List what shipped last month** (Linear): Whichever you plan in. Linear: `projects(filter: { completedAt: { gte: "<month start>", lt: "<next month start>" } })` for name, `completedAt` and `url`, plus `issues` with your feature label whose `completedAt` falls in the month. Jira: `GET /rest/api/3/project/{key}/versions`, keep versions with `released: true` and a `releaseDate` in the month, then `fixVersion = "<name>"` for the features in each.
2. **Map each feature to its PostHog event**: The key is the feature name, lowercased and trimmed, looked up in the map the person set once in the skill's settings (`bulk export = export_completed`, or a flag key such as `flag:saved-views`). A feature with no entry is listed as "not mapped" and asks for one; never guess an event from its name.
3. **Work out adoption among active accounts** (PostHog): Through the query API, run HogQL for the month: active accounts are `SELECT count(DISTINCT $group_0) FROM events WHERE timestamp >= '<month start>' AND timestamp < '<next month start>' AND $group_0 != ''`, and feature accounts the same with `event = '<mapped event>'` and `timestamp >= '<ship date>'`. Use the group index for your account group type, or `person_id` without group analytics. For a flag, count `$feature_flag_called` with `properties.$feature_flag = '<key>'` and label it exposure, not use.
4. **Count the tickets that name each feature** (Intercom): Whichever you use. Zendesk: `GET /api/v2/search.json?query=type:ticket created>=<month start> "<feature name>"`, or `tags:<feature tag>` if you tag by feature. Intercom: `POST /conversations/search` with `source.body` `~` the feature name and `created_at` in the month. A ticket that names two features counts for the one with the longer name.
5. **Give each feature a verdict**: Adopted: 20% of active accounts or more. Low: under 5% after at least 14 days live. Painful: 5 or more tickets, whatever the adoption. Features live under 14 days are marked early. Post the card with days live, accounts using it, adoption and tickets per feature.
## Route B: the browser
### What you need
- Signed in to Linear or Jira, to PostHog with access to the project, and to Zendesk or Intercom as an agent who can search all tickets.
If something is missing, say what and stop; do not invent numbers.
### Steps
Start at https://linear.app/. The user is signed in already; never type passwords or codes, and ask if a sign-in page appears.
1. **List last month's shipped features**: In Linear, open **Projects**, filter by status Completed and read the completion dates for last month; then filter issues by your feature label and Completed in the same month. Jira users open the project's **Releases** page and read versions released in the month.
2. **Count active and adopting accounts in PostHog**: Open `https://us.posthog.com/` (or `eu.posthog.com`), **Product analytics**, new **Trends** insight. Set the date range to last month, series **All events**, and aggregate by unique organizations (or unique users) to get active accounts. Then switch the series to the feature's mapped event, from its ship date, for the accounts that used it.
3. **Count the tickets**: In Zendesk search `type:ticket created>` with last month's first day and the feature name in quotes, or in Intercom search conversations for the feature name with last month as the date range. Count tickets per feature.
4. **Give each feature a verdict**: Adoption is adopting accounts over active accounts. Adopted at 20% or more, low under 5% after 14 days live, painful at 5 or more tickets, early under 14 days. Report the table and the one thing to do first.
Note: Aggregating by organizations needs PostHog group analytics; without it the browser route counts people. Ticket search in both support tools matches the words anywhere in the ticket, so a common feature name can overcount; read a few results to check. For more than 5 features a month the API route is faster.
## The report
- **Features shipped** last month and the active accounts in the month.
- **Per feature**: ship date, days live, accounts using it, adoption, tickets, and a verdict (adopted, low, painful, early).
- **Not mapped**: shipped features with no PostHog event yet.
- The first thing to do, for example "Read the 9 Slack alerts tickets before announcing it wider".
## Post it to Briefkin
When `BRIEFKIN_TOKEN` is set, or `~/.config/briefkin/env` exists (the installer from https://briefkin.dev/docs writes it), also send the result to the user's Briefkin board as one card. Keep the `item_key` the same on every run so the card updates in place, use a new `event_id` per run, and put today's real numbers in place of the example ones. If the request fails, say so once and carry on.
```bash
[ -n "${BRIEFKIN_TOKEN:-}" ] || . ~/.config/briefkin/env
curl -sS -X POST "${BRIEFKIN_URL:-https://briefkin.dev}/v1/events" \
-H "authorization: Bearer $BRIEFKIN_TOKEN" \
-H "content-type: application/json" \
-d @- <<'JSON'
{
"v": 1,
"event_id": "posthog-shipped-but-unused/<date of this run, e.g. 2026-10-16>",
"item_key": "posthog-shipped-but-unused",
"project": "Acme",
"source": "Shipped but unused: Linear releases, PostHog usage and support skill",
"kind": "update",
"title": "3 features shipped in October: one at 34% of accounts, one at 2%, one causing 9 tickets",
"summary": "Of **1,240 active accounts** in October, **34%** used Bulk export and **2%** used Saved views. Slack alerts reached 15% in 9 days and drew **9 support tickets**.",
"widget": [
{
"type": "Table",
"props": {
"columns": [
"Feature",
"Shipped",
"Accounts",
"Adoption",
"Tickets",
"Verdict"
],
"align": [
"left",
"left",
"right",
"right",
"right",
"left"
],
"rows": [
[
"Bulk export",
"Oct 6",
422,
"34%",
1,
"Adopted"
],
[
"Saved views",
"Oct 14",
25,
"2%",
0,
"Low"
],
[
"Slack alerts",
"Oct 22",
186,
"15%",
9,
"Painful"
]
]
}
},
{
"type": "Bars",
"props": {
"unit": "%",
"items": [
{
"label": "Bulk export",
"value": 34
},
{
"label": "Slack alerts",
"value": 15
},
{
"label": "Saved views",
"value": 2
}
]
}
},
{
"type": "Callout",
"props": {
"text": "Read the 9 Slack alerts tickets before announcing it wider: 7 of them say the alert arrived twice.",
"tone": "warn"
}
}
]
}
JSON
```
Widgets come from the Briefkin catalog (https://briefkin.dev/v1/catalog). Without a token, just give the user the report.
## Run it on a schedule
Suggested: 1st of the month at 9:00 (`0 9 1 * *`). From cron, with the agent signed in on that machine:
```bash
0 9 1 * * claude -p "Run the posthog-shipped-but-unused skill"
# Codex: codex exec, Gemini CLI: gemini -p, Copilot CLI: copilot -p, OpenCode: opencode run
```
Or use the agent's own scheduler (Claude Code routines, Codex automations, Claude or ChatGPT scheduled tasks): https://briefkin.dev/skills/posthog-shipped-but-unused#schedule
Source: https://briefkin.dev/skills/posthog-shipped-but-unused
A one-time map from feature name to PostHog event or flag key, kept in the skill's settings: the join depends on it, and the event must fire when the feature is used, not when its page loads.
A PostHog personal API key with query:read (or the PostHog MCP server), and group analytics if adoption should count accounts rather than people.
Read access to Linear (MCP server or LINEAR_API_KEY) or Jira, and to Zendesk or Intercom tickets.
https://mcp.linear.app/mcp. Add Linear from Claude's connector directory, or run claude mcp add --transport http linear https://mcp.linear.app/mcp in Claude Code, and sign in with OAuth.LINEAR_API_KEY, and send it as the Authorization header with no Bearer prefix. For a workspace bot, an OAuth app with the read scope does the same job.When you create the key, give it Read access and only the teams in the report; it then can't create or edit issues.
https://mcp.atlassian.com/v2/mcp. In Claude, add the Atlassian connector from the directory; in Claude Code, run claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp and authenticate with /mcp. It signs in with OAuth 2.1 or an API token and respects your Jira permissions (getting started).acli jira auth login, acli jira workitem search --jql "sprint in openSprints()" --json returns the same issues from a terminal.JIRA_EMAIL, JIRA_API_TOKEN and JIRA_BASE_URL (https://acme.atlassian.net) and uses basic auth. A scoped token limited to read:jira-work and read:jira-user is narrower; scoped tokens call https://api.atlassian.com/ex/jira/{cloudId} instead of your site URL.A classic token can do anything your account can, so prefer a scoped token with read scopes only, or an account that just has Browse permission on the projects in the report.
https://mcp.posthog.com/mcp. Sign in with OAuth, or let the PostHog Wizard install it in your client; it routes to the US or EU cloud based on your account. Clients without OAuth can send a personal API key made with the MCP Server preset as a Bearer token (docs).POSTHOG_API_KEY with POSTHOG_PROJECT_ID and POSTHOG_HOST (https://us.posthog.com or https://eu.posthog.com), and give it the query:read scope, plus insight:read or feature_flag:read if the report uses them.Add ?readonly=true to the MCP URL (or send x-posthog-read-only: true) to drop every tool that creates, updates or deletes; on the API, read scopes alone do the same.
https://mcp.intercom.com/mcp (https://mcp.eu.intercom.com/mcp for EU workspaces; Australian workspaces aren't supported yet). Intercom is in Claude's connector directory for US workspaces, and on Team and Enterprise plans an Owner adds it. Its tools search and fetch conversations and contacts (docs).INTERCOM_ACCESS_TOKEN, and call https://api.intercom.io (api.eu.intercom.io or api.au.intercom.io by region) with an Intercom-Version header. Give the app Read conversations and Read and list users and companies.The MCP server includes a few write tools (internal notes, Help Center articles), so for unattended reports an app token with read permissions only is the tighter option.
ZENDESK_SUBDOMAIN, ZENDESK_EMAIL and ZENDESK_API_TOKEN and sends basic auth as {email}/token:{token}.read scope.An API token acts as the user who made it, with that agent's full rights; an OAuth token with only read can't update, assign or close tickets.
Feature names in Linear rarely match event names in PostHog, and a guessed match (a pageview of the settings page instead of the action itself) makes adoption look higher than it is. You set the map once in the skill's settings and add a line when a new feature ships; unmapped features show up on the card so none are skipped quietly.
Not on its own, which is why the card shows days live and marks anything under 14 days as early. The denominator is every account active in the month, so a feature from the 22nd has had less time to reach them; the next month's run gives it a full month.
No. The skill runs with your own agent and gives you the report in the chat. With a Briefkin token set, each run also posts it to your board as a report card, so you can glance at it instead of asking again.
Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot CLI, OpenCode, Windsurf and Amp all read SKILL.md files. The install command puts it in ~/.claude/skills and ~/.agents/skills, where they look. ChatGPT, the Claude app and Grok take the prompt instead. Pick your agent under "Install and run it" and the commands change to match.
Yes. Switch the data source to "Your browser" and the steps change to the Linear, Jira, PostHog, Intercom and Zendesk pages themselves: the agent opens linear.app in a browser you are signed in to and reads the numbers off the page. Claude Code, Codex, Cursor, Claude app and ChatGPT can drive a browser out of the box; Gemini CLI, Copilot CLI and OpenCode need a Playwright or Chrome DevTools MCP server first. It is slower than the API and needs you signed in, so it suits a report you run by hand or from a scheduler on your own computer.
Skills are free to use with any agent. Briefkin is where their results land: one board for every report, number and question your agents send, with a ping when something needs you.
Free during the open beta. No card.