Field notes / tooling
No Reason to Be Kind
Out of a fifty-seven-item command catalogue, this setup kept exactly one. Before it went anywhere else, its first two real findings were sent, unprompted, to the actual owner of a document it had never seen. Both were accepted and implemented without being asked.
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
one prompt, ~440 linesWhat 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.
| ExpertReal-world credential | MethodologySample critique it's instructed to ask |
|---|---|
| Karl WiegersRequirements 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 AdzicCreator 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 CockburnUse-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 FowlerSoftware architecture and refactoring, Thoughtworks | Interface segregation, bounded contexts, refactoring patterns"This interface violates the single responsibility principle. Consider separating concerns." |
| Michael NygardAuthor 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 NewmanMicroservices and distributed systems author | Service decomposition, API versioning, distributed system patterns"How does this specification handle service evolution and backward compatibility?" |
| Gregor HohpeCo-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 CrispinAgile 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 GregoryTesting 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 HightowerCloud-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.
two findings, both acceptedProving 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.
0/0 to 6/6The receipts
| 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.
two findings rejectedWhat 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.
no gate, no limitWhat'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.