Plugin ships ~114 eagerly-listed skills (README says 30+) — please reconsider bundling the full catalog

[jokull]

Installing posthog@claude-plugins-official currently injects ~114 skills into every Claude Code session (the README still says "30+"), and the daily chore: sync skills workflow keeps growing that number by exporting what looks like your full internal catalog — including internal-facing skills like the signals-scout-* family and checking-deploy-timing ("for PostHog staff").

Skill names + descriptions are loaded eagerly into the system prompt (~100 tokens each per Anthropic's authoring docs), so the catalog costs roughly 11–15k tokens of every session, in every project, before PostHog is touched at all. Claude Code has no per-skill toggle, so the only remedy on our side is disabling the whole plugin.

A data point from our org: across 949 Claude Code session transcripts, posthog:* skills were invoked zero times, while the PostHog MCP tools were used 46 times. The skills aren't just unused — they dilute discovery for every other skill in the session, which is exactly what your own handbook warns about: "Skill count is a budgeted, shared resource, not a free axis to expand… a bloated set makes each individual skill less likely to fire." (https://posthog.com/handbook/engineering/ai/writing-skills)

Would you consider:

1. Splitting the plugin (core user-facing skills vs. scouts/staff-internal), or
2. Loading the long tail on demand via your skills-store MCP approach instead of bundling it, and
3. Updating the "30+ skills" README claim to match reality?

Thanks — the MCP side of the plugin is genuinely useful; it's the bundled catalog that's hard to justify keeping installed.

[AlexGodard]

+1. Some measured numbers from today's catalog (main @ 936b2d2) to add to this:

• 124 SKILL.md files (README still says "30+")
• 58,868 total frontmatter description characters — avg 474 chars/skill, 115 of 124 over 220 chars
• Longest: planning-voice-agent-user-interviews (1,018 chars), diagnosing-experiment-results (972), configuring-experiment-analytics (947), exploring-scouts (921), setting-up-a-custom-rest-source (907)

This also interacts badly with Codex CLI, which this plugin explicitly targets. Codex hard-caps eagerly injected skill metadata at 2% of the context window (~5,440 tokens, not configurable — openai/codex#19679). This catalog's descriptions alone are ~59k chars (~15k tokens), roughly 10× the entire Codex skills budget, so installing the plugin immediately triggers "Skill descriptions were shortened to fit the 2% skills context budget" and Codex truncates every skill description in the session — including other plugins' — degrading auto-triggering across the board.

Splitting the catalog or loading the long tail on demand via skills-store (as proposed above) would fix both surfaces. Even just linting descriptions to ~200 chars would cut the footprint by ~60%.

---

Update — the acute problem is Codex CLI specifically. Claude Code degrades gracefully and gives both sides escape hatches: its listing budget is configurable (skillListingBudgetFraction), it drops descriptions for least-used skills first (names always stay), and skills can be marked disable-model-invocation: true to become user-invocable-only, removed from model context entirely while /posthog:<skill> keeps working. Codex CLI has none of that: no user-invocable-vs-model-invocable distinction, no per-skill disable inside a plugin, and a hard non-configurable 2% cap — every installed skill is always injected into the model-visible list. So a cheap incremental fix would be marking the long tail disable-model-invocation: true for Claude Code surfaces, but only splitting the plugin or on-demand loading via skills-store actually fixes Codex.

[madrussa]

A bit of a tangent:
We're using the plugin to only capture LLM metrics. Having all of the skills, mcp and whatever else is a lot of unwanted overhead for me. Feels like it deserves being separated into 2 distinct plugins. One where you want to use all of the skills / mcp. With the other only used for capturing usage at the end of the session. I've just ported the metrics capturing to a separate plugin due to this... and I'm concerned about keeping them in sync.