Ideation: Move Brainforge agent assets into the team plugins marketplace
Date: 2026-04-22
Focus: /ce-ideate — how to relocate (or publish) Brainforge-specific agent assets—Cursor skills, rules, command patterns, MCP templates, and related guidance—so they travel with engineers across repos and workspaces, not only when brainforge-platform is open.
Mode: Repo-grounded — assets today live primarily in brainforge-platform (.cursor/, AGENTS.md, .agents/ for Codex, opencode.jsonc, sync scripts); distribution already started in brainforge-ai/brainforge-plugin-marketplace with per-vendor plugin folders.
Related plans: docs/plans/2026-04-21-002-feat-cursor-team-marketplace-repo-plan.md (dedicated marketplace repo; monorepo documents, does not replace). This ideation extends that with what to ship inside marketplace plugins vs what stays in the monorepo.
Session note: Full ce:ideate multi-agent dispatch was not run; this artifact follows the skill’s structure (grounding → many candidates → explicit rejection → ranked survivors) in one pass over AGENTS.md, .cursor/ layout, and marketplace state.
1. Grounding summary
What “agent assets” means here
| Bucket | Where it lives today | Portable without monorepo clone? |
|---|---|---|
| Cursor skills | .cursor/skills/ (many; some git submodules via scripts/ensure-git-submodules.mjs) | No — repo-scoped unless mirrored to user or marketplace |
| Cursor rules | .cursor/rules/*.mdc | No — project rules follow the repo |
| Compound Engineering | .cursor/settings.json + optional bunx @every-env/compound-plugin for OpenCode/Codex | Partially — different install paths per surface |
| Codex skills | .agents/skills/ + user ~/.agents/skills/ | User path is portable; repo path is not |
| “Cursor mirror” to Codex | sync-cursor-skills-to-codex.py (user-level mirror) | Yes for individuals who run the script |
| MCP | .cursor/mcp.json, docs, per-server OAuth | Templates portable; secrets and OAuth stay per machine |
| OpenCode | opencode.jsonc, user config merge | Mostly user + repo; not the same as Cursor plugins |
Why this topic matters now
- Engineers work in client repos, scratch folders, and other org repos; the richest skills in
brainforge-platformdo not load there. - The team marketplace is the intended org-wide channel for “install once, use everywhere” plugin-shaped bundles (Cursor plugins reference).
- Risk: Duplicating large trees into
brainforge-plugin-marketplacecreates drift and doubles review load unless there is a single source of truth or automated publish.
Past learnings (from repo docs)
- A dedicated marketplace repo is already the right shell; the monorepo should not be the import URL for the team marketplace (see plan above).
- Submodule-backed skills (Anthropic packs, Impeccable, Omni, last30days, etc.) are bootstrapped by npm in the monorepo — those are not “Brainforge-authored” and should likely stay upstream or marketplace vendor plugins, not copied into a “Brainforge bundle” wholesale.
2. Raw candidates (six frames → merged)
Ideas generated across pain / friction, inversion or automation, reframing, leverage, cross-domain analogy, constraint flip; near-duplicates merged.
A. Packaging and source of truth
- Single
brainforge-standardsmarketplace plugin — all org-authored skills + rules in one plugin folder; monorepo deletes copies and links to marketplace only. - Split plugins — e.g.
brainforge-delivery,brainforge-gtm,brainforge-platform-devas separate marketplace entries to limit noise and requiredness scope. - Monorepo remains SoT; CI publishes tarball into marketplace repo on tag (no hand-editing skills in two places).
- Marketplace repo is SoT; monorepo submodules the plugin ( inversion: app repo consumes the published bundle).
- “Thin marketplace, fat docs” — marketplace ships only
rules/+ pointers; long playbooks stay in a public or internal doc site with stable URLs in skills.
B. What moves vs what stays
- Move only
alwaysApply: false/ on-demand skills; keep security- and repo-specific rules inbrainforge-platformonly. - Move only rules; keep skills in monorepo (smaller bundle, less duplication ofSubmodule trees).
- Move skills; keep rules in monorepo (skills are what people miss cross-repo; rules are often path-globs to this codebase).
- Extract a “Brainforge core” of ~10 skills (ship loop, Linear bridge, mission-run, keep-running pointers) and leave the long tail in the monorepo.
- Nothing moves — instead improve user-level sync (scheduled job to pull from a release artifact into
~/.cursor/ user skills). (Constraint flip: marketplace is optional.)
C. MCP and secrets
- MCP templates only in marketplace —
mcp.jsonwith${VAR}placeholders; same file shape as today’s vendor plugins. - No MCP in org bundle — every engineer already gets vendor plugins from the marketplace; Brainforge only ships skills/rules.
- “MCP doctor” skill in marketplace — one skill that encodes how to log in to Slack/Linear/Notion per AGENTS, without storing tokens.
D. Submodule and third-party skills
- Re-list submodule skills as separate marketplace dependencies (Omni, Impeccable, etc.) — do not vendor into
brainforge-standards. - One meta-skill that says “enable these plugins from the team marketplace in this order.”
- Pin submodule versions in marketplace via copy at release — reject as high drift (already rejected mentally; list for critique).
E. Codex / OpenCode parity
- Document-only in
AGENTS.md: “After marketplace install, run X script to sync to Codex.” No dual publish. - Parallel publish job — same content rendered to
.cursor-pluginand a Codex pack zip; second-class but automated. - OpenCode out of scope for v1; revisit when OpenCode has a team channel comparable to Cursor Teams.
F. Governance and ergonomics
- CODEOWNERS on marketplace repo for
plugins/brainforge-*/only Platform + one designee. - Version line in
plugin.jsonmust match a changelog in monorepoknowledge/ordocs/. - “Required” only for a minimal plugin (e.g.
brainforge-core& Compound); heavy vertical skills stay optional. - Quarterly prune — survivorship review like any internal package; archive skills nobody invokes.
3. Critique — what to reject or narrow
| Idea | Verdict | Why |
|---|---|---|
| 1 — one mega plugin with everything | Reject as stated | Bundle size, cognitive load, and “required for all” becomes heavy; blurs GTM vs eng vs platform; Submodule/third-party content must not be copy-pasted in. Narrow: one plugin with curated Brainforge-only assets only. |
| 4 — marketplace as sole SoT with monorepo as consumer | Reject for now | Inverts how engineers edit skills today (they live and PR in the monorepo); high migration cost; conflicts with AGENTS.md and submodule story. Revisit only if the org commits to a packages-style skill repo. |
| 7 — rules only, skills stay | Weak | Cross-workspace value is skills; rules without globs to this repo help less than skills. Demote unless legal/compliance says “rules must not leave VPN boundary.” |
| 10 — nothing in marketplace, only user sync | Reject as org default | Does not use Required / team distribution; depends on every engineer running scripts; no central version pin. Viable for opt-in power users only. |
| 12 — no MCP in Brainforge bundle | Partially reject | Stubs and ${VAR} templates in marketplace are still useful for discoverability; no secrets in repo. Keep thin MCP templates optional. |
| 16 — copy submodule trees into marketplace | Reject | Drift from upstream; use vendor plugins in marketplace.json instead. |
| 18 — full Codex zip parity in v1 | Defer | Doubles build pipeline; get Cursor path working and adopted first. |
4. Survivors (ranked)
| Rank | Idea | Type | Effort | Why it survives |
|---|---|---|---|---|
| 1 | metadata.pluginRoot + thin brainforge-standards (or rename) plugin with org-authored skills/rules only; vendor/Submodule skills remain separate marketplace entries (14) | Architecture | Med | Matches “portable across workspaces” without forking Every/Omni/etc.; aligns with existing plugins/brainforge-platform slot (expand with real content or rename for clarity). |
| 2 | Monorepo SoT + CI publish to brainforge-plugin-marketplace on tag or main (3) | Process | Med–High | One authoritative edit location; marketplace gets reproducible updates; reviews stay in one PR flow if publish is automated. |
| 3 | Split optional plugins by concern (2) after v1 if one bundle is too big — e.g. brainforge-delivery vs brainforge-gtm | Scaling | Med | Unblocks “required = small” (22) while keeping optional depth for specialists. |
| 4 | Survivor 9 — start with a tight “core” list (ship loop, Linear/PR skills, mission-run/keep-running pointers, internal playbook links) | Scope cut | Low | Proves value before migrating dozens of skills; reduces first migration risk. |
| 5 | MCP: templates + skill 11/13 — placeholder mcp.json or env-only patterns + one “connect your MCPs” skill linking to AGENTS sections | Security-aware DX | Low | Improves onboarding without putting secrets in git. |
| 6 | 5 — “thin marketplace, fat docs” for long playbooks | Hybrid | Low | Skills stay short; knowledge/ and Notion stay canonical for walls of text. |
| 7 | 20–22 — governance (CODEOWNERS, minimal “required” set) | People | Low | Prevents marketplace sprawl and policy debates later. |
| 8 | 17 — post-install Codex mirror doc path | Docs | Low | Respects current sync-cursor-skills reality without blocking Cursor marketplace launch. |
5. Synthesis — not a build plan (handoff to ce:brainstorm / ce:plan)
Recommended directional sequence (to be turned into a real plan with owners and acceptance tests):
- Define the inventory — classify every
.cursor/skills/*and critical.cursor/rules/*as: (a) org-generic portable, (b)brainforge-platformpath- or app-specific, (c) third-party / submodule. Only (a) + a short list of (b) reframed to be path-agnostic are marketplace candidates. - Name the home plugin — either grow
plugins/brainforge-platforminto the real bundle or addplugins/brainforge-standardsand deprecate the empty name; document the difference from vendor plugins inbrainforge-plugin-marketplace/README.md. - Choose SoT — default monorepo SoT + automated publish (Survivor 2) unless leadership wants a skills-only repo later.
- Cut scope v1 to Survivor 4 core set + governance (Survivors 7).
- Codex — keep documented mirror for v1 (Survivor 8); defer full dual-target packaging (rejected 18) until adoption metrics say so.
- After v1 works: consider plugin split (Survivor 3) and quarterly prune (23).
6. Post-ideation menu (per ce:ideate handoff)
- Refine — narrow the “core 10” list with Platform + one GTM and one Delivery owner.
- Open in Proof — if you use Proof for stakeholder review.
/ce:brainstorm— one chosen direction (e.g. “monorepo SoT + CI publish toplugins/brainforge-standardsonly”) to define constraints and non-goals precisely./ce:plan— implementation: CI shape, folder layout,marketplace.jsonentries, andAGENTS.mdupdates.- Save and end — this file is the save for ideation; no requirements or code produced here.