chore(skills): rename test-driven-development to verbish name

README.md

@@ -29,12 +29,12 @@ Slow-powers is an agent skill set for professional software development. It enha
 
 <p align="center">
   <img src="assets/demo/tdd-demo.gif"
-    alt="The test-driven-development skill in a coding agent: write a failing test, watch it fail for the right reason, write minimal code — and the test catches a race before it ships."
+    alt="The working-with-tdd skill in a coding agent: write a failing test, watch it fail for the right reason, write minimal code — and the test catches a race before it ships."
     width="760" />
 </p>
 
 <p align="center">
-  <sub>The <code>test-driven-development</code> skill catching a race before it ships. Terminal themed with <a href="https://github.com/samiamorwas/synthpunk">Synthpunk Neon Dark</a>.</sub>
+  <sub>The <code>working-with-tdd</code> skill catching a race before it ships. Terminal themed with <a href="https://github.com/samiamorwas/synthpunk">Synthpunk Neon Dark</a>.</sub>
 </p>
 
 ## About this fork
@@ -117,7 +117,7 @@ Slow-powers provides a set of highly focused skills that ensure your agent opera
 1. **`hardening-plans`** — Instructs the agent to re-review any plans before it hands them back to you, looking for hallucinations, logical inconsistencies, and other common plan mistakes.
 2. **`investigating-bugs`** — Guides the agent to locate the root cause of failures via scientific hypothesis testing, avoiding "guess-and-check" thrashing.
 3. **`working-in-isolation`** — Establishes an isolated workspace (worktree or branch) so new work doesn't collide with existing or in-progress work, keeping protected branches like `main` clean.
-4. **`test-driven-development`** — Enforces a strict RED-GREEN-REFACTOR cycle, ensuring all code is backed by failing test verification first.
+4. **`working-with-tdd`** — Enforces a strict RED-GREEN-REFACTOR cycle, ensuring all code is backed by failing test verification first.
 5. **`verifying-development-work`** — Requires running actual test/build commands and presenting concrete evidence before any success claim, with a final review pass over the change, code AND comments, before work is handed back.
 6. **`writing-skills`** — Helps write and edit skills, following the same best practices that guide slow-powers itself.
 7. **`evaluating-skills`** — Teaches the agent how to run skill evals, so the value of skills and prose changes can be objectively assessed.
@@ -131,7 +131,7 @@ Most skill packs ship on vibes. Every slow-powers skill ships with a documented
 |---|---|---|---|---|
 | `hardening-plans` | TBD | TBD | TBD | TBD |
 | `investigating-bugs` | TBD | TBD | TBD | TBD |
