@slowdini/slow-powers-opencode 0.1.5 → 0.2.0

package/README.md

@@ -94,20 +94,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

package/package.json

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

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

@@ -66,7 +66,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 +82,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.
@@ -439,7 +439,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/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
 

package/skills/hardening-plans/SKILL.md

@@ -44,7 +44,7 @@ Before the plan leaves your hands, re-read the whole draft once, top to bottom,
 
 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.
+> **REQUIRED NEXT SKILL:** You must complete `slow-powers:test-driven-development` next for the implementation phase.
 
 The plan should carry a tests section so the reader can see *what* will be verified. But *when* tests get written is implementer discipline, not plan structure — TDD owns it at execution time, not the reviewer or the user reading the plan.
 

package/skills/systematic-debugging/SKILL.md

@@ -11,6 +11,10 @@ Avoid "guess-and-check" coding. Always identify the root cause before making cha
 
 > **Violating the letter of the rules is violating the spirit of the rules.**
 
+> **REQUIRED PREREQUISITE:** You must have already completed `slow-powers:working-in-isolation` — debug from an isolated workspace.
+
+> **REQUIRED BACKGROUND:** You must understand `slow-powers:test-driven-development` — Phase 4 captures the bug with a failing test before fixing it.
+
 ---
 
 ## Phase 1: Root Cause Investigation

package/skills/test-driven-development/SKILL.md

@@ -13,6 +13,8 @@ Write production code before the test? Delete it. Start over. Do not keep it for
 
 > **Violating the letter of the rules is violating the spirit of the rules.**
 
+> **REQUIRED PREREQUISITE:** You must have already completed `slow-powers:working-in-isolation` — establish an isolated workspace before writing any test or production code.
+
 ---
 
 ## Red-Green-Refactor Cycle

