New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Official agent skill

Adding Inbox Sources

by PostHog in PostHog/posthog-foss

Add a new warehouse-backed source to the PostHog Desktop Self-driving Inbox (the feature that ships GitHub, Linear, Zendesk, pganalyze, Jira).

OfficialMITAuto-check passedProductivity & Automation

Install Adding Inbox Sources

skills CLI
$ npx skills add PostHog/posthog-foss --skill adding-inbox-sources -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install PostHog/posthog-foss adding-inbox-sources --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/PostHog/posthog-foss.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/adding-inbox-sources .claude/skills/adding-inbox-sources && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
adding-inbox-sources
GitHub stars
721
Token cost
~5.3k tokens
SKILL.md length
2,074 words
Files
1
Skills in repo
213
Repo updated
First seen
Licence
MIT

At a glance

Add a new warehouse-backed source to the PostHog Desktop Self-driving Inbox (the feature that ships GitHub, Linear, Zendesk, pganalyze, Jira).

  • Works in 2 steps: packages/agent/packages/agent-contracts/s… → packages/api-client/src/posthog-client.ts…
  • Asked to add a new inbox/self-driving source
  • SKILL.md covers Deploy ordering (do not skip), The setup form: use the…, Source catalog (Tier-1) and posthog/code checklist (per…, plus 6 more sections
  • Calls git, npx and pnpm

What it does

Adding Inbox Sources is an agent skill from PostHog/posthog-foss, published by the product's own GitHub organization. Add a new warehouse-backed source to the PostHog Desktop Self-driving Inbox (the feature that ships GitHub, Linear, Zendesk, pganalyze, Jira). A source syncs one warehouse table (issues/tickets/conversations) and a cloud "signals scout" watches it and emits findings. Use when asked to "add a new inbox/self-driving source", "wire up <Jira/GitLab/Sentry/Intercom/Freshdesk/Front/Gorgias/etc as a signal source", or to extend the source-toggle grid. Covers all three surfaces (posthog/posthog scout emitter +…

Its SKILL.md is about 5.3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Productivity & Automation, covering Email management. It works with PostHog, Jira, GitHub and Zendesk. The repository describes itself as: PostHog FOSS is a read-only mirror of PostHog, with all proprietary code removed. NOTE: This repo is synced automatically from the main PostHog repo. Please raise any issues and… The licence is MIT.

When your agent uses it

  • Asked to add a new inbox/self-driving source
  • Wire up <Jira/GitLab/Sentry/Intercom/Freshdesk/Front/Gorgias/etc as a signal source
  • Extend the source-toggle grid

Example prompts

  • “signals scout”
  • “add a new inbox/self-driving source”
  • “/adding-inbox-sources”

Requirements

  • Node.js

Workflow steps

2 steps, taken from the first numbered list in SKILL.md.

  1. packages/agent/packages/agent-contracts/src/inbox-types.ts — add "jira" to the SourceProduct union.
  2. packages/api-client/src/posthog-client.ts — add to SignalSourceConfig.source_product union; add a new source_type value only if the record…

What it can do on your machine

Read from SKILL.md and the folder at commit 2c48221. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • npx
    • pnpm
    • python
    • node

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, npx and pnpm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Adding Inbox Sources loads about 5.3k tokens when it runs. Until then it costs about 181 tokens; SKILL.md has 2,074 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~181
When it runs · the whole SKILL.md, loaded when a task matches
~5.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from PostHog/posthog-foss at commit 2c48221, republished under its MIT licence (© PostHog). 2,074 words, ~5,278 tokens.

Download SKILL.mdSave it as .claude/skills/adding-inbox-sources/SKILL.md (or your agent's skills folder).
name
adding-inbox-sources
description
Add a new warehouse-backed source to the PostHog Desktop Self-driving Inbox (the feature that ships GitHub, Linear, Zendesk, pganalyze, Jira). A source syncs one warehouse table (issues/tickets/conversations) and a cloud "signals scout" watches it and emits findings. Use when asked to "add a new inbox/self-driving source", "wire up <Jira/GitLab/Sentry/Intercom/Freshdesk/Front/Gorgias/etc> as a signal source", or to extend the source-toggle grid. Covers all three surfaces (posthog/posthog scout emitter + posthog/code UI wiring + the context-mill self-driving wizard skill that offers the source in `npx @posthog/wizard self-driving`), the deploy ordering between them, and created_via attribution.

Adding a Self-driving Inbox source

The Self-driving Inbox connects a PostHog data-warehouse source (GitHub, Linear, Zendesk, pganalyze, Jira today), syncs one "actionable records" table (issues / tickets / conversations), and a server-side signals scout in posthog/posthog watches new rows and emits findings/reports into the Code Inbox.

Adding a source touches three surfaces. The scout is not generic over arbitrary tables — it is driven by a static registry keyed on (source_type, table). The first two surfaces are mandatory (without them the source can't emit signals or be toggled in the app); the third is what makes the CLI self-driving wizard offer the source during onboarding.

This skill lives in posthog/posthog; the UI lives in the separate posthog/code repo; the wizard's onboarding script lives in PostHog/context-mill:

SurfaceWhat changes
posthog/posthog (this repo)New scout emitter + registry entry + SignalSourceProduct enum value (+ migration) + contract variant. The data-warehouse source itself must already exist (all Tier-1 sources do).
posthog/code~8 UI/wiring files: the source-product unions, toggle card, setup form, hook maps, icon, filter option (+ OAuth service/router only for OAuth sources).
PostHog/context-millThe self-driving skill's connected-tools list, so npx @posthog/wizard self-driving offers the source. Optional — skip it and the source still works everywhere else; the wizard just won't proactively suggest it. See "The self-driving wizard surface" below.

Backend work in posthog/posthog should be done in a git worktree (see "Worktree setup" below). Merges in both repos go through the Trunk merge queue — see the merging-prs skill.

Deploy ordering (do not skip)

The backend SignalSourceProduct choice must ship before the Code UI surfaces the toggle. The Code toggle calls createSignalSourceConfig({ source_product }), and the Django model rejects a source_product that isn't in its choices → 400.

So: land the posthog/posthog PR(s) first (or at least the enum migration), then the posthog/code PR. When opening both together, note the dependency in the Code PR description.

The setup form: use the dynamic renderer, don't hardcode

Do not hand-code a per-source setup form. PostHog Cloud serves each source's connect-form field schema over HTTP, and the app renders it generically via DynamicSourceSetup (packages/ui/src/features/inbox/components/DynamicSourceSetup.tsx). A new credential-based source needs zero form code — just route its DataSourceSetup switch case to DynamicSourceSetup with the capitalized sourceType and the schemas to sync.

  • Endpoint: GET /api/environments/{projectId}/external_data_sources/wizard/?source_type=<Type> → Record<string, SourceConfig>. Client method: PostHogAPIClient.getExternalDataSourceConfigs. Hook: useSourceConfig(sourceType).
  • SourceConfig.fields is a union: input (text/email/password/url/number/…), select, switch-group, oauth, oauth-account-select, ssh-tunnel, file-upload. DynamicSourceSetup renders input/select/switch-group and oauth/oauth-account-select generically, and builds the createExternalDataSource payload from field names. The backend is the single source of truth for field names/labels/required/secret, so forms never drift.
  • The field names become the payload keys — so you no longer hand-maintain them. (Jira → subdomain, email, api_token; all secret:false except the token.)

OAuth sources need NO bespoke form. DynamicSourceSetup renders the oauth field (a connect button that starts the flow by kind and polls getIntegrationsForProject for the new integration, writing its id into payload[<name>]) and the oauth-account-select field (a server-side-searched picker over the integration's resources) generically. The connect flow is started by the generic, kind-parameterized integration tRPC router (packages/host-router/src/routers/integration.router.ts → IntegrationService), so any provider in OauthIntegration.supported_kinds works with no per-kind service or router. So an OAuth source (Intercom, HubSpot, Salesforce, …) is the same one-registry-entry change as a credential source — route its DataSourceSetup case to DynamicSourceSetup.

Only two field types still lack a generic renderer (disable submit): ssh-tunnel and file-upload. Route those to a bespoke form. Resource pickers that must run after OAuth (GitHub's repo picker) are handled by oauth-account-select; the old GitHubSetup/ZendeskSetup /PgAnalyzeSetup hardcoded forms remain only for historical reasons — leave them or migrate to DynamicSourceSetup opportunistically; don't add new ones.

Supported OAuth kind values (posthog OauthIntegration.supported_kinds, posthog/models/integration/oauth.py): slack, salesforce, hubspot, google-ads, google-analytics, google-search-console, google-sheets, snapchat, linkedin-ads, reddit-ads, tiktok-ads, bing-ads, meta-ads, intercom, linear, clickup, jira, pinterest-ads, stripe (+ github via App install). A source not in this list must use the API-key form — its warehouse connector takes credentials directly, independent of the OAuth integration list. (Note: even Jira's warehouse source uses an API token, not the OAuth kind=jira.)

Source catalog (Tier-1)

source_type = the capitalized DWH type string passed to createExternalDataSource. Verify exact source_type + payload key names against the posthog external_data_sources serializer / the source's source.py at implementation time.

Productsource_typeTableAuthSetup templatepayload keys
JiraJiraissuesAPI tokenDynamicSourceSetupsubdomain, email, api_token
GitLabGitLabissuesAPI tokenDynamicSourceSetupgitlab_host, personal_access_token, project
SentrySentryissuesAPI tokenDynamicSourceSetupauth_token, organization_slug, api_base_url?
FreshdeskFreshdeskticketsAPI keyDynamicSourceSetupsubdomain, api_key
FrontFrontconversationsAPI tokenDynamicSourceSetupapi_token
GorgiasGorgiasticketsAPI keyDynamicSourceSetupgorgias_domain, email, api_key
IntercomIntercomconversationsOAuth (kind=intercom)DynamicSourceSetupintercom_integration_id

(Zendesk tickets, GitHub issues, Linear issues, pganalyze issues+servers, and Jira issues are already shipped — copy them, don't re-add. The Jira row above stays as the canonical worked example for payload keys and the JSON-blob emitter gotcha below.)

posthog/code checklist (per source)

Product key is the lowercase source_product (e.g. "jira"). Grep the repo for "zendesk" (case-insensitive) inside packages/ — every hit that is source-list-relevant is a place you must add the new product. The canonical list:

Type gates (every source)
  1. packages/agent/packages/agent-contracts/src/inbox-types.ts — add "jira" to the SourceProduct union.
  2. packages/api-client/src/posthog-client.ts — add to SignalSourceConfig.source_product union; add a new source_type value only if the record type isn't already issue/ticket.
Live UI path (every source)
  1. packages/ui/src/features/inbox/hooks/useSignalSourceToggles.ts — SetupSourceProduct, SOURCE_TYPE_MAP, SOURCE_LABELS, DATA_WAREHOUSE_SOURCES ({ dwSourceType, requiredTable }), ALL_SOURCE_PRODUCTS, and the computeValues initializer object.
  2. packages/ui/src/features/inbox/components/SignalSourceToggles.tsx — SignalSourceValues field, a toggleX/setupX callback, and a <SignalSourceToggleCard> in the "External connections" column (icon/label/description + requiresSetup/onSetup/loading/syncStatus).
  3. packages/ui/src/features/inbox/components/DataSourceSetup.tsx — DataSourceType, REQUIRED_SCHEMAS, and the switch case. For a credential source, route the case to <DynamicSourceSetup sourceType="Jira" title="Connect Jira" schemas={schemasPayload("jira")} … /> — no new form component. Only OAuth/resource-picker sources need a bespoke XSetup.
  4. packages/ui/src/features/inbox/components/utils/source-product-icons.tsx — SOURCE_PRODUCT_META entry (Icon, color, label). Add an inline SVG icon file (copy PgAnalyzeIcon.tsx) if no Phosphor icon fits.
  5. packages/ui/src/features/inbox/filterOptions.tsx — INBOX_SOURCE_OPTIONS entry (source-filter dropdown).
Core mirror (keep in sync — SignalSourceService/DataSourceService mirror the maps; not on the live UI path today but keep them consistent)
  1. packages/core/src/inbox/signalSourceService.ts — mirror SOURCE_TYPE_MAP, DATA_WAREHOUSE_SOURCES, ALL_SOURCE_PRODUCTS, computeSourceValues init, plus WarehouseSourceProduct/SignalSourceValues.
  2. packages/core/src/inbox/dataSourceService.ts — DataSourceType, REQUIRED_SCHEMAS, a createXDataSource method.
OAuth plumbing — NOT needed per source anymore

There is now a generic, kind-parameterized integration flow: IntegrationService (packages/core/src/integrations/integration.ts) + the integration tRPC router (packages/host-router/src/routers/integration.router.ts). DynamicSourceSetup starts any OAuth flow through it via the field's kind. So a new OAuth source needs no per-kind service, symbol, or router — do not clone linear.ts/linear-integration.router.ts per source. (The old per-kind linear/slack/github routers still exist for other callers; leave them.)

Setup-form specifics
  • Credential source: route the DataSourceSetup switch case to DynamicSourceSetup. Nothing else — the fields come from the wizard endpoint.
  • OAuth source: also just route to DynamicSourceSetup. Its connect-form schema carries the oauth field (and, if the provider needs a resource picked, an oauth-account-select field), which DynamicSourceSetup renders generically — connect button + integration polling + account picker, all by kind. No bespoke form. The provider must be in OauthIntegration.supported_kinds.
  • Issues sources (github/linear/jira) force issues to full_refresh in ensureRequiredTableSyncing (useSignalSourceToggles.ts) — add the new product to that condition if it syncs an issues table (issues get edited/closed, so incremental append would miss updates). Ticket/conversation sources only force should_sync=true.
Verify
  • pnpm --filter @posthog/shared... build after touching inbox-types.ts (it's a published type).
  • pnpm typecheck (whole repo — the unions are consumed across packages).
  • biome lint packages/core packages/ui — zero noRestrictedImports, imports ordered.
Show full SKILL.md (897 more words)Show less

posthog/posthog checklist (per source)

Scout lives in products/signals/backend/. The warehouse→signals handoff is generic; only the per-source emitter + registry entry are new.

  1. Enum — products/signals/backend/enums.py: add a SignalSourceProduct value + a SIGNAL_SOURCE_PRODUCT_LABELS entry. This regenerates SIGNAL_SOURCE_PRODUCT_CHOICES used by the model.

  2. SourceType — products/signals/backend/models.py SignalSourceConfig.SourceType: only add if the record type isn't already ISSUE/TICKET.

  3. Migration — python manage.py makemigrations signals → NNNN_alter_signalsourceconfig_source_product. Batch all new enum values into ONE migration when doing several sources — parallel PRs each adding a migration to this model collide in the merge queue.

  4. Emitter — new module products/signals/backend/emission/<source>_<table>.py exporting a SignalSourceTableConfig: partition_field (incremental cursor column), fields (columns to SELECT), optional where_clause, partition_field_is_datetime_string, an emitter(row) -> SignalEmitterOutput(source_product, source_type, source_id, description, weight, extra), and optional LLM actionability_prompt/summarization_prompt. Copy github_issues.py and adapt to the warehouse table's columns (read the source's settings.py/canonical_descriptions.py under products/warehouse_sources/backend/temporal/data_imports/sources/<name>/ for exact column names).

    ⚠️ Not every source stores flat columns. GitHub/Linear expose title/body/created_at as top-level columns, so the generic data_warehouse_record_fetcher (SELECT {fields} FROM {table} WHERE {partition_field} > cursor) works directly. Others do not: e.g. Jira's issues table has only id, key, self, fields (a nested JSON blob), expand — summary/description/status/created all live inside fields. For such sources you must SELECT fields and JSONExtractString(fields, '…') in the emitter, and the partition_field must be a JSON expression (JSONExtractString(fields, 'created'), partition_field_is_datetime_string=True). Verify the generic fetcher accepts a JSON-expression partition_field (it interpolates it into HogQL WHERE) before assuming a clone works — this is the single most likely thing to be subtly wrong, and it can only be confirmed by running a sync, not by reading code. Inspect the real column shape via the source's canonical_descriptions.py first.

  5. Register — products/signals/backend/emission/registry.py _register_all_emitters(): register((ExternalDataSourceType.X, "<table>"), <config>).

  6. Contract — products/signals/backend/contracts.py: add a Literal[SignalSourceProduct.X] variant.

  7. The generic fetcher (emission/fetchers/data_warehouse.py), the gate (emission/gate.py), and the warehouse hook plumbing need no changes.

Verify
  • Migration applies cleanly; python manage.py makemigrations --check is clean afterward.
  • The ExternalDataSourceType member exists in products/warehouse_sources/backend/types.py.

The self-driving wizard surface (PostHog/context-mill) — optional

The two surfaces above make a source work in the app. They do not make the CLI npx @posthog/wizard self-driving onboarding offer it. That flow is an AI agent driven by a skill in the separate PostHog/context-mill repo, and its connected-tool list is hardcoded — it is not read dynamically from the wizard endpoint. So a new source is invisible to self-driving onboarding until you add it there.

Edit context/skills/self-driving/references/5-connected-tools.md (plus the source-list mentions in 4-sources.md, 2-read-context.md, and description.md):

  1. Add the tool to the step-5 wizard_ask multi-select options ({ label, value }).
  2. Add its responder mapping — the same source_product / source_type pair as the posthog emitter (e.g. Jira → jira / issue).
  3. Add its DWH source_type to the "already connected" detection list.
  4. Classify how the run connects it:
    • Credential source (API key/token — Jira, Zendesk, pganalyze): the run can't collect credentials in-flight, so it never sends the user to the UI. Group it with Zendesk — arm the dormant responder and record a follow-up. No connector file.
    • One-click OAuth source (Linear-style, kind=<source> integration): add a dedicated connector reference (5X-<source>.md, clone 5b-linear.md) that hands over the authorize link and creates the source from the integration id.

dist/ is gitignored (built in CI), but run node scripts/build.js (Node ≥20) once to confirm the skill bundles; the build validates structure.

created_via attribution

ExternalDataSource.created_via records how a source was created and is derived server-side from the request transport (get_event_source in posthog/event_usage.py, keyed on the user-agent) — an API caller cannot set it directly, which is deliberate (otherwise any client could self-label). A new source inherits this for free; there is nothing per-source to wire. For reference, the machine value mcp is upgraded based on the caller:

CallerTransportcreated_via
PostHog Desktop app inbox (posthog/code)EventSource.POSTHOG_CODEself_driving
npx @posthog/wizard (self-driving program)EventSource.WIZARDself_driving
Other MCP clientsEventSource.MCPmcp

The upgrade lives in _create_external_data_source in products/warehouse_sources/backend/presentation/views/external_data_source.py.

Worktree setup (posthog/posthog backend work)

bash
# from your local posthog/posthog clone
git fetch origin
git worktree add ../worktrees/inbox-<source> -b <your-branch-prefix>/inbox-<source>-source origin/master

If the agent sandbox has no GPG signing key configured, disable signing for the commit (git -c commit.gpgsign=false commit) so it doesn't fail on a missing key. Do not reflexively add --no-verify: the pre-commit/pre-push hooks run lint, type-check, and ci:preflight, and skipping them lets breakage reach CI. Only bypass a specific hook if it genuinely can't run in the worktree, and run the Verify steps above by hand first. Open PRs ready for review (not draft). Use semantic commit prefix feat(data-warehouse): for anything touching warehouse sources / signals. Clean up the worktree when merged: git worktree remove ../worktrees/inbox-<source>.

PR conventions

  • One PR per source per repo (per the request). Title: feat(data-warehouse): add <Source> as a self-driving inbox source.
  • Base the PR body on the repo's PR template.
  • Backend PRs first (or the shared enum migration first); Code PR references the backend PR and the deploy-ordering dependency.
  • Migration hygiene: if opening several backend PRs, put all new SignalSourceProduct values in ONE prep PR's migration, and have the per-source emitter PRs carry no migration — otherwise they conflict.
  • Follow the merging-prs skill to land each PR through the Trunk queue.

Gotchas

  • source_type (DWH, capitalized e.g. "Jira") ≠ source_product (lowercase e.g. "jira") ≠ SourceType record kind ("issue"). Three distinct fields.
  • DATA_WAREHOUSE_SOURCES matches an existing external source by source_type.toLowerCase() — so dwSourceType must equal the real DWH type string.
  • The exact payload keys are the real risk. They must match the posthog serializer for that source_type. Confirm against source.py before shipping.
  • Keep SOURCE_PRODUCT_META and INBOX_SOURCE_OPTIONS covered for every product (the inbox CLAUDE.md calls this out) or findings render without an icon/filter.
  • Do not confuse this with packages/core/src/onboarding/githubConnectService.ts — that's repo-access (clone/branch/PR), unrelated to warehouse sources.

© PostHog, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/adding-inbox-sources of PostHog/posthog-foss.

Open the folder on GitHubat commit 2c48221

Compare with similar skills

Adding Inbox Sources next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Adding Inbox Sources compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Adding Inbox Sources this skillPostHog/posthog-foss721—~5.3kAutomated safety check: PassMIT
Connect Apps with ComposioComposioHQ/awesome-claude-skills77k3 repos~557Automated safety check: PassNone
Jiramagnus919/agent-skills111—~3.3kAutomated safety check: PassMIT
Mfs Findzilliztech/mfs150—~4kAutomated safety check: PassApache-2.0
Supporthaacked/dotfiles134—~2.9kAutomated safety check: PassNone
Mfs Ingestzilliztech/mfs150—~4.7kAutomated safety check: PassApache-2.0

Similar skills

  • Connect Apps with Composio

    ComposioHQ/awesome-claude-skills

    Connects an agent to 1000+ external apps through the Composio Tool Router plugin, so it can actually send emails, create issues and post messages instead of only drafting them.

    77k GitHub starsUsed in 3 repos~557 tokens
    Productivity & AutomationAuto-check passed

  • Jira

    magnus919/agent-skills

    Interact with Atlassian Jira from the terminal: search issues with JQL, view details, create issues, add comments, count matches with fast approximate-count, list projects, discover valid…

    111 GitHub stars~3.3k tokensUpdated yesterday
    Productivity & AutomationAuto-check passed

  • Mfs Find

    zilliztech/mfs

    Search, grep, browse, and read across registered MFS data sources via the mfs CLI — codebases, docs, PDFs, web crawls, databases (postgres/mysql/mongo/snowflake/bigquery), issue trackers…

    150 GitHub stars~4k tokensUpdated 2 mo ago
    DatabasesAuto-check passed

  • Support

    haacked/dotfiles

    Support hero workflow — start a ticket investigation with auto-organized notes, find existing notes, or generate the weekly highlights log.

    134 GitHub stars~2.9k tokensUpdated yesterday
    Sales & SupportAuto-check passed

  • Mfs Ingest

    zilliztech/mfs

    Register, update, or re-sync data sources for MFS so they become searchable — postgres / mysql / mongo / snowflake / bigquery, github / jira / linear / notion / hubspot / zendesk, slack / discord /…

    150 GitHub stars~4.7k tokensUpdated 2 mo ago
    DatabasesAuto-check passed

  • Storefront PR Review

    shopsys/shopsys

    Reviews storefront pull/merge requests with risk-based static analysis, Jira context, project conventions, call-site tracing, test coverage audit, and Playwright runtime verification when available.

    350 GitHub stars~238 tokensUpdated today
    DevelopmentAuto-check passed

More from PostHog/posthog-foss

All 213 skills in this repo

  • Authoring Log Alerts

    PostHog/posthog-foss

    Official

    Author useful, low-noise log alerts on services in a PostHog project.

    721 GitHub stars~3k tokensUpdated today
    Auto-check passed

  • Autoresolving PR Conflicts

    PostHog/posthog-foss

    Official

    Operating procedure for the conflict-autoresolver agent: sweep open PostHog/posthog PRs that conflict with master, resolve the trivial conflicts (generated artifacts deterministically, source…

    721 GitHub stars~4.2k tokensUpdated today
    Auto-check passed

  • Diagnosing Stacktrace Symbolication

    PostHog/posthog-foss

    Official

    Help users debug PostHog Error Tracking stack-trace symbolication for any supported platform — JavaScript/TypeScript web, React Native (Hermes), Android (Proguard / R8), or iOS / macOS (dSYM).

    721 GitHub stars~2.2k tokensUpdated today
    Auto-check passed

  • Exploring Apm Traces

    PostHog/posthog-foss

    Official

    Investigates distributed application performance using PostHog APM (OpenTelemetry span) data via MCP.

    721 GitHub stars~3.5k tokensUpdated today
    Auto-check passed

  • Exploring LLM Traces

    PostHog/posthog-foss

    Official

    Debug and inspect LLM/AI agent traces using PostHog's MCP tools.

    721 GitHub stars~4.4k tokensUpdated today
    Auto-check passed

  • Investigate Metric

    PostHog/posthog-foss

    Official

    Diagnose why a product metric changed (dropped, spiked, or plateaued) by orchestrating breakdowns, actors, paths, lifecycle, retention, and annotations queries.

    721 GitHub stars~1.9k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Adding Inbox Sources

What does Adding Inbox Sources do?

Add a new warehouse-backed source to the PostHog Desktop Self-driving Inbox (the feature that ships GitHub, Linear, Zendesk, pganalyze, Jira). Adding Inbox Sources is an agent skill from PostHog/posthog-foss, published by the product's own GitHub organization. Add a new warehouse-backed source to the PostHog Desktop Self-driving Inbox (the feature that ships GitHub, Linear, Zendesk, pganalyze, Jira).

When should I use Adding Inbox Sources?

Adding Inbox Sources fits situations like: asked to add a new inbox/self-driving source; wire up <Jira/GitLab/Sentry/Intercom/Freshdesk/Front/Gorgias/etc as a signal source; extend the source-toggle grid.

How do I install Adding Inbox Sources in Claude Code?

Run `npx skills add PostHog/posthog-foss --skill adding-inbox-sources -a claude-code`. Or copy the skill folder (.agents/skills/adding-inbox-sources in PostHog/posthog-foss) into .claude/skills/adding-inbox-sources in your project. Claude Code loads it when a task matches its description.

How do I install Adding Inbox Sources in Codex?

Run `npx skills add PostHog/posthog-foss --skill adding-inbox-sources -a codex`. Or copy the skill folder (.agents/skills/adding-inbox-sources in PostHog/posthog-foss) into .agents/skills/adding-inbox-sources in your project. Codex loads it when a task matches its description.

Can I use Adding Inbox Sources in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add PostHog/posthog-foss --skill adding-inbox-sources -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/adding-inbox-sources, .gemini/skills/adding-inbox-sources, .github/skills/adding-inbox-sources and .opencode/skills/adding-inbox-sources in your project.

What does Adding Inbox Sources need to run?

Going by SKILL.md and its folder, Adding Inbox Sources needs the command-line tools its instructions call (git, npx, pnpm, python and node). Our summary lists: Node.js.

Does Adding Inbox Sources access the network?

SKILL.md contains no URLs. Its commands use git and npx, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Adding Inbox Sources safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Adding Inbox Sources use?

Adding Inbox Sources is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Adding Inbox Sources use?

About 5.3k tokens (SKILL.md is roughly 21k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Adding Inbox Sources?

Skills that share tags, products or a category with Adding Inbox Sources: Connect Apps with Composio (ComposioHQ/awesome-claude-skills, 77k stars), Jira (magnus919/agent-skills, 111 stars), Mfs Find (zilliztech/mfs, 150 stars) and Support (haacked/dotfiles, 134 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Adding Inbox Sources?

PostHog (a GitHub organization, an official publisher) maintains it in PostHog/posthog-foss, which has 721 GitHub stars. The repository holds 213 skills in this directory. The repository was last updated on October 7, 2026.

Source: PostHog/posthog-foss on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.