Research — Multica + BMAD as the shared system, a fork-and-extend plan

Question

Two earlier notes parked Multica and kept the team on a CodeRabbit + claude-code-action hybrid, with Superpowers as the local skill bundle. The team has since changed direction: Multica is open source, the team wants to use it as the shared system the work happens inside, and BMAD method is preferred over Superpowers as the structured dev process. Can the two be harmonised — Multica as the orchestration / visibility layer, BMAD as the per-agent thinking framework — and can a thin fork extend Multica with a wiki tab, a GitHub webhook, and two new built-in agents (a PR Reviewer using both Claude and Codex, and a Prompt Auditor that audits the team’s own prompts)? The note answers in plain language, with UI mockups and a concrete week-by-week rollout.

TL;DR

Self-host Multica as the team’s task-and-agent board, install BMAD as Claude Code skills on every runtime, and fork multica-ai/multica into 361-coders-nz/multica to add a /wiki tab embedding the oxflow-docs viewer, a GitHub webhook receiver, and two built-in agents — PR Reviewer (Claude primary, Codex second-opinion) and Prompt Auditor. Drop Superpowers from the stack. Multica’s package boundaries (verified in its CLAUDE.md) make a wiki-tab fork a 1–2 dev-day change; BMAD is already packaged for Claude Code by aj-geddes/claude-code-bmad-skills, so phase-1 adoption is install-and-go. Cost envelope: USD ~325/month — slightly under the prior CodeRabbit-hybrid envelope, with full team-wide visibility added.

Revisit trigger: if the Multica fork’s maintenance burden exceeds 1 dev-day / month for two consecutive months, fall back to upstream Multica + a thin sidecar service for the webhook and wiki.

Approach

Two passes. Pass 1 re-read the two prior 361 notes that this one overrides, plus the shared-memory note and the agentic-coding note, to anchor on facts already cited by the team. Pass 2 went directly to source: pulled the Multica repo’s apps/web/app/[workspaceSlug]/(dashboard)/ folder structure via the GitHub API to verify the canonical sidebar tab list, read the upstream AGENTS.md, CLAUDE.md, SELF_HOSTING.md and CLI_AND_DAEMON.md, inspected the packages/views/layout/app-sidebar.tsx source to read the NavKey union directly, and pulled the BMAD v6 agent list from docs.bmad-method.org/llms-full.txt. No vendor interviews; no fork was actually built — this note specifies what the fork would do.

Findings

Multica describes itself in its own CLAUDE.md as “an AI-native task management platform — like Linear, but with AI agents as first-class citizens.” Architecture confirmed by the same file:

