Merge pull request #16 from oduffy-delphi/work/striker/2026-04-02

Work: striker 2026-04-02

Author: dbc-oduffy

CHANGELOG.md

@@ -2,6 +2,26 @@
 
 All notable changes to coordinator-claude are documented here.
 
+## [1.3.0] — 2026-04-02
+
+### Independence from Superpowers — Conscious Uncoupling (D-032)
+
+Coordinator-claude is now fully self-contained. The soft dependency on [superpowers](https://github.com/obra/superpowers) (obra/superpowers) has been removed.
+
+Superpowers gave us our start — we installed it when plugins first shipped, before coordinator-claude existed as a formal system. Its core skills (TDD, systematic debugging, planning, verification) became the behavioral floor we built on. Over time, the philosophical gap widened: superpowers treats the agent as a system to be hardened against its own optimization tendencies; coordinator-claude treats the agent as a professional with defined authority (the PM/EM model). Both work, but for different reasons — and the layered approach was paying context budget for parallel instructions we were overriding.
+
+**New:**
+- **`coordinator:brainstorming` skill** — PM/EM-native design gate. Turns intent into a committed spec through collaborative dialogue. HARD-GATE prevents implementation once brainstorming starts, but the EM has judgment on when to invoke (not "always brainstorm"). Includes targeted rationalization resistance and scope-splitting. Output feeds directly into `coordinator:writing-plans`.
+- **`docs/specs/` convention** — brainstorming specs land at `docs/specs/YYYY-MM-DD-<topic>-design.md`.
+
+**Changed:**
+- **`skill-discovery` flowchart** — brainstorming gate is now judgment-based ("spec exists or EM judges brainstorming unnecessary?"), not mandatory.
+- **`using-git-worktrees`** — removed `~/.config/superpowers/worktrees/` path convention.
+- **`README.md`** — coordinator positioned as self-contained; superpowers install recommendation removed.
+- **`docs/customization.md`** — `superpowers:writing-skills` → `coordinator:writing-skills`.
+
+**Decision doc:** `docs/decisions/D-032-superpowers-conscious-uncoupling.md`
+
 ## [1.2.1] — 2026-04-01
 
 ### Path Hygiene — Move Default Output Paths Out of `.claude/`

README.md

@@ -162,7 +162,7 @@ Add to `~/.claude/plugins/installed_plugins.json`:
 
 ## Writing New Skills
 
-Skills are codified behavioral protocols. The `superpowers:writing-skills` skill guides you through creating one with TDD principles.
+Skills are codified behavioral protocols. The `coordinator:writing-skills` skill guides you through creating one with TDD principles.
 
 ### What a Skill Is
 

docs/customization.md

@@ -0,0 +1,53 @@
+# D-032: Superpowers Conscious Uncoupling
+
+**Date:** 2026-04-02
+**Status:** Decided
+**Decision:** Remove superpowers (obra/superpowers) as a soft dependency. Coordinator-claude becomes fully independent.
+
+## Background
+
+When Claude Code plugins first shipped, superpowers was one of the earliest and most visible entries in the marketplace (131K GitHub stars at time of writing). The name and listed skills — TDD, systematic debugging, plan-before-code, verification-before-done — were exactly what we needed. We installed it immediately, before coordinator-claude existed as a formal plugin system.
+
+Superpowers gave us a running start. Its core skills (TDD enforcement, systematic debugging with escalation, writing plans with placeholder scanning, verification before completion claims) became the behavioral floor we built everything else on top of. Several of those skills were absorbed into coordinator-claude's skill library, adapted with PM/EM terminology and integration points into our orchestration layer. We owe a genuine debt to the superpowers developers for establishing patterns that shaped our early thinking.
+
+## Why We're Going Independent
+
+Over time, the philosophical gap widened. Coordinator-claude evolved capabilities that superpowers doesn't attempt — named persona reviewers, multi-agent research pipelines (Agent Teams-based), session lifecycle management, context pressure hooks, chunk-enrich-review orchestration, autonomous operation modes. More importantly, we developed a fundamentally different trust model.
+
+**Superpowers' model:** The agent is an optimization system that will find shortcuts under pressure. Every skill is hardened with Iron Law blocks, rationalization tables, red flags, and spirit-over-letter clauses. The frame is adversarial — "you WILL try to skip this."
+
+**Coordinator-claude's model:** The agent is an Engineering Manager with defined authority and professional judgment. Structure exists to support good work, not to prevent bad behavior. Quality comes from reviewed plans, sequential review with mandatory fix gates, commit checkpoints, and context pressure hooks — safety nets, not straitjackets. The PM/EM division creates clear authority boundaries that make adversarial hardening less necessary: the EM knows what decisions are theirs to make, which reduces the temptation to rationalize skipping steps.
+
+**Practical friction points:**
+
+1. **Context budget.** Superpowers loads 14 skills + its `using-superpowers` meta-skill into every session. We override most of these with our own versions, paying context tokens for parallel instructions we don't follow.
+
+2. **Delegation philosophy.** Superpowers' SDD (subagent-driven-development) enforces rigid dispatch-vs-inline gates. Our model lets the EM make that call based on task complexity, token efficiency, and professional judgment. A good EM does quick edits inline and delegates complex work — the judgment IS the job.
+
+3. **Role identity.** Superpowers uses "your human partner" — deliberately vague about authority. Our PM/EM model is precise: the PM decides what to build, the EM decides how. This isn't terminology — it's a decision-making framework that eliminates ambiguity.
+
+4. **Platform scope.** Superpowers supports 7 platforms. We're a Claude Code shop. The cross-platform abstractions are dead weight.
+
+## What We Carry Forward
+
+- **Rationalization resistance** (targeted, not blanket): Adding focused "check yourself" tables to our 3 highest-pressure skills, framed as professional discipline rather than adversarial control.
+- **Brainstorming / design gate**: Building a PM/EM-native ideation-to-specification skill inspired by superpowers' HARD-GATE pattern.
+- **CSO (Claude Search Optimization)**: Skill descriptions must list triggering conditions only, never summarize workflow — an empirically observed failure mode.
+- **DONE_WITH_CONCERNS status**: Honest middle ground between "done" and "blocked" for executor reporting.
+- **Plan header execution protocol**: Plans carry their own execution instructions for cold-start resumption.
+- **Evidence-driven iteration**: Treating design decisions as hypotheses, documenting reversals with reasoning.
+
+## What We Leave Behind
+
+- Iron Law ceremony on every skill (verbose for our trust model)
+- Multi-platform adapters and detection logic
+- The `using-superpowers` meta-skill (we have our own capability-catalog + skill-discovery)
+- `model: inherit` for reviewers (our explicit model selection is a real optimization)
+- Monolithic plugin structure (our multi-plugin architecture enables per-project toggling)
+- Visual brainstorming server (interesting but not our priority)
+
+## Acknowledgment
+
+Superpowers is excellent software. The anti-rationalization architecture is genuinely novel. The evidence-driven iteration culture (v5.0.6 removing a feature based on regression data across 5 versions x 5 trials) is rare discipline. The 94% PR rejection rate protecting behavioral scaffolding from agent-generated slop is admirable governance. We learned from all of it.
+
+We're not leaving because superpowers is bad. We're leaving because we've grown into something different enough that the dependency creates more friction than value. Different trust models, different audiences, different ambitions. Time to spread our own wings.

docs/decisions/D-032-superpowers-conscious-uncoupling.md

@@ -0,0 +1,144 @@
+# Anthropic Multi-Agent Blog Post — Claims Verification
+
+**Source:** "How we built our multi-agent research system" (Anthropic Engineering blog, Jun 13 2025)
+**Verified:** 2026-04-01
+**Method:** Full-text extraction and keyword search against 10 specific claims
+
+---
+
+## 1. The 90.2% Figure
+
+**Found:** Yes
+
+**Exact quote:** "We found that a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval."
+
+**Context:** This is framed as a percentage by which the multi-agent system *outperformed* a single agent — not a win rate, not an accuracy score. The metric is relative improvement on "our internal research eval." The eval itself is not publicly defined. The sentence immediately following gives a concrete example (identifying S&P 500 IT sector board members) where the multi-agent system succeeded and the single agent failed.
+
+**Verdict:** If a research doc calls this a "win rate" or "accuracy gain," that would be inaccurate. The source says "outperformed ... by 90.2%" — a relative performance improvement metric on an internal eval.
+
+---
+
+## 2. "Synchronous Bottleneck"
+
+**Found:** Yes — the concept is described explicitly, though the exact two-word phrase "synchronous bottleneck" does not appear.
+
+**Exact quote:** "Synchronous execution creates bottlenecks. Currently, our lead agents execute subagents synchronously, waiting for each set of subagents to complete before proceeding. This simplifies coordination, but creates bottlenecks in the information flow between agents."
+
+**Additional context:** "Asynchronous execution would enable additional parallelism: agents working concurrently and creating new subagents when needed. But this asynchronicity adds challenges in result coordination, state consistency, and error propagation across the subagents. As models can handle longer and more complex research tasks, we expect the performance gains will justify the complexity."
+
+**Verdict:** The blog uses "Synchronous execution creates bottlenecks" as a section heading, describes the lead agent waiting synchronously for subagents, and explicitly flags async as future work with expected "performance gains." A research doc saying "synchronous bottleneck" would be a fair paraphrase. Saying they "flag async execution as future work" is accurate.
+
+---
+
+## 3. "15x Chat Tokens"
+
+**Found:** Yes
+
+**Exact quote:** "In our data, agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats."
+
+**Context:** Appears in the "Benefits of a multi-agent system" section, immediately after the 80% variance discussion. Framed as a cost/downside: "There is a downside: in practice, these architectures burn through tokens fast."
+
+**Verdict:** The figure is 15x *more tokens than chat interactions* (not 15x more than single-agent). If a research doc says "15x chat tokens" that is accurate. If it says "15x more than single-agent" that would be wrong — single-agent is 4x chat; multi-agent is 15x chat.
+
+---
+
+## 4. "Token Usage by Itself Explains 80% of the Variance"
+
+**Found:** Yes — very close to a direct quote.
+
+**Exact quote:** "We found that token usage by itself explains 80% of the variance, with the number of tool calls and the model choice as the two other explanatory factors."
+
+**Context:** This is specifically about the BrowseComp evaluation: "In our analysis, three factors explained 95% of the performance variance in the BrowseComp evaluation (which tests the ability of browsing agents to locate hard-to-find information)."
+
+**Verdict:** Essentially a direct quote. Key nuance: this is about BrowseComp specifically, not their internal research eval. A research doc should note the BrowseComp context. The three factors together explain 95%; token usage alone explains 80%.
+
+---
+
+## 5. "Minor System Failures Can Be Catastrophic for Agents"
+
+**Found:** Yes — near-direct quote.
+
+**Exact quote:** "Without effective mitigations, minor system failures can be catastrophic for agents."
+
+**Context:** Appears in the "Production reliability and engineering challenges" section, under "Agents are stateful and errors compound." Full surrounding context: "Agents can run for long periods of time, maintaining state across many tool calls. This means we need to durably execute code and handle errors along the way. Without effective mitigations, minor system failures can be catastrophic for agents."
+
+**Verdict:** This is almost verbatim. The only difference from the query is the addition of "Without effective mitigations" — the claim is conditional. A research doc quoting this without the qualifier would slightly overstate; with it, it is accurate.
+
+---
+
+## 6. "Agent-Tool Interfaces Are as Critical as Human-Computer Interfaces"
+
+**Found:** Yes — direct quote.
+
+**Exact quote:** "Agent-tool interfaces are as critical as human-computer interfaces."
+
+**Context:** Appears in the "Tool design and selection are critical" section. The surrounding sentence: "Agent-tool interfaces are as critical as human-computer interfaces. Using the right tool is efficient—often, it's strictly necessary."
+
+**Verdict:** Exact match. Direct quote, no paraphrasing needed.
+
+---
+
+## 7. Scale Effort to Complexity
+
+**Found:** Yes — with specific numbers.
+
+**Exact quote:** "Simple fact-finding requires just 1 agent with 3-10 tool calls, direct comparisons might need 2-4 subagents with 10-15 calls each, and complex research might use more than 10 subagents with clearly divided responsibilities."
+
+**Context:** This appears under the heading "Scale effort to query complexity" in the prompt engineering section. Prefaced by: "Agents struggle to judge appropriate effort for different tasks, so we embedded scaling rules in the prompts."
+
+**Verdict:** The numbers are: 1 agent (simple), 2-4 subagents (comparisons), 10+ subagents (complex). If a research doc says "1 agent for simple, 10+ for complex" that is accurate but omits the middle tier. The specific tool-call counts (3-10, 10-15) are also in the source.
+
+---
+
+## 8. SEO Content Farm Detection
+
+**Found:** Yes
+
+**Exact quote:** "human testers noticed that our early agents consistently chose SEO-optimized content farms over authoritative but less highly-ranked sources like academic PDFs or personal blogs. Adding source quality heuristics to our prompts helped resolve this issue."
+
+**Context:** Appears in the "Human evaluation catches what automation misses" section. Framed as an example of what human testers caught that automated evals missed.
+
+**Verdict:** The finding is that agents *preferred* SEO content farms over authoritative sources, and the fix was adding source quality heuristics to prompts. This was discovered through human evaluation, not automated testing.
+
+---
+
+## 9. LLM-as-Judge Evaluation
+
+**Found:** Yes — with specific methodology.
+
+**Exact quote:** "We used an LLM judge that evaluated each output against criteria in a rubric: factual accuracy (do claims match sources?), citation accuracy (do the cited sources match the claims?), completeness (are all requested aspects covered?), source quality (did it use primary sources over lower-quality secondary sources?), and tool efficiency (did it use the right tools a reasonable number of times?)."
+
+**Scoring methodology:** "a single LLM call with a single prompt outputting scores from 0.0-1.0 and a pass-fail grade was the most consistent and aligned with human judgements."
+
+**Context:** They tried multiple judges but converged on a single LLM call. "We experimented with multiple judges to evaluate each component, but found that a single LLM call with a single prompt outputting scores from 0.0-1.0 and a pass-fail grade was the most consistent."
+
+**Verdict:** The scoring is 0.0-1.0 continuous scores plus a binary pass/fail grade, evaluated across 5 rubric criteria, using a single LLM call (not multiple specialized judges). A research doc should note all five criteria and the single-call design.
+
+---
+
+## 10. Self-Improvement Loop
+
+**Found:** Yes
+
+**Exact quote:** "We found that the Claude 4 models can be excellent prompt engineers. When given a prompt and a failure mode, they are able to diagnose why the agent is failing and suggest improvements."
+
+**Additional context:** "We even created a tool-testing agent—when given a flawed MCP tool, it attempts to use the tool and then rewrites the tool description to avoid failures. By testing the tool dozens of times, this agent found key nuances and bugs. This process for improving tool ergonomics resulted in a 40% decrease in task completion time for future agents using the new description, because they were able to avoid most mistakes."
+
+**Verdict:** Yes, they describe Claude diagnosing failures and suggesting prompt improvements. The self-improvement has two flavors: (1) Claude as prompt engineer (diagnosing agent failures, suggesting prompt fixes), and (2) a tool-testing agent that rewrites tool descriptions after repeated testing. The 40% task completion time decrease is attributed to improved tool descriptions, not prompt improvements per se.
+
+---
+
+## Summary Table
+
+| # | Claim | Found | Direct Quote? | Accurately Represented? |
+|---|-------|-------|---------------|------------------------|
+| 1 | 90.2% figure | Yes | Yes | Check framing — it is "outperformed by 90.2%", not a win rate |
+| 2 | Synchronous bottleneck | Yes | Near-exact (heading: "Synchronous execution creates bottlenecks") | Accurate paraphrase; async flagged as future work |
+| 3 | 15x chat tokens | Yes | Yes | Accurate — 15x vs chat, not vs single-agent |
+| 4 | 80% variance from tokens | Yes | Yes | Accurate — but specific to BrowseComp eval |
+| 5 | Minor failures catastrophic | Yes | Near-exact | Accurate — note conditional "without effective mitigations" |
+| 6 | Agent-tool interfaces critical | Yes | Exact | Verbatim match |
+| 7 | Scale effort to complexity | Yes | Yes, with numbers | 1 / 2-4 / 10+ subagents for simple/comparison/complex |
+| 8 | SEO content farm detection | Yes | Yes | Human testers found it; fixed via prompt heuristics |
+| 9 | LLM-as-judge scoring | Yes | Yes | 0.0-1.0 scores + pass/fail, single LLM call, 5 criteria |
+| 10 | Self-improvement loop | Yes | Yes | Two flavors: prompt diagnosis + tool description rewriting (40% improvement) |