Menu
Operating without a UI โ MCP / IDE / Slack mode. How to compensate for missing client tools, how to be useful in a text-only chat. Load when the session client kind is NOT `posthog-code`.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Explore PostHog's Inbox and act on what it surfaces โ the place where signal reports cluster into actionable issues and trends. Use when the user asks "what's in my inbox?", "what should I look at?", "which reports are actionable?", "what's PostHog flagged recently?", asks about a specific report by ID or title, wants to act on / fix / implement a report (turn it into a PR), wants to resolve, dismiss, or snooze a report, or wants to see which signal sources are configured. Covers listing, filtering, drilling into, and acting on reports, plus pointers to the deeper `signals` skill when raw signals or semantic search are needed.
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.
How to author, edit, and adapt PostHog Signals scouts โ the scheduled agents that scan a project and write reports into the Signals inbox. Use when a user wants to customize a canonical scout for their own setup (narrow its scope, retune its thresholds, add disqualifiers), tweak a scout's schedule or dry-run posture, or write a brand-new scout from scratch for a specific use case (a custom event, a product surface no canonical scout covers), or steer a scout without editing it at all by leaving it a note. Covers the scout SKILL.md anatomy, the report contract, the dedupe + scratchpad-memory conventions, the scout-notes steering channel, the per-team skills-store path vs the canonical in-repo path, and the write-and-inspect test loop (with dry-run as an optional safety net). Trigger on "write/edit/customize a signals scout", "new scout for X", "tune my scout schedule", "make a scout that watches <event>", "leave a note for / give feedback to a scout", "tell the scouts about X".
Gates whether a code comment should exist and forces the ones that stay to explain why, not what. Use ALWAYS before writing or editing a comment in any language (Python, TypeScript, Go, Rust, SQL), and when reviewing a diff that adds comments. Removes the comment types that clutter the codebase: narration that restates the code, change-history and chat-context notes ("previously did X", "per PR #123", "AI:"), commented-out code, and redundant docstrings. Keeps the ones that earn their place: a non-obvious why, a warning about a non-local consequence, a pointer to context a future reader can't reconstruct. Not for user-facing copy (see `/writing-user-facing-copy`) or commit messages.
Sets the voice and word choices for any text a person reads in PostHog: UI labels, buttons, tooltips, empty and error states, notifications, in-app messages, onboarding, docs, and support replies. Use ALWAYS before writing or editing user-facing copy, and whenever a code change adds or changes a string a user will see. Enforces a humane, neutral tone: no editorializing, no sales-y or edgy one-liners, no em-dashes (use hyphens or rewrite), sentence case, plain language. Also carries feature-naming rules that are easy to get wrong, most importantly how to talk about the Wizard (name it "Wizard" once, then call it "the setup agent" / "the agent"). Not for internal code comments, commit messages, or variable names.
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.
| name | working-outside-the-console |
| description | Operating without a UI โ MCP / IDE / Slack mode. How to compensate for missing client tools, how to be useful in a text-only chat. Load when the session client kind is NOT `posthog-code`. |
| agents | ["agent-builder"] |
How to be useful when there is no UI โ load when the session
reports a non-PostHog-Desktop client kind (Claude Code, Cursor, MCP
Inspector, or any unknown shape) or when none of the focus_* /
toast client tools are in your tool surface. Without client
tools, every navigation has to happen in text.
| Capability | PostHog Desktop | MCP / IDE |
|---|---|---|
| User sees the artifact you're working on | Yes โ focus_* tools drive the panel | No โ the user sees only your text |
| User can context-switch by clicking | Yes โ they can wander | No โ the conversation IS the navigation |
| Status notifications | toast | A short line in the chat |
| Streaming partial output | Sometimes rendered nicely | Usually rendered as plain text |
| Approval requests | Inline buttons in the dock | A text instruction to take action elsewhere |
The biggest shift: the user has zero visibility into the
artifacts you call MCP tools against unless you put them in
text. A posthog__agent-applications-revisions-bundle-retrieve that
returns 5 files in PostHog Desktop can be opened in the panel; over
MCP, you have to summarize.
Every artifact you touch gets named in text. Slug, revision id, file path. The user copy-pastes these into their own tools (a browser at app.posthog.com, a curl) if they want to verify.
Reading
weekly-digest(idapp_abc123), live revisionr_xyz789, fileagent.md(87 lines, last edited 2026-05-12).
vs the PostHog Desktop-friendly equivalent:
Opening weekly-digest's live revision in the panel.
The MCP version pays for the extra words; the value is the user can act on the references without further round-trips.
When the user would have looked at the read panel, instead include the summary in your message. Trade tokens for context.
System prompt summary (3 sections, 87 lines total):
- Identity (1-12): "You are the weekly-digest agentโฆ"
- Job (13-50): walks through the digest flow, mentions $pageview / $autocapture
- Tone (51-87): casual, asks for ack at the end
Full file (paste to read)?
[contents on request]
Don't dump the file unprompted โ offer to.
In PostHog Desktop, you can fire multiple MCP calls in one turn because the user is watching the panel transitions. Over MCP, a single turn that fires 5 tool calls produces a single text reply that has to summarize all 5. Prefer:
Look at the session-start info event โ it reports the client kind. Treat it as a hint, not a contract:
The reliable signal is your own tool surface: if the focus_*
and toast client tools are present you're in PostHog Desktop; if
they're absent, you're not.
The MCP transport exposes things PostHog Desktop doesn't always:
Mcp-Session-Id header โ the connecting MCP client's
session id. Multiple chat-trigger sessions from the same MCP
connection share this. Useful when the user says "what was
that other session we just looked at?" โ you can list resources
filtered by their MCP connection.resources/list and resources/read โ agent sessions are
exposed as MCP resources (per agent-as-mcp-server.md ยง3).
The connecting client can read them directly without going
through chat โ encourage this for cases where the user just
wants the data.E.g. "show me the file tree visually" or "click that button". Be direct:
The file tree view is a PostHog Desktop-only thing โ you're connected via MCP. I can list the file paths in text instead:
- agent.md
- skills/triage-playbook.md
- skills/slack-thread-protocol.md
- tests/happy-path.json
Or, if you want the visual view, open PostHog Desktop โ weekly-digest โ bundle.
Don't pretend you can drive a UI that isn't there.
IDE clients render code blocks well. Use them for:
Keep them short. A 200-line agent.md is OK to paste; a 2000-
line custom tool source is not โ summarize and offer to walk
through a section.
Not in v0. When the agent grows a slack trigger and is invoked
in a Slack channel, the rules from working-outside-the-console
mostly apply (text-only) but with Slack-specific formatting:
*bold*, _italic_, code with single
backticks)Until the slack trigger lands, you won't see this client kind.