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

conductor/directives/delete_means_delete_no_reference/meta.md

@@ -0,0 +1,8 @@
+# delete_means_delete_no_reference
+
+## v1
+
+**Why this iteration:** Lifted from the global Openpowers plugin (obra/superpowers) — `skills/test-driven-development/SKILL.md`. The directive encodes the Iron Law's "No exceptions: Don't keep it as 'reference', Don't 'adapt' it while writing tests, Don't look at it, Delete means delete" block at lines 31-46. Counterweight to the LLM default of "I'll just keep the function as a reference and write the test around it," which bends the test to match the implementation and breaks the proof of failure.
+**Source:** superpowers plugin `skills/test-driven-development/SKILL.md:31-46` (The Iron Law + No exceptions block)
+
+**Lifted:** 2026-07-04 (scavenge sweep: superpowers plugin directives)

conductor/directives/delete_means_delete_no_reference/v1.md

@@ -0,0 +1,35 @@
+# "Delete" means delete — never keep untested code as "reference" or "adapt it while writing tests"
+
+## The rule
+
+If the agent writes production code before writing the failing test (i.e., violates the TDD red-green order), the code is deleted. Not kept, not referenced, not "adapted while writing the test." The agent writes the test FIRST against the desired behavior, then writes the implementation from scratch. "Delete means delete."
+
+Per `skills/test-driven-development/SKILL.md:31-46` (The Iron Law):
+
+> ```
+> NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+> ```
+>
+> Write code before the test? Delete it. Start over.
+>
+> **No exceptions:**
+> - Don't keep it as "reference"
+> - Don't "adapt" it while writing tests
+> - Don't look at it
+> - Delete means delete
+>
+> Implement fresh from tests. Period.
+
+## Why
+
+Keeping the code as "reference" is a trap. The agent reads it back while writing the test, the test ends up matching the implementation rather than the desired behavior, and the test passes immediately because it has been bent to fit. This is testing-after in disguise; the same failure modes apply.
+
+The only way out is cold: write the test against the desired behavior from memory, then write the implementation from the test. The sunk cost is real (the previous code is wasted), but the alternative (keeping it) is worse (the test is now contaminated).
+
+## What this means in practice
+
+- The agent writes the test BEFORE any implementation code touches disk.
+- If the agent catches itself having written code first (e.g., a function shell), the agent deletes it (`rm <file>` or `edit_file` to remove the function definition).
+- "I'll keep this as reference and write the test around it" is forbidden. The reference becomes the implementation; the test becomes the fitting exercise.
+- "I already manually tested this and want to preserve the working code" is forbidden. Manual testing is not the test; the test is the test.
+- The first commit on a feature is the failing test alone; the second commit is the implementation. Never reversed.