No Reason to Be Kind

SuperClaude is the same configuration layer for Claude Code covered here before: slash commands,
agents, behavioural modes, fifty-seven items in the catalogue in total. Two of them were already
out. /sc:pm turned out to be a session-management layer built entirely from calls to a server
this setup doesn't run. Deep Research mode wanted to run unbounded, multi-hop searches with no
cost gate in sight. Out of everything left, this setup kept exactly one command:

› /sc:spec-panel

Fifty-seven items in the catalogue. One command kept.

What it actually is

No install, no MCP (Model Context Protocol) server, no dependency on the rest of the framework. The
command file is a single prompt, about four hundred and forty lines long, that assembles a panel of
real named software engineers and has each one critique a document through their own actual
documented methodology.

Expert	Methodology	Sample critique it's instructed to ask
Karl Wiegers — Requirements engineering pioneer, author of Software Requirements	SMART criteria, testability analysis, stakeholder validation	"This requirement lacks measurable acceptance criteria. How would you validate compliance in production?"
Gojko Adzic — Creator of Specification by Example	Given/When/Then scenarios, example-driven requirements, collaborative specification	"Can you provide concrete examples demonstrating this requirement in real-world scenarios?"
Alistair Cockburn — Use-case methodology pioneer, Agile Manifesto co-author	Goal-oriented analysis, primary-actor identification, scenario modeling	"Who is the primary stakeholder here, and what business goal are they trying to achieve?"
Martin Fowler — Software architecture and refactoring, Thoughtworks	Interface segregation, bounded contexts, refactoring patterns	"This interface violates the single responsibility principle. Consider separating concerns."
Michael Nygard — Author of Release It!	Failure-mode analysis, circuit-breaker patterns, operational excellence	"What happens when this component fails? Where are the monitoring and recovery mechanisms?"
Sam Newman — Microservices and distributed systems author	Service decomposition, API versioning, distributed system patterns	"How does this specification handle service evolution and backward compatibility?"
Gregor Hohpe — Co-author, Enterprise Integration Patterns	Message-driven architecture, integration patterns, event-driven design	"What's the message exchange pattern here? How do you handle ordering and delivery guarantees?"
Lisa Crispin — Agile testing author	Whole-team, risk-based testing, quality attribute specification	"How would the testing team validate this requirement? What are the edge cases and failure scenarios?"
Janet Gregory — Testing advocate, co-author with Crispin	Specification workshops, "three amigos", quality conversation facilitation	"Did the whole team participate in creating this specification? Are quality expectations clearly defined?"
Kelsey Hightower — Cloud-native and Kubernetes advocate	Cloud-native patterns, infrastructure automation, operational observability	"How does this handle cloud-native deployment and operational concerns?"

The command does not throw all ten at every document. A focus flag picks a smaller panel suited to
the document's shape:

Focus	Panel (lead first)	For
requirements	Wiegers, Adzic, Cockburn	Constraints and requirement lists
architecture	Fowler, Newman, Hohpe, Nygard	System-design and interface documents
testing	Crispin, Gregory, Adzic	Test strategy, acceptance-criteria coverage
compliance	Wiegers, Nygard, Hightower	Security, audit, operational-risk documents

Native invocation, straight from the framework, takes a mode, an expert list, a focus area and a
format. On this setup it runs differently: as a promoted Claude Code skill, called directly rather
than through the framework:

Skill({ skill: "spec-panel", args: "@<path-to-file> --mode critique --focus requirements --format standard" })

The skill hands back the expert-panel prompt. The calling session then reads the actual target file
and performs the critique itself, with context on the file's intent an outside reviewer would never
have.

Proving it before trusting it

A prompt file assembling ten famous names is easy to admire and easy to fool yourself about. Before
this one went anywhere beyond the project that pulled it out, its first two real findings were
sent, unprompted, to the actual owner of a document it had never seen — a cross-project routing
policy belonging to a different project on this same setup — an owner with no reason to accept
anything from a tool it had never asked for.

"immediately" unmeasurable; no story for a nudge whose target session never reopens

undefined trigger words ("long"/"multi-step"/"low-interaction"); no positive-compliance example; prior fix not tied back to existing dispatch machinery

