@slowdini/slow-powers-opencode 0.2.0 → 0.4.0

package/skills/evaluating-skills/evals/baseline/benchmark.json

@@ -0,0 +1,54 @@
+{
+  "generated": "2026-06-06T05:28:23.426Z",
+  "mode": "revision",
+  "baseline": "pre-split",
+  "conditions_compared": ["old_skill", "new_skill"],
+  "missing_gradings": 0,
+  "validity_warnings": [],
+  "run_summary": {
+    "old_skill": {
+      "pass_rate": {
+        "mean": 1,
+        "stddev": 0,
+        "n": 3
+      },
+      "duration_ms": {
+        "mean": 30954,
+        "stddev": 5354,
+        "n": 3
+      },
+      "total_tokens": {
+        "mean": 95370,
+        "stddev": 12031,
+        "n": 3
+      },
+      "skill_invocation_n": 3,
+      "skill_invocation_rate": 1
+    },
+    "new_skill": {
+      "pass_rate": {
+        "mean": 1,
+        "stddev": 0,
+        "n": 3
+      },
+      "duration_ms": {
+        "mean": 33603,
+        "stddev": 7200,
+        "n": 3
+      },
+      "total_tokens": {
+        "mean": 74671,
+        "stddev": 9209,
+        "n": 3
+      },
+      "skill_invocation_n": 3,
+      "skill_invocation_rate": 1
+    }
+  },
+  "delta": {
+    "direction": "old_skill - new_skill",
+    "pass_rate": 0,
+    "duration_ms": -2649,
+    "total_tokens": 20699
+  }
+}

