User Query: Based on using the /modes-of-reasoning-project-analysis skill, what did the skill and the swarm that followed it get right? What was wrong? How could those findings be articulated into feedback that could be used to improve the skill so it's more effective?

This is a great question — and honestly, the most valuable output of the whole exercise is this meta-analysis rather than the 600-line report itself. Let me break it down honestly.

What the Skill/Swarm Got Right

1. Convergence as signal genuinely works. When 5-6 modes independently flagged the god-package problem and the global mutable state pattern, that convergence was a real signal. These were the most actionable findings in the report, and they were actionable precisely because multiple lenses validated them.
2. The adversarial mode (H2) found things nothing else would have. The pane input API missing policy checks, the SLB self-approval bypass in local mode, the CORS config mutation vector — these are real code-level findings with specific file/line evidence. The skill's insistence on including at least one adversarial mode is validated.
3. Edge-case mode (A8) found concrete, verifiable bugs. Checkpoint GenerateID collision risk (time-based, no atomic counter), REST handlers not calling ValidateSessionName(), SSE client channel never drained. These are bugs you can file as issues right now.
4. The FMEA scoring from F4 was genuinely useful. Quantified Risk Priority Numbers gave a prioritization framework that subjective analysis lacks. "RPN 441 > RPN 240 > RPN 160" is a clearer signal than "this seems important."
5. The inductive mode (B1) revealed non-obvious temporal structure. The "geological strata" insight — that code quality varies by era (legacy init() → modern newXCmd() factories), and newer code is measurably better — is something you can only see by sampling broadly across a large codebase. That's genuinely useful for deciding where to invest cleanup effort.
6. Perspective-Taking (I4) produced immediately actionable grades. "Documentation: AI agents A-, Inheritors F" is a crisp diagnostic that tells you exactly what gap to fill.
7. The debiasing mode (L2) introduced a genuinely novel concept. "Agent-amplified momentum" — where near-zero marginal cost of AI-generated code removes the natural friction that causes scope questioning — is a real phenomenon worth naming and watching for. The self-assessment of its own biases was also honest and rare.

---

What the Skill/Swarm Got Wrong

1. The single biggest failure: recommending to abstract away the project's core identity. Multiple modes converged on "tmux is a deep dependency → abstract it behind an interface." This is descriptively TRUE (tmux is deeply embedded) but the normative leap to "therefore decouple it" is wrong. NTM is a Named Tmux Manager. tmux isn't an incidental dependency — it IS the product. The skill treats decoupling as a universal good, with no mechanism to distinguish "dependency that should be abstracted" from "dependency that defines the product."
2. "Convergent" was often actually "redundant." Six modes all looked at the same LOC counts and import graphs, then independently concluded "the cli package is too big." The triangulation protocol scored this as 6-mode convergence with 0.95 confidence. But they used the same evidence (file sizes, import counts). True independent convergence would mean reaching the same conclusion via genuinely different evidence pathways. The skill conflates "multiple modes saw the same obvious thing" with "multiple independent analytical frameworks validate this finding."
3. Security severity was miscalibrated for the actual threat model. The adversarial mode rated the pane input API as "CRITICAL" by assuming a threat model (malware on localhost) that doesn't match reality (solo developer's laptop). If your machine is compromised enough for malware to hit localhost:7337, the attacker already has shell access and doesn't need NTM's API. The skill has no mechanism for calibrating severity against the actual deployment context rather than the theoretical worst case.
4. Option-generation mode produced intellectually stimulating but impractical ideas. "NTM as an operating system for AI agents," "self-orchestrating NTM," "competitive multi-NTM federations" — these are fun thought experiments disconnected from the project's reality: one developer, zero users, early development. The mode wasn't constrained by the project's actual constraints.
5. Counterfactual mode wasted analysis on irreversible, unactionable decisions. "What if NTM had been written in Rust?" is academically interesting and produces zero actionable output. The project is 85K lines of Go. It's not switching languages. The mode should have focused exclusively on decisions that are still reversible.
6. The "at least 8-15 findings" minimum created padding pressure. When you tell an agent to produce at least 8 findings, it will produce 8 even if 4 are substantive. Several modes had 5 solid findings and 7-10 that were restatements, obvious observations, or low-confidence speculation dressed up as findings. This diluted the signal.
7. The broken-build finding was over-interpreted. Multiple modes treated "build is broken on main" as evidence of systemic quality erosion, confirmation bias, and testing failure. It's a transient state — likely one bad commit. Using a snapshot as evidence of a structural property is itself a reasoning error.
8. The report is too long. 600 lines with 18 sections. The executive summary is useful; everything below section 7 is ceremony. The skill's report template mandates exhaustive structure that produces an impressive-looking document nobody will read end-to-end.
9. Some findings were "analysis theater." The FMEA table looks rigorous with calculated RPNs, but the relative ordering (tmux crash > Agent Mail down > false-positive restart) is what anyone would conclude after 5 minutes of thought. The framework added ceremony without substantially different conclusions from common sense.