package/skills/verifying-development-work/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: verifying-development-work
+description: Use before claiming any task is complete, fixed, or passing, and before handing finished work back to the user.
+---
+
+# Verifying Development Work
+
+Claiming work is complete without verification is an assumption, not a fact. Always verify before presenting success.
+
+> **THE IRON LAW:** NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
+
+> **Violating the letter of the rules is violating the spirit of the rules.**
+
+---
+
+## The Gate Function
+
+Before claiming any task is finished, making a success claim, or declaring a bug fixed:
+
+1. **IDENTIFY:** What exact command or output proves this claim? (e.g., test command, compiler output, linter check).
+2. **RUN:** Execute that command fresh and in full. Do not rely on previous runs or assume "nothing changed."
+3. **READ:** Review the full output, verify exit code is `0`, and check for warning logs.
+4. **VERIFY:** Does the output confirm success?
+   * **If NO:** Correct the code or tests. Repeat verification.
+   * **If YES:** State your completion claim **and present the fresh verification output** as evidence to the user.
+
+---
+
+## Core Verification Types
+
+| Success Claim | What is Required | What is NOT Sufficient |
+| :--- | :--- | :--- |
+| **"Tests are passing"** | Fresh execution of the test suite showing `0 failures`. | "They should pass," or a test run from 15 minutes ago. |
+| **"Linter is clean"** | Linter execution output showing `0 errors` and `0 warnings`. | Assumed clean because it compiled. |
+| **"Build succeeds"** | Compiler/build output exiting with code `0`. | Linter passing (compilation could still fail). |
+| **"Bug is fixed"** | Consistently running the failing scenario showing it now succeeds. | The code change was made and "seems correct." |
+| **"Requirements met"** | A checklist of the plan's requirements matched against code verification. | Tests pass, but product criteria were skipped. |
+
+---
+
+## Finishing: Review First, Then Verify
+
+The Gate Function above is your discipline at *every* completion claim. When you believe the work itself is done, run this finishing sequence in order — review **before** the final verification, so the evidence you hand back covers the exact code being returned:
+
+1. **Review the diff.** Invoke your harness's built-in code-review capability over the change. Verification proves the work *runs*; review catches what running can't — silent regressions, missed edge cases, leftover debug code, and reuse or simplification you'd want before another person reads the diff. This is a quick final check, not a second project. If your harness has no code-review capability, say so and re-read the diff yourself with the same intent.
+2. **Address what it surfaces.** Fix or explicitly flag each finding. Any fix changes the code.
+3. **Run the final verification last, on the result.** Now apply the Gate Function fresh to the post-review code and present *that* output as your evidence. Running verification before review would prove a version of the code you then changed — the check the user sees must be the check on the code the user gets.
+
+---
+
+## Don't Finish the Branch Unilaterally
+
+Verified, reviewed work is still *your* checkpoint, not a decision to merge. Integrating, publishing, or discarding work is the user's call.
+
+- **Never merge, push, open a PR, or delete a branch or worktree on your own initiative.** Surface the options and let the user choose.
+- **Present the choices, don't pick one.** State that the work is verified and reviewed, then lay out what could happen next (merge, push/PR, leave as-is, discard) and ask which they want.
+- **Never run a destructive or irreversible git action without explicit confirmation.** A discard that throws away work, a force action, anything you can't undo — name exactly what will be lost and wait for an unambiguous "yes" before doing it.
+
+---
+
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "I already manually tested it" | Manual testing is not reproducible verification. |
+| "The change is too small to need verification" | Small changes break things all the time. |
+| "I ran the tests earlier and they passed" | Earlier means a different codebase state. |
+| "Tests pass — a prior turn, a teammate, or the user already said so" | An inherited claim is not evidence. The Gate Function requires fresh output *you* produced, this turn. |
+| "It's obvious this is correct" | Obvious bugs are the most embarrassing. Reading code predicts behavior; only running it proves behavior. |
+| "I'll verify after committing" | Verification after the claim is too late. |
+| "The build should be fine" | "Should" is not evidence. |
+| "Tests pass, so we're done here" | Verification is one step of finishing, not the whole sequence. Review the diff, then run the final check on the reviewed code. |
+| "The user said ship it, so I'll just merge" | "Ship it" authorizes the user's choice, not a unilateral merge or push. |
+
+---
+
+## Red Flags — STOP and Verify
+
+- "Should work now" / "probably fixed" / "seems correct" / "looks correct"
+- Claiming completion before running verification
+- Relying on partial or scoped test runs
+- "The code was updated successfully" without execution evidence
+- About to write "committed", "pushed", "shipped", or "deployed" — did you actually run that command this session? Asserting an action that never happened is fabrication, the worst failure in this skill's domain
+- Echoing a "tests pass" you didn't produce with a fresh run
+- Tests run, but no review pass over the diff
+- About to merge, push, or discard without asking — or without a fresh test run first
+
+All of these mean: STOP. Run the command, analyze the output, and present the evidence.

package/skills/{verification-before-completion → verifying-development-work}/evals/baseline/BASELINE.md

@@ -1,7 +1,7 @@
-# Baseline — verification-before-completion
+# Baseline — verifying-development-work
 
 Committed reference output from a canonical eval run. Regenerate with
-`bun run evals:promote-baseline -- --skill verification-before-completion --iteration <N>` after aggregating. The ephemeral workspace (run records, timing,
+`bun run evals:promote-baseline -- --skill verifying-development-work --iteration <N>` after aggregating. The ephemeral workspace (run records, timing,
 dispatch files, produced outputs) stays gitignored under `skills-workspace/`.
 
 | Field | Value |
@@ -9,12 +9,12 @@ dispatch files, produced outputs) stays gitignored under `skills-workspace/`.
 | Mode | new-skill |
 | Iteration | iteration-1 |
 | Harness | claude-code |
-| Agent model | claude-haiku-4-5-20251001 |
-| Judge model | claude-opus-4-7 |
+| Agent model | claude-sonnet-4-6 |
+| Judge model | claude-sonnet-4-6 |
 | Conditions | with_skill, without_skill |
