@slowdini/slow-powers-opencode 0.4.0 → 0.4.1

package/opencode/plugins/slow-powers.js

@@ -3,8 +3,10 @@
  *
  * Injects slow-powers bootstrap context via system prompt transform.
  * Auto-registers skills directory via config hook (no symlinks needed).
+ * Intercepts plan file writes in plan mode and triggers hardening-plans skill.
  */
 
+import { createHash } from "node:crypto";
 import fs from "node:fs";
 import path from "node:path";
 import { fileURLToPath } from "node:url";
@@ -22,10 +24,12 @@ const bootstrapLeadingPhrase = "<EXTREMELY-IMPORTANT>";
 // once eliminates redundant fs work on every agent step.
 let _bootstrapCache; // undefined = not yet loaded, null = file missing
 
-export const SlowPowersPlugin = async ({
-  client: _client,
-  directory: _directory,
-}) => {
+// Deduplication state for plan hardening
+// Map<filePath, contentHash> - tracks processed plan file versions
+const processedPlanHashes = new Map();
+const HARDENED_MARKER = "<!-- hardened-plans -->";
+
+export const SlowPowersPlugin = async ({ client, directory: _directory }) => {
   // Helper to load bootstrap content (cached after first call)
   const getBootstrapContent = () => {
     if (_bootstrapCache !== undefined) return _bootstrapCache;
@@ -40,6 +44,61 @@ export const SlowPowersPlugin = async ({
     return _bootstrapCache;
   };
 
+  const hashContent = (content) =>
+    createHash("sha256").update(content).digest("hex");
+
+  const isPlanHardened = (content) => content.includes(HARDENED_MARKER);
+
+  const handlePlanFileEdit = async (event) => {
+    const filePath = event.properties.file;
+    const sessionID = event.properties.sessionID;
+
+    if (!filePath || !sessionID) return;
+
+    if (!filePath.match(/\.opencode\/plans\/.*\.md$/)) return;
+
+    let session;
+    try {
+      session = await client.session.get({ path: { id: sessionID } });
+    } catch {
+      return;
+    }
+    if (session.agent !== "plan") return;
+
+    let content;
+    try {
+      content = fs.readFileSync(filePath, "utf8");
+    } catch {
+      return;
+    }
+
+    if (isPlanHardened(content)) return;
+
+    const contentHash = hashContent(content);
+    const previousHash = processedPlanHashes.get(filePath);
+    if (previousHash === contentHash) return;
+
+    processedPlanHashes.set(filePath, contentHash);
+
+    try {
+      await client.session.prompt({
+        path: { id: sessionID },
+        body: {
+          noReply: true,
+          parts: [
+            {
+              type: "text",
+              text: `The plan at ${filePath} has been written. Please run the hardening-plans skill on this plan file to review it for hallucinations, missing file references, vague steps, and coverage gaps before presenting it. Update the file in place with the hardened version. Add ${HARDENED_MARKER} marker when done.`,
+            },
+          ],
+        },
+      });
+    } catch (err) {
+      processedPlanHashes.delete(filePath);
+      console.error("[slow-powers] Failed to trigger hardening-plans:", err);
+    }
+  };
+
   return {
     // Inject skills path into live config so OpenCode discovers slow-powers skills
     // without requiring manual symlinks or config file edits.
@@ -82,5 +141,10 @@ export const SlowPowersPlugin = async ({
 
       firstUser.parts.unshift({ type: "text", text: bootstrap });
     },
+
+    event: async ({ event }) => {
+      if (event.type !== "file.edited") return;
+      await handlePlanFileEdit(event);
+    },
   };
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@slowdini/slow-powers-opencode",
-  "version": "0.4.0",
+  "version": "0.4.1",
   "description": "Slow-powers — structured development workflows for coding agents (TDD, debugging, verification, git hygiene)",
   "type": "module",
   "main": "./opencode/plugins/slow-powers.js",

package/skills/hardening-plans/SKILL.md

@@ -40,13 +40,30 @@ Before the plan leaves your hands, re-read the whole draft once, top to bottom,
 
 ---
 
-## The Next Gate: Implementation
-
-When the plan is approved, implementation begins — and implementation has its own gate.
-
-> **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, not plan structure — TDD owns it at execution time, not the reviewer or the user reading the plan.
+## Choosing the Next Step
+
+When the plan is approved, the next move depends on what kind of work the plan
+describes. Route by the **first** branch that matches — then **close your hand-off
+by naming the required next skill verbatim**, with its `slow-powers:` identifier.
+Telling the reader to "work on a branch" or "write the tests first" in your own
+words is *not* the hand-off; the named skill is. State it even on a cold draft
+where nothing pushed back — the named hand-off is part of the deliverable, not a
+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 -->|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.)
+* **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.
 
 ---
 
@@ -57,6 +74,8 @@ The plan should carry a tests section so the reader can see *what* will be verif
 * The plan contains "TBD", "TODO", "later", "if needed", "appropriate", or "etc."
 * 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`).
 
 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.
 
@@ -70,3 +89,6 @@ If you hit a Red Flag: stop and fix it before the plan leaves your hands. Approv
 | "That file is probably where I said it is." | "Probably" isn't verified. Check it before the user does. |
 | "The plan reads fine — I don't need to re-review it." | You wrote it, so you're blind to its gaps. Re-read it as someone who has to execute it. |
 | "Repeating context across similar tasks is wasteful." | The reader may read tasks out of order. Restate the relevant detail. |
+| "It's just docs / a refactor — it doesn't need isolation." | Non-mechanical changes still collide with other work. Route by the flowchart: structural and docs changes get `slow-powers:working-in-isolation`. |
+| "TDD doesn't apply, so no skill applies." | TDD is only the *functional* branch. Non-functional, non-mechanical work still has a required next skill — isolation. |
+| "I told them to work on a branch / isolate the work — that covers it." | Generic isolation advice in your own words isn't the hand-off. Name `slow-powers:working-in-isolation` as the required next skill — the named hand-off is the deliverable, on a cold draft as much as a contested one. |

package/skills/hardening-plans/evals/baseline/BASELINE.md

@@ -1,20 +1,25 @@
 # Baseline — hardening-plans
 
 Committed reference output from a canonical eval run. Regenerate with
-`bun run evals:promote-baseline -- --skill hardening-plans --iteration <N>` after aggregating. The ephemeral workspace (run records, timing,
-dispatch files, produced outputs) stays gitignored under `skills-workspace/`.
+`skill-eval promote-baseline --skill hardening-plans --iteration <N>` after aggregating. The ephemeral workspace (run records, timing,
+dispatch files, produced outputs) stays gitignored under `skills-workspace/`
+and is reclaimable by `skill-eval teardown` once promoted (this commit's marker).
 
 | Field | Value |
 |-------|-------|
 | Mode | revision |
-| Iteration | iteration-1 |
+| Iteration | iteration-2 |
 | Harness | claude-code |
 | Agent model | claude-sonnet-4-6 |
 | Judge model | claude-sonnet-4-6 |
 | Conditions | old_skill, new_skill |
-| Run timestamp | 2026-05-31T18:40:23.484Z |
-| Label | 3b-fresh-eyes-review |
-| Promoted from commit | bbca8ca |
+| Run timestamp | 2026-06-07T04:07:44.660Z |
+| Label | next-step-named-handoff |
+| Promoted from commit | 7dc77dd |
+
+`old_skill` = `next-step-v1` (commit `b62c4cd`, the next-step flowchart **without**
+the named-hand-off requirement). `new_skill` = the working tree at promotion
+(`7dc77dd`, flowchart **with** the named-hand-off requirement).
 
 Files:
 - `benchmark.json` — aggregate pass-rate / duration / token deltas.

package/skills/hardening-plans/evals/baseline/NOTES.md

@@ -1,65 +1,79 @@
-# Notes — hardening-plans 3b baseline (iteration-1)
+# Notes — hardening-plans next-step baseline (iteration-2)
 
 Forward-looking observations from the run that produced this baseline. Read these
 before trusting the headline `benchmark.json` aggregate.
 
-## Read the per-case deltas, not the aggregate
-
-The aggregate `delta.pass_rate` is **−22pp (new_skill below old_skill)**, but that
-number is misleading on its own — it is dragged entirely by one confounded
-negative case (see below). The per-case picture:
-
-| Case | old | new | note |
-|------|-----|-----|------|
-| `concrete-todo-app-plan` | 100% | 100% | no discrimination (both pass) |
-| `seeded-review-catches-defects` | 67% | **100%** | **the headline: +33pp** |
-| `csv-parser-bug-no-plan` (negative) | 100% | **0%** | confounded regression, see below |
-
-## The headline behavioral delta is clean
-
-`seeded-review-catches-defects` is the case the 3b reframe targets. The
-discriminating assertion is **`catches_hallucinated_file`**: old_skill **FAIL**
-(carried `src/hooks/useLocalStorage.ts` forward as "Already exists; verify
-signature") → new_skill **PASS** (flagged it as unconfirmed, reworded to
-"create or extend"). Invocation rate 100% in both arms, no `validity_warnings` —
-so the delta reflects the skill, not a trigger artifact. `catches_irrelevant_step`
-(Redux) and `hands_off_to_tdd` passed in *both* arms, so they don't discriminate
-here; `catches_hallucinated_file` is the load-bearing one.
-
-## The csv-parser regression is explained and orthogonal to the reframe
-
-On the negative over-trigger guard, new_skill loaded `hardening-plans` and drafted
-+ hardened a plan instead of routing to `systematic-debugging` (old_skill routed
-correctly). **Confirmed proximate cause:** the pre-3b "When NOT to Use" section
-carried an explicit signpost —
-
-> * The task is debugging — load `slow-powers:systematic-debugging` instead.
-
-— and the 3b rewrite **dropped that line**. The old arm matched it and routed; the
-new arm had no such signpost and fell through to plan-then-harden. This is a *real*
-side effect of a 3b text change, **not** N=1 noise.
-
-Ruled out: plan-mode framing. `csv-parser-bug-no-plan` is a **cold** prompt — it
-injects no plan-mode context (only the seeded cases do). So the
-"debugging-request-in-plan-mode" philosophical wrinkle (tracked separately as an
-internal eval-framing issue) does **not** explain this failure; the dropped line
-does.
-
-## Suggested follow-up (not done here)
-
-Re-adding the one-line debugging route to "When NOT to Use" would very likely
-restore the negative guard at near-zero risk to the reframe. Deferred as a
-separate change so 3b stays one-problem-per-PR; left to the maintainer's call.
-
-**Update (2026-06-01):** `csv-parser-bug-no-plan` was retired per #111 — the
-over-trigger guard went red on correct consult-then-defer behavior (the agent
-loads `hardening-plans`, reads "When NOT to Use," and correctly routes to
-`systematic-debugging`, which the strict rubric scored as a failure). Its grading
-files were removed; the table and `benchmark.json` below still reflect the
-original 3-case run as it happened.
+## What this baseline measures
+
+Revision (Mode B), sonnet agent + sonnet judge, 8 cases, N=1 per case/condition:
+
+- **`old_skill` = `next-step-v1`** (commit `b62c4cd`): the next-step *flowchart*
+  (functional → TDD, non-mechanical/non-functional → working-in-isolation,
+  informational/trivial → no skill) **without** an explicit instruction to emit a
+  *named* hand-off.
+- **`new_skill`** (commit `7dc77dd`): same flowchart **plus** "close your hand-off
+  by naming the required next skill verbatim, even on a cold draft", the canonical
+  "You must complete … next" cross-references, and a red-flag + rationalization
+  closing the spirit-vs-letter loophole.
+
+This is the **second** iteration of the issue #188 work. Iteration-1 compared the
+flowchart (`b62c4cd`) against the *pre-flowchart* single-TDD-gate (`dev`); see the
+"iteration-1 context" section below for why iteration-2 exists.
+
+## Headline: clean sweep, but read the flakiness caveat
+
+`new_skill` passed **8/8 cases, stddev 0** (100%) vs `old_skill` **87.5%**
+(delta **+12.5pp** toward new). Both arms invoked the skill 100%; no
+`validity_warnings`. `new_skill` also used slightly fewer tokens on average.
+
+The two `old_skill` misses were the noisy fresh-eyes assertions, not routing:
+`seeded-plan-mode-todo-app-adversarial/no_placeholders` and
+`oauth-task-breakdown-cold/hands_off_to_tdd`. `new_skill` passed both — the
+strengthened "You must complete … next" phrasing plausibly firmed up the
+functional TDD hand-off too — but at N=1 these are within run-to-run noise.
+
+## The structural-refactor-cold caveat (the important one)
+
+`structural-refactor-cold` is the case the iteration-2 edit targeted, and it is
+**flaky at N=1**. The `routes_to_working_in_isolation` assertion on the
+*identical* `b62c4cd` content flipped across runs:
+
+| skill content | run | routes_to_working_in_isolation |
+|---|---|---|
+| `b62c4cd` (no named-hand-off line) | iteration-1 `new_skill` | **FAIL** (gave generic "set up an isolated branch" advice, never named the skill) |
+| `b62c4cd` (no named-hand-off line) | iteration-2 `old_skill` | **PASS** (named the skill on its own) |
+| `7dc77dd` (named-hand-off line)    | iteration-2 `new_skill` | **PASS** (explicit "REQUIRED NEXT SKILL: `slow-powers:working-in-isolation`") |
+
+So this single run does **not** cleanly attribute the cold-structural pass to the
+edit: `old_skill` happened to pass it too. What the run *does* show is that
+`new_skill` is **≥ `old_skill` on every case, swept 8/8 with zero variance, and
+emitted the named hand-off on the cold draft** — with no regressions. Treat the
++12.5pp as "at least as good, and reliably named" rather than proof the edit beats
+v1 *specifically on the flaky case*. **If you revisit this, replicate
+`structural-refactor-cold` a few times per condition** (the runner has no per-case
+run multiplier — use repeated `--only structural-refactor-cold` iterations) to
+firm up the attribution.
+
+## Iteration-1 context (why iteration-2 exists)
+
+Iteration-1 (`dev` single-TDD-gate vs `b62c4cd` flowchart) showed the flowchart's
+**clean win on the seeded #188 case**: `docs-refactor-plan-mode` — old talked
+itself out of isolation (the audited #188 bug), new routed to
+`slow-powers:working-in-isolation`. But it also exposed the gap this baseline
+closes: on the **cold** `structural-refactor-cold` draft, the flowchart produced
+isolation advice *in spirit* without *naming* the skill, failing the assertion.
+That gap motivated the named-hand-off edit measured here.
+
+## Noisy assertions to distrust at N=1
+
+`no_placeholders` and `hands_off_to_tdd` scatter PASS/FAIL across both conditions
+run-to-run; they are fresh-eyes/quality checks, not tests of the routing change.
+Don't read a single-run flip on either as signal. The routing assertions
+(`routes_to_working_in_isolation`, `does_not_force_tdd`, `no_forced_next_skill`)
+are the ones this baseline exists to track.
 
 ## Provenance / scope
 
-3-case cost-conscious subset (the runner has no per-case selector — tracked as a
-follow-up issue; the full 6-case suite was temporarily reduced for this run and
-restored afterward). Agent + judge both `claude-sonnet-4-6`.
+8-case full suite. Plan-mode injection **off** (the seeded cases carry plan
+framing in prose; the `*-cold` and research cases are deliberately cold). Agent +
+judge both `claude-sonnet-4-6`.

package/skills/hardening-plans/evals/baseline/benchmark.json

@@ -1,54 +1,54 @@
 {
-  "generated": "2026-05-31T18:45:08.006Z",
+  "generated": "2026-06-07T04:14:04.136Z",
   "mode": "revision",
-  "baseline": "pre-3b",
+  "baseline": "next-step-v1",
   "conditions_compared": ["old_skill", "new_skill"],
   "missing_gradings": 0,
   "validity_warnings": [],
   "run_summary": {
     "old_skill": {
       "pass_rate": {
-        "mean": 0.889,
-        "stddev": 0.157,
-        "n": 3
+        "mean": 0.875,
+        "stddev": 0.217,
+        "n": 8
       },
       "duration_ms": {
-        "mean": 67442,
-        "stddev": 25787,
-        "n": 3
+        "mean": 68065,
+        "stddev": 15551,
+        "n": 8
       },
       "total_tokens": {
-        "mean": 18945,
-        "stddev": 3610,
-        "n": 3
+        "mean": 84608,
+        "stddev": 6327,
+        "n": 8
       },
-      "skill_invocation_n": 2,
+      "skill_invocation_n": 8,
       "skill_invocation_rate": 1
     },
     "new_skill": {
       "pass_rate": {
-        "mean": 0.667,
-        "stddev": 0.471,
-        "n": 3
+        "mean": 1,
+        "stddev": 0,
+        "n": 8
       },
       "duration_ms": {
-        "mean": 50963,
-        "stddev": 6742,
-        "n": 3
+        "mean": 68376,
+        "stddev": 14889,
+        "n": 8
       },
       "total_tokens": {
-        "mean": 16728,
-        "stddev": 770,
-        "n": 3
+        "mean": 78521,
+        "stddev": 16433,
+        "n": 8
       },
-      "skill_invocation_n": 2,
+      "skill_invocation_n": 8,
       "skill_invocation_rate": 1
     }
   },
   "delta": {
     "direction": "old_skill - new_skill",
-    "pass_rate": 0.222,
-    "duration_ms": 16479,
-    "total_tokens": 2217
+    "pass_rate": -0.125,
+    "duration_ms": -311,
+    "total_tokens": 6087
   }
 }

package/skills/hardening-plans/evals/baseline/grading/concrete-todo-app-plan__new_skill.json

@@ -3,14 +3,14 @@
     {
       "id": "no_placeholders",
       "passed": true,
-      "evidence": "All 8 steps are fully concrete: file paths are named (e.g. 'src/types.ts', 'src/components/TodoItem.tsx'), prop interfaces are written out in full, handler logic is specified ('maps todos, flipping completed on the matching id'), CSS values are exact ('max-width: 480px', 'color: #888'), and the test table lists six explicit scenarios with expected results. No 'TBD', 'TODO', 'later', 'if needed', or equivalent placeholder appears anywhere in the plan.",
+      "evidence": "Every task in the plan is fully concrete: Task 1 gives exact CLI commands and filenames to delete; Task 2 provides the complete TypeScript interface; Task 3 specifies exact state shape, API signatures, and side-effect behavior; Tasks 4–6 give exact prop types, rendered element structure, and CSS class names; Task 7 specifies exact destructuring and JSX structure; Task 8 gives exact CSS property values. The tests section lists specific test cases per component. No 'TBD', 'TODO', 'later', 'if needed', or any other placeholder appears anywhere in the final_message.",
       "confidence": 1,
       "grader": "llm_judge"
     },
     {
       "id": "hands_off_to_tdd",
       "passed": true,
-      "evidence": "\"When implementation begins, use `slow-powers:test-driven-development` for the implementation phase.\"",
+      "evidence": "**REQUIRED NEXT SKILL:** `slow-powers:test-driven-development`\n\nThis plan adds runtime behavior, so TDD governs the implementation phase.",
       "confidence": 1,
       "grader": "llm_judge"
     }

package/skills/hardening-plans/evals/baseline/grading/concrete-todo-app-plan__old_skill.json

@@ -3,14 +3,14 @@
     {
       "id": "no_placeholders",
       "passed": true,
-      "evidence": "Every task in the plan names a specific file, function, and observable outcome. The final message states explicitly: 'Every task names the file, the function, and the observable outcome (exact error message or assertion). No placeholders.' The grep scan found no placeholder terms — all matches were false positives from domain vocabulary ('TodoItem', 'useTodos'). No 'TBD', 'TODO' (as a placeholder), 'later', 'if needed', or 'etc.' appear as unresolved items anywhere in the plan.",
+      "evidence": "All steps are fully concrete: step 1 gives exact CLI commands (`npm create vite@latest todo-app -- --template react-ts`), step 2 provides a complete TypeScript interface, step 4 lists specific file paths and prop signatures, step 7 names exact npm packages and config keys, and step 9 gives verbatim build/test commands. No 'TBD', 'TODO', 'later', 'if needed', or any other placeholder appears anywhere in the plan.",
       "confidence": 1,
       "grader": "llm_judge"
     },
     {
       "id": "hands_off_to_tdd",
       "passed": true,
-      "evidence": "\"Implementation follows Red→Green→Refactor — load `slow-powers:test-driven-development` when you start coding.\" (final_message, last line)",
+      "evidence": "\"Once you approve this plan, the next step is `slow-powers:test-driven-development` (this is a functional code change that adds runtime behavior).\"",
       "confidence": 1,
       "grader": "llm_judge"
     }

package/skills/hardening-plans/evals/baseline/grading/docs-refactor-plan-mode__new_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "routes_to_working_in_isolation",
+      "passed": true,
+      "evidence": "REQUIRED NEXT SKILL: `slow-powers:working-in-isolation` — before any file is touched.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "does_not_force_tdd",
+      "passed": true,
+      "evidence": "The final_message names exactly one required next skill: 'REQUIRED NEXT SKILL: `slow-powers:working-in-isolation`'. There is no mention of test-driven-development anywhere in the response.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/docs-refactor-plan-mode__old_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "routes_to_working_in_isolation",
+      "passed": true,
+      "evidence": "\"Wrong next step. I said 'I'll skip the slow-powers skills and just start editing on the current branch.' That's incorrect. A docs restructure of this scope ... is non-mechanical and non-functional. The routing rule is clear: non-mechanical, non-functional changes require `slow-powers:working-in-isolation` before starting.\" and \"Set the next step correctly to `slow-powers:working-in-isolation`.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "does_not_force_tdd",
+      "passed": true,
+      "evidence": "The final_message sets the corrected next step as 'slow-powers:working-in-isolation' and never mentions test-driven-development at all — TDD is neither imposed nor referenced anywhere in the response.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/oauth-task-breakdown-cold__new_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "no_placeholders",
+      "passed": true,
+      "evidence": "No 'TBD', 'TODO', 'later', or 'if needed' language appears anywhere in the final message. Every task is concrete: Task 9 even explicitly instructs 'Identify those routes now (do not defer)'. The angle-bracket tokens in Task 3 (e.g. '<paste from Google Console>') are engineer instructions, not deferred decisions.",
+      "confidence": 0.97,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "hands_off_to_tdd",
+      "passed": true,
+      "evidence": "**REQUIRED NEXT SKILL:** `slow-powers:test-driven-development`\n\nThis plan adds runtime behavior (new auth routes, session handling, database writes). Before the engineer writes any implementation code, they must complete `slow-powers:test-driven-development`.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/oauth-task-breakdown-cold__old_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "no_placeholders",
+      "passed": true,
+      "evidence": "No 'TBD', 'TODO', 'later', or 'if needed' strings appear anywhere in the final_message. Every task supplies concrete file paths (e.g. 'src/auth/passport.js'), package names with version-pinning instructions, explicit configuration values ('resave: false', 'saveUninitialized: false'), and step-by-step actions. Template tokens like '<provider>' are intentional decision-point markers resolved by Task 1, not unspecified implementation items.",
+      "confidence": 0.95,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "hands_off_to_tdd",
+      "passed": false,
+      "evidence": "The final_message contains no mention of 'slow-powers:test-driven-development', no hand-off to the TDD skill, and no use of the label 'TDD' anywhere. Task 10 ('Write tests') describes what tests to write but names no implementation skill and makes no explicit hand-off.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 1,
+    "failed": 1,
+    "total": 2,
+    "pass_rate": 0.5
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/research-plan-no-required-skill__new_skill.json

@@ -0,0 +1,32 @@
+{
+  "assertion_results": [
+    {
+      "id": "no_forced_next_skill",
+      "passed": true,
+      "evidence": "The final_message contains no mention of slow-powers:test-driven-development or slow-powers:working-in-isolation as required next steps; it closes with 'No repository or pipeline changes are required during the investigation,' confirming the response treats this as a pure read-only investigation with no forced skill gate.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/research-plan-no-required-skill__old_skill.json

@@ -0,0 +1,32 @@
+{
+  "assertion_results": [
+    {
+      "id": "no_forced_next_skill",
+      "passed": true,
+      "evidence": "The final_message ends with 'Once you've worked through these steps, share what you find and we can scope the fixes.' — no mention of slow-powers:test-driven-development or slow-powers:working-in-isolation as a required next step anywhere in the response.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/seeded-plan-mode-todo-app-adversarial__new_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "no_placeholders",
+      "passed": true,
+      "evidence": "Every section of the plan is fully concrete: file paths are specified ('src/components/TodoItem.tsx', 'src/components/TodoList.tsx', 'src/components/AddTodoForm.tsx', etc.), the data shape is typed with exact fields, prop interfaces are written out, handler logic is described step-by-step, test cases enumerate specific scenarios including edge cases ('Persistence — corrupt key: set localStorage.getItem(\"todos\") to \"not-json\" before mounting; assert the component mounts with an empty list and does not throw'), and the smoke test is a numbered checklist. No occurrences of 'TBD', 'TODO', 'later', 'if needed', or equivalent placeholder language appear anywhere in the final_message.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "hands_off_to_tdd",
+      "passed": true,
+      "evidence": "### Required next skill\n\nThis plan describes a functional code change (adds runtime behavior). The required next step is `slow-powers:test-driven-development`.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/seeded-plan-mode-todo-app-adversarial__old_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "no_placeholders",
+      "passed": false,
+      "evidence": "The agent explicitly labels the file paths as placeholders: 'I’ve added placeholder paths below using the conventional `src/components/` location — confirm or correct these before we proceed.' The plan therefore contains a declared placeholder rather than a confirmed concrete value.",
+      "confidence": 0.97,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "hands_off_to_tdd",
+      "passed": true,
+      "evidence": "\"This is a functional code change, so **`slow-powers:test-driven-development` is required next** — write the tests in Task 5 before touching the implementation files. TDD will also set up the isolated workspace.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 1,
+    "failed": 1,
+    "total": 2,
+    "pass_rate": 0.5
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/seeded-plan-mode-todo-app__new_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "no_placeholders",
+      "passed": true,
+      "evidence": "The final_message contains no placeholders — every step is fully specified: file paths are named (e.g. 'src/components/TodoItem.tsx'), props and state shapes are enumerated, handler logic is described in concrete terms (e.g. 'appends { id: crypto.randomUUID(), text, completed: false } to todos'), and all five test cases are spelled out with explicit setup and assertion steps. No 'TBD', 'TODO', 'later', 'if needed', or equivalent deferral language appears anywhere.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "hands_off_to_tdd",
+      "passed": true,
+      "evidence": "\"REQUIRED NEXT: `slow-powers:working-in-isolation` (to establish an isolated branch), then `slow-powers:test-driven-development` for the implementation phase.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/seeded-plan-mode-todo-app__old_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "no_placeholders",
+      "passed": true,
+      "evidence": "The final_message contains no instances of 'TBD', 'TODO', 'later', or 'if needed'. Every task specifies concrete file names, TypeScript interfaces, JSX snippets, and handler logic. The one vague phrase — 'max-width as appropriate for the app's existing style' in the TodoList.css description — is a style guidance note, not a placeholder that defers implementation.",
+      "confidence": 0.9,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "hands_off_to_tdd",
+      "passed": true,
+      "evidence": "\"This plan adds runtime behavior, so the implementation phase must follow `slow-powers:test-driven-development` (Task 1 above is the TDD entry point — tests before code). That skill also requires `slow-powers:working-in-isolation` before touching any files.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/seeded-review-catches-defects__new_skill.json

@@ -3,21 +3,21 @@
     {
       "id": "catches_hallucinated_file",
       "passed": true,
-      "evidence": "\"Unverified file reference. The draft said 'extend the *existing* `src/hooks/useLocalStorage.ts`' — I have no confirmation this file exists in your project. Reworded to 'create or extend' so the step is honest about what will happen.\"",
+      "evidence": "The final_message explicitly calls out 'Hallucinated file references — two files cited as \"existing\" without verification.' listing `src/hooks/useLocalStorage.ts` and noting 'Neither was confirmed to exist.' The corrected plan's Step 1 reads: 'Confirm `src/hooks/useLocalStorage.ts` exists. If it does not, create it…'",
       "confidence": 1,
       "grader": "llm_judge"
     },
     {
       "id": "catches_irrelevant_step",
       "passed": true,
-      "evidence": "\"Hallucinated Redux dependency (Red Flag). Step 4 introduced a Redux store and todo slice that you never asked for. Redux is a different state management pattern that contradicts the localStorage-first approach in step 1. Removed.\"",
+      "evidence": "**Unrequested dependency — Redux introduced with no basis in the spec.** The request is for localStorage persistence. A Redux slice is an invented architectural choice. It also creates structural incoherence: localStorage (Step 1) and Redux (Step 4) would both manage the same state.",
       "confidence": 1,
       "grader": "llm_judge"
     },
     {
       "id": "hands_off_to_tdd",
       "passed": true,
-      "evidence": "\"Ready to start? I'll follow `test-driven-development` for the implementation phase.\"",
+      "evidence": "**REQUIRED NEXT SKILL:** `slow-powers:test-driven-development`\n\nThis is a functional code change that adds runtime behavior. TDD governs the implementation phase.",
       "confidence": 1,
       "grader": "llm_judge"
     }

package/skills/hardening-plans/evals/baseline/grading/seeded-review-catches-defects__old_skill.json

@@ -2,31 +2,31 @@
   "assertion_results": [
     {
       "id": "catches_hallucinated_file",
-      "passed": false,
-      "evidence": "The file map states 'Already exists; verify signature covers generics.' and Task 2 says 'Open src/hooks/useLocalStorage.ts. Confirm the exported signature...' — the response treats the file's existence as a given inherited from the draft, only adding a signature-verification step, never questioning whether the file actually exists at all.",
-      "confidence": 0.92,
+      "passed": true,
+      "evidence": "\"Hallucinated file references (Red Flag): The plan said 'extend the existing `src/hooks/useLocalStorage.ts`' and 'add Redux store configuration in `src/store/index.ts`' — neither was verified to exist. The plan now flags both for explicit confirmation before coding begins.\" and the finalized plan includes a prerequisite verification step: \"Check whether `src/hooks/useLocalStorage.ts` exists. If yes, extend it. If no, create it at that path.\"",
+      "confidence": 1,
       "grader": "llm_judge"
     },
     {
       "id": "catches_irrelevant_step",
       "passed": true,
-      "evidence": "Redux introduced without justification. Step 4 added a Redux store slice for a feature that only needs `useLocalStorage`. Introducing Redux adds three files and a new dependency for no benefit here. I've dropped it and kept state local to the `TodoList` component, backed by the hook.",
+      "evidence": "\"Unrequested Redux dependency: Step 4 introduced a Redux slice and store wiring that the user never asked for and that useState + useLocalStorage handles without additional infrastructure. Removed entirely — it was an irrelevant step.\"",
       "confidence": 1,
       "grader": "llm_judge"
     },
     {
       "id": "hands_off_to_tdd",
       "passed": true,
-      "evidence": "\"For all code-writing tasks below, follow `slow-powers:test-driven-development` (Red-Green-Refactor).\" and \"load `slow-powers:test-driven-development` when you reach the code-writing steps\" — both replace the bare '(TDD.)' label from the draft with an explicit named skill hand-off.",
+      "evidence": "**Next step:** This is a functional code change. Required next skill: `slow-powers:test-driven-development`.",
       "confidence": 1,
       "grader": "llm_judge"
     }
   ],
   "summary": {
-    "passed": 2,
-    "failed": 1,
+    "passed": 3,
+    "failed": 0,
     "total": 3,
-    "pass_rate": 0.6666666666666666
+    "pass_rate": 1
   },
   "meta_results": [
     {

package/skills/hardening-plans/evals/baseline/grading/structural-refactor-cold__new_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "routes_to_working_in_isolation",
+      "passed": true,
+      "evidence": "REQUIRED NEXT SKILL: `slow-powers:working-in-isolation` — complete this before starting, so the reorganization branch doesn't collide with other in-flight work.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "does_not_force_tdd",
+      "passed": true,
+      "evidence": "The response names 'REQUIRED NEXT SKILL: `slow-powers:working-in-isolation`' as the required gate and never mentions test-driven-development. The only reference to tests is in step 6/Verify: 'Run: full test suite; tsc --noEmit; linter' — using existing tests to confirm no behavior change, not demanding tests-first authorship.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/baseline/grading/structural-refactor-cold__old_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "routes_to_working_in_isolation",
+      "passed": true,
+      "evidence": "\"Before you start: because this is a structural, non-functional change, set up an isolated branch/worktree first (`slow-powers:working-in-isolation`) so this work doesn't collide with other in-progress branches.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "does_not_force_tdd",
+      "passed": true,
+      "evidence": "Task 5 says 'Run the full test suite to confirm no behavior changes were introduced' — running existing tests to validate a refactor, not imposing TDD. The only skill referenced is 'slow-powers:working-in-isolation'; test-driven-development is never mentioned or required.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/hardening-plans/evals/evals.json

@@ -90,6 +90,52 @@
           "rubric": "Does the response make a real hand-off to the implementation skill — explicitly naming `slow-powers:test-driven-development` as the required next skill for the implementation phase — rather than merely dropping 'TDD' as an unexplained label or parenthetical? PASS if test-driven-development is named as the next/required skill for implementation. FAIL if 'TDD' appears only as a bare label with no hand-off, or is absent. (The plan is NOT required to sequence each task tests-first; that is implementer discipline owned by the TDD skill, not plan structure.)"
         }
       ]
+    },
+    {
+      "id": "docs-refactor-plan-mode",
+      "prompt": "[The following is the conversation so far in this session. You are the assistant operating inside the harness's plan-mode workflow — you have already explored the repo and drafted a plan. Continue from the final user turn.]\n\nUser: Our docs have drifted. I want a big restructure of the README and the docs/ tree — split the monolithic README into topic pages, rewrite the getting-started guide, and fix the cross-links. Draft a plan I can review before you touch any files.\n\nAssistant: I've read through the docs and drafted the restructure plan.\n\n## Approach\n1. Split `README.md` into `docs/install.md`, `docs/usage.md`, and `docs/faq.md`, leaving a short overview in `README.md`.\n2. Rewrite `docs/getting-started.md` against the current CLI flags.\n3. Update every internal cross-link to the new page locations.\n\n## Next step\nThis is a docs-only change — there's no code and nothing to test, so I'll skip the slow-powers skills and just start editing on the current branch once you approve. Working in a separate workspace would be overkill for prose.\n\nUser: Approach looks right. Give me the finalized plan and let's go.",
+      "expected_output": "The agent should load `hardening-plans` and run the fresh-eyes review on the drafted docs-restructure plan (spec coverage, referenced files real, every step relevant, no placeholders, names consistent). Crucially, on the next-step routing it should NOT force `slow-powers:test-driven-development` (there is no functional code change) and should NOT accept the seeded 'skip the skills, edit on the current branch' rationalization: a docs/skill rewrite is a non-mechanical, non-functional change, so the required next skill is `slow-powers:working-in-isolation`. This mirrors a real audited session (issue #188) where a docs refactor wrongly talked itself out of isolation. This is a seeded probe, so a pass is a stronger-than-cold signal, not ground truth (see the 'Seeding conversation context (and its ceiling)' note in evaluating-skills). skill_should_trigger stays true.",
+      "assertions": [
+        {
+          "id": "routes_to_working_in_isolation",
+          "type": "llm_judge",
+          "rubric": "Does the response name `slow-powers:working-in-isolation` as the required next step before editing — correcting the seeded plan's 'skip the skills and edit on the current branch' stance? PASS if working-in-isolation is named as the required/next skill for this docs change. FAIL if it endorses skipping isolation, or names no next skill at all."
+        },
+        {
+          "id": "does_not_force_tdd",
+          "type": "llm_judge",
+          "rubric": "Does the response correctly refrain from demanding `slow-powers:test-driven-development` as the required next skill for this docs-only change? PASS if TDD is not imposed as the required next step (it may be mentioned only to explain it does not apply). FAIL if the response forces test-driven-development as the next gate for a change with no runtime behavior."
+        }
+      ]
+    },
+    {
+      "id": "structural-refactor-cold",
+      "prompt": "I'm about to reorganize our backend source. Right now everything sits flat in `src/` — I want to move the files into module sub-directories (`src/auth/`, `src/billing/`, `src/users/`, etc.) and fix the imports, with no behavior changes. Before I start, break this into a plan I can review.",
+      "expected_output": "The agent should load `hardening-plans` and produce a concrete refactor plan (every referenced path real or a real named home, no placeholders, every step relevant to the move). On next-step routing, this is a structural, non-functional code change: existing tests act as a continuous green flag and there is no new behavior to drive tests-first, so the agent should NOT force `slow-powers:test-driven-development`. The required next skill is `slow-powers:working-in-isolation` (a large file move must be isolated from other work). This mirrors a real audited session (issue #188). This is a colder trigger: the request frames the agent as already about to plan, so the skill must fire on the about-to-hand-off moment.",
+      "assertions": [
+        {
+          "id": "routes_to_working_in_isolation",
+          "type": "llm_judge",
+          "rubric": "Does the response name `slow-powers:working-in-isolation` as the required next step before starting the refactor? PASS if working-in-isolation is named as the required/next skill. FAIL if no next skill is named, or only TDD is named."
+        },
+        {
+          "id": "does_not_force_tdd",
+          "type": "llm_judge",
+          "rubric": "Does the response correctly refrain from demanding `slow-powers:test-driven-development` as the required next skill for this behavior-preserving refactor? PASS if TDD is not imposed as the required next gate (it may note that existing tests verify the move). FAIL if the response forces test-driven-development tests-first for a refactor that adds no behavior."
+        }
+      ]
+    },
+    {
+      "id": "research-plan-no-required-skill",
+      "prompt": "Before we change anything, I want to understand why our CI pipeline got slow over the last month. Draft a plan for the investigation — what to measure, which logs and timing data to pull, and how to narrow down the regression. No code changes yet, just the investigation steps.",
+      "expected_output": "The agent should load `hardening-plans` and harden the investigation plan (concrete measurement steps, real log/artifact references, no placeholders, every step relevant to finding the regression). On next-step routing, this plan is purely informational — research and running commands, no code change — so the correct outcome is that NO follow-up skill is forced: neither `slow-powers:test-driven-development` nor `slow-powers:working-in-isolation` should be imposed as a required next gate. The agent should route to 'follow your instincts' for the investigation itself.",
+      "assertions": [
+        {
+          "id": "no_forced_next_skill",
+          "type": "llm_judge",
+          "rubric": "Does the response correctly avoid imposing any required follow-up slow-powers skill for this research/investigation plan? PASS if it does not mandate `slow-powers:test-driven-development` or `slow-powers:working-in-isolation` as a required next step (it may mention that no required skill applies). FAIL if it forces either skill as the required next gate for a pure investigation with no code change."
+        }
+      ]
     }
   ]
 }