---

Feedback to Improve the Skill

Here's how I'd articulate these into concrete skill improvements:

High-Priority Changes

1. Add a "project identity filter" to the synthesis phase. Before any recommendation to "abstract X behind an interface," require the lead agent to answer: "Is X the core identity/purpose of this project?" If yes, coupling to X is a feature, not a bug, and the recommendation should be filtered out. Add this as an explicit operator card:

   Identity Check: Before recommending decoupling from dependency X, ask: "Would removing X change what this project IS?" If yes, the coupling is by design.

2. Distinguish "convergent" from "redundant" in the triangulation protocol. Currently the protocol counts any 3+ modes reaching the same claim as KERNEL. Add a requirement: "Did these modes use DIFFERENT evidence to reach this conclusion?" If all modes cited the same LOC counts, that's one observation seen by many, not independent triangulation. Add to the triangulation process:

   True convergence requires: (1) same claim, (2) different evidence, (3) different analytical framework. If all modes cite the same file sizes or import counts, count as 1 observation regardless of mode count.

3. Require deployment-context severity calibration. Add a mandatory "Deployment Context" section to Phase 0 that captures: who runs this, where, with what exposure, threat model. All severity ratings must reference this context. A finding that's CRITICAL for a public-facing web service might be LOW for a localhost-only developer tool. Add to the prompt template:

   Before rating any finding above MEDIUM severity, state the actual deployment context and explain why the severity applies to THAT context, not a hypothetical worse one.

4. Cap findings at 5-8 per mode, not 8-15. Change the output contract from "at least 5, up to 15" to "exactly 5-8, with every finding required to cite specific evidence." This eliminates padding pressure and forces modes to prioritize.
5. Add an "actionability gate" to recommendations. Before including any recommendation in the final report, require: "Given this project's team size, development stage, and user count, could this be done in the next 30 days?" If not, move to an "Exploratory" appendix rather than the main recommendations list.

Medium-Priority Changes

6. Constrain counterfactual mode to reversible decisions. Add to the F3 prompt: "Skip decisions that are irreversible at reasonable cost (language choice, core substrate). Focus analysis on decisions where the project could still change course."
7. Constrain option-generation to project constraints. Add to the B5 prompt: "This project has [N] developers, [N] users, and is in [stage]. Only suggest alternatives that are realistic given these constraints. Label 'radical ideas' as explicitly speculative."
8. Compress the report template from 18 sections to 7. Keep: Executive Summary, Convergent Findings (5 max), Critical Disagreements (2 max), Security Findings, Top Recommendations (5 max), Open Questions, and a compact Provenance Index. Move Mode Performance Notes, Contribution Scoreboard, Taxonomy Axis Analysis, and individual mode outputs to appendices referenced by link.
9. Add a "senior engineer gut check" operator card. After synthesis, the lead agent should role-play a senior engineer who knows the codebase intimately and challenge each finding: "Would someone who built this system and uses it daily agree with this finding and its severity?" The tmux abstraction recommendation and the scope-is-5x-too-large claim would both fail this check.
10. Read the project's AGENTS.md/CLAUDE.md rules BEFORE mode selection. The skill currently selects modes based on project type. It should also factor in project rules. NTM's AGENTS.md says "no premature abstraction," "no file proliferation," "no backwards compatibility." Modes that tend toward recommending abstractions should be calibrated against these rules, and the synthesis should filter recommendations that violate stated project principles.