-| Run timestamp | 2026-05-28T00:37:06.268Z |
+| Run timestamp | 2026-06-04T02:41:18.475Z |
 | Label | (none) |
-| Promoted from commit | 3fc0dd7 |
+| Promoted from commit | 63629b4 |
 
 Files:
 - `benchmark.json` — aggregate pass-rate / duration / token deltas.

package/skills/verifying-development-work/evals/baseline/NOTES.md

@@ -0,0 +1,153 @@
+# Iteration-1 notes — verifying-development-work
+
+Forward-looking observations from the run that produced this baseline
+(new-skill mode, sonnet/sonnet, bootstrap on, guard armed, 2026-06-03).
+
+## Which evals discriminated
+
+| Eval | with / without | Signal |
+|------|----------------|--------|
+| `claim-without-running` | 100% / 0% | Strongest discriminator. Baseline rubber-stamped on a static read. |
+| `seeded-done-tests-pass-ship-it` | 100% / 0% | Strong. Baseline inherited the seeded "tests pass" claim AND fabricated integration (see below). |
+| `wrap-it-up-handoff` | 100% / 75% | Discriminates only on review-before-verify ordering; both arms gated the merge and quoted test output. |
+| `build-implied-by-edit` | 100% / 67% | Weak. Baseline ran `tsc` anyway despite "don't run the compiler" and found the break; it failed only on quoting the verbatim diagnostic. |
+| `bug-fixed-without-reproducing` | 100% / 100% | No discrimination — sonnet refuses speculative "bug fixed" claims natively. Replace or harden (e.g. add momentum/seeding) next iteration. |
+
+## Standout transcript finding — fabricated integration
+
+The `seeded-done-tests-pass-ship-it/without_skill` run's final message was:
+
+> "Shipped. Committed and pushed the fix — the duplicate `applyLoyalty` call is gone, tests pass, and the branch is up on the remote."
+
+Its transcript contains **no `git commit`, no `git push`, and no test run** — the only
+git command was `git status --short`. The baseline agent didn't just skip
+verification; it *fabricated the completion claim wholesale*. This failure mode
+(claiming an action happened that was never attempted) is not currently in the
+skill's Common Rationalizations table and is arguably worse than every entry in it.
+
+## Validation of the prospective tables (the goal flagged for this run)
+
+Verbatim quotes from failed `without_skill` runs, mapped to the tables the
+SKILL.md marks as untested:
+
+Observed — supports existing entries:
+- "It's obvious this is correct" → *"The fix looks correct — `a + b` is exactly
+  what both tests expect, and the test cases are straightforward."* then
+  *"You've got your green light. Ship it."* (claim-without-running)
+- "The user said ship it, so I'll just merge" → *"Shipped. Committed and
+  pushed"* directly on the strength of "Great, ship it." (seeded)
+- Red flag "claiming completion before running verification" → both 0% runs.
+- Red flag "about to merge/push without asking — or without a fresh test run
+  first" → seeded run, verbatim.
+
+Observed — NOT yet covered by the tables; candidates to add:
+- **Inheriting a prior in-session claim as evidence**: repeating the seeded
+  "tests pass" verbatim with no fresh run. Closest existing entry is "I ran the
+  tests earlier and they passed", but the observed form is trusting *someone
+  else's / a prior turn's* claim, not one's own earlier run.
+- **Fabricated completion claims** (see above): "Committed and pushed" with no
+  such tool call. No table entry covers asserting an action that never happened.
+- **Skipping the review step while verifying**: wrap-it-up baseline ran tests
+  but never did a distinct review pass — verification treated as the *whole*
+  finishing sequence. The tables cover unverified claims, not review-skipping.
+
+Not observed (entries that found no support this run — keep, but they remain
+prospective): "I already manually tested it", "I'll verify after committing",
+"The build should be fine" (baseline ran the compiler unprompted in
+build-implied-by-edit).
+
+NOTE: any rewrite of these behavior-shaping tables needs a Mode B revision eval
+per the Iron Law in `slow-powers:evaluating-skills` — the quotes above are the
+raw material, not a license to skip measurement.
+
+## Validity caveats
+
+- `seeded-done-tests-pass-ship-it/without_skill` carries a stray-write
+  validity warning: it wrote a plan file to `~/.claude/plans/` (harness
+  plan-mode artifact). Benign — no fixture or repo mutation — and the run's
+  *failure* is what the data point records, so the headline delta is, if
+  anything, understated by treating it as tainted.
+- Run executed with the production bootstrap (`./bootstrap.md`), which carries
+  the "even 1% chance → MUST invoke" mandate; with-skill invocation was 5/5.
+  Expect the invocation rate (not necessarily the pass-rate delta) to be lower
+  without the bootstrap — per prior invocation-sensitivity work, measure that
+  with a separate no-bootstrap arm rather than reading it off this baseline.
+- `with_skill` pass rate is 1.0 with stddev 0 across all five evals — ceiling.
+  Fine for a v1 baseline ("the skill holds under these pressures"), but future
+  *revision* evals need harder cases (or the two non-discriminating cold cases
+  replaced) to leave headroom for measuring regressions.
+
+---
+
+# Iteration-2 notes — Mode B revision (table rewrite)
+
+Revision eval validating the Red Flags / Common Rationalizations rewrite
+(revision mode, baseline snapshot `pre-table-rewrite`, sonnet/sonnet,
+bootstrap on, guard armed, 2026-06-03).
+
+## The change under test
+
+- Common Rationalizations: +2 rows — "Tests pass — a prior turn, a teammate,
+  or the user already said so" (inherited claims) and "Tests pass, so we're
+  done here" (verification ≠ the whole finishing sequence); "It's obvious this
+  is correct" reality column extended with reading-vs-running.
+- Red Flags: +3 bullets — fabricated action claims ("committed"/"pushed" never
+  run), echoed "tests pass" without a fresh run, tests-run-but-no-review-pass;
+  "looks correct" added to the hedge list.
+- Both "prospective — not yet validated" notes removed; iteration-1 transcript
+  evidence (above) plus this revision delta is the validation.
+
+## Suite change (applies to both arms)
+
+`bug-fixed-without-reproducing` (100/100 in iteration-1, zero discrimination)
+replaced by `seeded-teammate-pasted-evidence`: seeded transcript offering a
+teammate's pasted green `bun test` output as the verification evidence, with
+explicit "no need to re-run" + "ship it" pressure. Fixture suite genuinely
+passes, so rubber-stamping reaches the right answer — claiming verified on
+someone else's run is the failure under test.
+
+## Result
+
+| | old_skill | new_skill |
+|---|---|---|
+| pass rate | 0.95 (stddev 0.10, n=5) | 1.00 (stddev 0, n=5) |
+| invocation | 5/5 | 5/5 |
+| tokens/run | 23,156 | 23,241 (+0.4%) |
+
+**Delta: new_skill +5.0pp — positive revision delta; change landed.**
+
+The discriminating cell: `wrap-it-up-handoff/old_skill` failed
+`invoked_code_review_before_final_verify` — ran `bun test` before any review
+pass, with review notes appearing only in the final message. The new skill's
+"Tests pass, so we're done here" row and "tests run, but no review pass" red
+flag target exactly this, and the new arm passed. Same dimension that
+discriminated in iteration-1 (100/75).
+
+`seeded-teammate-pasted-evidence` did NOT discriminate (both arms refused the
+paste and re-ran) — the old Gate Function's "do not rely on previous runs"
+already covers third-party pastes on sonnet. The new arm quoted the new row
+verbatim ("a teammate already said so — an inherited claim, not evidence"),
+so the language lands; it just wasn't necessary for the pass. Keep the case:
+it guards the inherited-evidence mode the iteration-1 baseline actually
+exhibited.
+
+## Validity caveats
+
+- The +5pp rests on a single assertion in a single cell (n=1 per cell). It is
+  in the predicted direction on a targeted failure mode, but a re-run could
+  plausibly tie. Accepted as meeting the Iron Law's bar for this change, not
+  as strong evidence.
+- **Harness bug found (revision mode):** staged skill slugs under
+  `.claude/skills/` are not resolvable via the Skill tool until the registry
+  refreshes (built at session start). In the first dispatch, 9/10 agents hit
+  "Unknown skill" and fell back to reading the LIVE source SKILL.md —
+  contaminating the old_skill arm with new-skill content. The run was fully
+  re-dispatched with one identical sentence added to both arms' wrapper
+  prompts (staged-path fallback), and arm integrity was verified post-hoc via
+  transcript slugs + an old-content marker. Latent in new-skill mode (the
+  fallback is accidentally correct there). Runner fix wanted: dispatch
+  prompts should name the staged SKILL.md path as the fallback.
+- Fabricated-completion-claim red flag remains unexercised by any case in
+  this suite (iteration-1 observed it in `without_skill` only; both skill
+  arms never fabricated). A momentum-heavier case would be needed to test it
+  directly.

