feat: update logo to current PostHog brand mark

[rafaeelaudibert]

Swaps assets/logo.svg for the current PostHog logomark and bumps every manifest so the marketplaces re-index.

What changed

The old asset was the previous flat three-bar hedgehog. The new one is the current brand logomark, pulled from @posthog/brand (Logo.Logomark, gradient variant, rendered from src/logo/geometry.ts at v0.10.2) — brand gradients and the updated silhouette.

	old	new
viewBox	0 0 50 30	0 0 52 28
fills	3 flat colors + #000	9 linear gradients + #111

Aspect ratio is near-identical, so it's a drop-in — no layout changes needed anywhere.

One file, every client

.cursor-plugin/plugin.json and .codex-plugin/plugin.json both already reference assets/logo.svg, so replacing the single file covers both. No new per-client asset.

Gradient ids are namespaced (posthog-logomark-* rather than the package's generic logo-jump-p*) so the mark still renders correctly if it's ever inlined alongside other SVGs.

Version bumps

Patch bump on all four manifests, mirroring what sync-skills.yml already does (marketplace.json tracks plugin.json):

manifest
.claude-plugin/plugin.json	1.1.62	1.1.63
.claude-plugin/marketplace.json	1.1.62	1.1.63
.cursor-plugin/plugin.json	1.1.56	1.1.57
.codex-plugin/plugin.json	1.0.60	1.0.61
gemini-extension.json	1.0.58	1.0.59

Known caveat: dark backgrounds

The hedgehog's head is #111, so on a dark surface it recedes into the background — the three gradient spikes read fine, the head largely doesn't. This is not a regression (the old mark had the same problem with fill="#000"), and it's how the brand gradient logomark is defined, so I've kept it faithful rather than deviating unilaterally.

If we do want to fix it, @posthog/brand ships a mono variant (<Logo variant="mono" color="#fff" />) that inherits or takes an explicit color — happy to swap, but that's a brand call rather than a mechanical one.

Why only Cursor and Codex get a logo

.claude-plugin/plugin.json, .claude-plugin/marketplace.json, and gemini-extension.json deliberately get no logo field — neither format has one. Verified rather than assumed:

• Claude Code — the plugins reference and marketplace reference define no logo/icon/image/avatar field. Confirmed empirically against claude plugin validate (v2.1.266) by adding the fields to a scratch copy:

  > plugins[0].logo: Unknown field 'logo' (commonly seen in manifests across many tools).
    Claude Code ignores unrecognized fields at load time, so it's safe to keep.
  > plugins[0].icon: Unknown field 'icon' (commonly seen in a VS Code/Cursor extension manifest).
  > plugins[0] plugin.json -> logo: Unknown field 'logo' ...
  

  Tolerated but ignored — so adding them buys nothing and costs three permanent validation warnings. (Arbitrary data belongs under the free-form metadata object, which Claude Code also doesn't read.)

• Gemini CLI — the extension reference lists name, version, description, mcpServers, contextFileName, excludeTools, migratedTo, plan, settings, themes. No icon/logo field; listings on geminicli.com/extensions are text-only.

If either format grows a logo field later, it should point at this same assets/logo.svg.

Testing

• ./tests/test_gate_exec_write.sh — 45 passed
• pytest tests/test_session_parser.py tests/test_posthog_llma.py — 86 passed
• claude plugin validate . passes clean
• SVG verified as well-formed XML; all five JSON manifests verified as valid; both logo path references confirmed to still resolve

🤖 Generated with Claude Code