Lower-Priority Changes

11. Add a first-class "non-NTM execution" path. The skill is written assuming NTM tmux swarms with pane monitoring, staggered dispatch, and cron-based monitoring. In practice, I ran it with 10 parallel Agent subagents. The skill should have an explicit "direct agent dispatch" variant that skips the NTM orchestration ceremony.
12. Add a "so what?" filter to every finding. For each finding in the report, require: "If the project owner reads this, what specifically would they do differently tomorrow?" Findings that don't produce a concrete next-day action should be demoted from "finding" to "observation."
13. Track a "false positive rate" across runs. If the skill is used repeatedly, keep a memory of which recommendations the project owner accepted vs. rejected, and why. Feed this back into mode selection and severity calibration. The tmux abstraction recommendation is a learnable false-positive pattern: "don't recommend abstracting the core substrate of a tool named after that substrate."

---

The Meta-Lesson

The skill is architecturally sound — deploying diverse reasoning modes, triangulating, and scoring contributions is a genuinely powerful approach. But it has a systematic bias toward the perspective of an outside consultant rather than the perspective of someone who lives in the codebase. It over-indexes on theoretical risks and architectural ideals while under-indexing on practical constraints, project identity, and the economics of who actually uses this tool and how.

The single most impactful improvement would be making the synthesis phase adversarial against its own recommendations: "Why would the person who built this system reject this finding?" If you can't answer that question, the finding might be genuinely novel. If you can easily answer it ("because tmux is the whole point"), the finding is probably a projection of generic architectural advice onto a specific project where it doesn't apply.

---

---

User Query: Good question. Let me think through this carefully based on what actually happened when the findings met reality.

What the Swarm Got Right

Structurally correct findings (validated by investigation):

1. Bus factor = 1 is a real risk (6/10 modes) — This is straightforwardly true and didn't need code investigation to validate. The convergence across modes was genuine.
2. Claims exceed implementation (4/10 modes) — H2's Cx::current() finding was real and specific. The unwrap() count, the todo! count, the HashMap non-determinism in production — all verifiable facts.
3. Ergonomics barrier (4/10 modes) — The &Cx threading tax, toy examples, and "migration is really a rewrite" observations were grounded in actual API surface reading.
4. Formal methods genuine but narrow (4/10 modes) — A3's analysis was the most impressive single-mode output. The opaque IsReady finding, the sequential-model limitation, the Budget.infinite identity bug — all correct and specific.
5. Lab runtime is the strongest differentiator (B6, F7) — Validated. Nothing like it in the Rust ecosystem.
6. Two-phase effects are a genuine innovation (B6, F3) — Validated by the analogical comparison to database 2PC.
7. Lock ordering debug-only (F4) — Real finding with real RPN score. Actionable.
8. Monitoring without actuation (F7) — The Lyapunov-scheduler gap was real and led directly to the ProgressCertificate wiring work.

What the Swarm Got Wrong

The central claim — "30-40K lines of dead math" — was significantly overstated. Here's the breakdown:

