adding-inbox-sources

Adds warehouse-backed signal sources to the PostHog Self-driving Inbox across three repositories.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill adding-inbox-sources
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: adding-inbox-sources
Source: https://github.com/PostHog/posthog-foss/tree/main/.agents/skills/adding-inbox-sources
Command: npx skills add https://github.com/PostHog/posthog-foss --skill adding-inbox-sources

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Adding a new signal source (Jira, GitLab, Sentry, Intercom, etc.) to the PostHog Self-driving Inbox requires coordinated changes across three separate repositories, and missing any one surface leaves the source unable to emit signals, appear in the UI, or be offered by the onboarding wizard.

Core Features & Use Cases

  • Backend scout emitter: Guides creation of a SignalSourceProduct enum value, migration, emitter module, and registry entry in posthog/posthog, including the JSON-blob table gotcha for sources like Jira.
  • Desktop UI wiring: Lists the ~8 files in posthog/code to update (type unions, toggle cards, setup forms, icons, filter options), favoring the generic DynamicSourceSetup renderer over bespoke forms.
  • Wizard onboarding: Explains the optional PostHog/context-mill changes so npx @posthog/wizard self-driving offers the new source, plus deploy ordering and created_via attribution.
  • Use Case: When asked to wire up GitLab as a self-driving inbox source, follow the checklists to land the backend enum migration first, then the Code UI PR, with correct payload keys verified against the warehouse source serializer.

Quick Start

Add Sentry as a new self-driving inbox source following the posthog and posthog/code checklists in this skill.

Frequently Asked Questions about adding-inbox-sources

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new source to the PostHog Self-driving Inbox?

Add a SignalSourceProduct enum value and migration in posthog/posthog, create an emitter module and registry entry, then wire the source-product unions, toggle card, and setup routing in posthog/code. Optionally update the context-mill wizard skill so onboarding offers the source.

What is the deploy ordering for a new inbox source?

The backend SignalSourceProduct enum must ship before the Code UI toggle, because createSignalSourceConfig rejects an unknown source_product with a 400. Land the posthog/posthog PR first, then the posthog/code PR, noting the dependency in the PR description.

Does a new OAuth source need a custom setup form?

No. DynamicSourceSetup renders oauth and oauth-account-select fields generically using the kind-parameterized integration router, so any provider in OauthIntegration.supported_kinds works without a bespoke form or per-kind service.

Why does a Jira-style emitter fail with the generic warehouse fetcher?

Some sources store data in a nested JSON fields blob instead of flat columns, so the emitter must use JSONExtractString expressions for both selected fields and the partition_field cursor. Verify the real column shape in the source's canonical_descriptions.py and confirm with an actual sync run.

Can multiple sources share one migration for SignalSourceProduct?

Yes, and they should. Batch all new enum values into one migration in a prep PR, because parallel PRs each adding a migration to the same model collide in the Trunk merge queue.