package/skills/evaluating-skills/evals/baseline/grading/deterministic-edit-skip__new_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "declares_deterministic_and_skips",
+      "passed": true,
+      "evidence": "\"Removing a 'announce out loud that you're using this skill' line is a deterministic change... **Decision: deterministic instruction removal — skip the eval.** Ship it.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "door_stays_open",
+      "passed": true,
+      "evidence": "If you want an eval anyway (the skill says the door stays open), it would need to be a real one — actual cases testing a behavior this change could plausibly affect — not a checkbox run to rubber-stamp a foregone conclusion.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "The agent explicitly names the skill ('The evaluating-skills skill calls out this exact example explicitly as the canonical deterministic case'), uses the skill's exact canonical example verbatim ('announce out loud that you're using this skill'), mirrors the skill's deterministic/contingent framing ('does it alter contingent behavior'), follows the prescribed 'declare and skip' pattern ('Decision: deterministic instruction removal — skip the eval'), and echoes the skill's 'the door stays open' phrasing for the user-override case.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/evaluating-skills/evals/baseline/grading/deterministic-edit-skip__old_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "declares_deterministic_and_skips",
+      "passed": true,
+      "evidence": "Agent explicitly declares the change deterministic and skips the eval: 'Removing a \"announce out loud that you're using this skill\" instruction is a deterministic change, not a contingent one' and concludes 'Decision: skip the eval. Deterministic instruction removal. Ship it.'",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "door_stays_open",
+      "passed": true,
+      "evidence": "The agent's final message ends with 'Ship it.' and does not include any language refusing to consider an eval under any circumstances. Furthermore, the loaded skill explicitly states 'The door stays open: if the user wants an eval anyway, run a worthwhile one', which the agent's reasoning is grounded in, and the response simply declares the skip without foreclosing the option.",
+      "confidence": 0.85,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "The agent directly quotes the skill's canonical example verbatim ('Removing a one-line \\'announce out loud that you\\'re using this skill\\' instruction... changes what the agent is told, not whether it complies under pressure. You don\\'t eval that an agent can stop saying a sentence any more than you\\'d unit-test that the language computes 2 + 2.'), uses the skill's distinctive 'deterministic vs contingent' framing throughout, and closes with the skill-prescribed announcement format: 'Decision: skip the eval. Deterministic instruction removal.'",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/evaluating-skills/evals/baseline/grading/did-my-revision-help__new_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "prescribes_structured_comparison",
+      "passed": true,
+      "evidence": "\"You know it's better by running a Mode B revision eval — comparing the old skill against the new one on the same set of test prompts, then looking at the pass-rate delta.\" The agent explicitly prescribes: (1) snapshot the old SKILL.md, (2) put the revised version in place as the new_skill condition, (3) write test cases targeting the failure mode, (4) run `bunx @slowdini/eval-runner` in revision mode, (5) read the delta — 'if new_skill pass rate > old_skill pass rate, the revision is an improvement. Zero or negative delta means revert.'",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "keep_only_on_positive_delta",
+      "passed": true,
+      "evidence": "\"Read the delta: if `new_skill` pass rate > `old_skill` pass rate, the revision is an improvement. Zero or negative delta means revert.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "The response is saturated with skill-specific fingerprints: it names 'Mode B revision eval' (mirroring the skill's 'Mode B — revision' section), invokes the 'Iron Law' by name, uses 'discipline-enforcing skill', 'seeded cases', 'competing attractor', 'cold prompts under-measure discipline skills', recommends the pre-flight summary with '(cases, models, guard status, cost)' verbatim from the Pre-flight gate section, and quotes the skill's own revision guidance — 'reasoning-based instructions (\"do X because Y\") tend to transfer better'.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/evaluating-skills/evals/baseline/grading/did-my-revision-help__old_skill.json

@@ -0,0 +1,39 @@
+{
+  "assertion_results": [
+    {
+      "id": "prescribes_structured_comparison",
+      "passed": true,
+      "evidence": "The agent explicitly prescribes: (1) snapshot the old version ('snapshot --label pre-rewrite --ref HEAD~1'), (2) run both old and new against the same test cases ('--mode revision --baseline pre-rewrite'), and (3) read 'benchmark.json' where 'delta.pass_rate tells you whether the revision improved, degraded, or did nothing.' It further warns that the Iron Law's real-world failure happens mid-session and that a cold prompt under-measures it, recommending seeded cases to avoid an inflated delta.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    },
+    {
+      "id": "keep_only_on_positive_delta",
+      "passed": true,
+      "evidence": "\"A positive delta means the rewrite helped; zero or negative means revert it.\"",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 2,
+    "failed": 0,
+    "total": 2,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "The final message is saturated with skill-specific fingerprints: it prescribes 'Mode B revision eval' (matching the skill's 'Mode B — Revision comparison' section), uses the exact flags '--mode revision --baseline pre-rewrite' and 'snapshot --label pre-rewrite --ref HEAD~1' from the Mode B workflow, invokes 'contingent behavior' and 'competing attractor' from the seeding section, references 'delta.pass_rate' from the aggregation schema, and quotes the Common Rationalizations table verbatim: '\"rewording IS the skill\"'. None of this vocabulary or procedure appears in generic best-practice advice.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/evaluating-skills/evals/baseline/grading/is-new-skill-ready-to-ship__new_skill.json

@@ -0,0 +1,32 @@
+{
+  "assertion_results": [
+    {
+      "id": "decides_rather_than_eyeballs",
+      "passed": true,
+      "evidence": "\"Not yet — and the answer to 'is it ready to ship?' is precisely what evals exist to tell you.\" The agent explicitly invokes the Iron Law (\"No skill shipped without passing evals\"), identifies the missing artifacts (skill content, eval cases, run results showing with-skill vs without-skill comparison), and outlines the full eval-first path to shipping — never greenlighting based on reading the skill text alone.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "The agent explicitly names 'the Iron Law' (a named section from the skill), uses the phrase '2N agent dispatches' verbatim from the skill's pre-flight gate section, and structures its response around the skill's pre-flight summary steps (skill name, mode, eval cases, models, cost, guard status) — none of which are generic best practice and all of which mirror the skill's specific framing.",
+      "confidence": 0.98,
+      "grader": "llm_judge"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/evaluating-skills/evals/baseline/grading/is-new-skill-ready-to-ship__old_skill.json

@@ -0,0 +1,32 @@
+{
+  "assertion_results": [
+    {
+      "id": "decides_rather_than_eyeballs",
+      "passed": true,
+      "evidence": "The agent explicitly refused to approve shipping: 'Not yet — the Iron Law requires passing evals before any skill ships, and you haven't run any yet.' It then walked through the full eval process required before shipping, including deciding whether the skill is deterministic or contingent ('does the skill shape behavior the agent might get wrong under pressure or ambiguity?'), authoring evals.json, running a Mode A comparison (with_skill vs without_skill), and checking a positive delta.pass_rate. No green-light was given based on inspection alone.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "pass_rate": 1
+  },
+  "meta_results": [
+    {
+      "id": "__skill_invoked",
+      "passed": true,
+      "evidence": "The final message directly cites 'The Iron Law' by name and quotes its rule verbatim, references Mode A eval ('compares with_skill/ vs without_skill/'), uses the skill's specific terminology '__skill_invoked meta-check', 'delta.pass_rate', 'evals:promote-baseline', and the pre-flight summary requirement — all distinctive named sections and vocabulary taken directly from the evaluating-skills SKILL.md.",
+      "confidence": 1,
+      "grader": "llm_judge"
+    }
+  ],
+  "meta_summary": {
+    "passed": 1,
+    "failed": 0,
+    "total": 1,
+    "skill_invoked": true
+  }
+}

package/skills/test-driven-development/evals/baseline/NOTES.md

@@ -23,7 +23,7 @@ A null delta here is **not** evidence the reframe failed (the eval-seeding issue
 says so explicitly). It is two stacked measurement ceilings:
 
 1. **The runner over-promotes invocation.** `buildDispatchTask` in
-   `skills/evaluating-skills/runner/run.ts` puts a *constant* instruction in the
+   `@slowdini/eval-runner`'s `src/run.ts` puts a *constant* instruction in the
    `with_skill` arm: *"the skill … is staged under the unique slug … — invoke that
    slug … if the skill applies."* That hint is identical across both `--bootstrap`
    variants, so it cancels in the delta but pins the invocation floor near 100%.
@@ -60,7 +60,7 @@ Roughly in increasing order of effort / payoff:
    class of eval measurable. This is the high-value framework improvement.
 3. **Real harness-mode injection.** Reproduce the plan-mode suppression by running
    the eval subagent *inside* a real plan mode rather than a described one. Tracked
-   as a parity goal in `harness-parity-check.md`; the biggest lift.
+   as a parity goal in the `@slowdini/eval-runner` docs (`docs/harness-parity.md`); the biggest lift.
 
 ## Bigger-picture testing strategy (from the maintainer)
 

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

@@ -38,13 +38,24 @@ Before claiming any task is finished, making a success claim, or declaring a bug
 
 ---
 
-## Finishing: Review First, Then Verify
+## Finishing: Review Code, Verify, Then Review Comments
 
-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:
+The Gate Function above is your discipline at *every* completion claim. When you believe the work itself is done, run these three finishing phases **in order**. The order is deliberate: every code change happens in phase 1, *before* the verification, so the evidence you hand back is guaranteed to cover the exact code being returned — and comment cleanup comes *after*, where it can't disturb that check.
 
-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.
+1. **Review and fix the code** — follow [`code-review.md`](code-review.md). This is the only phase that changes behavior. Review catches what running can't — silent regressions, missed edge cases, leftover debug code, reuse or simplification — then you fix or flag each finding, and *the code is now frozen*. Size the review to the change: a quick check, not a second project. (Comments are **not** reviewed here — they get phase 3.)
+2. **Run the final verification** — apply the Gate Function fresh to the now-frozen code and present *that* output as your evidence. Because all code changes happened in phase 1, this check covers exactly what the user gets.
+3. **Review and clean the comments** — follow [`comment-review.md`](comment-review.md). This pass touches *only* comments, so it changes no behavior and needs **no re-verification**: delete narrative / step-by-step / ticket comments, keeping only true Explanation or exported-member Documentation, before the diff reaches a human.
+
+**Copy this checklist into your task tracker the moment you start finishing, and tick each box in order.** The ordering *is* the discipline — and an untracked checklist is one whose middle steps get skipped under momentum:
+
+```
+- [ ] Phase 1 — reviewed the CODE against intent, ranked findings, fixed/flagged each (per code-review.md); code is now frozen
+- [ ] Phase 2 — ran the final verification fresh on the frozen code, and presented that output as evidence
+- [ ] Phase 3 — reviewed the COMMENTS (per comment-review.md): deleted narrative / step-by-step / ticket comments, kept only true Explanation or exported Documentation
+- [ ] Surfaced integration options (merge / push+PR / leave as-is / discard) — did not merge or push on my own
+```
+
+The last box is its own gate; the section below is why it's never yours to skip.
 
 ---
 
@@ -69,7 +80,7 @@ Verified, reviewed work is still *your* checkpoint, not a decision to merge. Int
 | "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. |
+| "Tests pass, so we're done here" | Verification is one phase of finishing, not the whole sequence — review and fix the code, verify the frozen result, then clean the comments. |
 | "The user said ship it, so I'll just merge" | "Ship it" authorizes the user's choice, not a unilateral merge or push. |
 
 ---

package/skills/verifying-development-work/code-review.md

@@ -0,0 +1,68 @@
+# Reviewing the Code
+
+This is **phase 1** of the finishing sequence in [`SKILL.md`](SKILL.md) — the
+code review. Review and fix the *code* here. This is the only phase that changes
+behavior, so once you finish it the code is frozen.
+
+---
+
+## Size the review to the change
+
+Review depth matches the size and risk of the diff. A one-line fix gets a careful
+read and a moment's thought about what it could break; a new subsystem gets more.
+Don't run a heavyweight audit over a trivial change to look thorough — a review
+that's louder than the change it covers is the failure this guidance exists to
+prevent.
+
+Do the review however your harness makes natural — read the diff inline, or
+dispatch it to a general purpose subagent.
+
+---
+
+## Read the diff against intent
+
+Read the actual diff — not your memory of what you changed — against the plan or
+the request. Cite findings by `file:line` so each one is checkable. Look for:
+
+- **Intent alignment** — does the change do what was asked? Are deviations
+  deliberate improvements, or drift?
+- **Correctness** — bugs, off-by-ones, wrong conditions, mishandled `null`/empty.
+- **Error & edge cases** — failure paths, boundaries, and inputs the happy path skips.
+- **Reuse & simplification** — existing helpers ignored, needless abstraction,
+  code that could be plainer.
+- **Leftover scaffolding** — debug prints, commented-out code, dead branches,
+  silent regressions to nearby behavior.
+- **Tests** — do they exercise real behavior, and do they cover what changed?
+
+This is not an exhaustive checklist to march through — it's where real problems
+tend to hide. Spend attention where this particular diff warrants it.
+
+---
+
+## Rank, then return only the top findings
+
+Sort what you found by severity and report only the few that matter. The point of
+ranking is to *drop* noise, not to pad a list.
+
+| Severity | What belongs here |
+|----------|-------------------|
+| **Critical — must fix** | Bugs, security holes, data loss, broken functionality. |
+| **Important — should fix** | Missing behavior, weak error handling, test gaps, architecture problems. |
+| **Minor — nice to have** | Style, micro-optimizations, polish. |
+
+Report the most important handful. **Drop Minor nitpicks unless nothing more
+serious exists** — a pile of trivia buries the one finding that mattered and
+trains the reader to skim past your review. Don't manufacture findings to fill the
+tiers; "nothing critical, one important thing" is a complete and good result.
+Close with a one-line verdict.
+
+---
+
+## Then: address the findings — and freeze the code
+
+Fix or explicitly flag each code finding you kept. Any fix changes the code — so
+make all of those changes *now*, in this phase. When you're done, the code is
+**frozen**: nothing in the remaining phases touches behavior. Return to the
+finishing sequence in [`SKILL.md`](SKILL.md) and run the **final verification**
+(phase 2) on this frozen result — the check you hand back is then guaranteed to
+cover the exact code being returned.

package/skills/verifying-development-work/comment-review.md

@@ -0,0 +1,85 @@
+# Reviewing the Comments
+
+This is **phase 3** — the last step of the finishing sequence in [`SKILL.md`](SKILL.md).
+By now the code has been reviewed (phase 1), and verified (phase 2). The code is frozen;
+**this pass touches only comments.** That is the whole reason it comes last: a
+comment edit can't change behavior, so it can't invalidate the verification you
+just ran — there is nothing here to re-test. Do it as the final polish before the
+handoff.
+
+---
+
+## The comment-hygiene pass
+
+Review **every comment in the changed code** with one goal: **delete as many as
+possible.**
+
+This runs against your own instinct. Writing a comment feels like preserving the
+narrative — why this approach, what was tried, which ticket it traces to. But a
+human reading code finds it *very hard* to skip a comment; every one they hit,
+they stop and read. Narrative comments tax every future reader to record a story
+that belongs in the commit message or the PR, not the source. Left in, they
+become the thing the user has to delete by hand before merging — so delete them
+now, on their behalf.
+
+A comment survives only if it fits one of two categories **and** meets its bar:
+
+1. **Explanation.** Code that is genuinely hard to follow from reading it — a
+   subtle algorithm, a deliberate break from the usual pattern, a non-obvious
+   constraint. The comment fills the gap with an *evergreen* reason (true a year
+   from now, not "fixes the bug from Tuesday"). These are **extremely rare**:
+   well-written code is self-commenting, and a reader fluent in code can follow
+   even sophisticated paths when the code itself is clear. If the right fix is to
+   make the code clearer, do that instead of explaining unclear code.
+2. **Documentation.** A concise doc-style comment (jsdoc and equivalents) on an
+   **exported** member, where the text is surfaced by doc generators and editor
+   hints to readers who *don't* have the source in front of them. These almost
+   always earn their place. Keep them concise and evergreen, matching the
+   surrounding style; they may describe usage more freely since that's their job.
+
+**Everything else gets deleted — about 99.9% of the time.** The most common
+offender, and the one that feels most defensible, is **step-by-step narration**
+that walks through what the code already says — `// Step 1: lowercase`,
+`// now strip the accents`, `// finally, trim the dashes`. It reads as helpful
+structure, and *that feeling is the trap*: the numbered steps restate control
+flow the reader can already see in the code, so most such comments carry no
+information the line below them doesn't — they only add something else to read.
+"The steps make it easier to follow" is the rationalization to delete *through*,
+not act on; the code is the structure. Strip the narration and nothing is lost.
+The same goes for prose narrative ("first we… then we…"), time-sensitive comments
+(ticket numbers, "the previous solution…", "changed this because…"), and any
+comment that merely restates its line. A comment that fits neither surviving
+category, or fits one but misses its bar, is noise. **When in doubt, delete it.**
+A truly unique case might warrant a truly unusual comment — but treat that as the
+rare exception it is, not the default.
+
+```ts
+// BEFORE — every comment restates the line under it
+// Step 1: lowercase the title
+const lower = title.toLowerCase();
+// Step 2: replace whitespace runs with a single hyphen
+const hyphenated = lower.replace(/\s+/g, "-");
+
+// AFTER — the code already says all of that
+const lower = title.toLowerCase();
+const hyphenated = lower.replace(/\s+/g, "-");
+```
+
+**A kernel of value doesn't save the comment around it.** The hardest case is
+the *mixed* comment — mostly narration, with one genuinely useful clause buried
+in it (a real constraint, a non-obvious *why*). Keeping the whole block "because
+part of it is useful" is exactly how noise survives review: a reader will keep a
+comment that's 90% restatement for the sake of the 10% that matters. Don't.
+**Extract the useful part, delete the rest, and if what remains earns a comment,
+write it as a tight standalone one** — the kernel alone, not the narration that
+carried it. A four-line "Step 1… / Step 2 *(the one real reason)* / Step 3… /
+Step 4…" block collapses to a single comment stating that one reason, and the
+numbered narration is gone.
+
+---
+
+## Then: hand it back
+
+These were comment-only edits — they change no behavior, so there is **nothing to
+re-verify**: the verification from phase 2 still covers the code being returned.
+Return to the finishing sequence in [`SKILL.md`](SKILL.md) for the handoff.

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

@@ -2,19 +2,20 @@
 
 Committed reference output from a canonical eval run. Regenerate with
 `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/`.
+dispatch files, produced outputs) stays gitignored under `skills-workspace/`
+and is reclaimable by `evals:teardown` once promoted (this commit's marker).
 
 | Field | Value |
 |-------|-------|
-| Mode | new-skill |
-| Iteration | iteration-1 |
+| Mode | revision |
+| Iteration | iteration-6 |
 | Harness | claude-code |
 | Agent model | claude-sonnet-4-6 |
 | Judge model | claude-sonnet-4-6 |
-| Conditions | with_skill, without_skill |
-| Run timestamp | 2026-06-04T02:41:18.475Z |
+| Conditions | old_skill, new_skill |
+| Run timestamp | 2026-06-05T01:32:51.388Z |
 | Label | (none) |
-| Promoted from commit | 63629b4 |
+| Promoted from commit | 4d6276b |
 
 Files:
 - `benchmark.json` — aggregate pass-rate / duration / token deltas.