SuperClaude reshapes how Claude Code thinks; nablr adds a layer that governs what Claude Code is allowed to ship. SuperClaude is a large, install-time bundle of markdown instructions and slash-commands that get loaded into ~/.claude/ — it steers a single session's behavior through prompt injection and persona framing, with no independent process checking the result. nablr is a standing MCP server with its own state machine, AST-based scanners, and validator gates that run as real code, outside the model's control, and can refuse to let a phase close.
Put differently: SuperClaude answers "how should Claude behave on this task?" nablr answers "how do I know whether Claude's output is actually good, and who's on the hook if it isn't?" They are not mutually exclusive — SuperClaude's personas/commands run inside a session; nablr's gates run around one. A team could plausibly run both, though nothing in either project is built with that combination in mind.
allowed=False. SuperClaude's "quality scoring" and mode-switching are the model narrating its own compliance — no external check..nablr_state/, docs/requirements/, nablr-reports/). SuperClaude has no native state store; cross-session memory is delegated to a third-party MCP server.uvx nablr, one MCP server process. SuperClaude: pipx install SuperClaude && SuperClaude install, writes ~50MB of markdown/config into ~/.claude/.The two projects start from different diagnoses of why AI-assisted coding goes wrong.
AI assistants accelerate typing, not engineering. More code ships, same defect rate, more rework. The fix isn't a smarter prompt — it's a governance layer that sits between the model and the repo: a place where "did this pass QA" is answered by a validator function, not by the same model that wrote the code grading its own homework. Positioned explicitly against SonarQube (analysis without workflow), Jira (tracking without analysis), and raw Cursor/Copilot (generation without either).
Claude Code's default behavior is generic — it doesn't reliably adopt the mental models of an architect, a security reviewer, or a PM, and users repeat the same context-setting prompts every session. The fix is to pre-load specialized behavioral instructions (personas, modes, command templates) so the model consistently reasons like the right kind of specialist. Validation is explicitly "through model behavior, not technical constraints" — the stated mechanism is better thinking, not an external check.
The load-bearing philosophical split: nablr treats the LLM as a capable-but-unreliable actor that needs an external referee. SuperClaude treats the LLM as an actor that just needs better direction. Neither belief is wrong on its face — but it means nablr's entire value proposition collapses if its gates fail open (a governance layer with no teeth is just more markdown), while SuperClaude's proposition collapses if its instructions get ignored or out-context'd (a persona with no memory is just a longer prompt).
| Aspect | nablr | SuperClaude |
|---|---|---|
| Work hierarchy | Epic → Feature → Story, each a durable file under docs/requirements/, tracked through an 8-phase state machine (Intake → Discovery → PM → Specifier → Architect → QA/TestDesign → Developer → PR Review → Tester/Security → Close) | Slash command invocation (/sc:implement, /sc:analyze, …) scoped to the current session; no cross-session work object |
| Role model | 19 personas, each a distinct MCP prompt with its own rule-file bundle, activated via agent(action="activate"), gated to specific phases | ~20 "agents" (personas) selected by context-aware routing inside a single ongoing conversation; no phase gating between them |
| Fix vs. feature | Separate Mandatory Fix Workflow: forensic_engineer (RCA) → strategist (trade-offs) → impact_architect (blast-radius) → developer, distinct from the feature flow | No structural distinction; a bug fix and a feature both go through whichever command/persona the user or router picks |
| Discovery/audit | scan (12 targets: health, debt, security, complexity, dead_code, ai_patterns, docs, codemap_freshness, migration_readiness, full_suite, …), audit_discovery, generate_codemap — all run as local static analysis (tree-sitter AST) | /sc:analyze, "Deep Research" mode with multi-hop web search and a self-reported confidence score (0.0–1.0) — reasoning-based, not AST-based |
| Testing | browser tool for E2E check/write/execute/verify; full_suite gate runs the project's real test command and signs a pass/fail artifact before PR review | No independent test runner; testing is whatever the model does when a /sc:test-style command is invoked in-session |
nablr exposes a small number of namespaced dispatcher tools (scan, workflow, validate, remediate, context, pattern, plus flatter action tools) — a deliberate API-design choice to keep the MCP tool count low while the action space stays large via an action/target parameter. SuperClaude exposes ~30 distinct slash commands as the primary UX, each a separate markdown-templated behavior; breadth is achieved by adding more commands, not more parameters on fewer commands.
| nablr | SuperClaude | |
|---|---|---|
| What it is, mechanically | A standing MCP server process (stdio JSON-RPC) with real application code: a state machine, a validator registry, AST scanners, a context graph | A one-time installer that writes markdown instruction files + a settings JSON into ~/.claude/; no persistent process of its own |
| Language / runtime | Python 3.12+, fastmcp/mcp, tree-sitter (AST), networkx (graphs), pydantic, structlog | Python 3.8+ installer/CLI (PyPI SuperClaude, also an npm wrapper); the delivered payload itself is markdown/JSON, not executable logic |
| Distribution | uvx nablr / pip install nablr; registered once as an MCP server in the client config; nothing written to ~/.claude/ | pipx install SuperClaude && SuperClaude install, or npm install -g, or git-clone + install.sh; ~50MB written into the user's global Claude Code config directory |
| How "intelligence" is added | By running deterministic code (AST walk, state transition, file existence check) that the model cannot talk its way around | By injecting more/better-framed context into the model's own context window before it reasons |
| Where state lives | Local JSON/markdown under the project (.nablr_state/, docs/, nablr-reports/) — survives restarts, diffable, git-trackable | Nowhere by default; optional Serena MCP server for cross-session memory is a separate install |
| External calls | One disclosed outbound path — license validation against nablr's own API; all code analysis stays local (air-gapped by design) | None inherent to the framework itself, but several of the optional bundled MCP servers (Tavily search, Context7 docs, Playwright) are themselves network-calling |
| Bundled MCP ecosystem | None — nablr is the MCP server; no other servers are wired in | Up to 8 optional MCP servers pre-wired: Tavily, Context7, Sequential-Thinking, Serena, Playwright, Magic, Morphllm-Fast-Apply, Chrome DevTools |
| Versioning trajectory | Single architecture since inception (dispatcher tools + state machine); no major rewrite announced | v5 TypeScript plugin system in development specifically to replace eager-loading of all instruction files with selective loading (issue #419) — a tacit admission the current markdown-everything-always model doesn't scale |
This is the sharpest technical distinction and worth stating plainly, because it's easy to read both projects as "the same idea, different packaging."
workflow(action="validate_and_advance") is a Python function that inspects on-disk artifacts and returns a boolean. Whether the model "agrees" its work is done is irrelevant — the gate either finds the artifact or it doesn't. (Per nablr's own dogfood audit, several of these gates historically failed open rather than closed — a real implementation risk — but the design intent and the fixed-in-practice examples are still "code decides," not "model decides.")health_report.md, security_audit_*.md, a handoff log, a context graph. SuperClaude's output is the session transcript — there's no separate report format, because there's no separate process generating one.Despite the architectural gap, the two projects are answering some of the same user complaints, and it's worth naming the overlap so the comparison doesn't read as one-sided:
rules/<category>/*.md); SuperClaude's entire payload is markdown files. The difference is where the markdown sits in the pipeline: nablr's rules are gated behind phase-and-role logic in code; SuperClaude's rules are the top-level product.Two parallel research passes: (1) direct source inspection of this repo — README.md, CLAUDE.md/AGENTS.md, docs/ARCHITECTURE.md, docs/USP.md, pyproject.toml, and the src/nablr/ tool implementations; (2) SuperClaude's public README, install docs, a GitHub issue on its v5 plugin rework, and one third-party technical critique (dev.to), since no local source tree for SuperClaude exists in this environment.
Caveats: SuperClaude figures (agent count, command count, star count) vary across its own v3/v4/v5 docs and were still in flux as of this research; where sources disagreed, the higher/more-recent figure is cited and the disagreement is noted in-line. This is a comparison for internal brainstorming, not a security or correctness audit of either project — nablr's own known gate-enforcement gaps (documented separately in docs/audit/nablr-audit-report.html) are referenced above only where they bear on the config-vs-code distinction, not re-litigated in full.