Add headset-bridge-toolkit plugin with Bridge reporting skills

[svickers]

Summary

Migrates the headset-bridge-toolkit plugin (v0.2.2) from the claude-plugins repo into this marketplace, alongside the existing root headset plugin.

• Three skills built on live Bridge sell-through data: bridge-account-review (buyer-meeting one-pager), bridge-restock-risk (velocity-based restock report), and bridge-weekly-pulse (Monday leadership brief).
• Each skill carries its own references/ copies of the Bridge data conventions and Headset report style — claude.ai org installs package each skill directory in isolation, so skills never reference files outside their own directory.
• shared/ holds the canonical cross-product reference files; scripts/sync-shared.sh syncs them into every skill (run and verified in this repo — zero drift).
• Marketplace catalog now lists both plugins; the README documents the install choice; CLAUDE.md captures repo conventions (sync workflow, release process, customer-facing content rules).
• The toolkit's .mcp.json gains callbackPort: 5420 to match the root plugin's OAuth config; otherwise the plugin is byte-identical to the source repo.

Verification

• All JSON manifests validated; marketplace entry version matches plugin.json (0.2.2).
• Structural validation passed: SKILL.md frontmatter valid, skill names match directories, zero out-of-directory path references, all reference copies byte-identical to canonical sources.
• ./scripts/sync-shared.sh runs cleanly in this repo (6 copies, no drift).

🤖 Generated with Claude Code

[marc-wilson]

a few issues

• Reinvented folder structure that isn't correct. The shared/ + plugin-level references/ + per-skill references/ layout looks like it's simulating some kind of nested/isolated sub-plugin setup, and references/ isn't even a documented folder name. The plugin structure overview only documents .claude-plugin/, skills/, commands/, agents/, hooks/, .mcp.json, .lsp.json, monitors/, bin/, and settings.json at the plugin root — no references/. The documented pattern for a skill's supporting docs (Skills — Add supporting files) is just a flat file living next to SKILL.md in that skill's own directory (e.g. reference.md), linked from SKILL.md. It's not a shared folder pulled in from elsewhere in the plugin. On top of that, the whole plugin ships as one cached unit (Plugins reference — plugin caching & path traversal), so even a cross-skill shared file could just be referenced directly from the plugin root — no copying required.
• Duplicate code. bridge-data-conventions.md and headset-report-style.md are each copied byte-for-byte into 4 places. That's ~535 of the 887 added lines in this PR that are just copies.
• A custom script process that shouldn't need to exist. sync-shared.sh (plus the "never hand-edit the synced copies" rule in CLAUDE.md) only exists to keep those duplicates in sync. Fix the structure and the script goes away.
• Probably shouldn't be checking in a CLAUDE.md here at all. This is a public repo, and it isn't really meant to be a place someone sits down and develops in — it's a distribution point for plugins. Not a big deal on its own, but worth figuring out before this goes out. Open to being wrong here — if we can point to a few other Claude Code plugin marketplace repos that check in this kind of internal/contributor doc, that'd change my mind.
• Just set the version to 1.0.0. No clear reason for 0.2.2.
• plugins/headset-bridge-toolkit/.mcp.json duplicates config that belongs in plugin.json. The root headset plugin already defines its MCP server inline in .claude-plugin/plugin.json via the mcpServers field — that's a documented, first-class option (Plugins reference — manifest schema). The new toolkit instead adds a standalone .mcp.json with the same server config duplicated byte-for-byte (just a different key casing, Headset vs headset). That's a second, separate place the same MCP config now has to be kept in sync. Also flagging: we don't want a file named .mcp.json sitting in this repo at all — working in this repo locally, a stray .mcp.json collides with whatever MCP setup you're using to test the plugin you're actively developing, and that's caused real confusion before (chasing down "is this hitting the shipped MCP or the one I just registered locally"). If we genuinely need MCP config in more than one place, there's a proper way to structure that — ping before implementing so it's done right rather than duplicating this.