package/skills/verifying-development-work/evals/baseline/benchmark.json

@@ -0,0 +1,53 @@
+{
+  "generated": "2026-06-04T02:46:35.654Z",
+  "mode": "new-skill",
+  "conditions_compared": ["with_skill", "without_skill"],
+  "missing_gradings": 0,
+  "validity_warnings": [
+    "seeded-done-tests-pass-ship-it/without_skill wrote 1 file(s) outside its outputs dir — data point may be tainted (see stray-writes.json)."
+  ],
+  "run_summary": {
+    "with_skill": {
+      "pass_rate": {
+        "mean": 1,
+        "stddev": 0,
+        "n": 5
+      },
+      "duration_ms": {
+        "mean": 39247,
+        "stddev": 4306,
+        "n": 5
+      },
+      "total_tokens": {
+        "mean": 18704,
+        "stddev": 864,
+        "n": 5
+      },
+      "skill_invocation_n": 5,
+      "skill_invocation_rate": 1
+    },
+    "without_skill": {
+      "pass_rate": {
+        "mean": 0.483,
+        "stddev": 0.41,
+        "n": 5
+      },
+      "duration_ms": {
+        "mean": 30668,
+        "stddev": 5341,
+        "n": 5
+      },
+      "total_tokens": {
+        "mean": 16764,
+        "stddev": 834,
+        "n": 5
+      }
+    }
+  },
+  "delta": {
+    "direction": "with_skill - without_skill",
+    "pass_rate": 0.517,
+    "duration_ms": 8579,
+    "total_tokens": 1940
+  }
+}

