OverviewHistoryStatsSecurity
npx skills add ...
Documentation
SKILL.md
npx skills add posthog/skills --skill account-handover
Draft structured handover notes for transitioning a PostHog account from one TAM or CSM to another. Use this skill when a TAM needs to hand over an account, prepare a transition briefing, write handover notes, create an account summary for a new owner, or any request involving account transitions between TAMs or CSMs. Triggers on "hand over this account", "transition account to", "draft handover notes", "account briefing for new TAM", "prepare account transition", or when a TAM names an account and says they're leaving or reassigning it.
npx skills add posthog/skills --skill account-handover
Draft a structured handover document when transitioning a PostHog account from one TAM or CSM to another. The document gives the incoming owner everything they need to pick up the account without the customer noticing a gap.
Input: Account name (and optionally: reason for transition, any context the outgoing TAM wants to include)
Search for the account and pull everything relevant. Run these in parallel where possible.
Use vitally:find_account_by_name with the account name. If multiple results come back, ask the TAM which one. Then use vitally:get_account_full with detailLevel: "full" on the matching account ID.
From the account record, pull:
Use vitally:get_account_users on the account ID. For each user, note:
lastSeenTimestamp can be stale — PostHog event data is the truth for activity)Identify these roles from the contact list:
If the data doesn't make these roles obvious, mark them as "[TAM to confirm]" in the output. Don't guess.
Use vitally:get_account_notes and vitally:get_account_conversations on the account ID.
From the notes and conversations, build a timeline of key events:
Pay special attention to the last 90 days. The incoming TAM needs to know what's active right now, not just the full history. Separate recent context from historical context in the output.
Look through recent conversations and notes for anything unresolved:
Flag every open item clearly. These are the things that will make the transition feel broken if the incoming TAM doesn't know about them.
Run these queries in parallel via the query-run MCP tool. Every query must be scoped to the account's project — pass the organization_id (externalId from Vitally) as the project_id parameter in the query-run tool call so the events table only returns data for that account.
This shows whether usage is growing, flat, or declining — critical context for the incoming TAM.
Map the top events to PostHog products:
$pageview, insight viewed, dashboard viewed → Product Analytics$recording_viewed, recording analyzed → Session Replay$feature_flag_called (excluded from query but check separately if needed) → Feature Flags$ai_generation, $ai_span, $ai_trace → LLM Analyticserror tracking issue viewed → Error Trackingsurvey sent, survey shown → Surveys$export events → Data PipelinesCross-reference with the Vitally contacts from Step 1c. The most active users are who the incoming TAM should build rapport with first.
Query the billing report to understand spend patterns.
From the billing reports, extract:
Current spend breakdown by product (using Vitally forecasted MRR fields as a cross-reference):
product_analytics_forecasted_mrrsession_replay_forecasted_mrrfeature_flags_forecasted_mrrllm_analytics_forecasted_mrrerror_tracking_forecasted_mrrdata_warehouse_forecasted_mrrsurveys_forecasted_mrrenhanced_persons_forecasted_mrrSpend trend: Compare the last 3 billing reports to classify as growing, flat, or declining.
SDK breakdown (from billing report fields):
web_events_count_in_periodnode_events_count_in_period, python_events_count_in_period, go_events_count_in_periodios_events_count_in_period, android_events_count_in_periodflutter_events_count_in_period, react_native_events_count_in_periodThe SDK split tells the incoming TAM what the customer's tech stack looks like without having to ask.
Compile everything into the format below. Read references/handover-template.md for the full template with guidance notes.
Every section in the handover document should be clearly sourced:
Present the handover document with these sections. Use the template from references/handover-template.md as the structure.
Table format:
| Name | Role | Last Active | Relationship | |
|---|---|---|---|---|
| ... | ... | ... | ... | Champion / Decision-maker / Technical lead / [TAM to confirm] |
Include a note on who the outgoing TAM typically communicated with and through what channel (email, Slack, calls).
Chronological list of key events, split into:
Recent (last 90 days):
Historical:
This section relies heavily on TAM input. Present what the data shows, then leave clear prompts:
Based on the data, suggest:
[TAM to confirm] for anything the data can't answer. Relationship context, communication preferences, and verbal commitments live in the TAM's head, not in Vitally.lastSeenTimestamp is unreliable for activity. Always cross-reference with PostHog event data for "last active" dates.Once the handover document is generated, tell the outgoing TAM:
"This is the data-sourced draft. Please review each section — especially Relationship Context and Open Items — and fill in anything marked [TAM to confirm]. Once you've added your notes, this is ready to share with the incoming TAM/CSM."
If the outgoing TAM provides additional context, incorporate it into the document and regenerate the relevant sections.
SELECT event, count() AS cnt
FROM events
WHERE timestamp >= now() - INTERVAL 30 DAY
AND properties.$organization_id = '{externalId}'
AND event NOT IN (
'$feature_flag_called',
'$autocapture',
'$web_vitals',
'$dead_click'
)
GROUP BY event
ORDER BY cnt DESC
LIMIT 30SELECT
person.properties.email AS email,
count() AS event_count,
max(timestamp) AS last_active
FROM events
WHERE timestamp >= now() - INTERVAL 30 DAY
AND properties.$organization_id = '{externalId}'
AND person.properties.email IS NOT NULL
AND person.properties.email != ''
GROUP BY email
ORDER BY event_count DESC
LIMIT 15SELECT date, report
FROM postgres.prod.billing_usagereport
WHERE organization_id = '{externalId}'
ORDER BY date DESC
LIMIT 3