Module	Swarm Said	Reality
SpectralHealthMonitor (3.4K)	"Dead/overkill"	Actively wired into scheduler governor, drives scheduling decisions
boundary.rs + gf2.rs + scoring.rs (~2K)	"Dead/zero callers"	Actively wired into DPOR explorer for topology-guided seed prioritization
HealthThresholdCalibrator	"Dead/simpler alternative"	Actively used in RaptorQ regression detection and messaging SLO contracts
Obligation LeakMonitor (eprocess)	"Dead"	Actively used in messaging service contract monitoring
geodesic.rs	"Dead/zero callers"	Partially wired via trace/mod.rs normalize_trace() wrapper
ProgressCertificate (2.5K)	"Dead/zero callers"	Correctly identified as unwired, but clean API ready for integration
Lab oracle EProcessMonitor	"Dead"	Correctly unwired, easy to wire
sheaf.rs, tla_export.rs	"Dead/zero callers"	Correctly unwired
separation_logic, dialectica, session_types, no_aliasing, marking (~10K)	"Dead/zero callers"	Correctly unwired (post-hoc validators)

The actual dead code was ~15-18K lines, not 30-40K. The swarm roughly doubled the real number by including modules that were genuinely integrated but that the agents failed to find callers for. The B9 (Simplicity) agent's grep methodology was sound in principle but missed integration through indirect paths (re-exports consumed by other modules, conditional compilation paths, callers behind if enable_governor guards).

Root Cause Analysis of the Errors

1. Grep-based "zero callers" methodology was too shallow B9 grepped for use crate::observability::spectral_health and found limited direct imports. But SpectralHealthMonitor was instantiated via the already-imported type in three_lane.rs, which imports the module at line 54. The agent didn't trace through the import chain or search for type names (SpectralHealthMonitor::new) — it searched for module-level imports.
2. Modes amplified each other's errors (echo chamber effect) B9 said "30-40K dead." L5 cited B9. L2 cited the pattern. F7 referenced the "sensors without actuators" framing. The triangulation protocol treated 4-mode agreement as high-confidence KERNEL, but all 4 modes were working from the same flawed premise (grep results) rather than independently verifying. The "convergence" was actually amplification of a single methodology failure.
3. The lead agent (me) didn't apply the Kill Thesis operator rigorously enough The skill explicitly says: "For each convergent finding, apply Kill Thesis. Actively try to find a reason the convergent finding is WRONG." I triangulated the 4-mode agreement into a KERNEL finding without independently verifying the grep claims. When you asked me to actually wire the code, the first thing I did was investigate — and immediately found the claims were overstated.
4. Agents confused "I can't find callers" with "there are no callers" In a 708K-line codebase with complex conditional compilation, module re-exports, and trait-mediated indirection, a single grep pass is insufficient to prove non-usage. The agents should have searched for type names, method names, and constructor calls — not just use statements.
5. The "Simplicity" mode had a structural bias toward finding complexity B9's entire mandate was "find unnecessary complexity." This created confirmation bias — every module was evaluated through a lens that favors removal. The antagonistic pair (B9 vs F7) was supposed to counter this, but F7 also identified the "sensors without actuators" pattern, reinforcing rather than challenging B9's conclusion.

Feedback for Improving the Skill

1. Add a "Ground Truth Verification" phase between Collection and Synthesis The skill goes directly from mode outputs (Phase 5) to synthesis (Phase 6). There should be a Phase 5.5: Spot-Check Critical Claims where the lead agent independently verifies the top 3-5 highest-impact findings before triangulating them into KERNEL status. For each candidate KERNEL finding:
   1. Identify the specific evidence claim (e.g., "zero callers")
   2. Run an independent verification (different search methodology)
   3. If verification fails, downgrade to HYPOTHESIS regardless of mode count
