nablr doesn't need SuperClaude's mechanism — it needs to finish wiring the mechanism it already built. Every high-value idea in SuperClaude (cross-session learning, token-efficient loading, pre-build review) already has a code-level counterpart sitting half-built inside nablr: a pattern-capture tool nobody calls automatically, a context graph that's loaded whole but barely used, a remediation tier system with no memory of its own outcomes, and an FPY metric that was written about in an audit but never instrumented.
The actionable move isn't "import SuperClaude's behavioral modes." It's: close the loops nablr already has open, using the diagnosis SuperClaude's own architecture points at — that eager, uncurated context is the dominant token-and-quality cost, not prompt verbosity.
pattern_learner.py), zero automatic callers outside manual dispatch. No learning from failures.handoff_log.jsonl (1,701 real lines). Audit's "FPY" section was aspirational.capture_pattern (pattern_learner.py:123-209) appends to .nablr_cache/patterns_registry.jsonl; find_patterns (:234-294) scores by keyword/tag overlap only — no embeddings. Grep across the repo: no caller besides the MCP dispatch in server.py:1258-1272 invokes it. No persona, validator, or gate consults it automatically.context_graph.py:472-580 reads the full nablr-reports/context_graph.json (measured: 16.5MB, 32,413 nodes, 144 edges — 31,329 nodes are type issue, essentially unconnected) into memory on first access every session. format_for_prompt_graph() (:582-679) then BFS's down to ~5-8 nodes for the actual prompt injection at start_agent.py:213-222. The query-capable actions (get_related, subgraph, query in context_impl.py) exist but aren't used on the default injection path.VIOLATION_CLASSIFICATION (compliance_remediation.py:69-157) maps rule IDs to tier + responsible agent; Tier1 fixes run through ruff check --fix with before/after violation counts (tier1_fixer.py:180-322) — not just claimed, actually re-checked. But no module aggregates remediation success/failure across sessions; the closest longitudinal metric is override_rate_report.py:60-155, which tracks gate-bypass rate, not remediation outcome.FPY, first_pass_yield, efficiency_report across src/nablr: zero matches outside prose docs. handoff_logger.py:109-139 writes JSONL with timestamp/event/story_id/phase/outcome — no token count, no payload size, no duration field. runner/gate.py:evaluate_gate (:82-130) is binary pass/fail on report freshness + exit codes, nothing retry-aware.start_agent.py:load_rules (:64-116) concatenates whole .md files with no section-level filtering beyond a coarse backend/frontend substring exclusion. Measured: architect 10 files/36.3KB (~9k tok), developer 10 files/50.5KB (~12.6k tok), scrum_master 6 files/24.2KB (~6k tok) — reloaded on every phase transition, and scrum_master alone bookends every story.Where it comes from: SuperClaude is rebuilding its own loader in v5 specifically because eager-load-all-instructions doesn't scale (GitHub issue #419) — the exact disease confirmed at start_agent.py:106.
What to change: load rule sections by phase-need, not the whole persona bundle. A developer persona doesn't need architecture-review rules until PR-review phase; a scrum_master doesn't need the same intake checklist re-read at every subsequent phase transition it bookends. Split the current whole-file concatenation into phase-tagged sections and only pull what the current phase requires.
Expected effect: cuts a meaningful share of the ~12.6k-token developer payload per activation — and activation repeats across every phase transition in a story, so the saving compounds, not a one-time discount.
Where it comes from: not a literal SuperClaude feature — but the same lesson their memory delegation (to the Serena MCP server, which is query-on-demand rather than an eager dump) points at. nablr already built the query surface; it just isn't the default path.
What to change: swap format_for_prompt_graph's "load the whole 16.5MB file into memory, BFS in-process" for an indexed/on-disk query using the existing get_related/subgraph/query actions in context_impl.py. Separately: the graph's 99.6% edgeless issue-node pile suggests capturing raw scan findings as graph nodes isn't earning its cost — either start writing real edges (issue → file → decision) or stop dumping issues into the graph and let TECH_DEBT.md carry that data instead.
Expected effect: near-zero session-start IO/memory cost instead of a 16.5MB full-file load for a 5-8 node prompt injection.
Where it comes from: SuperClaude's "ReflexionMemory" pitch — closing the loop between an error occurring and a future session remembering it. The pitch itself is self-described and unverified in their repo, but the diagnosis is right, and nablr has the storage half of this already built and unused.
What to change: auto-fire capture_pattern when a Tier2/Tier3 remediation halts (compliance_remediation.py's tier dispatch) and when a fix-flow forensic RCA closes, tagged with the triggering rule ID. Then have find_patterns auto-inject its top matches into the developer/architect prompt on activation — today it has zero callers outside the manual MCP dispatch at server.py:1258-1272.
Expected effect: repeat mistakes surface at build-time instead of being rediscovered at the next Tier3 halt or the next audit. This is the most direct lever on first-pass acceptance of anything on this list, because it acts before the code is written rather than after.
Where it comes from: SuperClaude's "Business Panel" mode — running multiple specialist angles over a plan before committing to it.
What to change: before a spec/design doc is marked ready-for-build, run architect + security_owner + qa_lead perspectives over it as a cheap gate, reusing personas that already exist rather than adding new ones. Nothing about this requires new infrastructure — just an additional review step wired into the existing Specifier→Architect phase boundary.
Expected effect: catching a bad spec at this stage costs one review pass. Catching the same defect at a Tier3 halt costs a full forensic→strategist→developer remediation cycle (nablr's own known worst inefficiency, per the earlier audit's rework-dominates-token-cost finding). This is a cheap trade.
Where it comes from: steal the practice of publishing cost/efficiency telemetry — not SuperClaude's actual numbers, which are self-reported ("2-3x faster, 30-50% fewer tokens") with no independent verification anywhere in their repo or docs.
What to change: add payload_tokens and retry_count fields to the existing handoff_logger.py:log_event call (:109-139) — same file, same write path, no new subsystem. override_rate_report.py:60-155 is a working template for exactly this shape of longitudinal parse; clone its structure for a real FPY report instead of writing another aspirational doc about one.
Expected effect: turns nablr's own previously-promised STORY-FPY-METRICS-001 from aspirational prose into a computable report, and gives every other recommendation on this page something to be measured against.
scan/workflow/validate keyed by an action parameter) is the better API design for a growing action space — don't regress toward one-MCP-tool-per-verb to look more like SuperClaude's surface.payload_tokens/retry_count to handoff_logger.py:log_event (Rec 5) — everything else benefits from having this data flowing before it's needed.capture_pattern calls on Tier2/Tier3 halts and fix-flow RCA close (Rec 3) — reuses existing storage, just adds callers.Grounded in a direct source read of five nablr subsystems (pattern_learner.py, context_graph.py + live context_graph.json on disk, compliance_remediation.py + tier1_fixer.py, handoff_logger.py + runner/gate.py, prompts/start_agent.py), plus the earlier comparison research against SuperClaude's public README, install docs, and one third-party critique. All nablr file:line citations and measured artifact sizes (16.5MB graph, 1,701 handoff-log lines, per-persona byte counts) are from direct reads, not the audit report or memory.
Caveats: SuperClaude's own efficiency claims ("2-3x faster," "30-50% fewer tokens") are self-reported by that project with no independent benchmark found — they're cited here only as the stated diagnosis behind their loader rework, not as a number nablr should target. nablr's own artifact sizes are a point-in-time snapshot (2026-08-06) and will drift as the project accumulates more scan/session data.