Both were accepted and implemented independently. That was the bar spec-panel had to clear before
it became a shared command available to every project on the setup. Not "this sounds like good
advice." The document's actual owner read it and changed the rule.

The receipts

That is a snapshot of a running log, taken for this piece, not a constant.

Document type	What was found	Fixed?
A cross-project dispatch and routing policy document	"queued send_message result never stated as success vs. pending"	1/1
The same policy document, self-reviewed later by its own owning project	"misroute schema self-contradiction; concurrent-append atomicity assumed, never stated; no catastrophic-corruption recovery stance; decided_by audit loop was write-only; Codex graduation bar undefined; deep-research compliance check had no numeric floor"	6/6
A trading-analytics project's own constraints file	"stale duplicate-SELL-gap claim (fixed in code, doc never updated); Current-Release section stale (178 vs actual 180 tests, 3 commits unreflected); ambiguous no-subject constraint clause"	3/3
A personal finance tracker's project handoff document	Seven issues found, four fixed: a stale test count (claimed 121, actual 143), a false "no test file" gap claim for a module that actually had 22 real passing tests undocumented, the same stale count duplicated across two other files, and a stale next-step note for work already done. The other three (a wrong section cross-reference, a minor line-anchor drift, missing staleness signalling on regenerated counts) were flagged and deferred, not fixed	4/7
One module of a personal dashboard suite's own constraints file	"self-contradicting/stale pin claim (line 15 said Current Release v1.17, the module-status section 29 lines later still said pinned 1.9, live 1.16); consistencyUrl's failure-mode degradation undocumented despite existing in code, asymmetric with the documented liveUrl behavior"	2/2
The parent hub of that same dashboard suite, reviewed independently the same day	"Current Release's per-module version prose had already gone stale the same day it was written (said Studio v0.3.0, live manifest already 0.4.0); resolved session narrative duplicating another file; an undefined-trigger clause with no actor or condition named"	3/3
This setup's own global rulebook, the file every project reads on session start	"duplicated INBOX-delivery procedure had drifted from its source (stale 'immediately,' missing the queued-success clause, missing the sender-slug filename shape); the Homes convention violated by full duplication instead of a pointer"	3/5
A design-token reference document	Checked nine canonical tokens plus heading size, badge and button geometry, and a documented override against the live CSS. Every value matched. No findings	0/0

Two of the rows are worth sitting with regardless of what the count reads on any given day.

The dashboard suite pair, a parent hub and one of its own modules, were reviewed independently by
two different sessions on the same calendar day, neither aware of the other's result. Both turned up
the same defect: a live version number, typed into prose, already stale next to the one place that
actually tracked it.

The global-rulebook row is stranger still. The bug was in the global rulebook's own copy of the
cross-project delivery procedure, the mechanism that lets one project hand a proposal to another. It
had been duplicated from the routing project's own document instead of pointing at it, and had
drifted from that source twice because nothing forced the copy to stay in sync. The fix wasn't a
third rewrite. It was deleting the copy and leaving a pointer, so it couldn't drift again.

What it actually taught, past "the tool works"

Not every vague-sounding phrase is a defect. A document meant to work identically across many
unrelated contexts sometimes needs things left underspecified on purpose; pin them down and every
context except the one you were thinking about breaks. A second look rejected two of the findings
that had flagged "unmeasurable" language, for exactly this reason.

A document thorough about failure modes is usually silent about the case where everything goes
right. Every document reviewed so far described what breaks in detail and showed no worked example
of the correct path end to end.

A proposed fix has to be checked against what actually reads the document, not its own wording. One
fix assumed a downstream tool enforced a line-count limit. Reading the real parser that consumed the
document found the limit was never enforced at all. Only exact section headings and bullet markers
were. This setup rewrote the fix around the real mechanism instead of the plausible-sounding
assumption.

What's still open

There is no cost gate and no volume limit on spec-panel itself. Coverage depends entirely on someone
remembering to point it at something. Nobody tracks that automatically, and nothing forces a project
to run it twice on the same document to catch drift. The numbers above are already out of date by
the time anyone reads them. That is how a running log works, not a flaw in it.

---

Originally published at thekilted.dev/no-reason-to-be-kind.