feat(directives): scavenge superpowers plugin (test-driven-development, systematic-debugging): 6 directives

conductor/directives/single_hypothesis_minimal_test/meta.md

@@ -0,0 +1,8 @@
+# single_hypothesis_minimal_test
+
+## v1
+
+**Why this iteration:** Lifted from the global OpenCode superpowers plugin (obra/superpowers) — `skills/systematic-debugging/SKILL.md`. The directive encodes Phase 3 (lines 145-163): Form Single Hypothesis + Test Minimally + Verify Before Continuing + Don't add more fixes on top. Counterweight to the LLM default of bundling multiple changes into one commit to "save time," which makes the outcome unauditable and slows diagnosis.
+**Source:** superpowers plugin `skills/systematic-debugging/SKILL.md:145-163` (Phase 3: Hypothesis and Testing)
+
+**Lifted:** 2026-07-04 (scavenge sweep: superpowers plugin directives)

conductor/directives/single_hypothesis_minimal_test/v1.md

@@ -0,0 +1,39 @@
+# Form a SINGLE hypothesis, test it MINIMALLY — do not bundle multiple fix attempts into one change
+
+## The rule
+
+When debugging, the agent forms exactly one hypothesis at a time ("I think X is the root cause because Y"), states it explicitly, and tests it with the smallest possible change. The agent does not change multiple variables at once; the agent does not "fix several obvious problems" while in the debugging flow; the agent does not "while I'm here" improve unrelated code.
+
+Per `skills/systematic-debugging/SKILL.md:145-163` (Phase 3: Hypothesis and Testing):
+
+> **Scientific method:**
+>
+> 1. **Form Single Hypothesis**
+>    - State clearly: "I think X is the root cause because Y"
+>    - Write it down
+>    - Be specific, not vague
+>
+> 2. **Test Minimally**
+>    - Make the SMALLEST possible change to test hypothesis
+>    - One variable at a time
+>    - Don't fix multiple things at once
+>
+> 3. **Verify Before Continuing**
+>    - Did it work? Yes → Phase 4
+>    - Didn't work? Form NEW hypothesis
+>    - DON'T add more fixes on top
+
+## Why
+
+Bundled fixes are unauditable. If the test passes, the agent doesn't know WHICH of the bundled changes was responsible; if the test fails, the agent doesn't know which to revert. The next fix attempt becomes a search across multiple variables, which is exponentially slower than testing one at a time.
+
+Stating the hypothesis explicitly is a discipline against "I just tried a bunch of things." If the agent cannot state the hypothesis in one sentence, the hypothesis is too vague to test — refine first, then test.
+
+## What this means in practice
+
+- Before each fix attempt, the agent writes: "I think [specific X] is the root cause because [specific Y]; I will test by [single change Z]."
+- The change is single-line or single-parameter; not multi-file.
+- If the change does not resolve the bug, the agent REVERTS the change (or notes it explicitly) and forms a new hypothesis. The revert is part of the protocol, not an option.
+- "While I'm here" improvements are forbidden inside a debugging flow. The agent returns to the improvement in a separate commit after the bug is resolved.
+- After three failed hypotheses (not three fix attempts in one commit; three SEPARATE hypotheses), the architecture question is reached (see `three_fix_failures_question_architecture`).
+- The agent does not batch commits inside a debugging flow to "save time." Each hypothesis gets its own commit (atomic per hypothesis), with the test commit prepended when possible.