`aidokit` vs. alternatives

An honest comparison of aidokit against the other structured-AI-workflow kits and the "just write your own CLAUDE.md" baseline. Use it to decide whether aidokit is the right choice for your project — not to be sold on it.

aidokit is one of several ways to put discipline around an AI coding CLI. Most teams should pick something — this page exists to help you pick the right something, even if that turns out not to be aidokit.

At a glance #

Aspect	aidokit	GitHub SpecKit	BMAD-METHOD	Superpowers	Hand-rolled CLAUDE.md
Primary surface	One CLI scaffolder, multi-package	`specify` CLI + slash commands	Persona prompts + numbered story files	Skill library (plugins)	Plain markdown files you write
Setup cost	One command (`npx aidokit init`)	One command (`specify init`)	Manual setup per project	Plugin install per CLI	None — you author it
Enforcement	Watchdog hooks (scope, deletion, version) + conformance verification	Light — relies on convention	Light — relies on persona discipline	None (skills are guidance)	Whatever you build in
Role separation	Six explicit roles, scoped MCPs per role	Spec/plan/tasks phases	Multi-persona (PM/Architect/Dev/QA)	Per-skill scoping	Whatever you wire up
Audit / governance	Strict tier: capability declarations, change summaries, signed manifest	Not designed for it	Not designed for it	Not designed for it	DIY
Adapters	Claude Code (Strict), Codex + Copilot (Minimum, growing)	Claude, Copilot, Cursor, Gemini, Codex (lighter touch on each)	Mostly Claude-centric	Plugin-host dependent	Whatever CLI you use
Stack packs	5 (Node-TS, Node-JS, Python, React, Go)	Stack-agnostic	Stack-agnostic	Stack-agnostic	Hand-tuned
Vocabulary cost	Medium — 6 roles, 3 tiers, MCP scoping (hideable at Starter tier)	Low — 3 slash commands	Medium — multiple personas	Low — skill names	Zero — your words
Defensibility	Engineering rigor, tier system, audit artifacts	GitHub-backed mindshare	Active community	Plugin distribution	None — it's yours
License & telemetry	Apache-2.0, zero telemetry	MIT, opt-in telemetry	MIT, none	Varies	N/A

When `aidokit` is the right pick #

You'll get the most out of aidokit if two or more of these describe you:

You're a TypeScript or Python team using Claude Code daily and your hand-rolled CLAUDE.md has outgrown its usefulness.
You want six-role separation (Researcher / Architect / Planner / Builder / Tester-Reviewer / Maintainer) with watchdog hooks that enforce scope rather than just suggest it.
You care about audit artifacts — capability declarations, change summaries, conformance verification — that survive code review and (eventually) compliance review.
You expect to use more than one AI coding CLI on the same project, now or soon (Claude Code today, Codex / Copilot tomorrow).
You value engineering rigor in your tooling: typed contracts, deterministic emission, no template engines, no LLM calls in the scaffolder itself.

When `aidokit` is the wrong pick #

Be honest with yourself if any of these apply:

You just want a tighter CLAUDE.md. Write one. It's faster than learning a new vocabulary, and you can graduate to aidokit later.
Your team uses Cursor, Aider, or Continue as the primary AI coding interface. No aidokit adapter exists for those today; SpecKit or a hand-rolled approach is a better fit.
You want a graphical project-management surface. aidokit is CLI-only by design and stores state in files + Beads. Linear, Jira, and friends are not in scope.
You need vendor-supplied SLA / commercial support. aidokit is OSS-only (Apache-2.0) with no commercial offering. SpecKit (GitHub-backed) has a clearer institutional home.

Honest weaknesses (today) #

We'd rather you find these here than in your project a month from now.

Conformance levels differ across first-party adapters. All three first-party adapters are supported in v1.0. Conformance levels reflect the maturity of each adapter's emission against the contract: claude-code ships at Strict, codex and copilot ship at Minimum. The contract surface is the same for all three; conformance level indicates which optional capabilities are implemented today (see docs/specs/conformance-levels.md).
The vocabulary is real. Six roles, three tiers, MCP scoping, Beads, and slash commands are a lot to absorb. The Starter tier hides most of it, but Standard and Strict require investment.
Single-maintainer pace. aidokit is built primarily by one person. Community maintainers for non-canary stack packs are being recruited; until they land, response times reflect that.
The dogfood gate is strict. Adapter changes must match the hand-built reference snapshot byte-for-byte (with documented exceptions). This catches drift early but also slows adapter authoring.
No hosted dashboard, no telemetry. Zero usage analytics by design — the trade-off is that the maintainers have no way to see what's breaking unless you tell them (mailto in your CLAUDE.md, GitHub issues, or the devlog).

Picking a starting point #

If you describe yourself as…	Start with…
"I have no structure, want to try something."	SpecKit or `aidokit` Starter tier. Both are 60-second setups.
"I have a CLAUDE.md and it's getting messy."	`aidokit` Standard tier. It's exactly the layer you'd build next.
"I'm in a regulated industry / need audit trails."	`aidokit` Strict tier. No other tool ships capability declarations + audit export.
"I want active community + persona-based discipline."	BMAD-METHOD. Strong community, lower engineering rigor than `aidokit`.
"I want skills, not a workflow."	Superpowers. Composes well with `aidokit` — you can install both.
"I want to learn how this stuff works."	Hand-roll your own first. Three months of pain teaches you what `aidokit` is solving.

Maintenance pledge #

This page is meant to stay honest. If a competitor ships something that weakens aidokit's case for a given audience, the table above should reflect that within one release cycle. If you spot an inaccuracy — about aidokit or any of the alternatives listed — open an issue or send a one-line note to feedback@aidokit.dev. Corrections matter more here than anywhere else in the docs.

aidokit vs. alternatives