feat(mcp): add synthetic git endpoints for per-skill plugin distribution

[daniloc]

Adds a synthetic git smart HTTP layer to the MCP server that enables per-skill install attribution. Instead of one monolithic plugin clone from GitHub, each skill becomes an individually installable plugin served via git clone from mcp.posthog.com, with PostHog analytics events fired on every install and update fetch.

Problem

Skill distribution is a bit of a shitshow, and worse yet, we don't know exactly what skills are most desired. This resolves the issue by putting us in direct control of the marketplace interface.

Changes

• Git interface for MCP server
• Marketplace distribution via MCP server
• Analytics events for Skill consumption, including installs and updates
• Per-skill installation requests in the marketplace structure allow us to measure demand for skills

How did you test this code?

MCP run locally and installed marketplace to Claude Code.

🤖 Agent context

Claude Code reimplemented a strategy I've used in personal projects to good success here. Supplemented with some interesting research:

Issue #46163 on anthropics/claude-code (open, no Anthropic response): plugin authors have zero visibility into installs, active users, or adoption. They're requesting exactly what the synthetic git approach provides — install counts, version distribution, usage signals. VS Code Marketplace and npm both provide this as first-party analytics. Claude Code's ecosystem has nothing.

This means the synthetic git marketplace isn't just PostHog solving its own problem — it's a reference implementation for what every plugin author needs. That's a positioning opportunity: PostHog can dogfood its own analytics product on its own plugin distribution, and the pattern is reusable by anyone running a marketplace.

[daniloc]

Oh I forgot the best part:

this is the command to add it to Claude Code

/plugin marketplace add https://mcp.posthog.com/

[daniloc]

refinement: pipe through the version data from context-mill for ongoing, proper versioning.

[cvolzer3]

very nice! excited to see this get rolled out.

[daniloc]

further refined to 11 plugins/skill bundles, plus a plugin selection skill that suggests the ideal plugin to install to the user when PostHog-shaped needs arise:

Bundle	Name	Skills	Description
posthog-nextjs	PostHog for Next.js	10	Analytics, feature flags, error tracking, and logging for Next.js applications
posthog-react	PostHog for React	5	Analytics, feature flags, and error tracking for React applications
posthog-python	PostHog for Python	10	Analytics, feature flags, error tracking, and logging for Python applications
posthog-node	PostHog for Node.js	7	Analytics, feature flags, error tracking, and logging for Node.js applications
posthog-react-native	PostHog for React Native	7	Analytics, feature flags, and error tracking for React Native applications
posthog-svelte	PostHog for Svelte	5	Analytics, feature flags, and error tracking for SvelteKit applications
posthog-vue	PostHog for Vue / Nuxt	7	Analytics, feature flags, and error tracking for Vue.js and Nuxt applications
posthog-ruby	PostHog for Ruby	8	Analytics, feature flags, error tracking, and logging for Ruby and Rails applications
posthog-go	PostHog for Go	6	Analytics, feature flags, error tracking, and logging for Go applications
posthog-llm	PostHog LLM Analytics	2	Monitor LLM usage, costs, traces, and evaluations with PostHog
posthog-android	PostHog for Android	6	Analytics, feature flags, and error tracking for Android applications

Depends on a new generator in context-mill:

PostHog/context-mill#120

Plugin recommender

    # Recommend PostHog Skills

    You are helping the user install the right PostHog skills for their project.

    ## Step 1: Detect the technology stack

    Check the project for framework indicators:

    ```bash
    # Check for key files
    ls package.json requirements.txt Gemfile go.mod Cargo.toml build.gradle pubspec.yaml 2>/dev/null

    # If package.json exists, check dependencies
    cat package.json 2>/dev/null | grep -E '"(next|react|react-native|expo|vue|nuxt|svelte|@sveltejs|astro|angular)"' | head -10

    # If requirements.txt or setup.py exists
    cat requirements.txt setup.py pyproject.toml 2>/dev/null | grep -iE '(django|flask|fastapi)' | head -5

    # If Gemfile exists
    cat Gemfile 2>/dev/null | grep -iE '(rails|sinatra)' | head -5
    ```

    ## Step 2: Match to a bundle

    Based on what you find, recommend ONE bundle from this list:

    {bundle_list}

    ## Step 3: Recommend installation

    Tell the user which bundle matches their stack and give them the install command:

    ```
    /plugin install posthog-{bundle-name}@posthog
    ```

    If the project uses multiple frameworks (e.g., a Next.js frontend + Python backend), recommend multiple bundles.

    If no framework is detected, ask the user what they're building.

[daniloc]

So here's the flow, if we did this.

1. we change the source.url value in the official plugin registry to point at mcp.posthog.com/git/core
2. users run /plugin install posthog as usual, giving them MCP, etc
3. the base plugin gives them a basic skills bundle for MCP interactions
4. the plugin also ensures the necessary PostHog skills are present for any coding task that requires them

5. now we have a surface to serve the user the content they need, when they need it, and the ability to measure their consumption

[github-actions]

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, please remove the stale label – otherwise this will be closed in another week. If you want to permanently keep it open, use the waiting label.