2. Strengthen the Kill Thesis operator with mandatory counter-search The current Kill Thesis instruction says "try to find a reason the finding is WRONG." This is too abstract. For code-related findings, make it concrete: For "dead code" findings specifically:
   • Search for the TYPE NAME, not just the module import
   • Search for constructor calls (::new, ::with_defaults, etc.)
   • Check conditional compilation paths (#[cfg(...)])
   • Check if the module is re-exported and consumed transitively
   • Check test files — code exercised only by tests is "tested" not "dead"
3. Distinguish "unintegrated" from "dead" in the taxonomy The skill's output contract asks for severity ratings but doesn't distinguish between:
   • Dead code: Implemented, never called, provides no value
   • Unintegrated code: Implemented, has a clear integration point, just not wired yet
   • Aspirational code: Implemented, no current integration point exists These have very different recommended actions (delete vs wire vs feature-gate). The report template should require this distinction.
4. Add a "False Convergence" anti-pattern The existing anti-patterns include "Premature Consensus" (modes didn't look at the same things). Add:

   Methodological Convergence (False KERNEL)

   Problem: Multiple modes agree on a finding, but all derive their evidence from the same methodology (e.g., grep results). Agreement reflects shared methodology, not independent confirmation. Fix: For KERNEL findings, require at least two DISTINCT evidence methodologies. "4 modes all grepped and found zero callers" is one methodology used 4 times, not 4 independent confirmations. Require at least one mode to verify through a different path (reading the call site, tracing imports, checking runtime behavior).

5. Mode-specific evidence quality requirements B9 (Simplicity) should have a higher evidence bar for "unnecessary complexity" claims than other modes, because its mandate structurally biases toward finding things to remove. Add to the mode assignment block:

   FOR SIMPLICITY/MDL MODE SPECIFICALLY:

   • "Zero callers" claims MUST be verified by searching for: (a) type name constructors, (b) method calls, (c) trait impls
   • "Simpler alternative suffices" claims MUST include a concrete comparison showing the simpler approach achieves the same guarantee
   • Do NOT count test-only usage as "dead" — it means "tested"

6. The Contribution Scoreboard should penalize unverified amplification Currently the scoring formula is: score = 0.40 * (findings/total) + 0.30 * (unique/total_unique) + 0.20 * evidence_quality + 0.10 * calibration Add a penalty for findings that depend on another mode's evidence without independent verification: dependency_penalty = 0.15 * (findings_citing_other_modes / total_findings) score = base_score - dependency_penalty
7. The prompt template should explicitly instruct agents to distinguish observation from integration The current prompt says "cite specific file, function, line." For "dead code" claims, it should say:

   If you claim code is unused:

   1. State what you searched for and how
   2. State what you found (or didn't find)
   3. Acknowledge the limitations of your search methodology
   4. Rate your confidence that the code is TRULY unused vs that your search was insufficiently thorough

8. Lead agent should run at least one "adversarial verification" agent After collecting mode outputs but before synthesis, spawn one more agent whose sole job is to try to DISPROVE the top 3 findings. Give it the specific claims and ask it to find counter-evidence. This is cheap (one agent) and catches the exact failure mode that occurred here.

The Core Lesson

The core lesson: convergence across modes is only meaningful when the modes arrive at their conclusions through genuinely independent evidence paths. When they all use the same methodology (grep for imports), agreement is methodological monoculture, not epistemic triangulation. The skill should make this distinction explicit and require methodological diversity for KERNEL-status findings.

---

---

User Query: Great question. Having gone through the full cycle -- skill invocation, swarm analysis, synthesis, then actually implementing the top recommendations -- I'm in a good position to evaluate.

What the Skill and Swarm Got Right

1. The convergent findings were genuinely the most important. The triangulation protocol worked as designed: findings that 3+ modes independently flagged (hysteresis oscillation risk, merge-proof silent failures, asupersync dependency) turned out to be the most actionable. The hysteresis fix was a real improvement; the merge-proof logging addressed a genuine observability gap. The ranking mechanism is sound.
2. Bayesian mode was correctly identified as most valuable. It caught the most technically precise and actionable issues: EMA inadequacy for phase changes, warmup sample-size insufficiency, cost-scale concerns. The mode-to-project affinity was strong because FrankenFS has explicit Bayesian machinery to scrutinize.
3. Mode selection was well-suited to the project. A filesystem needs formal verification (Deductive), adversarial thinking (FUSE trust boundary), systems analysis (feedback loops), and stakeholder perspectives. The 10-mode spread covered meaningful ground.
4. The disputed findings were correctly marked as disputes. The report didn't force resolution on "is complexity justified?" -- it presented both positions (research contribution vs. engineering debt) with reasoning chains. This is honest and useful.
5. The P0/P1 recommendations were implementable. All three turned into real, working code changes that passed the full CI gate. The skill produced actionable output, not just analysis.

---

What the Skill and Swarm Got Wrong

1. "319 panic points" was inflated and misleading. The Adversarial agent counted unwrap_or(), unwrap_or_else(PoisonError::into_inner), and test-only unwrap() calls as "panic points in hot paths." These are defensive fallbacks and test scaffolding, not production panic risks. The count was scary but the actual hot-path danger was far smaller. The adversarial mode didn't distinguish safe fallback patterns from actual panic vectors.
2. The "100% parity is self-referential" critique misunderstands intentional transparency. FEATURE_PARITY.md explicitly documents its interpretation rules (lines 21-26) -- that's not deception, it's disclosure. Four modes flagged this as a problem, but the developer already put the caveat in the same file. The swarm treated transparent documentation as a red flag, which penalizes honesty.
3. The Beta(1,100) prior critique was backwards. The Bayesian agent said the prior was "optimistic" (implying too little repair), but Beta(1,100) has mean ~1%, which is conservative (over-provisioning repair symbols). Real disk corruption is ~0.01-0.1%, so the prior intentionally assumes more corruption to be safe during early operation. The agent criticized the prior without understanding its design intent -- it assumed "calibrate to empirical rates" when the actual goal was "be pessimistic until data arrives."
4. Several findings were already-known limitations restated as discoveries. "FUSE latency is an architectural ceiling," "bus factor = 1," and "nightly Rust is a build risk" are things the developer explicitly documents in README.md and AGENTS.md. The swarm spent significant analytical budget rediscovering known constraints. A 600-line report where 30% restates what the developer already wrote isn't efficient.
5. The "9.5x expected loss" claim was flagged as "not found" but may exist in test output. The Deductive agent searched for the string and didn't find it hardcoded, concluding it was unsourced. But verification-gate tests compute expected-loss ratios at runtime and assert on them -- the number may be a computed test result rather than a hardcoded constant. The agent did static text search when it needed dynamic analysis.
6. No agent ran the code. None of the five agents executed cargo test, cargo bench, or verified claims empirically. They all did static analysis (reading source, grepping patterns). The "120-writer stress test" was read about but never run. The "9.5x" claim couldn't be verified because nobody ran the test that computes it.
7. Cost-scale mismatch concern is weaker than presented. The Bayesian agent flagged data_loss_cost=1e6, storage_cost=1.0 as dimensionally mismatched. But the expected-loss grid search only needs relative ordering to select the minimum -- it's invariant to uniform rescaling of both costs. The absolute values don't matter for the decision; only the ratio matters, and 1e6:1 is a reasonable ratio expressing "data loss is catastrophically worse than storage overhead."
8. The EMA alpha and warmup recommendations contradicted each other. The same Bayesian agent recommended both (a) "increase warmup to 50+ commits" (more data before switching) and (b) "consider dual-rate EMA for phase-change detection" (respond faster to changes). These are in tension -- you can't simultaneously be more conservative about switching and more responsive to workload shifts without more complex machinery. The report didn't flag this internal contradiction.
9. The overengineering verdict underweights the project's stated goals. AGENTS.md says: "We want to do things the RIGHT way with NO TECH DEBT." The project explicitly prioritizes correctness and rigor over simplicity. Three modes calling this "overengineered" reflects a default software-engineering prior ("ship fast, iterate") that doesn't match this project's values. The skill anchored on generic engineering norms instead of the project's stated philosophy.

---

Feedback for Skill Improvement

High-Impact Changes

• F1. Add a "known limitations" pre-filter. Before dispatch, the lead agent should extract all documented limitations/caveats from README, AGENTS.md, and issue trackers. Tag each as "owner-acknowledged." During synthesis, findings that merely restate owner-acknowledged limitations should be categorized separately (e.g., "Confirmed Known Risks") rather than presented as discoveries. This prevents the report from spending 30% of its length telling the developer what they already wrote.
• F2. Require at least one agent to do dynamic analysis. The skill should mandate that at least one mode (ideally Deductive or Edge-Case) actually runs the code: execute tests, check assertions, measure benchmarks. Static-only analysis missed the "9.5x" verification and couldn't confirm whether panic sites are actually reachable. Add to the prompt template: "You MUST run cargo test, cargo bench, or equivalent to empirically verify at least 3 claims."
• F3. Add a "design intent" step before criticizing parameters. The Bayesian mode should be instructed: "Before flagging a parameter as miscalibrated, first determine what the designer intended. Read comments, docs, and tests that justify the value. Distinguish 'this parameter is wrong' from 'this parameter serves a different purpose than I assumed.'" The Beta(1,100) prior error was caused by assuming "calibrate to reality" when the intent was "be conservative until data arrives."
• F4. Add post-implementation feedback loop. After the top 3-5 recommendations are implemented, the lead agent should assess: "Did implementing this reveal any issues with the original analysis? Were any findings harder/easier than expected? Did the implementation uncover inaccuracies?" This closes the loop and generates ground truth for scoring mode quality. In this case, the implementation was clean and the findings held up, which is positive signal -- but the Beta prior critique would have been corrected.

Medium-Impact Changes

• F5. Distinguish "novel insight" from "restated known limitation" in scoring. The contribution scoreboard weights unique_insights / total_unique, but all "unique" findings are treated equally. An insight the developer doesn't know is worth 10x more than restating a documented limitation. Add a multiplier for findings that aren't in README/AGENTS.md.
• F6. Check for internal contradictions within a single mode's output. The Bayesian agent's "increase warmup" + "respond faster" tension wasn't caught. The synthesis phase should include a step: "For each mode, check whether its own recommendations are mutually consistent."
• F7. Adversarial mode needs false-positive calibration. The panic-count inflation happened because the Adversarial prompt says "find weaknesses" without saying "verify each finding is exploitable." Add to the adversarial prompt: "For every vulnerability you report, you must demonstrate a concrete scenario that triggers it. Counts without validation (e.g., 'N instances of unwrap()') are insufficient -- you must classify each as reachable or defensive."
• F8. Add "single-agent mode" for when NTM/tmux isn't available. The skill assumes NTM swarm orchestration, but I ran it with parallel Claude subagents. The skill should have explicit instructions for this fallback path (which is probably the more common case), including how to distribute modes across available agents and how to avoid context-window issues.

Lower-Impact Refinements

• F9. Reduce report verbosity. The 18-section report template is thorough but produces 600+ lines. For a single developer, sections 14-18 (scoreboard, mode performance, retrospective, provenance) add bulk without proportional value. Add a --concise flag that collapses these into a single summary table.
• F10. Weight findings by project-stated values. The mode selection algorithm should factor in the project's stated values (from AGENTS.md/README). If the project says "no tech debt, do it right," modes that penalize complexity should have their severity discounted. If the project says "ship fast," modes that flag missing features should be weighted higher. The current algorithm is project-type-aware but not project-values-aware.
• F11. Same-model correlation caveat. The report should note when all agents are the same model (all Claude, all Codex). True triangulation requires model diversity. The current scoring treats same-model agreement as independent confirmation, but Claude-on-Claude agreement is weaker evidence than Claude-vs-Codex agreement. Add a model_diversity_discount to the convergence scoring.