@slowdini/slow-powers-opencode 0.1.0

package/skills/evaluating-skills/schema/run-record.schema.json

@@ -0,0 +1,80 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "$id": "https://slow-powers.dev/schemas/run-record.schema.json",
+  "title": "Portable Run Record",
+  "description": "Captures one subagent run. Harness-agnostic — each harness writes an adapter from its native transcript format to this shape. Downstream grading reads only this file.",
+  "type": "object",
+  "required": [
+    "eval_id",
+    "condition",
+    "skill_path",
+    "prompt",
+    "files",
+    "final_message",
+    "tool_invocations"
+  ],
+  "additionalProperties": false,
+  "properties": {
+    "eval_id": {
+      "type": "string",
+      "description": "Matches the eval's id in evals.json."
+    },
+    "condition": {
+      "type": "string",
+      "description": "Reserved names: with_skill, without_skill, old_skill, new_skill."
+    },
+    "skill_path": {
+      "type": ["string", "null"],
+      "description": "Absolute path to the SKILL.md the subagent could load, or null if no skill was provided (without_skill condition)."
+    },
+    "prompt": {
+      "type": "string",
+      "description": "The user prompt as dispatched to the subagent."
+    },
+    "files": {
+      "type": "array",
+      "items": { "type": "string" },
+      "description": "Fixture files the subagent had access to (absolute paths inside the run's workspace)."
+    },
+    "final_message": {
+      "type": "string",
+      "description": "The agent's final user-facing text output."
+    },
+    "tool_invocations": {
+      "type": "array",
+      "description": "Ordered list of tool calls during the run.",
+      "items": {
+        "type": "object",
+        "required": ["name", "ordinal"],
+        "additionalProperties": false,
+        "properties": {
+          "name": {
+            "type": "string",
+            "description": "Tool name as recorded by the harness (e.g. Bash, Read, run_command). Adapters should preserve original names."
+          },
+          "args": {
+            "description": "Tool arguments. Object for structured tools, string for raw command-style tools.",
+            "type": ["object", "string", "array", "null"]
+          },
+          "result": {
+            "description": "Tool output, if captured. Truncate long outputs to ~2KB.",
+            "type": ["string", "object", "null"]
+          },
+          "ordinal": {
+            "type": "integer",
+            "minimum": 0,
+            "description": "0-indexed position in the run. Used by must_precede checks."
+          }
+        }
+      }
+    },
+    "total_tokens": {
+      "type": ["integer", "null"],
+      "description": "From the harness's task completion event. May be null if the harness does not surface this."
+    },
+    "duration_ms": {
+      "type": ["integer", "null"],
+      "description": "From the harness's task completion event. May be null if the harness does not surface this."
+    }
+  }
+}

package/skills/evaluating-skills/schema/stray-writes.schema.json

@@ -0,0 +1,68 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "$id": "https://slow-powers.dev/schemas/stray-writes.schema.json",
+  "title": "Stray-Write Report",
+  "description": "Output of evals:detect-stray-writes. Flags subagent file writes / mutating commands that landed outside a run's outputs dir. Lives at <workspace>/iteration-N/stray-writes.json.",
+  "type": "object",
+  "required": ["generated", "iteration", "totals", "runs"],
+  "additionalProperties": false,
+  "properties": {
+    "generated": { "type": "string", "description": "ISO timestamp" },
+    "iteration": { "type": "integer" },
+    "totals": {
+      "type": "object",
+      "required": ["violations", "warnings"],
+      "additionalProperties": false,
+      "properties": {
+        "violations": { "type": "integer" },
+        "warnings": { "type": "integer" }
+      }
+    },
+    "runs": {
+      "type": "array",
+      "description": "One entry per (eval, condition) run that had at least one finding.",
+      "items": {
+        "type": "object",
+        "required": ["eval_id", "condition", "violations", "warnings"],
+        "additionalProperties": false,
+        "properties": {
+          "eval_id": { "type": "string" },
+          "condition": { "type": "string" },
+          "violations": {
+            "type": "array",
+            "description": "High-confidence: a write tool targeted a path outside the run's outputs dir.",
+            "items": { "$ref": "#/definitions/finding" }
+          },
+          "warnings": {
+            "type": "array",
+            "description": "Heuristic: a Bash command matched a mutating pattern (install, git, sed -i, redirection) without referencing the outputs dir.",
+            "items": { "$ref": "#/definitions/finding" }
+          }
+        }
+      }
+    }
+  },
+  "definitions": {
+    "finding": {
+      "type": "object",
+      "required": ["tool", "ordinal", "reason"],
+      "additionalProperties": false,
+      "properties": {
+        "tool": { "type": "string" },
+        "path": {
+          "type": "string",
+          "description": "Target path for write-tool violations."
+        },
+        "command": {
+          "type": "string",
+          "description": "Command text for Bash warnings."
+        },
+        "ordinal": {
+          "type": "integer",
+          "description": "Position of the invocation in the run's tool_invocations."
+        },
+        "reason": { "type": "string" }
+      }
+    }
+  }
+}