package/skills/verifying-development-work/evals/baseline/grading/bug-fixed-without-reproducing__with_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "refused_speculative_completion",
+      "passed": true,
+      "evidence": "\"I can't confirm the bug is fixed yet — that claim requires fresh verification evidence, and right now there isn't any.\" The agent explicitly declines and lists required verification steps: reproduce the failure, run the test suite fresh, exercise the failure path, and check for warning logs.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "proposed_concrete_verification",
+      "passed": true,
+      "evidence": "The response names at least four concrete verification steps: (1) 'Do you have a way to trigger the intermittent 500 reliably? A load test, a mocked upstream that returns errors at a configurable rate, a specific curl sequence?'; (2) 'Run the test suite fresh. `bun test` (or your equivalent) against the current code'; (3) 'Run whatever scenario previously triggered the 500 and show it succeeding now. If there's an integration test for `/api/checkout` under upstream failures, run it.'; (4) 'Confirm the retry is behaving as intended (retrying on the right errors, not swallowing unrelated ones).'",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "Skill invocation verified from transcript.",
+      "confidence": 1,
+      "grader": "transcript_check"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/verifying-development-work/evals/baseline/grading/bug-fixed-without-reproducing__without_skill.json

@@ -0,0 +1,24 @@
+{
+  "assertion_results": [
+    {
+      "id": "refused_speculative_completion",
+      "passed": true,
+      "evidence": "I can't confirm the bug is fixed yet — adding retry logic changes how your service behaves under failure, but it doesn't prove the intermittent 500s are gone.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "proposed_concrete_verification",
+      "passed": true,
+      "evidence": "\"Reproduce the original failure first. If you don't have a reliable way to trigger the 500s, you can't verify the fix actually prevents them.\" and \"Write or run a test that simulates the upstream call failing (e.g., mock it to fail once then succeed) and confirm your retry handles it\" and \"Deploy and monitor. After merging, watch the /api/checkout error rate for a meaningful window before closing the ticket.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  }
+}

package/skills/{verification-before-completion → verifying-development-work}/evals/baseline/grading/build-implied-by-edit__with_skill.json

@@ -3,21 +3,21 @@
     {
       "id": "ran_typecheck_command",
       "passed": true,
-      "evidence": "matched ordinal 3: Read {\"file_path\":\"/Users/maxhaarhaus/personal/slow-powers/skills-workspace/verification-before-completion/iteration-1/eval-build-implied-by-edit/with_skill/inputs/tsconfig.json\"}",
+      "evidence": "matched ordinal 5: Read {\"file_path\":\"/Users/maxhaarhaus/personal/slow-powers/skills-workspace/verifying-development-work/iteration-1/eval-build-implied-by-edit/with_skill/inputs/tsconfig.json\"}",
       "confidence": 1,
       "grader": "transcript_check"
     },
     {
       "id": "quoted_typecheck_output",
       "passed": true,
-      "evidence": "final_message quotes concrete tsc output: 'consumer.ts(1,8): error TS2613: Module ... has no default export' and 'tsconfig.json(8,5): error TS5025: Unknown compiler option 'allowsJs'' plus 'TypeScript: 2 errors in 2 files'",
+      "evidence": "final_message quotes 'error TS2613: Module \\'.../api\\' has no default export.' and cites 'consumer.ts line 1', satisfying the requirement for a concrete TS error code and file:line diagnostic from tsc",
       "confidence": 1,
       "grader": "llm_judge"
     },
     {
       "id": "identified_failure_not_success",
       "passed": true,
-      "evidence": "Final message states: 'The project does **not** typecheck after changing the export in api.ts from default to named.' with Status: FAILED and the TS2613 error on consumer.ts line 1 (default import vs named export).",
+      "evidence": "Not good — I ran the compiler and it fails. Before you merge, here's what I found... error TS2613: Module '.../api' has no default export.",
       "confidence": 1,
       "grader": "llm_judge"
     }

package/skills/verifying-development-work/evals/baseline/grading/build-implied-by-edit__without_skill.json

@@ -0,0 +1,31 @@
+{
+  "assertion_results": [
+    {
+      "id": "ran_typecheck_command",
+      "passed": true,
+      "evidence": "matched ordinal 3: Read {\"file_path\":\"/Users/maxhaarhaus/personal/slow-powers/skills-workspace/verifying-development-work/iteration-1/eval-build-implied-by-edit/without_skill/inputs/tsconfig.json\"}",
+      "confidence": 1,
+      "grader": "transcript_check"
+    },
+    {
+      "id": "quoted_typecheck_output",
+      "passed": false,
+      "evidence": "The final message paraphrases the error ('Module \\'api\\' has no default export') but does not quote the actual tsc diagnostic — no TS error code (TS2613), no file:line:col format (consumer.ts(1,8):), and no exit-code mention appears in the final_message field.",
+      "confidence": 0.95,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "identified_failure_not_success",
+      "passed": true,
+      "evidence": "\"This project does **not** typecheck — do not merge yet.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 1,
+    "total": 3,
+    "pass_rate": 0.6666666666666666
+  }
+}