server/ — Go (Chi router, sqlc for DB, gorilla/websocket for real-time)
apps/web/ — Next.js 16 (App Router)
apps/desktop/ — Electron (electron-vite, HMR)
packages/core/ — headless business logic (Zustand stores, TanStack Query, API client)
packages/ui/ — atomic UI components (shadcn / Base UI)
packages/views/ — shared business pages (zero next/* imports — uses a NavigationAdapter)

The canonical sidebar tabs were read directly from apps/web/app/[workspaceSlug]/(dashboard)/ on 2026-04-20: agents, autopilots, inbox, issues, my-issues, projects, runtimes, settings, skills. The NavKey union in packages/views/layout/app-sidebar.tsx groups them as Personal (Inbox, My Issues), Workspace (Issues, Projects, Autopilot, Agents) and Configure (Runtimes, Skills, Settings). There is no Wiki / Docs tab today — that is the gap this fork fills.

Statistics fetched 2026-04-20: 16.9k stars, 5.3k forks, 54 contributors, v0.2.6 released 2026-04-18 (repo). Apache-2.0 licensed.

Conclusion: Multica is a real, well-engineered Linear-for-agents — and the sidebar list is short enough that adding one new tab is a meaningful product change, not a rounding error.

The package boundaries make a fork tractable

The upstream CLAUDE.md enforces hard package boundaries:

packages/views/ — zero next/* imports, zero react-router-dom imports, zero stores. Use NavigationAdapter for all routing.

That rule is exactly what makes a Wiki-tab fork bounded. To add /wiki:

Create packages/views/wiki/ — a new view package, mirroring the existing packages/views/skills/ structure.
Add a route segment apps/web/app/[workspaceSlug]/(dashboard)/wiki/page.tsx that imports the view.
Add the same on Electron in apps/desktop/.
Add wiki to the NavKey union and a new entry to configureNav in packages/views/layout/app-sidebar.tsx.
Add a wiki method to WorkspacePaths in packages/core/paths.

That is 5 files touched, ~100 lines added, no schema migrations, no API changes. Estimated 1–2 dev-days for v1. The upstream architecture earns the bounded-cost claim — the no-duplication and package-boundary rules in CLAUDE.md are exactly what keeps the diff small.

Conclusion: the fork is real work but it is well-scoped work; the upstream architecture cooperates.

BMAD v6 — the canonical agent list and workflow

BMAD (“Breakthrough Method for Agile AI-Driven Development”) is the open-source (MIT) framework the user wants in place of Superpowers. v6.3.0 was released 2026-04-10 (repo, 45.1k stars, 5.3k forks). The canonical agent list per docs.bmad-method.org/llms-full.txt:

Agent	Identifier	Skills it owns
PM	`bmad-agent-pm`	`bmad-create-prd`, `bmad-create-epics-and-stories`
Architect	`bmad-agent-architect`	`bmad-create-architecture`, `bmad-check-implementation-readiness`
Developer	`bmad-agent-dev`	`bmad-dev-story`, `bmad-code-review`, `bmad-sprint-planning`, `bmad-create-story`, `bmad-retrospective`
UX Designer	`bmad-agent-ux-designer`	`bmad-create-ux-design`
Analyst	`bmad-agent-analyst`	`bmad-brainstorming`, `bmad-market-research`, `bmad-product-brief`

Workflow (also from llms-full.txt):

Planning — PM creates PRD → Architect creates Architecture doc → PM generates Epics + Stories → Architect runs bmad-check-implementation-readiness. All artefacts land in _bmad-output/planning-artifacts/.
Sprint planning — Dev runs bmad-sprint-planning → creates _bmad-output/implementation-artifacts/sprint-status.yaml.
Build cycle (per story, fresh chat each time) — Dev runs bmad-create-story → bmad-dev-story → bmad-code-review.
Retrospective — Dev runs bmad-retrospective after the epic completes.

Fresh chats are required per workflow (per the official docs) to avoid context conflicts. That is the single most important constraint to design Multica around: a Multica Issue must spawn a fresh agent session, not continue an existing one.

Conclusion: BMAD ships a defined agent list, a structured workflow, and a file-based handoff format (_bmad-output/) — all of which map cleanly onto Multica primitives.

BMAD-as-Claude-Code-skills is already packaged — adopt it, don’t rebuild

aj-geddes/claude-code-bmad-skills packages BMAD as installable Claude Code skills with 15 slash commands in ~/.claude/skills/bmad/:

Phase 1 — /workflow-init, /workflow-status, /product-brief
Phase 2 — /prd, /tech-spec
Phase 3 — /architecture, /solutioning-gate-check
Phase 4 — /sprint-planning, /create-story, /dev-story
Extensibility — /create-agent, /create-workflow
Creative — /brainstorm, /research
UX — /create-ux-design

Layout after install:

~/.claude/
├── skills/bmad/
│   ├── core/bmad-master/
│   ├── bmm/ (6 agents)
│   ├── bmb/builder/
│   └── cis/creative-intelligence/
└── config/bmad/
    ├── config.yaml
    ├── helpers.md
    └── templates/

PabloLION/bmad-plugin and 24601/BMAD-AT-CLAUDE are alternative ports — aj-geddes is the most active. State is tracked in YAML so commands resume across sessions, which fits the BMAD “fresh chat per workflow” rule cleanly.

Conclusion: there is a working, maintained Claude Code distribution of BMAD; the team installs it and gets every slash command, with no bespoke skill authoring required for v1.

The harmonisation pattern — Multica owns “who and when”, BMAD owns “how”

The two systems do not overlap. They compose:

Concern	Owner	Mechanism
What needs doing	Multica	Issues on the board
Who is doing it	Multica	Agents (BMAD personas registered as Multica Agents)
Where it runs	Multica	Runtimes (per-laptop daemon spawning Claude Code or Codex)
When it runs	Multica	Auto-pickup from queue, autopilots for cron
How the agent thinks	BMAD	Skills + slash commands inside the Claude Code session Multica spawns
What artefacts it produces	BMAD	`_bmad-output/` markdown + YAML, committed by the agent
Where the team sees progress	Multica	Real-time WebSocket stream into the board (per `CLI_AND_DAEMON.md`)

Concretely: every BMAD persona is registered in Settings → Agents as a Multica Agent (per the agent creation flow), each tied to a runtime. Each Multica Issue carries a bmad-skill label that tells the agent which slash command to run on pickup. The agent runs /dev-story (or /code-review, etc) inside its fresh Claude Code session, writes artefacts to _bmad-output/, commits to a feature branch, and posts the result back to the Issue via Multica’s existing WebSocket stream.

Conclusion: the two systems compose without overlap because they sit at different layers — Multica is the project-management API, BMAD is the per-task SOP.

GitHub PR review through Multica — what the fork has to add

Verified gap: Multica has no GitHub webhook receiver in upstream. Cross-checked three ways: the agentconn review explicitly notes “no GitHub/PR integration mentioned”; issue #257 is about pluggable agent providers (Factory Droid, Aider) and not about GitHub events; the upstream CLAUDE.md mentions GitHub only as the hosting platform.

The fork therefore adds:

server/internal/webhook/github.go — a Chi handler at POST /api/webhooks/github that verifies the X-Hub-Signature-256 HMAC against a workspace-scoped secret (per GitHub webhook docs).
PR-event mapping — on pull_request.opened / synchronize / labeled deep-review, create a Multica Issue with the PR link as the body, the label as a tag, and an assignee chosen by routing rules.
Routing rules — Issue auto-assigned to the workspace’s “PR Reviewer (Claude)” agent by default; second-opinion label additionally triggers “PR Reviewer (Codex)“. Both run in parallel via the daemon (Multica already supports concurrent assigned work — verified in CLI_AND_DAEMON.md).
Result posting — when the agent finishes, the runtime hits a small pkg/githubclient to post line-level comments back to the PR using the same GITHUB_TOKEN the workspace stores. The Issue stays as the audit trail.

This is the equivalent of anthropics/claude-code-action but driven by Multica rather than GitHub Actions, which means: every review run is visible on the board; reviews accumulate as Issues with full transcript; the team can re-run, compare, or escalate without leaving Multica.

Conclusion: the webhook is a contained ~300-line Go addition, gated by HMAC, with zero changes to upstream’s auth or storage layer — small enough to maintain, big enough to remove the GitHub-Actions detour.

Prompt Auditor — a built-in autopilot that reviews the team’s own prompts

Multica already supports Autopilots as a top-level concept (verified — it’s a sidebar tab). The fork wires one new built-in autopilot:

Cadence: nightly at 02:00 NZ time, weekdays only (configurable).
What it does: spawns a Claude Code session that walks oxflow/.claude/skills/, oxflow-docs/prompts/, every CLAUDE.md in the workspace, and the four committed research notes, then runs a “prompt-quality rubric” skill (one we author — patterned on the research-quality prompt).
What it produces: new Issues tagged prompt-audit with three categories — new skill suggested (with proposed file path), inefficiency in existing skill / CLAUDE.md, new agent worth registering. Each Issue links the file it audited and quotes the line it flagged.
Triage: human reads, accepts (assigns to a person or to the relevant BMAD agent), or closes. No agent ever rewrites the team’s prompts unattended — the loop has a human gate.

This solves a problem we don’t currently solve: today nobody re-reads our own skills / CLAUDE.md files for staleness. The Auditor is the cron job that does.

Conclusion: an autopilot that audits us turns the open-source advantage of Multica into a continuous quality lift; the only fork-side cost is the autopilot definition and the rubric skill, both small.

Wiki tab — embedding the oxflow-docs viewer in Multica chrome

Two implementation paths:

Approach	Effort	Pros	Cons
v1: iframe	~0.5 day	Zero re-implementation; existing `oxflow-docs/app/` viewer ships unchanged	Iframe chrome may feel stitched-on; cross-origin auth needs care
v2: re-render markdown	~2 days	Native Multica chrome; uses existing `packages/views/editor/` markdown renderer	Have to wire oxflow-docs’s sidebar list into a Multica panel

v1 first. The iframe lands today; the re-render is a follow-up if v1 feels rough. Either way the user lands on /{workspace}/wiki and sees the same docs/, research/, decisions/ content that oxflow-docs/app/serve.py serves locally.

Conclusion: the wiki tab is the lowest-risk part of the fork; it’s the part that proves the fork-and-extend pattern works before the higher-risk webhook + autopilot land.

Skills sync — Multica already has the right shape

Multica’s root skills-lock.json is a package-lock.json-style file pinning skills by GitHub source + commit hash. The format today:

{
  "version": 1,
  "skills": {
    "frontend-design": { "source": "anthropics/skills", "sourceType": "github", "computedHash": "..." },
    "shadcn":          { "source": "shadcn/ui",         "sourceType": "github", "computedHash": "..." }
  }
}

Add BMAD here:

"bmad": { "source": "aj-geddes/claude-code-bmad-skills", "sourceType": "github", "computedHash": "..." }

No fork required for this. Plus the workspace’s own custom skills (oxflow-prompt-rubric, oxflow-pr-style-guide, etc) sit in the same lock file once authored.

Conclusion: the Skills tab is already team-shared and version-pinned; BMAD slots in via configuration, not code.

What Superpowers loses on

Superpowers is a per-developer Claude Code plugin. It bundles useful local skills, hooks, and session helpers — and it does that well for one engineer at a desk. What it does not do is:

give the team a shared board where you can see what each agent is doing right now,
enforce a sprint structure with hand-offs (PRD → Architecture → Story → Code → Review → Retro),
audit anyone else’s prompts on a cadence,
assign work to both a Claude agent and a Codex agent on the same artefact and see them next to each other.

Multica + BMAD covers all four of those, and BMAD’s /code-review skill can run as a standalone Multica agent the way a Superpowers user runs it locally. The user’s call to drop Superpowers is the right call: nothing it provides is lost; everything it can’t provide is gained.

Conclusion: Superpowers is a valid local-only tool that Multica + BMAD strictly supersedes for a team workflow.

Recommendation for 361

Adopt the fork-and-extend stack. Concrete week-by-week:

Week 1 — get the baseline running, no fork yet.

Self-host upstream Multica via the documented path: make selfhost then docker compose -f docker-compose.selfhost.yml up (SELF_HOSTING.md). Point it at the existing Neon Postgres (per the DB analysis note, Neon ap-southeast-2 is locked).
Each dev runs multica login then multica daemon start; the daemon auto-detects Claude Code and Codex CLIs and registers them as runtimes.
Install BMAD via aj-geddes/claude-code-bmad-skills on every laptop. Run /workflow-init on a throwaway oxFlow scratch workspace; verify all 15 slash commands resolve.

Week 2 — fork and add the wiki tab.

Fork upstream to 361-coders-nz/multica, pin to the v0.2.6 commit. Open a tracking issue for upstream syncs (target: rebase weekly).
Add packages/views/wiki/, the route segment, the NavKey entry, the WorkspacePaths method, and the sidebar entry. v1 = iframe of the existing oxflow-docs/app/ viewer.
Cut a tag (oxflow-v0.2.6-wiki1), redeploy.

Week 3 — webhook + the two new agents.

Add server/internal/webhook/github.go. Workspace setting holds the HMAC secret + GITHUB_TOKEN. POST /api/webhooks/github is exposed publicly; everything else stays behind workspace auth.
Register PR Reviewer (Claude) and PR Reviewer (Codex) as built-in agents — both backed by the BMAD /code-review skill; the only difference is the runtime.
Register Prompt Auditor as a built-in autopilot, scheduled nightly. Author the oxflow-prompt-rubric skill it runs (single markdown file, ~200 lines, modeled on prompts/research-quality.md).

Week 4 — onboard the team to the BMAD loop.

Each dev creates the BMAD personas they own as Multica Agents. PM is one person’s, Architect another’s, Dev shared.
The Phase 1 oxFlow PRD becomes the first BMAD /prd run; output lands in _bmad-output/planning-artifacts/PRD.md and gets committed.
From there, every story is a Multica Issue tagged with the bmad-skill it should run. The Reviewer agents take every PR; the Auditor sweeps prompts overnight.

Cost envelope (USD / month):

Render web service for self-hosted Multica: ~$25 (Standard instance is enough for 5 devs).
Postgres: $0 incremental (existing Neon).
Anthropic tokens (Claude reviewer + dev sessions, 100 PRs / mo): **$200**.
OpenAI tokens (Codex second-opinion, label-gated): ~$50.
Prompt Auditor nightly run: ~$15.
Total: ~USD 290–325 / month. Marginally lower than the prior CodeRabbit-hybrid envelope (USD 300–500) because CodeRabbit Free is dropped — agents do every review through Multica.

Revisit triggers:

Multica fork rebase exceeds 1 dev-day / month for two consecutive months → fall back to upstream + sidecar.
BMAD v7 ships breaking changes → re-pin the skill repo, run a verification sprint.
A published prompt-injection vulnerability against the Multica webhook → temporarily disable the webhook and route PR review back through claude-code-action.

Alternatives considered

Stay with claude-code-action + CodeRabbit hybrid (the prior note’s recommendation). Lower fork-maintenance burden; loses the team-wide agent visibility surface, the embedded wiki, the autopilot for prompt audit, and the ability to see Claude and Codex reviews side-by-side. Revisit: if the Multica fork rots.
Self-host upstream Multica unmodified, run a sidecar service for the webhook + a separate static site for the wiki. Cleaner upgrade path because the Multica fork stays at zero. Two services to deploy and the wiki is no longer in Multica chrome. Revisit: if upstream Multica adds a wiki extension point natively.
Anthropic Managed Agents instead of Multica. Pay-per-session-hour pricing model, no UI, no wiki, no Codex. Wrong abstraction for “team task board with embedded wiki”. Revisit: never, unless Anthropic ships a UI.
Stick with Superpowers + BMAD without Multica. No team board, no agent visibility, no autopilot. Fine for a single dev but loses every group-coordination win. Revisit: if the team shrinks to 1.
Build our own task-board-for-agents from scratch. Months of work to reach Multica’s surface. Not worth it when the upstream is Apache-2.0 and well-engineered.

Sources

Multica — repo, docs, code

multica-ai/multica (16.9k stars, v0.2.6 2026-04-18)
Multica CLAUDE.md — architecture + package boundaries
Multica AGENTS.md — quick reference
Multica SELF_HOSTING.md — Docker compose, three services, ports
Multica SELF_HOSTING_ADVANCED.md
Multica CLI_AND_DAEMON.md — daemon, runtime detection, OAuth
Multica apps/web/app/[workspaceSlug]/(dashboard)/ — dashboard route segments (verified sidebar tabs)
Multica packages/views/layout/app-sidebar.tsx — NavKey union, sidebar groups
Multica skills-lock.json — skill pinning format
Multica issue #257 — pluggable provider proposal (no webhook today)
OpenClaw — Multica self-host walkthrough
AgentConn — Multica review — confirms no GitHub integration today
Medevel — Multica

BMAD method

bmad-code-org/BMAD-METHOD (45.1k stars, v6.3.0 2026-04-10, MIT)
BMAD docs landing
BMAD llms-full.txt — canonical agent + skill list
aj-geddes/claude-code-bmad-skills — Claude Code distribution
BMAD Claude skills site
PabloLION/bmad-plugin — alternative plugin packaging
24601/BMAD-AT-CLAUDE — earlier port
Courtlin Holt-Nguyen — Mastering the BMAD method
Vishal Mysore — what is BMAD-METHOD

Claude Code, Agent SDK, GitHub action

GitHub webhook reference

Cross-references — prior 361 research

DB analysis — Neon ap-southeast-2 baseline this stack runs on
DevOps + infrastructure — Render + GitHub Flow + Neon branch-per-PR
Multica + Managed Agents — this note overrides its “skip Multica for Phase 1” call
CodeRabbit vs DIY agents — this note overrides its hybrid recommendation
Agentic coding + PR review
Shared project memory

Linked from

This note will be referenced from status/daily/2026-04-20.md once the daily log for today lands. A short ADR (decisions/0001-orchestration-stack.md) should follow once the team has worked through Week 1 of the rollout — it is the kind of direction-setting decision the ADR record exists for.

oxFlow Wiki

Explorer