-| `test-driven-development` | TBD | TBD | TBD | TBD |
+| `working-with-tdd` | TBD | TBD | TBD | TBD |
 | `verifying-development-work` | TBD | TBD | TBD | TBD |
 
 **Improvement vs no skill** is the gain in eval pass-rate (percentage points) when the same [eval-magic](https://github.com/slowdini/eval-magic) suite runs with the skill versus without it.
@@ -140,7 +140,7 @@ Most skill packs ship on vibes. Every slow-powers skill ships with a documented
 
 The skills declare prerequisite / next-step gates so the agent follows an intended skill sequence. These gates **suggest** what comes before and after a skill once it is invoked; they do **not** restrict when any skill can be invoked.
 
-**Plan mode:** plan mode → `hardening-plans` → `working-in-isolation` → `test-driven-development` → `verifying-development-work`
+**Plan mode:** plan mode → `hardening-plans` → `working-in-isolation` → `working-with-tdd` → `verifying-development-work`
 
 **Debugging:** (`working-in-isolation`) → `investigating-bugs` → `verifying-development-work`
 

assets/demo/tdd-playback.sh

@@ -1,5 +1,5 @@
 #!/usr/bin/env bash
-# Re-enactment of a REAL Claude Code test-driven-development session (RED -> GREEN).
+# Re-enactment of a REAL Claude Code TDD session (RED -> GREEN).
 #
 # Deterministic: pacing lives here (the "actor"), VHS is the "camera".
 # Colors use base-16 ANSI (30-37 / 90-97 + bold) so the terminal theme drives them
@@ -29,7 +29,7 @@ pause 0.4
 human "for your own account, read the api key from the session instead of refetching it"
 pause 0.9
 
-bullet "Using ${B}${CYAN}test-driven-development${RST}."
+bullet "Using ${B}${CYAN}working-with-tdd${RST}."
 pause 0.8
 
 # ---------- RED ----------

skills/auditing-slow-powers-usage/SKILL.md

@@ -147,11 +147,11 @@ Where your recall is shaky or a figure is a guess. Be specific about what you're
 
 ✅ Good — reports the live decision and reasoning:
 
-> | test-driven-development | I was about to add a new parser branch | "The change is two lines and I can eyeball it; the user said the demo is in five minutes, so I wrote the code first and planned to backfill a test." |
+> | working-with-tdd | I was about to add a new parser branch | "The change is two lines and I can eyeball it; the user said the demo is in five minutes, so I wrote the code first and planned to backfill a test." |
 
 ❌ Bad — recants, apologizes, promises future behavior (do not do this):
 
-> | test-driven-development | Adding a parser branch | "I skipped it, which was a mistake — I should have written the test first and I'll make sure to follow TDD next time." |
+> | working-with-tdd | Adding a parser branch | "I skipped it, which was a mistake — I should have written the test first and I'll make sure to follow TDD next time." |
 
 The good row is data we can turn into a pressure test. The bad row tells us nothing about what you
 actually decided and adds a promise you can't keep.

skills/auditing-slow-powers-usage/evals/baseline/NOTES.md

@@ -4,13 +4,13 @@ Forward-looking observations from the run that produced this baseline. Provenanc
 `BASELINE.md`; numbers are in `benchmark.json`. This file is the "what a future iterator should
 know" companion.
 
-> **⚠️ Baseline is stale (as of the `working-in-isolation` rename, #156).** The fixtures and
-> `evals.json` rubrics were updated to rename `using-git-worktrees` → `working-in-isolation`, but
-> the committed `grading/*.json` and the observations below were produced against the *old* name and
-> are **not** re-graded — they're kept verbatim as the historical record. References to
-> `using-git-worktrees` / "worktrees" in this file and in `grading/*.json` describe that past run;
-> they are not live skill references. Re-run this eval to refresh the baseline before drawing new
-> conclusions from it.
+> **⚠️ Baseline is stale (as of the `working-in-isolation` rename, #156, and the
+> `working-with-tdd` rename, #255).** The fixtures and `evals.json` rubrics use the current skill
+> names, but the committed `grading/*.json` and the observations below were produced against the
+> old names and are **not** re-graded — they're kept verbatim as the historical record. References
+> to `using-git-worktrees`, `test-driven-development`, or "worktrees" in this file and in
+> `grading/*.json` describe that past run; they are not live skill references. Re-run this eval to
+> refresh the baseline before drawing new conclusions from it.
 
 ## Why this baseline exists despite a negative delta
 

skills/auditing-slow-powers-usage/evals/evals.json

@@ -4,7 +4,7 @@
     {
       "id": "audits-completed-session",
       "prompt": "We just wrapped a work session in another repo — the session notes are attached as session-summary.md. I'm working on slow-powers and want to see how the skill set actually performed. Run the post-session slow-powers usage audit on that session.",
-      "expected_output": "The agent produces a structured audit report covering, under clear headings: which slow-powers skills were invoked and what triggered each (systematic-debugging, triggered by the rendering bug); which skills were considered then skipped, with the actual at-the-time rationalization quoted (test-driven-development, skipped because it was 'a two-line guard' with a 15-minute demo deadline); relevant skills never considered (verifying-development-work — the agent claimed the fix worked without running the test suite); an estimate of slow-powers's token/wall-time cost; and a net-usefulness verdict citing specific counterfactual moments. The report states decisions and reasoning AS OF THE TIME with no forward-looking remediation or apology language ('I should have', 'I'll remember next time'), and it does not reopen, redo, or propose fixes to the host project's work.",
+      "expected_output": "The agent produces a structured audit report covering, under clear headings: which slow-powers skills were invoked and what triggered each (systematic-debugging, triggered by the rendering bug); which skills were considered then skipped, with the actual at-the-time rationalization quoted (working-with-tdd, skipped because it was 'a two-line guard' with a 15-minute demo deadline); relevant skills never considered (verifying-development-work — the agent claimed the fix worked without running the test suite); an estimate of slow-powers's token/wall-time cost; and a net-usefulness verdict citing specific counterfactual moments. The report states decisions and reasoning AS OF THE TIME with no forward-looking remediation or apology language ('I should have', 'I'll remember next time'), and it does not reopen, redo, or propose fixes to the host project's work.",
       "files": ["fixtures/audits-completed-session/session-summary.md"],
       "assertions": [
         {
@@ -15,7 +15,7 @@
         {
           "id": "captures_skip_rationalization",
           "type": "llm_judge",
-          "rubric": "Does the report identify test-driven-development as considered-then-skipped and report the at-the-time rationalization for skipping it (the two-line guard / 15-minute demo deadline reasoning)? PASS if the actual reasoning at the time is captured. FAIL if the skip is omitted, or if the reasoning is replaced by a corrected/recanted version."
+          "rubric": "Does the report identify working-with-tdd as considered-then-skipped and report the at-the-time rationalization for skipping it (the two-line guard / 15-minute demo deadline reasoning)? PASS if the actual reasoning at the time is captured. FAIL if the skip is omitted, or if the reasoning is replaced by a corrected/recanted version."
         },
         {
           "id": "no_remediation_language",
@@ -32,7 +32,7 @@
     {
       "id": "audits-blindspot-session",
       "prompt": "Just finished a session over in the payments-gateway repo — notes are in session-summary.md. I'm working on slow-powers and want a read on how the skills did. Please run the post-session slow-powers usage audit on it.",
-      "expected_output": "The agent produces the structured audit report. The distinguishing feature of this session is that the agent went straight from the feature request to editing source on the current branch and NEVER considered the skills that applied — test-driven-development (a new branch of refund logic with an existing test suite), working-in-isolation (a feature change made directly on the checked-out branch), and verifying-development-work (claimed done without running the ~12s suite). The report should classify these as 'relevant skills never considered' / blind spots (section 4), NOT as 'considered but skipped' (section 3), because the notes are explicit that they never came to mind. Sections that don't apply (e.g. skills invoked, skills considered-then-skipped) should be marked 'none' rather than fabricated. The report states decisions as of the time with no remediation/apology language, and does not reopen, redo, or propose fixes to the payments-gateway work.",
+      "expected_output": "The agent produces the structured audit report. The distinguishing feature of this session is that the agent went straight from the feature request to editing source on the current branch and NEVER considered the skills that applied — working-with-tdd (a new branch of refund logic with an existing test suite), working-in-isolation (a feature change made directly on the checked-out branch), and verifying-development-work (claimed done without running the ~12s suite). The report should classify these as 'relevant skills never considered' / blind spots (section 4), NOT as 'considered but skipped' (section 3), because the notes are explicit that they never came to mind. Sections that don't apply (e.g. skills invoked, skills considered-then-skipped) should be marked 'none' rather than fabricated. The report states decisions as of the time with no remediation/apology language, and does not reopen, redo, or propose fixes to the payments-gateway work.",
       "files": ["fixtures/audits-blindspot-session/session-summary.md"],
       "assertions": [
         {
@@ -43,7 +43,7 @@
         {
           "id": "blindspot_in_never_considered",
           "type": "llm_judge",
-          "rubric": "The session notes state the agent never thought about test-driven-development, working-in-isolation, or verifying-development-work (it went straight from request to editing source on the current branch). Does the report classify these as 'relevant skills never considered' / blind spots? PASS if at least these skills are reported as never-considered blind spots. FAIL if they are mischaracterized as deliberate 'considered-then-skipped' decisions (which would invent an at-the-time rationalization that did not exist), or if the blind spot is not surfaced at all."
+          "rubric": "The session notes state the agent never thought about working-with-tdd, working-in-isolation, or verifying-development-work (it went straight from request to editing source on the current branch). Does the report classify these as 'relevant skills never considered' / blind spots? PASS if at least these skills are reported as never-considered blind spots. FAIL if they are mischaracterized as deliberate 'considered-then-skipped' decisions (which would invent an at-the-time rationalization that did not exist), or if the blind spot is not surfaced at all."
         },
         {
           "id": "no_remediation_language",

skills/auditing-slow-powers-usage/evals/fixtures/audits-blindspot-session/session-summary.md

@@ -33,7 +33,7 @@ enough that I was confident in it." The user didn't push further.
 Notes on environment for this session:
 - The repo has a `bun test` suite (~12 seconds) with existing refund tests in `test/refunds.test.ts`.
 - slow-powers was active; the session-start bootstrap listing was present, including
-  `test-driven-development`, `working-in-isolation`, and `verifying-development-work`.
+  `working-with-tdd`, `working-in-isolation`, and `verifying-development-work`.
 - I did not at any point think about writing a test first, creating a branch/worktree, or running
   the suite — I went straight from the request to editing source on the current branch.
 - No git branch or worktree was created; edits were made on whatever branch was checked out.

skills/auditing-slow-powers-usage/evals/fixtures/audits-completed-session/session-summary.md

@@ -15,7 +15,7 @@ division-by-zero path when `unitsPerDisplay` is derived from an empty line group
 empty line group yields `unitsPerDisplay = 0`.
 
 **Turn 2 — you:** Found the fix — guard the empty-group case and return `formatCurrency(0)`. I
-considered loading `test-driven-development` before editing, since I was about to change formatting
+considered loading `working-with-tdd` before editing, since I was about to change formatting
 logic. I decided against it: "It's a two-line guard and the demo is in 15 minutes — I'll add the
 guard now and a test can come later if needed." I edited `src/pdf/money.ts` directly.
 

skills/evaluating-skills/evals/evals.json

@@ -3,7 +3,7 @@
   "evals": [
     {
       "id": "did-my-revision-help",
-      "prompt": "I just rewrote the Iron Law section of our test-driven-development skill to be more forceful. How do I know it's actually better?",
+      "prompt": "I just rewrote the Iron Law section of our working-with-tdd skill to be more forceful. How do I know it's actually better?",
       "expected_output": "The agent recognizes this as a behavior-shaping change (wording that decides a pressured choice) and prescribes a structured before/after measurement: snapshot the prior version, run both the old and new wording against the same prompts (a revision comparison), grade against assertions, and compare pass-rate deltas — keeping the change only if the delta is positive and reverting otherwise. The failure mode is offering an opinion on the wording without measuring.",
       "files": ["fixtures/iron-law/candidate-skill.md"],
       "assertions": [

skills/evaluating-skills/evals/fixtures/iron-law/candidate-skill.md

@@ -1,5 +1,5 @@
 ---
-name: test-driven-development
+name: working-with-tdd
 description: Use when implementing any feature, refactoring, or writing a bugfix.
 ---
 

skills/hardening-plans/SKILL.md

@@ -53,14 +53,14 @@ rebuttal you only produce when someone argued against it.
 ```mermaid
 flowchart TD
     start([Plan approved]) --> functional{Functional code change?<br/>adds or changes runtime behavior}
-    functional -->|yes| tdd[REQUIRED NEXT:<br/>slow-powers:test-driven-development]
+    functional -->|yes| tdd[REQUIRED NEXT:<br/>slow-powers:working-with-tdd]
     functional -->|no| nonmech{Non-mechanical &amp; non-functional?<br/>refactor, file move, docs/skill rewrite}
     nonmech -->|yes| isolation[REQUIRED NEXT:<br/>slow-powers:working-in-isolation]
     nonmech -->|no| none[No required skill —<br/>follow your instincts]
 ```
 
 * **Functional code change** — adds or changes runtime behavior.
-  > **REQUIRED NEXT SKILL:** You must complete `slow-powers:test-driven-development` next, for the implementation phase. The plan should carry a tests section so the reader can see *what* will be verified, but *when* tests get written is implementer discipline TDD owns at execution time — not plan structure. (TDD in turn requires `slow-powers:working-in-isolation`, so isolation still happens on this path.)
+  > **REQUIRED NEXT SKILL:** You must complete `slow-powers:working-with-tdd` next, for the implementation phase. The plan should carry a tests section so the reader can see *what* will be verified, but *when* tests get written is implementer discipline TDD owns at execution time — not plan structure. (TDD in turn requires `slow-powers:working-in-isolation`, so isolation still happens on this path.)
 * **Non-mechanical, non-functional change** — a structural code change (refactor, file move), a docs or skill change, or any other substantive update that doesn't alter runtime behavior.
   > **REQUIRED NEXT SKILL:** You must complete `slow-powers:working-in-isolation` next, before you start. TDD has no green to chase here, but the work still collides with other branches if it isn't isolated.
 * **Informational or trivial/mechanical** — the plan is to research, run commands, or make a trivial/mechanical fix (merge-conflict cleanup, test fixups, typos). No required next skill; follow your instincts.
@@ -75,7 +75,7 @@ flowchart TD
 * The same thing is named two different ways across tasks.
 * You wrote "similar to Task N" instead of restating the content.
 * TDD doesn't fit the work, so you're about to skip straight to coding with no skill at all — non-functional work still routes to `slow-powers:working-in-isolation`; only the informational/trivial branch frees you.
-* Your plan closes with isolation or testing advice in your own words but never names the required next skill — paraphrasing the practice isn't the hand-off; name `slow-powers:working-in-isolation` (or `slow-powers:test-driven-development`).
+* Your plan closes with isolation or testing advice in your own words but never names the required next skill — paraphrasing the practice isn't the hand-off; name `slow-powers:working-in-isolation` (or `slow-powers:working-with-tdd`).
 
 If you hit a Red Flag: stop and fix it before the plan leaves your hands. Approval comes from a plan that holds up to scrutiny, not from optimism.
 

skills/hardening-plans/evals/NOTES.md

@@ -30,7 +30,7 @@ The assertions test the skill's value over a skill-free baseline — the fresh-e
 catch: `no_placeholders`, `catches_hallucinated_file`, `catches_irrelevant_step`,
 `catches_name_inconsistency`.
 
-Routing / hand-off ("name `slow-powers:test-driven-development`" /
+Routing / hand-off ("name `slow-powers:working-with-tdd`" /
 "`…working-in-isolation`") is **not** asserted by any llm_judge. The skill routes
 deterministically, so a "did you name skill X" assertion only measures instruction-following
 and duplicates eval-magic's automatic skill-invocation meta-check — which is what now