bonsaipowers

This is the Bonsai Software fork of obra/superpowers, customized with team-specific skills and Tier 2 orchestration edits. Team members should install from this repo, not upstream.

Install (Bonsai team)

In Claude Code:

/plugin marketplace add BonsaiSoftware/bonsaipowers
/plugin install bonsaipowers@bonsaipowers

The first command registers this repo as a marketplace; the second installs the plugin from it. The default branch on GitHub is bonsai-custom — that's where all Bonsai customization lives — so the marketplace fetches our fork, not upstream.

To update:

/plugin update bonsaipowers

After installing, start a new session and say brainstorm a small feature. The first checklist step should be "Structured codebase recon" (step 1) — the agent should grep package.json, read CLAUDE.md, and find a similar existing feature before asking any clarifying questions. Later, before proposing approaches, it should run at least one context7 query AND one WebSearch query (the Tier 2 research HARD-GATE). If those Bonsai-specific behaviors are missing, you're on the wrong branch.

Required MCP servers

The Bonsai workflow depends on three MCP servers that are not bundled with the plugin — per the "no MCP in plugin" rule (see CLAUDE.md), MCPs belong in the consuming project's .mcp.json (shared with the team, committed to git) or the user's ~/.claude.json (personal, not shared). The plugin ships zero MCP config so it works cleanly with both per-project and per-user setups.

MCP	Used by	Why it's required
context7	brainstorming (step 4 research HARD-GATE), writing-plans (research section), executing-plans (JIT API verification), subagent-driven-development (implementer prompts)	Library documentation and API signature lookups. Without it, brainstorming fails its research gate, plans ship guessed method signatures, and implementers can't verify APIs before writing code.
microsoft-docs	writing-plans (research step 6, Azure features)	Official Azure and Microsoft documentation plus code samples via microsoft_code_sample_search. Required whenever a plan touches an Azure service — which, for this team, is most of them.
chrome-devtools	bonsai-verify-ui	Drives real Chrome from the orchestrator's main context (mcp__chrome-devtools__navigate_page, click, fill, take_snapshot, evaluate_script, etc.). Without it, runtime UI verification after subagent-driven-development cannot run.

Follow each MCP server's own install instructions. If any are missing, the relevant skills will surface an explicit error rather than silently degrading — but it's a lot faster to configure all three up front.

Pinning to a specific version

For critical work where you don't want surprise updates, pin to a tag by passing it as a ref when adding the marketplace:

/plugin marketplace add BonsaiSoftware/[email protected]
/plugin install bonsaipowers@bonsaipowers

Current version lives in .claude-plugin/plugin.json. Maintainers tag stable points on bonsai-custom when significant Tier 2 changes ship.

Maintainers

If you're editing this repo (not just installing it), read CLAUDE.md and docs/bonsai/customizing/README.md before touching anything in skills/ — the three-tier model determines what's safe to change. Local development loop is in the Local Development section further down.

---

Superpowers

Superpowers is a complete software development methodology for your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them.

Quickstart

Give your agent Superpowers: Claude Code, Codex CLI, Codex App, Factory Droid, Gemini CLI, OpenCode, Cursor, GitHub Copilot CLI.

How it works

It starts from the moment you fire up your coding agent. As soon as it sees that you're building something, it doesn't just jump into trying to write code. Instead, it steps back and asks you what you're really trying to do.

Once it's teased a spec out of the conversation, it shows it to you in chunks short enough to actually read and digest.

After you've signed off on the design, your agent puts together an implementation plan that's clear enough for an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing to follow. It emphasizes true red/green TDD, YAGNI (You Aren't Gonna Need It), and DRY.