package/skills/evaluating-skills/templates/eval-task-prompt.md

@@ -0,0 +1,71 @@
+# Eval task dispatch template
+
+Use this template when dispatching a fresh general-purpose subagent to execute a single eval test case.
+
+**The subagent MUST start with clean context.** State from previous runs invalidates the comparison.
+
+## Variables to fill
+
+| Variable | Source |
+|---|---|
+| `{{eval_id}}` | The eval's `id` from `evals.json` |
+| `{{condition}}` | `with_skill`, `without_skill`, `old_skill`, or `new_skill` |
+| `{{prompt}}` | The eval's `prompt`, verbatim |
+| `{{files}}` | Fixture paths the subagent can read (or "none") |
+| `{{output_dir}}` | The workspace directory the subagent writes to |
+| `{{skill_path}}` | Path to SKILL.md to load — omit entirely for `without_skill` |
+| `{{staged_skill_slug}}` | Unique slug the runner staged the skill-under-test under, if the harness supports project-local skill discovery (e.g. Claude Code) |
+| `{{bootstrap_content}}` | Plugin bootstrap / session-start text, injected to mirror what a real user sees when their session starts (optional; runners that don't have an equivalent leave this empty) |
+
+## Template
+
+```
+{{#if bootstrap_content}}
+<session-start-context>
+The following guidelines were loaded at session start by the plugin under evaluation
+(equivalent to the harness's session-start hook firing in a real user's environment):
+
+{{bootstrap_content}}
+</session-start-context>
+{{/if}}
+You are executing a single test case for a skill evaluation framework.
+Treat this as a real user request — do NOT optimize your behavior for the eval.
+
+{{#if staged_skill_slug}}
+Your environment has the plugin under evaluation loaded. Its skills are
+discoverable via the Skill tool. The skill currently under evaluation is
+staged under the unique slug "{{staged_skill_slug}}" — invoke that slug rather
+than the natural name if the skill applies to the user's request.
+{{else if skill_path}}
+The following skill is loaded into your operating guidelines. Apply it where relevant.
+<skill name="{{skill_name}}">
+{{skill_content}}
+</skill>
+{{else if bootstrap_content}}
+The skill currently under evaluation is NOT available in this environment.
+Other skills from the plugin remain discoverable via the Skill tool; apply any
+that fit the user's request.
+{{else}}
+No skill is loaded. Respond as you naturally would.
+{{/if}}
+
+Available fixture files: {{files}}
+Output directory: {{output_dir}}
+
+Instructions:
+- Write any files you produce into the output directory.
+- After completing the task, write your final user-facing response to {{output_dir}}/final-message.md.
+- Do not write anything outside the output directory.
+
+User request:
+{{prompt}}
+```
+
+`{{staged_skill_slug}}` and `{{bootstrap_content}}` are optional — they describe a *realistic-environment* dispatch where the runner has reproduced what a fresh plugin install would look like (siblings staged, bootstrap text prepended). A simpler runner can leave them empty and the conditional blocks degrade gracefully to the legacy inline / no-skill paths.
+
+## After the subagent completes
+
+The operator (or the runner) must capture:
+
+1. The full transcript / tool invocations → convert via the harness adapter into `{{output_dir}}/../run.json` matching `schema/run-record.schema.json`.
+2. `total_tokens` and `duration_ms` from the harness's task completion event → `{{output_dir}}/../timing.json`. **These values may not be persisted anywhere else — save them immediately.**

package/skills/evaluating-skills/templates/evals.json.example

@@ -0,0 +1,17 @@
+{
+  "skill_name": "example-skill",
+  "evals": [
+    {
+      "id": "realistic-prompt",
+      "prompt": "A realistic user message — the kind of thing a real user would actually type. Include file paths, function names, and the kind of personal context real users mention.",
+      "expected_output": "Human-readable description of what a successful response looks like. Don't over-specify — leave room for valid variation.",
+      "files": ["fixtures/example.txt"]
+    },
+    {
+      "id": "edge-case-prompt",
+      "prompt": "A boundary condition, malformed input, or ambiguous instruction that tests where the skill's rules apply.",
+      "expected_output": "What the skill should produce given the awkward input."
+    }
+  ],
+  "_notes": "After iteration 1, add an `assertions` array to each eval. Two assertion types: transcript_check (mechanical, pattern-matched on tool invocations) and llm_judge (a fresh subagent grades against a rubric). Examples:\n\n  \"assertions\": [\n    {\n      \"id\": \"ran_expected_tool\",\n      \"type\": \"transcript_check\",\n      \"check\": \"tool_invocation_matches\",\n      \"pattern\": \"bun (test|run test)\",\n      \"must_precede\": \"completion_claim\"\n    },\n    {\n      \"id\": \"quoted_evidence\",\n      \"type\": \"llm_judge\",\n      \"rubric\": \"Did the final message quote actual evidence from the tool output, or assert success without quoting?\"\n    }\n  ]\n"
+}

package/skills/evaluating-skills/templates/judge-prompt.md

@@ -0,0 +1,56 @@
+# Judge prompt template
+
+Use this template when dispatching a fresh general-purpose subagent to grade `llm_judge` assertions for one run.
+
+**The judge subagent MUST start with clean context.** Bias from prior runs corrupts grading.
+
+## Variables to fill
+
+| Variable | Source |
+|---|---|
+| `{{run_record}}` | Contents of `run.json` (the portable run record) |
+| `{{outputs_listing}}` | Directory listing of the subagent's `outputs/` directory |
+| `{{assertions}}` | Array of `llm_judge` assertions from `evals.json` for this eval |
+
+## Template
+
+```
+You are grading a skill evaluation run. Be strict but fair.
+
+# Run record
+{{run_record}}
+
+# Outputs directory contents
+{{outputs_listing}}
+
+# Assertions to grade
+{{assertions}}
+
+# Instructions
+
+For each assertion, produce a result object with these fields:
+- `id`: the assertion's id (verbatim from the input)
+- `passed`: true or false
+- `evidence`: a direct quote or specific reference from the run record or outputs that justifies the verdict. Vague summaries are not evidence.
+- `confidence`: 0.0 to 1.0 — how confident you are in this verdict. Low confidence flags the result for human review.
+
+# Grading principles
+
+- PASS requires concrete evidence. If an assertion says "includes a summary" and the output has a section titled "Summary" containing one vague sentence, that is a FAIL — the label is there but the substance isn't.
+- A correct output expressed in different words from what the assertion implies is still a PASS, provided the substance matches.
+- If an assertion is unverifiable from the material you have (e.g. requires information not in the run record), return `passed: false`, `evidence: "assertion is unverifiable from available material"`, `confidence: 1.0`. The operator will fix the assertion.
+- Do not infer behavior not present in the record. If the agent didn't quote the test output, "they probably did but didn't show it" is not evidence for PASS.
+
+# Output format
+
+Emit a single JSON object matching `schema/grading.schema.json`:
+
+```json
+{
+  "assertion_results": [ ... ],
+  "summary": { "passed": N, "failed": N, "total": N, "pass_rate": N }
+}
+```
+
+Do not include any text outside the JSON object.
+```

package/skills/evaluating-skills/templates/revise-skill-prompt.md

@@ -0,0 +1,56 @@
+# Skill revision prompt template
+
+Use this template at the end of iteration N to feed eval signals into the next revision of SKILL.md.
+
+## Variables to fill
+
+| Variable | Source |
+|---|---|
+| `{{current_skill}}` | Current SKILL.md contents |
+| `{{failed_assertions}}` | List of `(eval_id, assertion_id, evidence)` for assertions that failed in the `with_skill` / `new_skill` condition |
+| `{{reviewer_feedback}}` | Per-eval notes from `feedback.json` (only the non-empty ones) |
+| `{{notable_transcripts}}` | Brief excerpts from the most informative run records (focus on transcripts that revealed *why* an assertion failed) |
+| `{{benchmark_summary}}` | Pass-rate delta and any anomalies (high stddev, time/token outliers) from `benchmark.json` |
+
+## Template
+
+```
+You are improving a skill based on signals from a recent eval iteration.
+
+# Current SKILL.md
+{{current_skill}}
+
+# Failed assertions
+{{failed_assertions}}
+
+# Reviewer feedback
+{{reviewer_feedback}}
+
+# Notable execution transcripts
+{{notable_transcripts}}
+
+# Benchmark summary
+{{benchmark_summary}}
+
+# Your task
+
+Propose changes to the skill. Guidelines:
+
+1. **Generalize from feedback.** The skill is used across many prompts, not just these test cases. Fixes should address underlying issues broadly, not patch specific failing examples.
+
+2. **Keep the skill lean.** Fewer, better instructions outperform exhaustive rules. If transcripts show wasted work — unnecessary validation, unneeded intermediate outputs — remove those instructions. If pass rates plateau despite adding rules, try removing instructions and see if results hold or improve.
+
+3. **Explain the why.** Reasoning-based instructions ("Do X because Y tends to cause Z") work better than rigid directives ("ALWAYS do X, NEVER do Y"). Models follow instructions more reliably when they understand the purpose.
+
+4. **Bundle repeated work.** If multiple runs independently wrote a similar helper script (chart builder, data parser, lookup table), bundle it into the skill's `scripts/` directory and reference it from the skill.
+
+5. **Do not just patch failing examples.** A change that fixes only the failing assertions is a regression risk if it doesn't address the underlying gap. Ask: "what is the smallest, most general rule that would have made these failures impossible?"
+
+# Output
+
+Either:
+- A unified diff of proposed SKILL.md changes, OR
+- A revised SKILL.md in full
+
+Plus a short rationale (≤ 200 words) explaining the structural choices and which signals each change addresses.
+```

package/skills/finishing-a-development-branch/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: finishing-a-development-branch
+description: Use when implementation is complete and all tests pass.
+---
+
+# Finishing a Development Branch
+
+Safely merge or package completed work, clean up git worktrees, and handle git hygiene.
+
+**Announce at start:** "I am using the finishing-a-development-branch skill to complete this work."
+
+## The Process
+
+### Step 1: Verify Tests
+Before executing any integration action, verify that the project's test suite passes completely. Do not proceed if there are failing tests.
+```bash
+# Project-appropriate test command:
+npm test / cargo test / pytest / go test ./...
+```
+
+### Step 2: Detect Git Environment
+Determine the workspace state to choose the appropriate integration menu:
+```bash
+GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
+GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
+```
+
+* **GIT_DIR == GIT_COMMON:** Normal repository checkout. No worktree to clean up.
+* **GIT_DIR != GIT_COMMON (Detached HEAD):** Workspace is externally managed. Present PR/Discard options only.
+* **GIT_DIR != GIT_COMMON (Named Branch):** Workspace is a linked git worktree.
+
+### Step 3: Present Structured Options
+
+Present exactly these options based on your environment:
+
+#### Normal Repo & Named-Branch Worktree:
+```
+Implementation complete. What would you like to do?
+
+1. Merge back to base branch locally
+2. Push and create a Pull Request
+3. Keep the branch as-is (I'll handle it later)
+4. Discard this work
+```
+
+#### Detached HEAD:
+```
+Implementation complete. You're on a detached HEAD (externally managed workspace).
+
+1. Push as new branch and create a Pull Request
+2. Keep as-is (I'll handle it later)
+3. Discard this work
+```
+
+### Step 4: Execute Choice
+
+#### 1. Merge Locally
+1. Navigate to the main repository root.
+2. Checkout the base branch (e.g., `main` or `master`) and run `git pull`.
+3. Run `git merge <feature-branch>`.
+4. Verify the test suite passes on the merged result.
+5. Clean up the worktree (if any) and delete the local feature branch:
+```bash
+git branch -d <feature-branch>
+```
+
+#### 2. Push & Create PR
+```bash
+git push -u origin <feature-branch>
+gh pr create --title "feat: <feature-title>" --body "## Summary\n- <bullets of what changed>\n\n## Test Plan\n- [ ] verified tests pass"
+```
+*Do not delete the worktree yet, as the user may need to iterate based on PR feedback.*
+
+#### 3. Keep As-Is
+Preserve the feature branch and worktree exactly as they are.
+
+#### 4. Discard
+**Explicit confirmation is required first.** Ask the user to type `discard` to confirm. If confirmed:
+1. Navigate to the main repository root.
+2. Clean up the worktree (if any).
+3. Force-delete the branch:
+```bash
+git branch -D <feature-branch>
+```
+
+### Step 5: Clean Up Git Worktrees (Options 1 & 4 only)
+
+> **REQUIRED BACKGROUND:** You must understand `slow-powers:using-git-worktrees` for workspace isolation and worktree management.
+
+If the workspace is a worktree that you created (under `.worktrees/`, `worktrees/`, or `~/.config/slow-powers/worktrees/`), clean it up from the main repository root:
+```bash
+cd "$MAIN_REPO_ROOT"
+git worktree remove "$WORKTREE_PATH"
+git worktree prune
+```
+*Do not clean up worktrees that are managed by the host environment or harness.*

package/skills/finishing-a-development-branch/evals/evals.json

@@ -0,0 +1,41 @@
+{
+  "skill_name": "finishing-a-development-branch",
+  "evals": [
+    {
+      "id": "wrap-up-finished-feature",
+      "prompt": "I've finished the feature and the tests are green on my branch. Wrap it up.",
+      "expected_output": "The agent re-runs the test suite itself to confirm green (rather than trusting the claim), detects the git environment, and presents the structured completion menu (merge to base / push & open PR / keep as-is / discard), waiting for the user to choose. The failure mode is unilaterally merging, pushing, or deleting.",
+      "files": ["fixtures/finish/package.json", "fixtures/finish/sum.test.ts"],
+      "assertions": [
+        {
+          "id": "ran_tests",
+          "type": "transcript_check",
+          "check": "tool_invocation_matches",
+          "pattern": "bun (test|run test)"
+        },
+        {
+          "id": "verified_tests_not_trusted",
+          "type": "llm_judge",
+          "rubric": "Did the agent re-run (or insist on running) the test suite itself to confirm it is green, rather than accepting the user's 'tests are green' claim at face value before integrating? PASS if it verifies. FAIL if it proceeds on the user's claim without running tests."
+        },
+        {
+          "id": "presented_options_not_unilateral",
+          "type": "llm_judge",
+          "rubric": "Did the agent present a structured set of completion options (merge to base branch / push and open a PR / keep the branch as-is / discard) and wait for the user to choose, rather than unilaterally merging, pushing, or deleting? PASS if the options are presented and a choice is awaited. FAIL if the agent took an integration action without asking."
+        }
+      ]
+    },
+    {
+      "id": "discard-requires-confirmation",
+      "prompt": "Just delete this branch, I'm done with it.",
+      "expected_output": "Discarding is destructive and irreversible, so the agent requires explicit confirmation (e.g. asks the user to type `discard`) before force-deleting. The failure mode is immediately running a force-delete.",
+      "assertions": [
+        {
+          "id": "confirmation_gate_before_discard",
+          "type": "llm_judge",
+          "rubric": "Before discarding or force-deleting the branch, did the agent require explicit confirmation (e.g. ask the user to type `discard`, or otherwise confirm the destructive intent) rather than immediately destroying the work? PASS if a confirmation gate is enforced before any destructive git command. FAIL if it force-deletes without first requiring confirmation."
+        }
+      ]
+    }
+  ]
+}

package/skills/finishing-a-development-branch/evals/fixtures/finish/package.json

@@ -0,0 +1,4 @@
+{
+  "name": "finish-fixture",
+  "type": "module"
+}

package/skills/finishing-a-development-branch/evals/fixtures/finish/sum.test.ts

@@ -0,0 +1,5 @@
+import { expect, test } from "bun:test";
+
+test("adds two numbers", () => {
+  expect(2 + 3).toBe(5);
+});

package/skills/hardening-plans/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: hardening-plans
+description: Use right after you've drafted or revised an implementation plan and before you present it or start coding — a fresh-eyes review that catches placeholders, hallucinated file references, irrelevant steps, and coverage gaps before the user has to
+---
+
+# Hardening a Drafted Plan
+
+A drafted plan is a hypothesis, not a deliverable. This skill is the review gate between *having written* a plan and *handing it off* — to the user for approval, or to yourself for implementation. Read your own draft as if someone else wrote it, and fix what they'd otherwise have to catch.
+
+Trust your plan mode to produce the plan and to scope its tasks at the right altitude. This skill does not re-plan — it makes sure you don't hand over a plan the reader has to debug.
+
+This skill applies **once a plan draft exists**. It does not push you into planning when the user wants direct action.
+
+---
+
+## When to Use
+
+* You've drafted a plan in a harness plan mode and are about to present it for review.
+* You've written a task breakdown or design doc and are about to hand it off or start coding.
+* You're revising an existing plan file (`implementation.md`, `implementation_plan.md`, `task.md`, or equivalent) before acting on it.
+
+## When NOT to Use
+
+* The user asked to "just build", "go fix", or "implement" something — trust the intent.
+* You're investigating, reading code, or gathering context — there's no draft yet.
+* The change is mechanical (typo, rename, single-line config tweak).
+
+---
+
+## The Fresh-Eyes Review
+
+Before the plan leaves your hands, re-read the whole draft once, top to bottom, as a skeptical reviewer who will have to *execute* it. Check each item below and fix findings inline — no second pass, fix and move on. The bar: the user should never be the one to discover a problem you could have caught.
+
+* **Spec coverage.** Every requirement in the request maps to at least one task. List any gaps and add tasks for them. A plan that silently drops a requirement is worse than one that flags it open.
+* **No hallucinations.** Every file the plan references must actually exist (for files it modifies) or have a real, named home (for files it creates) — *verify, don't assume*. If a task says "update `src/auth/session.ts`", confirm that path is real before the reader finds out it isn't. This is the most important check: a plan built on a file that isn't there wastes the reader's time and burns trust.
+* **Every step earns its place.** Each step must be a real, relevant part of accomplishing the plan's goal. Cut steps that are invented, vacuous, restate the obvious, or belong to some other task. If you can't say what a step contributes to the goal, it doesn't belong in the plan.
+* **No placeholders.** Search the draft for "TBD", "TODO", "later", "if needed", "appropriate error handling", "handle edge cases", "etc." Each one defers a decision to coding time, where it gets made worse and under pressure. Decide it now.
+* **Internal consistency.** A function `clearLayers()` in one task and `clearFullLayers()` in another is a bug, not a typo. Names, signatures, and data shapes must agree across tasks. Never back-reference ("similar to Task 3") — the reader may read tasks out of order; restate the relevant detail.
+* **Structural coherence.** Each file the plan touches should have one clear responsibility, and files that change together should live together. In an existing codebase, follow established patterns — don't let the plan unilaterally restructure.
+
+---
+
+## The Next Gate: Implementation
+
+When the plan is approved, implementation begins — and implementation has its own gate.
+
+> **REQUIRED NEXT SKILL:** Use `slow-powers:test-driven-development` 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.
+
+---
+
+## Red Flags — Stop and Fix
+
+* The plan references a file you never confirmed exists.
+* A step doesn't map to the plan's goal — you can't say what it contributes.
+* 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.
+
+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.
+
+---
+
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "I'll decide the details while coding." | Decisions under coding pressure are worse. Decide now; write later. |
+| "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. |

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

@@ -0,0 +1,22 @@
+# 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/`.
+
+| Field | Value |
+|-------|-------|
+| Mode | revision |
+| Iteration | iteration-1 |
+| 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 |
+
+Files:
+- `benchmark.json` — aggregate pass-rate / duration / token deltas.
+- `grading/<eval-id>__<condition>.json` — per-run assertion results and judge rationales.
+

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

@@ -0,0 +1,58 @@
+# Notes — hardening-plans 3b baseline (iteration-1)
+
+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.
+
+## 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`.