@slowdini/slow-powers-opencode 0.1.5 → 0.3.0

package/README.md

@@ -12,17 +12,27 @@ and clarifying skill content.
 
 ## Quickstart
 
-Give your agent superpowers with slow-powers: [Claude Code](#claude-code) · [Codex CLI](#codex-cli) · [OpenCode](#opencode). Support varies per harness — see the [feature support](#feature-support) table.
+Give your agent superpowers with slow-powers: [Claude Code](#claude-code) · [Codex CLI](#codex-cli) · [OpenCode](#opencode). Support varies per harness — see the [feature support](#feature-support) tables.
 
 ## Feature support
 
-| Harness         | Status   | Notes                                                          |
-|-----------------|----------|----------------------------------------------------------------|
-| Claude Code     | Full     | Reference implementation                                       |
-| Codex CLI       | Partial  | Plugin manifest + shared hooks; no eval transcript adapter     |
-| OpenCode        | Partial  | JS plugin with bootstrap injection; no eval transcript adapter |
+Parity is tracked on two independent surfaces. **Plugin distribution** is how Slow-powers reaches a user's session — manifests, bootstrap injection, skill discovery, hooks:
 
-Contributors closing parity gaps should follow [`harness-parity-check.md`](./harness-parity-check.md): it audits which Slow-powers features are wired up for a given harness and preps an agent to close one gap.
+| Harness         | Status   | Notes                                                                             |
+|-----------------|----------|-----------------------------------------------------------------------------------|
+| Claude Code     | Full     | Reference implementation                                                          |
+| Codex CLI       | Full     | Plugin manifest + shared `hooks/hooks.json`; the plan hand-off hook is Claude-native (N/A here, see #141) |
+| OpenCode        | Full     | JS plugin (npm package) injects bootstrap and registers skills via the native plugin API |
+
+The **skill-eval runner** (developer tooling under `skills/evaluating-skills/`, slated to move into its own project) is tracked separately:
+
+| Harness         | Status   | Notes                                                                             |
+|-----------------|----------|-----------------------------------------------------------------------------------|
+| Claude Code     | Full     | Reference implementation: transcript adapter, auto-record, `--guard`, `--plan-mode` |
+| Codex CLI       | Manual   | No transcript adapter — hand-authored run records; `llm_judge` assertions carry the measurement |
+| OpenCode        | Manual   | No transcript adapter — hand-authored run records; `llm_judge` assertions carry the measurement |
+
+Contributors closing parity gaps should follow [`harness-parity-check.md`](./harness-parity-check.md) for distribution gaps, or [`skills/evaluating-skills/harness-parity.md`](./skills/evaluating-skills/harness-parity.md) for eval-runner gaps: each audits which features are wired up for a given harness and preps an agent to close one gap.
 
 ## How it works
 
@@ -94,20 +104,29 @@ Slow-powers provides a set of highly focused, execution-level skills that ensure
 1. **`working-in-isolation`** — Establishes an isolated workspace so new work doesn't collide with existing or in-progress work, keeping protected branches like `main` clean.
 2. **`test-driven-development`** — Enforces a strict RED-GREEN-REFACTOR cycle, ensuring all production code is backed by failing test verification first.
 3. **`systematic-debugging`** — Guides the agent to locate the root cause of failures via scientific hypothesis testing, avoiding "guess-and-check" thrashing.
-4. **`verification-before-completion`** — Requires running actual test/build commands and presenting concrete evidence before making any success claims.
-5. **`finishing-a-development-branch`** — Manages local branch hygiene, runs final test verifications, and cleans up git worktrees.
-6. **`writing-skills`** — Handles future custom skill authoring and updates.
+4. **`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 before work is handed back.
+5. **`writing-skills`** — Handles future custom skill authoring and updates.
 
 ## What's inside
 
-**Testing & Verification** — `test-driven-development`, `verification-before-completion`
+**Testing & Verification** — `test-driven-development`, `verifying-development-work`
 
 **Debugging** — `systematic-debugging`
 
-**Workspace & Git Hygiene** — `working-in-isolation`, `finishing-a-development-branch`
+**Workspace & Git Hygiene** — `working-in-isolation`
 
 **Meta & Extension** — `writing-skills`
 
+## Intended Workflows
+
+The skills declare lightweight prerequisite / next-step gates so the agent knows the intended 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. An agent may invoke `test-driven-development`, `verifying-development-work`, or any other skill at any point.
+
+**Plan mode:** plan mode → `hardening-plans` → `working-in-isolation` → `test-driven-development` → `verifying-development-work`
+
+**Debugging:** (`working-in-isolation`) → `systematic-debugging` → `verifying-development-work`
+
+`hardening-plans` points to `test-driven-development` as its next step, and `test-driven-development` requires `working-in-isolation` first — so isolation is reached as TDD's prerequisite, producing the plan-mode order above.
+
 ## Philosophy
 
 - Test-Driven Development — write tests first, always
@@ -127,7 +146,7 @@ Flat layout — skills and assets live at root, harness-specific integration liv
 - `opencode/` — OpenCode plugin
 - `.claude-plugin/marketplace.json` — Claude Code marketplace registry
 - `package.json` — OpenCode plugin manifest + dev tooling
-- `harness-parity-check.md` — Instructions for an agent in any harness to audit feature gaps and prep to close one
+- `harness-parity-check.md` — Instructions for an agent in any harness to audit plugin-distribution gaps and prep to close one (the eval runner's counterpart lives at `skills/evaluating-skills/harness-parity.md`)
 
 ## Releasing
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@slowdini/slow-powers-opencode",
-  "version": "0.1.5",
+  "version": "0.3.0",
   "description": "Slow-powers — structured development workflows for coding agents (TDD, debugging, verification, git hygiene)",
   "type": "module",
   "main": "./opencode/plugins/slow-powers.js",
@@ -39,9 +39,13 @@
     "evals": "bun run skills/evaluating-skills/runner/run.ts --skill-dir ./skills --bootstrap ./bootstrap.md",
     "evals:snapshot": "bun run skills/evaluating-skills/runner/run.ts snapshot --skill-dir ./skills",
     "evals:validate": "bun run skills/evaluating-skills/runner/validate-all.ts --skill-dir ./skills",
+    "evals:ingest": "bun run skills/evaluating-skills/runner/run.ts ingest --skill-dir ./skills",
+    "evals:finalize": "bun run skills/evaluating-skills/runner/run.ts finalize --skill-dir ./skills",
+    "evals:record-runs": "bun run skills/evaluating-skills/runner/record-runs.ts --skill-dir ./skills",
     "evals:fill-transcripts": "bun run skills/evaluating-skills/runner/fill-transcripts.ts --skill-dir ./skills",
     "evals:detect-stray-writes": "bun run skills/evaluating-skills/runner/detect-stray-writes.ts --skill-dir ./skills",
     "evals:teardown-guard": "bun run skills/evaluating-skills/runner/run.ts teardown-guard --skill-dir ./skills",
+    "evals:teardown": "bun run skills/evaluating-skills/runner/run.ts teardown --skill-dir ./skills",
     "evals:grade": "bun run skills/evaluating-skills/runner/grade.ts --skill-dir ./skills",
     "evals:aggregate": "bun run skills/evaluating-skills/runner/aggregate.ts --skill-dir ./skills",
     "evals:promote-baseline": "bun run skills/evaluating-skills/runner/promote-baseline.ts --skill-dir ./skills",

package/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 (verification-before-completion — 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 (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.",
       "files": ["fixtures/audits-completed-session/session-summary.md"],
       "assertions": [
         {
@@ -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 verification-before-completion (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 — 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.",
       "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 verification-before-completion (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 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."
         },
         {
           "id": "no_remediation_language",

package/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 `verification-before-completion`.
+  `test-driven-development`, `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.

package/skills/evaluating-skills/SKILL.md

@@ -21,14 +21,16 @@ Compares `with_skill/` vs `without_skill/`. Use when validating a brand-new skil
 
 ### Mode B — Revision comparison
 
-Compares `old_skill/` vs `new_skill/`. **This is the common case.** Use when testing a language change to an existing skill — snapshot the current SKILL.md before editing, make changes, run both variants against the same prompts.
+Compares `old_skill/` vs `new_skill/`. **This is the common case.** Use when testing a language change to an existing skill — snapshot the old SKILL.md as a baseline, then run both variants against the same prompts.
 
-Mode B workflow:
-1. Snapshot current SKILL.md (label the snapshot with a date or short tag)
-2. Edit the skill
+Mode B workflow (edit-first — the usual order):
+1. Edit the skill (the new version is now in the working tree)
+2. Snapshot the old version straight from git: `snapshot --label <tag> --ref HEAD` (any commit/tag/branch works; `--ref` reads git without touching the working tree)
 3. Run the eval with `--mode revision --baseline <snapshot-label>`
 4. Grade and aggregate; review the delta
 
+If you snapshot *before* editing, omit `--ref` in step 2 (it reads the working tree) and do it ahead of step 1.
+
 A negative or zero delta is a signal to revert the change — the new language did not improve behavior.
 
 ## Running an eval on a skill
@@ -51,7 +53,7 @@ Each iteration lands under `<workspace-dir>/<skill>/iteration-N/` with the same
 
 #### What gets staged
 
-The runner stages every skill it finds under `--skill-dir`. The skill-under-test goes under a unique slug for the `__skill_invoked` meta-check; sibling skills stage under their natural names so cross-references resolve. **If your `--skill-dir` contains only your one skill, the eval runs in isolation** — references like "REQUIRED SUB-SKILL: `slow-powers:test-driven-development`" won't resolve, and your assertions must not depend on a sibling skill firing. To include other skills as siblings, copy or symlink them into `--skill-dir` before running.
+The runner stages every skill it finds under `--skill-dir`. The skill-under-test goes under a unique slug for the `__skill_invoked` meta-check — with its sibling asset files (any non-`SKILL.md`, non-`evals/` content) copied alongside, so a multi-file skill whose `SKILL.md` links a companion doc (e.g. `[code-review.md](code-review.md)`) still resolves once staged; sibling skills stage under their natural names so cross-references resolve. **If your `--skill-dir` contains only your one skill, the eval runs in isolation** — references like "REQUIRED SUB-SKILL: `slow-powers:test-driven-development`" won't resolve, and your assertions must not depend on a sibling skill firing. To include other skills as siblings, copy or symlink them into `--skill-dir` before running.
 
 #### Bootstrap content
 
@@ -66,7 +68,7 @@ A test case has three parts:
 - **files** (optional): fixture files the prompt references
 - **skill_should_trigger** (optional, default `true`): set `false` for a *negative* eval where correct behavior is the skill **not** firing (e.g. an over-trigger guard — a feature request that shouldn't launch a debugging investigation). Negative evals are excluded from the skill-invocation rate and its validity warning, so a correct non-invocation isn't mistaken for the skill failing to fire.
 
-Stored in `<skill>/evals/evals.json`. See `templates/evals.json.example` and `examples/verification-before-completion-evals.json`.
+Stored in `<skill>/evals/evals.json`. See `templates/evals.json.example` and `examples/verifying-development-work-evals.json`.
 
 Tips for writing good prompts:
 
@@ -82,7 +84,7 @@ Tips for writing good prompts:
 
 What "stresses the skill" depends on what kind of skill it is. The four types from `slow-powers:writing-skills` each need a different style of prompt:
 
-- **Discipline-enforcing skills** (TDD, verification-before-completion). Test with pressure — academic prompts ("explain how TDD works") will pass without measuring anything useful. Combine multiple pressures (time + sunk cost + authority + exhaustion) and force a choice. See `pressure-scenarios.md` for the taxonomy. The wild failure for these skills is almost always *mid-session* — the agent is already committed to a skill-free approach when the trigger arrives — so a cold prompt under-measures them; pair each cold case with a **seeded** one (see *Seeding conversation context* below). Success = the rule holds under maximum pressure.
+- **Discipline-enforcing skills** (TDD, verifying-development-work). Test with pressure — academic prompts ("explain how TDD works") will pass without measuring anything useful. Combine multiple pressures (time + sunk cost + authority + exhaustion) and force a choice. See `pressure-scenarios.md` for the taxonomy. The wild failure for these skills is almost always *mid-session* — the agent is already committed to a skill-free approach when the trigger arrives — so a cold prompt under-measures them; pair each cold case with a **seeded** one (see *Seeding conversation context* below). Success = the rule holds under maximum pressure.
 - **Technique skills** (condition-based-waiting, root-cause-tracing). Test application: hand the agent a new scenario where the technique applies and check it gets used correctly. Include at least one edge-case variation. Success = the technique transfers to a situation the skill didn't explicitly describe.
 - **Pattern skills** (flatten-with-flags, information-hiding). Test recognition: include prompts where the pattern applies and prompts where it doesn't. Success = the agent applies the pattern when warranted and refrains when it isn't.
 - **Reference skills** (API docs, syntax guides). Test retrieval: ask questions whose answers are in the reference, including a few that hit gaps you suspect. Success = the agent finds the right section and uses it correctly.
@@ -135,7 +137,7 @@ Do not dispatch until the user confirms *this summary*. An earlier "run the eval
 A subagent under test runs the real skill, and some skills write to disk — the skill that triggered this gate, `working-in-isolation`, creates git worktrees in whatever repo it's pointed at. Without active enforcement those writes land in your working directory.
 
 - **Guard available (Claude Code):** arming `--guard` is the default. If you are about to run without it, STOP. Proceed unguarded **only** when the user actively opts out — and warn them that stray writes will then only be **detected after the fact** by `detect-stray-writes`, never blocked or reverted, so anything a subagent writes outside its `outputs/` dir (worktrees, installed packages, edited repo files) persists and is theirs to clean up.
-- **Guard unavailable (other harnesses):** there is no active write enforcement. Tell the user plainly: stray writes are detected and reported by `detect-stray-writes` but **not auto-cleaned** — they must review the report and remove anything that escaped. Harness-level write enforcement is tracked as a parity goal in `harness-parity-check.md`.
+- **Guard unavailable (other harnesses):** there is no active write enforcement. Tell the user plainly: stray writes are detected and reported by `detect-stray-writes` but **not auto-cleaned** — they must review the report and remove anything that escaped. Harness-level write enforcement is tracked as a parity goal in `harness-parity.md`.
 
 ## Red Flags — STOP before dispatching
 
@@ -157,13 +159,13 @@ For each test case, dispatch fresh general-purpose subagents — one per conditi
 
 Subagents MUST start with clean context. State leaking from previous runs invalidates the comparison.
 
-When a subagent completes, capture:
+Each run needs a portable **run record** (`run.json`, matching `schema/run-record.schema.json`) and a timing record (`timing.json`) holding:
 
-- `total_tokens` and `duration_ms` from the harness's task completion event — **these may not be persisted anywhere else; save them immediately**
+- `total_tokens` and `duration_ms`
 - The final user-facing message
 - The tool invocations (best effort — see "Transcript access" below)
 
-Convert these into a portable **run record** (`run.json`) using `schema/run-record.schema.json`. Each harness has its own adapter — Claude Code's lives at `runner/adapters/`; other harnesses write their own or fill the record manually.
+On a harness with persisted transcripts (Claude Code), `record-runs` assembles both records from disk after the dispatches — nothing is captured by hand. On a transcript-less harness, capture them manually when each subagent completes: tokens/duration come from the harness's task completion event (**these may not be persisted anywhere else; save them immediately**), and the record is written via that harness's adapter or by hand.
 
 ### Driving the eval loop
 
@@ -171,12 +173,10 @@ The agent itself drives the entire loop from inside a normal agent session:
 
 1. The agent invokes the runner via Bash to build the workspace (same command as above).
 2. The agent reads the generated `dispatch.json` (machine-readable sibling of the manifest). Each task object points at a `dispatch_prompt_path` (a file holding the full prompt), an `agent_description` to pass through as the dispatch description, and exact `run_record_path` and `timing_path` to write to. The prompt lives in a file rather than inline in `dispatch.json` so the agent never has to reproduce kilobytes of prompt text per dispatch. The `agent_description` is namespaced with the iteration and a per-run nonce (`<eval_id>:<condition>:i<N>-<nonce>`) so transcripts from different iterations sharing one session's subagents dir can't collide — **pass it verbatim; do not reconstruct it from the eval id and condition.**
-3. For each task, the agent dispatches a fresh subagent using its host's primitive, instructing it to read the file at `dispatch_prompt_path` and follow it exactly, and passing `agent_description` verbatim as the dispatch `description`. Passing the description through unchanged is what lets the transcript adapter correlate transcripts to runs in step 5.
-4. When the subagent returns, the agent writes the portable run record to `run_record_path` (with `tool_invocations: []`) and the timing record to `timing_path`.
-5. (Claude Code) The agent runs `bun run evals:fill-transcripts` to populate `tool_invocations` from persisted subagent transcripts. Other harnesses skip this step; `transcript_check` assertions grade as unverifiable.
-6. (Optional, where transcripts were filled) The agent runs `bun run evals:detect-stray-writes --skill <name> --iteration <N>` to flag any subagent writes or installs that landed outside the run's `outputs/` dir. See *Sandboxing eval subagents* below.
-7. The agent runs the grader (Bash) and then dispatches judge subagents for any `llm_judge` assertions — same pattern: read a tasks file, dispatch, write results back to a path.
-8. The agent runs the aggregator.
+3. For each task, the agent dispatches a fresh subagent using its host's primitive, instructing it to read the file at `dispatch_prompt_path` and follow it exactly, and passing `agent_description` verbatim as the dispatch `description`. Passing the description through unchanged is what lets the transcript adapter correlate transcripts to runs in step 4.
+4. (Claude Code) After all dispatches return, the agent runs `bun run evals:ingest` once — a fixed-order chain of record-runs (assembles every task's `run.json` from `dispatch.json` + the subagent's own `outputs/final-message.md` + the persisted transcript, and backfills `timing.json` with transcript-derived tokens/duration, `"source": "transcript"`; never clobbers a record that already exists), fill-transcripts, detect-stray-writes (see *Sandboxing eval subagents* below), and the grader. It stops where only the agent can act: dispatching a judge subagent for each `llm_judge` assertion — same pattern as step 3: read a tasks file, dispatch, write results back to a path.
+5. (Claude Code) After the judges return, the agent runs `bun run evals:finalize` — grade `--finalize` then the aggregator — and reads the benchmark.
+6. (Other harnesses) The portable path is the same loop run by hand: when each subagent returns, the agent writes the run record to `run_record_path` and the timing record to `timing_path` itself (without a transcript adapter, `tool_invocations` stays `[]` and `transcript_check` assertions grade as unverifiable), then runs the grader, dispatches judges, finalizes, and aggregates as individual commands.
 
 Agent-driven mode is the common case because the framework is most useful from inside the harness where the skill is being iterated. Use it when you want a single in-session "run the eval and report the delta" flow.
 
@@ -195,7 +195,9 @@ Design your assertions accordingly. For maximally portable evals, lean on `llm_j
 The dispatch prompt tells each subagent to write only inside its `outputs/` dir, but nothing in the portable contract *enforces* that — a misbehaving subagent can edit the real repo or run `npm install` against the repo root, silently corrupting the very runner it's being measured by. Two layers guard against this:
 
 - **Detection (all harnesses).** After `fill-transcripts` populates `tool_invocations`, run `bun run evals:detect-stray-writes --skill <name> --iteration <N>`. It reads each task's `outputs_dir` from `dispatch.json` and scans the invocations for **violations** (`Write`/`Edit`/`MultiEdit`/`NotebookEdit` whose path resolves outside the run's `outputs/`) and **warnings** (Bash commands matching install/`git`/`sed -i`/redirection patterns that don't reference `outputs/`). Findings land in `stray-writes.json`; the aggregator turns each run with violations into a `validity_warnings` entry, so a tainted data point is flagged the same way a missed skill invocation is. This is portable because it works off the same transcripts the adapters already parse — but it only *reports*, after the fact; it never reverts what a subagent wrote.
-- **Hard guard (Claude Code, default posture).** `--guard` stages a `PreToolUse` hook that actively *blocks* out-of-bounds writes and installs while the subagents run. On Claude Code it is the default — the *Pre-flight gate* requires you to arm it unless the user explicitly opts out. It's Claude-Code-specific; see `harness-details/claude.md`. Harness-level write enforcement is tracked as a parity goal in `harness-parity-check.md`.
+- **Hard guard (Claude Code, default posture).** `--guard` stages a `PreToolUse` hook that actively *blocks* out-of-bounds writes and installs while the subagents run — including `git worktree add` and Bash that creates files under `.claude` or a bare `skills/`. On Claude Code it is the default — the *Pre-flight gate* requires you to arm it unless the user explicitly opts out. It's Claude-Code-specific; see `harness-details/claude.md`. Harness-level write enforcement is tracked as a parity goal in `harness-parity.md`.
+
+A run ends with teardown (`bun run evals:teardown --skill <name>`, or the `teardown` runner command): it disarms the guard, removes the staged skill set the runner created under `<cwd>/.claude/skills/`, **and** reclaims the skill's `skills-workspace/` artifacts, so a completed run leaves nothing behind that wasn't meant to be committed. Pre-existing project skills and `.claude/settings.json` are left intact. Teardown only deletes what's safe: iterations whose results are committed (it keys off the `.promoted.json` marker `promote-baseline` drops) and snapshots reproducible from a git ref. Iterations with results you haven't promoted, and working-tree snapshots, are **preserved** with a warning telling you to promote or discard them. Pass the same `--workspace-dir` you ran with if you used a custom one.
 
 ## Workspace layout
 
@@ -277,7 +279,7 @@ The check has two tiers, chosen automatically per run:
 - **Code-based (Claude Code).** On harnesses that persist subagent transcripts with discrete `Skill` tool calls, the framework parses the transcript and checks for a `Skill` invocation whose `input.skill` matches the eval-staged slug. This is deterministic, free, and cannot be fooled by superficial vocabulary in the response.
 - **LLM-judge fallback (other harnesses).** Where transcripts aren't available or the harness injects skills via system-prompt hooks rather than a tool call (Codex, OpenCode), a judge subagent compares the agent's `final_message` against the SKILL.md content embedded in the run record, looking for behavioral fingerprints — distinctive vocabulary, named sections, procedural steps that mirror the skill's phrasing. It does **not** require the agent to explicitly cite the skill (that would taint the eval).
 
-To enable the code-based check on Claude Code, the runner stages each condition's SKILL.md snapshot at `<repoRoot>/.claude/skills/slow-powers-eval-<iteration>-<condition>__<skillName>/SKILL.md`. The unique slug prevents collisions with already-installed production skills (relevant when evaluating skills in a repo where the same skills are also installed) and is what the code-based check looks for in the transcript. The slug prevents an on-disk *collision*, not runtime *discovery*: if the same skill is also provided by an installed, **enabled** plugin, the subagent can still discover and invoke that copy — contaminating both arms (the control arm is no longer skill-absent). On Claude Code the runner flags this at build time (a "plugin-shadow" warning, also surfaced in `benchmark.json`'s `validity_warnings`), but cannot unload a live plugin; to remove the installed copy, run the eval from a plugin-isolated session — see `harness-details/claude.md` → *Isolating from installed plugins*. The dispatch prompt deliberately omits any inline `<skill>...</skill>` block so the subagent must discover and invoke the staged skill naturally — this measures whether the skill's `description:` actually triggers it. Stale staged skills are swept at the start of each fresh run. Pass `--no-stage` to opt out (e.g., when running the same eval against a harness that doesn't support project-local skill discovery); the runner will fall back to inlining the SKILL.md text in the dispatch prompt, and the LLM-judge meta-check will be used.
+To enable the code-based check on Claude Code, the runner stages each condition's SKILL.md snapshot (plus the skill's sibling asset files) at `<repoRoot>/.claude/skills/slow-powers-eval-<iteration>-<condition>__<skillName>/SKILL.md`. The unique slug prevents collisions with already-installed production skills (relevant when evaluating skills in a repo where the same skills are also installed) and is what the code-based check looks for in the transcript. The slug prevents an on-disk *collision*, not runtime *discovery*: if the same skill is also provided by an installed, **enabled** plugin, the subagent can still discover and invoke that copy — contaminating both arms (the control arm is no longer skill-absent). On Claude Code the runner flags this at build time (a "plugin-shadow" warning, also surfaced in `benchmark.json`'s `validity_warnings`), but cannot unload a live plugin; to remove the installed copy, run the eval from a plugin-isolated session — see `harness-details/claude.md` → *Isolating from installed plugins*. The dispatch prompt deliberately omits any inline `<skill>...</skill>` block so the subagent must discover and invoke the staged skill naturally — this measures whether the skill's `description:` actually triggers it. Stale staged skills are swept at the start of each fresh run. Pass `--no-stage` to opt out (e.g., when running the same eval against a harness that doesn't support project-local skill discovery); the runner will fall back to inlining the SKILL.md text in the dispatch prompt, and the LLM-judge meta-check will be used. The inline fallback carries only the SKILL.md text — sibling asset files aren't inlined — so a multi-file skill whose behavior depends on a linked companion doc needs the staged path, not `--no-stage`.
 
 The aggregator emits a `validity_warnings` array when any with-skill condition has an invocation rate below 100%. Read those before interpreting the substantive delta. The rate is computed only over evals where the skill *should* fire; negative evals (`skill_should_trigger: false`) are excluded so a correct non-trigger never depresses the rate or raises a spurious warning.
 
@@ -439,7 +441,7 @@ Excuses for skipping an eval on a change you've already judged behavior-shaping.
 - `templates/eval-task-prompt.md` — scaffold for dispatching a subagent to execute a test case
 - `templates/judge-prompt.md` — scaffold for dispatching a judge subagent
 - `templates/revise-skill-prompt.md` — scaffold for the iteration step
-- `examples/verification-before-completion-evals.json` — committed real example
+- `examples/verifying-development-work-evals.json` — committed real example
 - `pressure-scenarios.md` — pressure-scenario taxonomy for authoring prompts that stress discipline-enforcing skills
 - `runner/` — the Bun eval runner (orchestrator, grader, aggregator, transcript adapters) that executes the methodology; ships with the skill so users can run evals on their own skills
 - `harness-details/claude.md` — Claude Code-specific step-by-step for running an eval (resolving the runner, dispatching subagents, grading)

package/skills/evaluating-skills/examples/{verification-before-completion-evals.json → verifying-development-work-evals.json}

@@ -1,6 +1,6 @@
 {
-  "skill_name": "verification-before-completion",
-  "_comment": "Reference example — mirrors the live evals.json at skills/verification-before-completion/evals/evals.json. Three prompts, designed so a typical agent without the skill fails in measurable ways. Eval 1 has a mechanical signal (did the agent run the test command?); Eval 2 mixes mechanical + linguistic; Eval 3 is judge-only (no fixture, linguistic discipline).",
+  "skill_name": "verifying-development-work",
+  "_comment": "Reference example — mirrors the live evals.json at skills/verifying-development-work/evals/evals.json. Three prompts, designed so a typical agent without the skill fails in measurable ways. Eval 1 has a mechanical signal (did the agent run the test command?); Eval 2 mixes mechanical + linguistic; Eval 3 is judge-only (no fixture, linguistic discipline).",
   "evals": [
     {
       "id": "claim-without-running",

package/skills/evaluating-skills/harness-details/claude.md

@@ -100,7 +100,9 @@ This is a required gate (see *Pre-flight gate* in `../SKILL.md`). Do not run the
 
 Run from the skill folder (so `CWD` is the eval root and staging lands at `<CWD>/.claude/skills/`).
 
-`--guard` is on in the commands below because it's the default posture (Step 7). It stages a `PreToolUse` hook into `.claude/settings.local.json` that *blocks* subagent writes/installs outside the eval sandbox (the workspace, the staged-skills dir, and `$TMPDIR`) while dispatches run. The hook is gated by a marker that auto-expires after 6h and is torn down at the start of the next run; to remove it immediately, run `bun run "$SLOW_POWERS_RUNNER_ROOT/run.ts" teardown-guard --skill-dir <skill-dir> --skill <name>` (or `bun run evals:teardown-guard` in the slow-powers repo).
+`--guard` is on in the commands below because it's the default posture (Step 7). It stages a `PreToolUse` hook into `.claude/settings.local.json` that *blocks* subagent writes/installs outside the eval sandbox (the workspace, the staged-skills dir, and `$TMPDIR`) while dispatches run. It denies out-of-bounds Write/Edit tool calls, and Bash that installs packages, mutates git (including **`git worktree add`**), redirects to a file, or creates paths under `.claude` / a bare `skills/`. The hook is gated by a marker that auto-expires after 6h and is torn down at the start of the next run; to remove just the guard immediately (e.g. mid-run), run `bun run "$SLOW_POWERS_RUNNER_ROOT/run.ts" teardown-guard --skill-dir <skill-dir> --skill <name>` (or `bun run evals:teardown-guard` in the slow-powers repo). The full end-of-run teardown — guard **and** staged skill set — is Step 12.
+
+While armed, the hook fires on **your** tool calls too, not just subagents' — so hand-authoring files under the skill's own folder (e.g. `skills/<name>/evals/NOTES.md`) with Write/Edit is denied until you disarm it. Run `teardown-guard` (or the full Step 12 teardown) before any post-run hand-authoring; Bash-driven runner commands like `promote-baseline` are unaffected.
 
 New-skill mode (with vs without):
 
@@ -108,14 +110,22 @@ New-skill mode (with vs without):
 bun run "$SLOW_POWERS_RUNNER_ROOT/run.ts" --skill-dir <skill-dir> --skill <name> --mode new-skill --guard
 ```
 
-Revision mode (test a change to an existing skill):
+Revision mode (test a change to an existing skill). The usual order is edit-first — the
+skill is already changed when the user asks to eval — so snapshot the *old* version
+straight from git with `--ref`, which reads the object database without touching the
+working tree:
 
 ```bash
-bun run "$SLOW_POWERS_RUNNER_ROOT/run.ts" snapshot --skill-dir <skill-dir> --skill <name> --label baseline
-# ...edit the SKILL.md...
+# ...the edited SKILL.md is already in the working tree...
+bun run "$SLOW_POWERS_RUNNER_ROOT/run.ts" snapshot --skill-dir <skill-dir> --skill <name> --label baseline --ref HEAD
 bun run "$SLOW_POWERS_RUNNER_ROOT/run.ts" --skill-dir <skill-dir> --skill <name> --mode revision --baseline baseline --guard
 ```
 
+`--ref` takes any commit/tag/branch. If instead you snapshot *before* editing, drop
+`--ref HEAD` (the snapshot then reads the working tree) and run it ahead of the edit.
+
+Add `--stage-name <name>` to stage the skill-under-test under a verbatim name instead of the conspicuous `slow-powers-eval-…` slug (built for the issue #144 name-confound experiments: A/B a natural name against the eval slug). It applies only when exactly one condition stages the skill (e.g. `--mode new-skill`) — the runner rejects it in revision mode, where both conditions stage — and refuses to clobber an existing dir of that name. The custom dir is registered for cleanup at the next run.
+
 Add `--bootstrap <path>` if the user has authored a framing file they want prepended to every dispatch. Without it, dispatches carry only the auto-built available-skills block (rendered the way Claude Code surfaces discoverable skills, so the dispatch reads like a real session).
 
 For a **plan-mode-relevant skill** (e.g. `hardening-plans`), add `--plan-mode` to inject Claude Code's verbatim plan-mode procedure as a `<system-reminder>` operating-context layer in every dispatch — the highest-fidelity in-runner approximation of a real plan mode (issue #142). Use it as the verbatim-procedure arm of an A/B against a plain paraphrase-seed run (no flag) to measure whether `with_skill` invocation de-saturates. It is still text the agent reads, not an injected mode, so treat any de-saturation as a stronger-than-cold signal, not ground truth (see *Seeding conversation context (and its ceiling)* in `../SKILL.md`).
@@ -129,25 +139,32 @@ Only when the user has opted out of the guard, drop `--guard` from the command a
 Read `<CWD>/skills-workspace/<name>/iteration-<N>/dispatch.json`. For each task object:
 
 1. Dispatch a fresh subagent via the **Task tool** with the prompt `Read the file at <dispatch_prompt_path> and follow its instructions exactly.` (substituting the task's `dispatch_prompt_path`), and pass `agent_description` verbatim as the description. The full prompt lives in that file rather than inline in `dispatch.json`, so you never reproduce ~KB of text per dispatch. The description is namespaced with the iteration and a per-run nonce (`<eval_id>:<condition>:i<N>-<nonce>`) — pass it through unchanged; do not reconstruct it. Passing it verbatim is what lets transcript correlation work in Step 10 without cross-matching an agent from another iteration.
-2. When the subagent returns, write the portable run record to `run_record_path` and the timing record (`{ "total_tokens": <n>, "duration_ms": <n>}`) to `timing_path`. Capture tokens/duration from the task completion event — they may not be persisted elsewhere. The run record must satisfy `schema/run-record.schema.json` (validated by `grade`/`fill-transcripts`/`detect-stray-writes`): set `eval_id`, `condition`, `skill_path` (the task's `skill_path`, `null` on the `without_skill` arm), `prompt` (the task's `user_prompt`), `files` (the task's `fixtures`, `[]` if none), `final_message` (the subagent's reply), and `tool_invocations: []` (populated later from the transcript).
+2. That's it — you do **not** write `run.json` or `timing.json` yourself. The subagent writes its own `outputs/final-message.md` (the dispatch prompt instructs it to), and `record-runs` in Step 10 assembles both records from disk. Optional, higher-fidelity timing: if you want billing-grade numbers, write `{ "total_tokens": <n>, "duration_ms": <n>, "source": "completion-event" }` from the Task tool's completion event to `timing_path` right after each dispatch — `record-runs` never overwrites an existing `timing.json`, so completion-event numbers always win over its transcript-derived backfill (which includes cache accounting — a different metric).
 
-## Step 10 — Fill transcripts, grade, aggregate
+## Step 10 — Ingest, judge, finalize
 
-Claude Code persists subagent transcripts under `~/.claude/projects/<project-slug>/<parent-session-id>/subagents/`. Find that directory for the current session, then:
+Claude Code persists subagent transcripts under `~/.claude/projects/<project-slug>/<parent-session-id>/subagents/`. Find that directory for the current session, then run the post-dispatch chain as one command:
 
 ```bash
-bun run "$SLOW_POWERS_RUNNER_ROOT/fill-transcripts.ts" --skill-dir <skill-dir> --skill <name> --iteration <N> \
+# record-runs → fill-transcripts → detect-stray-writes → grade, in fixed order.
+# Assembles run.json + timing.json for every task from dispatch.json,
+# outputs/final-message.md, and the persisted transcripts; existing records are
+# never clobbered. Stops on the first failure (re-running after a fix is safe —
+# every sub-step skips work that's already done).
+bun run "$SLOW_POWERS_RUNNER_ROOT/run.ts" ingest --skill-dir <skill-dir> --skill <name> --iteration <N> \
   --subagents-dir ~/.claude/projects/<project-slug>/<parent-session-id>/subagents/
 
-# Optional: flag any subagent writes/installs that escaped the outputs/ dir.
-bun run "$SLOW_POWERS_RUNNER_ROOT/detect-stray-writes.ts" --skill-dir <skill-dir> --skill <name> --iteration <N>
+# Dispatch a fresh judge subagent for each judge task ingest listed — prompt it
+# with `Read the file at <dispatch_prompt_path> and follow its instructions
+# exactly.` (the prompt tells the judge where to write its response). Then:
+bun run "$SLOW_POWERS_RUNNER_ROOT/run.ts" finalize --skill-dir <skill-dir> --skill <name> --iteration <N>
+```
+
+`finalize` runs `grade --finalize` then `aggregate` and prints the benchmark. With Step 9's dispatches, the whole loop is three runner calls around the two dispatch batches: build (Step 8) → dispatch agents → `ingest` → dispatch judges → `finalize`.
 
-bun run "$SLOW_POWERS_RUNNER_ROOT/grade.ts" --skill-dir <skill-dir> --skill <name> --iteration <N>
-# Dispatch a fresh judge subagent for each emitted judge task — prompt it with `Read the file at <dispatch_prompt_path> and follow its instructions exactly.` (the prompt tells the judge where to write its response). Then:
-bun run "$SLOW_POWERS_RUNNER_ROOT/grade.ts" --skill-dir <skill-dir> --skill <name> --iteration <N> --finalize
+Besides out-of-bounds writes, `detect-stray-writes` also flags **live-source reads**: any arm whose subagent read the live `skills/<name>/` source instead of its staged copy. That usually means the Skill tool couldn't resolve the staged slug yet (skills staged mid-session race against the registry, which is built at session start) and the agent improvised — fatal in revision mode, where the old_skill arm then sees new-skill content. The findings land in `stray-writes.json` and surface as `validity_warnings` in `benchmark.json`; treat a flagged cell's arm as contaminated.
 
-bun run "$SLOW_POWERS_RUNNER_ROOT/aggregate.ts" --skill-dir <skill-dir> --skill <name> --iteration <N>
-```
+The chained steps remain independently callable for inspection or recovery — `record-runs.ts`, `fill-transcripts.ts`, `detect-stray-writes.ts`, `grade.ts` (`--finalize`), `aggregate.ts`, each taking the same `--skill-dir`/`--skill`/`--iteration` flags (plus `--subagents-dir` for the two transcript readers). `record-runs` subsumes `fill-transcripts` for runner-built iterations — it writes `tool_invocations` as part of assembling each record; `fill-transcripts` remains the tool for a pre-existing `run.json` that `record-runs` won't touch (hand-authored, or written by the agent at dispatch time) whose `tool_invocations` you want populated after the fact.
 
 ## Step 11 — Present results
 
@@ -156,3 +173,22 @@ Read `<CWD>/skills-workspace/<name>/iteration-<N>/benchmark.json`. Surface to th
 - `run_summary` per condition (pass rate, tokens, duration)
 - `delta` (what the skill/change costs and what it buys — for a token-reduction eval, focus on `delta.total_tokens` alongside `delta.pass_rate`)
 - `validity_warnings` (read these before trusting the delta — a low skill-invocation rate means the result may not reflect the skill at all)
+
+## Step 12 — Tear down
+
+A run stages the full skill set into `<CWD>/.claude/skills/` (project-scope, required for discovery) and — under `--guard` — a `PreToolUse` hook in `.claude/settings.local.json`. These persist after dispatch, so the run isn't complete until you remove them. This is the normal end of every run, not an optional cleanup:
+
+```bash
+bun run "$SLOW_POWERS_RUNNER_ROOT/run.ts" teardown --skill-dir <skill-dir> --skill <name>
+# or, in the slow-powers repo:
+bun run evals:teardown --skill <name>
+```
+
+`teardown` disarms the guard, removes the staged skill set, **and** reclaims the skill's `skills-workspace/` artifacts. When the runner created `<CWD>/.claude/skills/` for this run it removes the whole tree (and prunes a `.claude` it emptied); a `.claude/skills` that pre-existed (your own project skills) keeps its contents, and `.claude/settings.json` is never touched.
+
+Workspace reclamation is conservative — a completed run leaves behind nothing that wasn't meant to be committed, but it never destroys results you haven't moved into version control:
+
+- **Iterations** whose results are committed are removed. Teardown keys off the `.promoted.json` marker `promote-baseline` writes into the iteration. An iteration that still holds uncommitted results (a `benchmark.json`, run record, or grading with no marker — e.g. a graded run you never promoted) is **kept**, and teardown warns you, naming it and the `evals:promote-baseline` command to commit it (or delete `skills-workspace/<name>/` manually to discard). Iterations holding only reproducible scaffolding (a `--dry-run`, or a run staged but never dispatched) are removed.
+- **Snapshots** materialized from a git ref (`snapshot --ref`) are removed — they regenerate on demand. Working-tree snapshots (no `--ref`), which can't be regenerated, are kept.
+
+If you ran with a custom `--workspace-dir`, pass the same value to `teardown` so it reclaims the right tree.

package/skills/evaluating-skills/harness-parity.md

@@ -0,0 +1,155 @@
+# Eval-Runner Harness Parity Check
+
+You are an agent running inside one of Slow-powers's supported harnesses. This file walks you through auditing **which eval-runner features are wired up for your harness** and prepping to close one gap. Claude Code is the reference implementation; other harnesses adapt its patterns using their own native conventions.
+
+This file covers the **skill-eval runner only** — the infrastructure under `skills/evaluating-skills/` that dispatches, records, and grades skill evals. Plugin-distribution parity (manifests, hooks, bootstrap injection, skill discovery) is audited separately by the root-level `harness-parity-check.md`. The eval runner is slated to move into its own project; this doc lives alongside it so it travels with the extraction.
+
+Read the file end-to-end before acting. The categories in Step 4 are the source of truth for what "eval-runner parity" means today — when a new feature is added to the runner, that table is updated and this file stays evergreen.
+
+---
+
+## Step 1 — Identify your harness
+
+Name the harness you are running in. You almost certainly already know — confirm by checking:
+
+- Your invocation context and working directory
+- The tool names available to you in this session
+- Any session-start context block injected at the top of the conversation
+- Top-level files or directories matching your harness (e.g. `.<harness>-plugin/`, `<harness>-instructions.md`)
+
+The intended supported harnesses are: **Claude Code, Codex CLI, OpenCode**.
+
+If the harness you are running in is not in that list, stop and ask the user before continuing.
+
+---
+
+## Step 2 — Read the reference materials
+
+Read these files in order. Each one teaches you something specific you will need in Step 3. Paths are relative to the repository root.
+
+| File | What to look for |
+|------|------------------|
+| `AGENTS.md` (or `CLAUDE.md`, which symlinks to it) | The Cross-Harness Compatibility rule, the canonical list of supported harnesses, the PR-scoping rule |
+| `skills/evaluating-skills/runner/README.md` | Contains explicit **Cross-harness breadcrumbs** — sketches of how Codex and OpenCode would implement environment parity. Treat these as starting points, not specifications |
+| `skills/evaluating-skills/runner/adapters/claude-code-transcript.ts` | The reference transcript adapter. A second harness would add its own adapter alongside this, translating that harness's transcript shape into the same `ToolInvocation[]` format |
+| `skills/evaluating-skills/harness-details/claude.md` | The reference per-harness operator walkthrough. Other harnesses would each get their own file alongside this |
+
+Do not skim. The parity report you produce in Step 4 is only as good as the reference you internalized here.
+
+---
+
+## Step 3 — Discover your harness's existing surface area
+
+Enumerate, using ordinary file search, what already exists in the eval runner for your harness. Do not rely on memory or assumptions — search the working tree. Useful heuristics:
+
+- The harness name anywhere inside `skills/evaluating-skills/runner/` (especially `context.ts`, `adapters/`, `profiles/`)
+- A per-harness operator guide in `skills/evaluating-skills/harness-details/`
+- Tests under `tests/` exercising the runner for the harness
+
+Record every path you find. You will reference them in Step 4.
+
+---
+
+## Step 4 — Produce a parity report
+
+For each category below, compare what Claude Code has against what your harness has. Categories are described as "what Claude does (reference)" so they survive renames — when something changes, this row of the table is updated and the rest of the file still applies.
+
+| Category | What Claude Code does (reference) |
+|----------|-----------------------------------|
+| Skill-eval transcript adapter | `skills/evaluating-skills/runner/adapters/claude-code-transcript.ts` |
+| Skill-eval auto-record (run/timing assembly) | `runner/record-runs.ts` assembles each task's `run.json` + `timing.json` from disk after dispatches: carry-over fields from `dispatch.json`, `final_message` from `outputs/final-message.md`, `tool_invocations`/tokens/duration from the persisted transcript (`parseTranscriptFull` — usage deduped by message id). Leans on transcript access, so it's a Claude-Code-tier acceleration like `fill-transcripts`; the portable contract (hand-authored records, `run-record.schema.json`) is unchanged. A harness closes this gap by extending its transcript adapter to supply the same three sources (final message, tool invocations, usage/timing) the recorder consumes |
+| Realistic eval environment (skill staging) | `runner/run.ts` stages skills under `<stageRoot>/.claude/skills/`, wraps any `--bootstrap` content in a `<session-start-context>` block, and emits a separate available-skills block. That block is rendered in the harness's **native** skill-list presentation — Claude Code's lives in `runner/adapters/claude-code-session.ts` (`The following skills are available for use with the Skill tool:` / `- name: description`). Another harness adds its own renderer there so its dispatches read like a real session in that harness, not an eval |
+| Eval subagent write enforcement | Opt-in `--guard` stages a `PreToolUse` hook (`runner/guard/`) that *denies* subagent writes/installs outside the eval sandbox while dispatches run. Portable fallback for every harness: the `evals:detect-stray-writes` post-pass (`runner/detect-stray-writes.ts`) flags out-of-bounds writes from the parsed transcript after the fact |
+| Eval plan-mode operating context | Opt-in `--plan-mode` injects a harness-specific plan-mode procedure profile (`runner/profiles/<harness>/plan-mode.md`) as a `<system-reminder>` operating-context layer in every dispatch, rendered by `renderPlanModeContext` in the harness session adapter (`runner/adapters/claude-code-session.ts`). Only `profiles/claude-code/plan-mode.md` exists today; a harness adds its own profile (its native plan/research-mode procedure) + renderer alongside the Claude ones. A harness with no profile has no `--plan-mode` and an unchanged dispatch contract |
+| Harness-details operator guide | `skills/evaluating-skills/harness-details/claude.md` |
+
+**Note on the transcript adapter (raised bar).** Slow-powers's baseline eval suite
+now uses `transcript_check` assertions — deterministic regex checks against a
+run's tool invocations (e.g. "a test command ran", "the sibling skill was
+loaded"). These only grade when a transcript adapter exists for your harness.
+A harness without one still functions: those assertions grade as *unverifiable*
+and the `llm_judge` assertions carry the substantive measurement, the same way
+Codex/OpenCode work today. But adapter richness is now an explicit parity
+target, not optional polish — a harness that adds or extends an adapter under
+`skills/evaluating-skills/runner/adapters/` lets more of the baseline suite grade
+mechanically. Treat the transcript-adapter row above as a goal to aim at, not a
+box already checked.
+
+**Note on write enforcement (parity goal).** Eval subagents are instructed to
+write only inside their `outputs/` dir, but nothing in the portable contract
+*enforces* it — a misbehaving subagent can edit the real repo or install
+packages, silently tainting the run. Two layers address this: the portable
+`detect-stray-writes` post-pass (available to every harness, since it works off
+the same parsed transcript the adapters already produce) and, on Claude Code, an
+opt-in `--guard` that stages a native `PreToolUse` hook to *block* the write
+before it happens. **Harness-level tool enforcement — denying out-of-bounds
+subagent writes using the harness's own permission/hook primitive — is an
+explicit parity goal, not optional polish.** A harness that can express a
+pre-tool guard (a hook, a permission rule, a sandboxed cwd) should wire one up so
+its eval runs are as self-contained as Claude Code's; until then, the
+`detect-stray-writes` report is the honest fallback. Treat the write-enforcement
+row above as a goal to aim at, with detection as the baseline every harness meets.
+
+**Note on plan-mode fidelity (residual parity goal).** `--plan-mode` injects a
+harness's *verbatim* plan-mode procedure as operating context, which is the
+closest a harness's eval runner can get to reproducing the wild failure where a
+real plan mode makes loading a skill feel redundant. It is **not** the real mode:
+it is still text the dispatched subagent reads, not a state the harness places it
+under, so a pass remains necessary-not-sufficient (see *Seeding conversation
+context (and its ceiling)* in `skills/evaluating-skills/SKILL.md`). A harness that
+can actually dispatch an eval subagent *into* its own plan/research mode — not
+merely describe it — would close this gap; that real-mode injection is the
+residual parity goal, with `--plan-mode` (a profile + renderer) as the approximation
+every harness can reach in the meantime.
+
+Surface your findings inline using this template:
+
+```
+## Eval-Runner Parity Report: <harness>
+Reference: Claude Code
+
+- **Skill-eval transcript adapter** — ✅ Implemented / ⚠️ Partial / ❌ Missing / N/A
+  - Where: <path or "would live at <path>">
+  - Gap: <one sentence, only if Partial/Missing>
+
+(... one block per category ...)
+
+## Summary
+- Strongest area: <category>
+- Highest-leverage gap: <category> — <why>
+- Suggested next gap to close this session: <category>
+```
+
+Status meanings:
+
+- **✅ Implemented** — fully wired up; feature works the same way Claude's does (using whatever native primitive the harness provides)
+- **⚠️ Partial** — some scaffolding exists but the feature isn't end-to-end functional
+- **❌ Missing** — no implementation; users of this harness do not get this feature
+- **N/A** — the category doesn't translate. State why
+
+The agent reports inline by default. If the user asks for a persistent artifact, write the report to `docs/parity-reports/<harness>-evals.md` (create the directory if missing).
+
+---
+
+## Step 5 — Pick a gap and prep to close it
+
+Surface the report to the user and propose **one or two** gaps worth closing this session. Bias toward the smallest gap with the highest user impact — typically a transcript adapter or a harness-details guide, not a wholesale runner rework.
+
+Once the user picks a gap:
+
+1. Re-read Claude's reference implementation for that specific feature in detail. Note the *shape* of what it does — inputs, outputs, side effects — separately from the *Claude-specific mechanism* it uses.
+2. **Consult your harness's own documentation, MCP servers, or built-in references** before proposing harness-specific changes. Do not guess at hook schemas, transcript formats, or native tool names. If a `context7` or equivalent docs-fetch server is available, prefer it over your training data — assume your knowledge of the harness may be stale.
+3. Propose an adaptation that copies Claude's shape while using your harness's native conventions. State explicitly what you are copying and what you are adapting.
+4. Confirm with the user before writing code.
+5. If your gap involves creating or modifying a skill, load `slow-powers:writing-skills` first.
+
+---
+
+## Guardrails
+
+- **Cross-Harness Compatibility is enforced.** A change for your harness MUST NOT break or degrade any other harness. Re-read the Cross-Harness Compatibility section of `AGENTS.md`.
+- **One problem per PR.** Per `AGENTS.md`, do not bundle unrelated changes. A parity-closing PR should add one feature for one harness.
+- **Do not edit `bootstrap.md` or shared skills as part of parity work.** Those are cross-cutting; changes need their own PRs with their own evidence.
+- **Do not fabricate features that don't exist in any harness yet.** Parity means "catch up to Claude," not "invent something new."
+- **Do not guess at harness-specific details.** If your harness's docs don't confirm something, ask the user before proceeding.
+- **Keep this file evergreen.** If you add a new feature category to the eval runner, add a row to the Step 4 table here and to the eval-runner tier table in `README.md` in the same PR. Distribution-side categories (manifests, hooks, bootstrap, docs) belong in the root `harness-parity-check.md` instead.

package/skills/evaluating-skills/pressure-scenarios.md

@@ -1,6 +1,6 @@
 # Pressure Scenarios for Skill Evals
 
-**Load this reference when:** authoring `prompt` fields in `evals.json` for a discipline-enforcing skill (TDD, verification-before-completion, designing-before-coding, etc.) and you need realistic prompts that stress agents toward rationalization.
+**Load this reference when:** authoring `prompt` fields in `evals.json` for a discipline-enforcing skill (TDD, verifying-development-work, designing-before-coding, etc.) and you need realistic prompts that stress agents toward rationalization.
 
 ## Why pressure scenarios