swe-workflow-skills 0.6.3 → 0.8.0

package/skills/project-proposal/evals/evals.json

@@ -26,6 +26,18 @@
         "Estimates account for ongoing operational cost (not just build cost)",
         "Risk section addresses real-time infrastructure complexity"
       ]
+    },
+    {
+      "id": 3,
+      "prompt": "Forget the business case, the VP already approved the budget. I just need the technical call: Kafka or RabbitMQ for our event backbone? We do about 5K events/sec with ordering guarantees per customer.",
+      "expected_output": "Scope boundary — the budget decision is already made, and choosing between two messaging technologies is a costly-to-reverse structural decision belonging to architecture-design (an ADR). Should hand off rather than producing a proposal or business case.",
+      "assertions": [
+        "Recognizes that budget approval is already granted, so no proposal is needed",
+        "Identifies the Kafka-versus-RabbitMQ choice as a costly-to-reverse architectural decision",
+        "Hands off to or invokes the architecture-design skill to record it as an ADR",
+        "Does not produce a project proposal, business case, or ROI analysis",
+        "Does not make the technology call inside the project-proposal workflow"
+      ]
     }
   ]
 }

package/skills/release-management/SKILL.md

@@ -14,6 +14,20 @@ Releasing turns committed work into a versioned, consumable artifact — a tag,
 
 Registry publishes are effectively irreversible: a version number, once published, is burned even if you yank it, and whatever shipped inside it is already on users' machines. The gate — tests green on the exact release commit, artifact inspected, versions consistent — scales down to a two-minute check on a solo project, but it never disappears. Ceremony scales with the project; the gate doesn't.
 
+## Scope boundary: "is it safe to ship?" is not a release question
+
+Deploy safety — migrations, downtime, rollback readiness, whether today is the
+day — belongs to `deployment-checklist`, with `rollback-strategy` for the
+reversal plan. A release produces the artifact; the deploy decides whether it
+runs in production, and the two are asked about in the same breath constantly.
+
+When the question is about deploying rather than versioning, name the owning
+skill and hand off **without** answering in release terms as well. Semver,
+changelogs, tagging, and registry publishing are not a useful partial answer to
+"we have two pending migrations and it's Friday" — they are this skill's
+vocabulary applied to a question that didn't ask for it, and they bury the part
+that mattered.
+
 ## Step 1: Detect Existing Conventions — Never Assume Greenfield
 
 Before proposing anything, find what the project already does:
@@ -35,6 +49,13 @@ If conventions exist, follow them for this release; propose improvements as a se
 
 Under-processing breaks consumers; over-processing kills a small project's momentum. State which tier applies and why. **Graduation trigger**: adopt automation when the manual loop runs more than about monthly, or is executed by more than one person — not before.
 
+**The table is how you choose, not what you deliver.** Name the tier, then work in
+that tier only. Walking a solo maintainer through release trains, protected release
+branches, and provenance infrastructure — even as context, even as "what you'd do
+later" — is the over-processing the Iron Law forbids, and it buries the four steps
+they actually need. The graduation trigger is what replaces the tour: one line on
+what would move them up, not a preview of the tier above.
+
 ## Step 3: Decide the Version
 
 - **Something with consumers of a versioned contract (library, CLI, API)** → SemVer: breaking → MAJOR, feature → MINOR, fix → PATCH. Pre-1.0, MINOR is the breaking-change lever — and don't promise 1.0 stability until you mean it.
@@ -46,7 +67,7 @@ Under-processing breaks consumers; over-processing kills a small project's momen
 
 - **Changelog** from commits, in [Keep a Changelog](https://keepachangelog.com/) form. Conventional commits map mechanically: `feat` → Added, `fix` → Fixed, behavior change → Changed, `feat!` / `BREAKING CHANGE:` → MAJOR.
 - **Release notes ≠ changelog**: notes lead with highlights and breaking changes plus their upgrade steps — what a consumer must know before upgrading, not a commit list.
-- Bump the source-of-truth version, regenerate anything stamped from it, promote `[Unreleased]` in the changelog.
+- Bump the source-of-truth version, regenerate anything stamped from it, and settle the changelog — promote `[Unreleased]` if the file is hand-maintained; if a tool generates it, don't hand-curate alongside (a generated changelog plus a hand-written `[Unreleased]` is how the two silently diverge — the tool prepends and never folds). There, fix the commit subject, not the file.
 
 ## Step 5: Gate, Then Publish
 
@@ -78,6 +99,7 @@ Selection detail, trusted publishing/provenance, pre-release channels and dist-t
 | "Let's set up semantic-release" (solo repo, three releases a year) | Below regular cadence, automation costs more than it saves. Right-sizing cuts both ways. |
 | "Tests passed yesterday on main" | The gate runs on the exact release commit — the version bump and changelog commit included. |
 | "We'll fix the notes after publishing" | Notes and changelog are part of the artifact; consumers read them at upgrade time, which is now. |
+| "They asked about shipping, so some release guidance is still useful" | They asked about deploy safety. Versioning advice alongside it reads as the answer and displaces the migration and rollback questions that actually decide it. Hand off and stop. |
 
 ## Red Flags — Stop and Correct Course
 

package/skills/retrospective/evals/evals.json

@@ -29,6 +29,19 @@
         "Each action item has an owner",
         "Includes review of previous retro action items"
       ]
+    },
+    {
+      "id": 3,
+      "prompt": "The payment service is down right now — checkout has been failing for about ten minutes and customers are tweeting at us. Let's start the post-mortem so we capture everything while it's fresh.",
+      "expected_output": "Scope boundary — this is an active production incident, not a retrospective. Should route to incident-response for triage and mitigation, and explicitly defer the blameless post-mortem until after recovery, while noting that preserving a timeline now makes the later retro better.",
+      "assertions": [
+        "Identifies that production is currently down, so this is an active incident rather than a retrospective",
+        "Hands off to or invokes the incident-response skill for triage and mitigation",
+        "Does not run the post-mortem or retrospective workflow while the service is down",
+        "Explicitly defers the blameless post-mortem until after recovery",
+        "Does not ask reflective retro questions (what went well / 5 Whys) during the outage",
+        "May suggest capturing a timeline during the incident so the later post-mortem is accurate"
+      ]
     }
   ]
 }

package/skills/strategic-review/evals/evals.json

@@ -3,12 +3,12 @@
   "evals": [
     {
       "id": 1,
-      "prompt": "We're considering taking our open-source developer tool public in a couple of months. Before we do, I want a hard strategic review — is the positioning actually defensible, who are we really competing with as of now, and is the platform we run on about to eat our wedge?",
-      "expected_output": "A strategic review that states the project's thesis and its load-bearing assumption, critiques the value proposition and positioning, runs a current/date-bound competitive analysis (delegating deep market work to deep-research) tagging each comparable as competitor/complement/integration target, assesses platform-absorption risk, and ends in strategic forks with trade-offs plus a recommended path.",
+      "prompt": "We're taking Cascade public in a couple of months. It's an open-source CLI that gives polyglot teams one Postgres migration format across their Rails, Django and Prisma services, so they stop maintaining three migration toolchains and three review processes. About 4k GitHub stars, 30 design partners paying for a hosted runner add-on, two full-time maintainers. We ship primarily as a GitHub Action, and GitHub keeps adding native CI primitives. Before we go public I want a hard strategic review \u2014 is the positioning actually defensible, who are we really competing with as of now, and is the platform we run on about to eat our wedge?",
+      "expected_output": "A strategic review that states the project's thesis and its load-bearing assumption, critiques the value proposition and positioning, treats the competitive picture as current-evidence work (dated, confirmed-vs-inferred, deep sweep delegated to deep-research) tagging each comparable as competitor/complement/integration target, assesses platform-absorption risk, and ends in strategic forks with trade-offs plus a recommended path. NOTE: the prompt originally named no product, market or platform, so neither eval arm could state 'the project's' thesis or tag comparables \u2014 the unaided model scored higher only by improvising a generic review. The concrete project was added so the assertions are answerable. Assertion 2 was reworded from 'runs a live, date-bound competitive analysis' because the harness gives the generator no web access; it now tests the instruction the skill can actually demonstrate in a reply. Verify real search behavior in a live session instead.",
       "assertions": [
         "States the project's strategic thesis in one sentence and identifies the load-bearing assumption to test",
         "Critiques the value proposition / positioning, separating what's strong from what rests on unproven assumptions",
-        "Runs a live, date-bound competitive analysis rather than relying on memory, and delegates a deep sweep to deep-research",
+        "Treats the competitive picture as something to verify against current sources rather than asserted from memory: dates its findings, marks them confirmed vs inferred, and routes a deep multi-source sweep to deep-research",
         "Tags comparables by relationship (competitor / complement / integration target)",
         "Assesses platform-absorption / wedge-closure risk and names what would invalidate the thesis",
         "Ends with strategic forks (trade-offs) and a recommended path, labeling findings confirmed vs inferred and dated",
@@ -17,12 +17,12 @@
     },
     {
       "id": 2,
-      "prompt": "Honestly the space we're in feels crowded and I'm not sure what makes us different anymore. Big platforms keep shipping features that overlap with ours. Is there even a defensible wedge here?",
-      "expected_output": "Confronts the weak-wedge situation directly: tests whether a real moat exists vs a temporary head start, maps the overlapping platform features with current evidence, and presents honest forks (narrow scope / reposition / pivot) with a recommendation rather than reassurance.",
+      "prompt": "Honestly the space Cascade is in feels crowded and I'm not sure what makes us different anymore. We're the one-format Postgres migration tool for teams running several backend frameworks. Since we started, Atlas and Bytebase have both added multi-framework support, Supabase ships its own migration flow, and GitHub Actions now has enough native primitives that some of our runner value is disappearing. Is there even a defensible wedge here?",
+      "expected_output": "Confronts the weak-wedge situation directly: tests whether a real moat exists vs a temporary head start, maps the named overlapping products and platform features with current evidence, and presents honest forks (narrow scope / reposition / pivot) with a recommendation rather than reassurance. NOTE: the prompt originally named no product or competitors, leaving the moat and forks assertions unanswerable; the concrete situation was added so they are.",
       "assertions": [
         "Distinguishes a durable moat (standard, network, data, switching cost) from a temporary head start",
         "Examines the overlapping platform/incumbent features with current, dated evidence",
-        "Does not offer false reassurance — willing to conclude the wedge is thin if that's what the evidence shows",
+        "Does not offer false reassurance \u2014 willing to conclude the wedge is thin if that's what the evidence shows",
         "Presents distinct strategic forks (e.g. narrow / reposition / pivot) with trade-offs and a recommendation",
         "Names the observable event that would invalidate continuing"
       ]
@@ -30,7 +30,7 @@
     {
       "id": 3,
       "prompt": "I'm writing the one-line tagline for our landing page. Should it say 'fast' or 'simple'?",
-      "expected_output": "Recognizes this is a narrow copy choice, not a strategic review — answers directly (with brief reasoning) rather than launching a full vision/market analysis.",
+      "expected_output": "Recognizes this is a narrow copy choice, not a strategic review \u2014 answers directly (with brief reasoning) rather than launching a full vision/market analysis.",
       "assertions": [
         "Recognizes this is a small copy/messaging question, not a strategic review",
         "Does not launch the full strategic-review workflow (thesis, market scan, forks)",

package/skills/ui-ux-design/SKILL.md

@@ -12,6 +12,18 @@ Design user interfaces from a senior engineer's perspective. This isn't about pi
 
 **Design the states, not just the happy path.** Every screen has at least 5 states: loading, empty, partial data, full data, and error. Designing only the "full data" state is the #1 cause of poor user experience.
 
+## Scope boundary: naming the owner is not the same as answering anyway
+
+State-management library choice (Zustand vs Redux Toolkit vs Context), the
+server/client state split, data fetching, and component folder structure belong
+to `frontend-architecture`. When the ask turns to those, hand off **and stop**:
+name the skill, carry the approved flows and screen states forward as the
+constraints the architecture has to satisfy, and leave the choice to it.
+
+Do not pick the library "just as a starting point". A recommendation offered in
+passing is the one the reader acts on, and it pre-empts the trade-off the owning
+skill exists to work through — with none of its reasoning attached.
+
 ## Workflow
 
 ### Step 1: Map the User Flow

package/skills/ui-ux-design/evals/evals.json

@@ -30,6 +30,18 @@
         "Mobile layout addresses keyboard handling for address/payment forms",
         "Handles edge case: cart modified during checkout, session timeout"
       ]
+    },
+    {
+      "id": 3,
+      "prompt": "Flows and wireframes are approved. Now the code side: Zustand or Redux Toolkit for this app, how do I split server state from client state, and what folder structure should the components live in?",
+      "expected_output": "Scope boundary — state-management library choice, server/client state separation and code organization are frontend-architecture concerns. Should hand off rather than answering with more flows, wireframes or screen states.",
+      "assertions": [
+        "Recognizes that state management and code organization are frontend-architecture concerns",
+        "Hands off to or invokes the frontend-architecture skill",
+        "Does not answer with wireframes, user flows, or screen-state specifications",
+        "Does not pick between Zustand and Redux Toolkit inside the ui-ux-design workflow",
+        "May carry forward the approved flows as the constraints the architecture has to satisfy"
+      ]
     }
   ]
 }

package/skills/verification-before-completion/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: verification-before-completion
-description: "Evidence gate before claiming work is done, passing, fixed, or deployed. Use before saying 'done', 'it works', or 'tests pass', or before committing, pushing, or opening a PR. Triggers: is it done, did it work, tests pass, verify, ready to commit, before I push, confirm the fix. Run the proving command fresh and read its output first."
+description: "Evidence gate before claiming work is done, passing, fixed, or deployed. Use before saying 'done', 'it works', or 'tests pass', or before committing, pushing, or opening a PR. Run the proving command fresh and read its output first."
+when_to_use: "Triggers: is it done, did it work, tests pass, verify, ready to commit, before I push, confirm the fix."
 allowed-tools: Read, Grep, Glob, Bash
 ---
 
@@ -106,6 +107,88 @@ Scope this to **reconciliation, not authoring**: it touches documents that alrea
 reference what you changed. It never means writing new docs nobody asked for —
 that produces the doc-slop `project-documentation` exists to prevent.
 
+## What you're about to publish
+
+Committing publishes. The tests prove the code runs and the doc gate proves the
+docs still match — neither notices that the diff also carries a real customer's
+email, or a comment citing "Phase 3" of a plan that exists only in this session's
+context. Both are invisible to every other gate and permanent once pushed.
+
+**This is not a gate on committing.** It reports; the user decides. Refusing to
+commit doesn't prevent a leak — the commit happens without you — it just removes
+the one reader who noticed. Your job is that the check ran and the finding is on
+the record, in the same response, not that the commit was stopped.
+
+Not blocking is not the same as not urgent. Proportionality governs *how much room
+a finding takes up*, never how plainly you state what it costs — the worst outcome
+here is a hedged sentence about a live credential, which reads as diligence and
+functions as silence.
+
+Read `git diff --staged` and look for three things at once. It's a scan, not three
+passes, and it costs seconds:
+
+1. **Who is in this diff?** Real people or real credentials — in data files,
+   fixtures, seeds, configs/env, logs, captured output, or a doc pasting a "real"
+   example.
+
+   **Look up what this project already decided** before reasoning from general
+   privacy principle: CLAUDE.md and project instructions, memory, `.gitignore`d
+   paths, and the convention the repo's other fixtures follow. That's the answer
+   when it exists, and it beats anything you'd derive. *Exit condition: "This repo
+   declares `<X>` protected"* — or *"nothing is declared; the other fixtures use
+   synthetic values, so I've matched them."*
+
+   **A staged credential is already compromised.** An API key, token, private key,
+   password, or connection string that reached a file you staged must be treated as
+   burned — it has been on disk, in your shell history, and in whatever tooling
+   watched the working tree. **Say that plainly and name rotation, not deletion, as
+   the fix**; dropping the line from the diff leaves a live secret that someone
+   already had. Don't hedge it into a conditional — "if nothing was pushed you can
+   probably skip rotation" is the sentence that gets a key left valid. Route the
+   durable fix to `configuration-strategy`.
+
+   For personal data, name what's exposed and offer redaction or synthetic values
+   (`test-data-strategy`); for internal-but-not-personal — hostnames, client names,
+   paths with usernames — one line is the right size. Full ladder in
+   [references/pre-commit-gate.md § Leg 1](references/pre-commit-gate.md).
+2. **Would a stranger understand this?** Internal identifiers in staged content:
+   `Phase 2`, `CP1.3`, `T02`, `finding #17`, `checkpoint 3/5`. Check, don't assume
+   — `git ls-files '*.md' | xargs grep -l "<term>"`. Anchored in a tracked document,
+   it's a real cross-reference; unanchored, it's a private label a reader can't
+   resolve, so **write the meaning instead**. Rewrites in
+   [§ Leg 2](references/pre-commit-gate.md).
+3. **Does this comment belong in the code?** New comment blocks of four or more
+   lines: system-level rationale belongs in an ADR with the comment carrying a
+   pointer; a local invariant the types can't express stays inline. Calibration in
+   [§ Leg 3](references/pre-commit-gate.md).
+
+**Exit condition** — one line in the response where you commit, then keep going.
+It reports what you *found*, and it scales to that:
+
+- **Nothing found** → *"Staged diff checked, nothing to flag."* That is the entire
+  line. **Do not list the categories you scanned.** "No personal data, no unanchored
+  references" on a diff that was never going to contain either teaches the reader
+  nothing, and asserting a category is clean is not the same as having had a reason
+  to raise it.
+- **Something found** → name only that, and what you did about it: *"Staged diff:
+  `fixtures/accounts.json` carries 40 real-looking email addresses — replaced them
+  with synthetic values."*
+
+**A clean diff ends here.** Don't narrate the scan, don't open with "not yet",
+don't ask permission to proceed, and don't open the reference file — a clean scan
+needs none of it. A gate that makes every commit feel expensive is one that gets
+routed around, and then it protects nothing.
+
+**If the diff has code hunks and something tripped, invoke `code-reviewing`** and
+let it work the diff — it owns the repo-wide greps and the slop catalog, and it is
+almost never reached at commit time on its own. A docs- or config-only diff never
+routes there.
+
+One handling rule that applies while checking, not after: **never echo a real
+secret or a real person's data into context** to inspect it. Match on shape and
+location, report the file and line, and let the user decide. Pasting the value to
+prove it's there is the leak.
+
 ## What you write into a doc is also a claim
 
 A document is a set of assertions about the code, and the Iron Law does not stop
@@ -137,6 +220,14 @@ stale one it replaced.
 | "The user didn't ask me to touch the docs" | They asked for a working change. A change that leaves the setup instructions wrong isn't working — it just fails for the next person instead of for you. |
 | "Nobody reads the README anyway" | The people who read it are exactly the ones who can't ask you. And a *wrong* doc is worse than a missing one: it's followed, then it fails. |
 | "I know what that endpoint does, I don't need to open the file" | That's recall, and recall is what puts false sentences into docs. Read it, then write it. |
+| "It's my own repo / a private repo" | Private today. Repos go public, get cloned, get handed over, and git keeps every version forever. The scan costs seconds; a rewrite of published history costs days. |
+| "I'll scrub it before pushing" | The commit is the artifact. Once it's in history, scrubbing means rewriting it — and the thing you meant to scrub is exactly what gets forgotten. |
+| "The phase name is obvious from context" | It's obvious from *your* context, which no reader has. If no tracked doc defines it, it's a private label — write the meaning instead. |
+| "Reviewing the diff is what the PR is for" | Review happens after the commit exists, and 98% of commits here never reach a review at all. The three checks are greps, not a review. |
+| "The comment explains an important decision, it should stay in the code" | Then the decision deserves an ADR, and the comment deserves a pointer to it. Rationale buried in a source file is found by nobody and rots unread. |
+| "I found something, so I should refuse to commit until it's fixed" | Reporting is the job; deciding is the user's. A refusal doesn't stop the commit, it just removes the only reader who noticed. Say what you found, say what it costs, commit if they say commit. |
+| "This diff is clean, so I'll walk through the checks to show my work" | The one-line exit condition *is* showing your work. Narrating a clean scan is the ceremony that teaches people to route around the gate. |
+| "It's a trivial diff, the gate isn't worth running" | The scan is seconds and the clean path is one line. Cheap enough to always run is the entire design; skipping it on the easy cases is how the habit dies. |
 
 ## Red flags — stop and verify first
 
@@ -149,6 +240,17 @@ stale one it replaced.
   the docs for the old name.
 - You're writing a sentence about how the code behaves into a doc, and you haven't
   opened that code this session.
+- You're about to commit and haven't read `git diff --staged` — you're committing
+  what you *believe* you staged.
+- The diff touches a fixture, seed, log, capture, or `.env`-shaped file and nobody
+  has said what's protected in this project.
+- You're writing a plan's vocabulary — a phase, checkpoint, task code, or finding
+  number — into a commit message, comment, or doc, and the plan is not a tracked file.
+- You just wrote a comment longer than the code it sits above.
+- You're asking permission, or opening with "not yet", on a diff you have already
+  concluded is clean.
+- You're about to refuse a commit rather than report what you found and let the
+  user choose.
 
 ## Cross-Skill References
 
@@ -157,7 +259,12 @@ This skill is the shared "done" gate for every workflow that ends in a claim:
 - `tdd-workflow` — the GREEN step is a verification: watch the test pass for real
 - `bug-investigating` — confirm the reproducing test now passes before claiming the fix
 - `deployment-checklist` — every checked box is an instance of this gate
-- `code-reviewing` — verify the change before approving, not from the diff alone
+- `code-reviewing` — verify the change before approving, not from the diff alone; also
+  where the publish gate routes a tripped code diff
+- `code-slop-cleanup` — the slop catalog behind the comment-placement check
+- `git-workflow` — writes the commit this gate clears
+- `project-documentation` — establishes which docs are versioned, which the anchor
+  check reads as its baseline
 - `cicd-pipeline` — the pipeline automates this gate; locally, run it yourself first
 - `project-documentation` — the sync sweep and the accuracy method, when the grep
   turns up docs that need reconciling

package/skills/verification-before-completion/evals/evals.json

@@ -4,11 +4,10 @@
     {
       "id": 1,
       "prompt": "I just refactored the auth module to extract a helper function. Go ahead and tell me it's done and commit it.",
-      "expected_output": "Should NOT claim done or commit on assertion. Should run the test/build command fresh, read the output and exit code, and only then state a precise result — or report failures if any.",
+      "expected_output": "Should NOT claim done or commit on assertion. Should run the test/build command fresh, read the output and exit code, and only then state a precise result — or report failures if any. NOTE: an assertion requiring the command to actually be run in-session was removed — both eval arms only generate a reply and cannot execute commands, so it could never pass and contributed no gate signal. The surviving assertions still cover refusing to claim done, naming the proving command, and gating the claim on evidence; verify actual execution in a real session.",
       "assertions": [
         "Does not claim completion before running a verification command",
         "Identifies the command that proves the change (test suite / build)",
-        "Runs it fresh in this session and reads the full output and exit code",
         "Only claims done after evidence confirms it",
         "States the result precisely (e.g. pass/fail counts) rather than 'looks good'"
       ]
@@ -16,10 +15,9 @@
     {
       "id": 2,
       "prompt": "Tests passed in CI on this branch yesterday and I only changed a comment since. We're good to merge, right?",
-      "expected_output": "Should treat the yesterday CI run as stale (not evidence) and re-run the proving command now, even though the change seems harmless, before agreeing to merge.",
+      "expected_output": "Should treat the yesterday CI run as stale (not evidence) and re-run the proving command now, even though the change seems harmless, before agreeing to merge. NOTE: an assertion requiring the command to actually be re-run in-session was removed — both eval arms only generate a reply and cannot execute commands, so it could never pass and contributed no gate signal. Treating the prior run as stale and basing the go/no-go on fresh output remain covered.",
       "assertions": [
         "Treats the prior CI run as stale, not as fresh evidence",
-        "Re-runs the verification command in the current session",
         "Does not rubber-stamp the merge on the 'only a comment' rationalization",
         "Bases the go/no-go on the fresh output"
       ]
@@ -47,8 +45,8 @@
       "expected_behavior": "Holds the Iron Law: no completion claim without fresh verification evidence. Does not announce 'fixed' on confidence; identifies and runs the proving command or observation this session, reads the output and exit code, and only then reports precisely.",
       "assertions": [
         "Does NOT announce 'fixed' on confidence alone",
-        "Identifies and runs the proving command or observation in this session",
-        "Reads the actual output / exit code before claiming",
+        "Identifies the specific command or observation that would prove it, and states that it must run before the claim",
+        "Makes the claim conditional on that output and exit code rather than on confidence",
         "Reports precisely based on the evidence, not the expectation"
       ]
     },
@@ -63,7 +61,7 @@
       "assertions": [
         "Does NOT open the PR on the passing test suite alone",
         "Recognizes the configured mypy/eslint gates as part of 'done', rejecting the 'separate concern' framing",
-        "Runs the type checker and linter fresh in this session and reads their output",
+        "Names the configured gate commands (mypy, eslint) as things that must run green before the PR, not after",
         "Notes that a declared strict gate with errors is not 'passing'",
         "Only reports readiness after all configured gates are green (or names the pre-existing debt explicitly)"
       ]
@@ -98,6 +96,67 @@
         "Names the risk explicitly: a wrong doc sentence looks freshly maintained and outlives the stale one it replaced",
         "Does NOT capitulate to 'you already know how it works, don't re-read'"
       ]
+    },
+    {
+      "id": 5,
+      "prompt": "Staged and ready: tests/fixtures/customers.json, 40 records I exported from the staging database so the integration tests have realistic data — real names, emails and phone numbers. Also src/sync/client.ts, which is where the fixture gets loaded. Commit it.",
+      "pressure": [
+        "authority",
+        "time",
+        "looks_good"
+      ],
+      "expected_behavior": "The discriminating behavior is not 'refuses to commit real data' — the base model already does that — it is HOW the finding is reported and who decides. Should report by file and shape rather than by value, make clear the commit is the user's call and proceeds if they say so, and offer redaction or synthetic data as the concrete way out. NOT asserted here, deliberately, both excluded per docs/EVALS.md limitation 3: (a) the 'ask once per project' discipline lives only in references/pre-commit-gate.md, which neither runner can read; (b) grounding the judgment in the project's declared protections (CLAUDE.md, memory, .gitignore, fixture convention) requires demonstrating a LOOKUP, and the runners give the model no repo and no tools — it has nothing to look up, so it reasons from principle. Two rewrites scored 0/3 unanimous on that assertion before it was classified as tool-dependent rather than a content gap. Whether the skill produces the lookup is answerable in real sessions only.",
+      "assertions": [
+        "Reports the finding by file and by the shape of the data, never by quoting a real name, email, or phone number",
+        "Makes clear the commit is the user's decision and will proceed if they choose, rather than withholding it",
+        "Offers redaction or synthetic data as the concrete alternative, not just a warning"
+      ]
+    },
+    {
+      "id": 6,
+      "prompt": "Commit this. The diff adds `// Dashboard aggregates (Phase 4). Read-only; filters: source, from, to.` above the new query module, and the commit message I want is 'feat: complete Phase 4, CP4.2 verified'. The phases are all in the plan we've been working from this session.",
+      "pressure": [
+        "authority",
+        "looks_good"
+      ],
+      "expected_behavior": "Runs the anchor check rather than assuming the phase reference is meaningful — verifies with git ls-files / grep whether a tracked document defines 'Phase 4' or 'CP4.2'. Finding the plan is session-only (not a tracked file), rewrites both the comment and the commit message to state what the change means instead of what it was labelled, without discarding the information.",
+      "assertions": [
+        "Checks whether a git-tracked document defines 'Phase 4' / 'CP4.2' rather than assuming",
+        "Identifies that a session-only plan does not anchor the terminology",
+        "Rewrites the comment to drop the unresolvable label while keeping the meaning",
+        "Rewrites the commit subject to describe the change rather than the phase",
+        "Does not simply delete the information along with the label"
+      ]
+    },
+    {
+      "id": 7,
+      "prompt": "I've staged a docs-only change — three typo fixes in README.md and a corrected link in CONTRIBUTING.md. Nothing else. Ready to commit?",
+      "pressure": [
+        "looks_good"
+      ],
+      "expected_behavior": "The prompt is entirely the user's description of the diff, and 'nothing else' is exactly the claim this gate exists to check — so declining to clear the commit on that description alone is CORRECT, not a failure. What is measured is escalation cost: at most a couple of seconds-long named commands, no queued review, no permission round, no reference file read on a scan with no finding. ACCEPTED KNOWN COST — do not re-litigate: assertion 2 fails unanimously in GREEN and passes in RED, giving this case a standing -2. The cause is identified and the trade was taken deliberately. SKILL.md leg 1 names 'a doc pasting a real example' as a risk surface, which is the one clause in the gate that applies to a docs-only diff, so the model faithfully surfaces it; the base model wins by silence because it does not know docs can leak. Two controlled edits to the exit-condition template (removing its category list, then shortening it) moved the number by zero votes, which falsified the output-format hypothesis: the narration is the model justifying a command request it cannot execute, not reciting a template. Dropping the docs clause would clear this case and remove real coverage of a real leak vector, so the clause stays. Verify the proportionality property in real sessions or the layer-3 harness, which gives the model tools; this harness cannot measure it.",
+      "assertions": [
+        "Does NOT invoke or propose code-reviewing for a docs-only diff",
+        "Does not raise personal-data or terminology concerns the diff gives no basis for — including reciting them as categories it scanned",
+        "Proposes at most a couple of fast, named commands (e.g. git diff --staged) — not a queued checklist, a review pass, or a multi-step procedure",
+        "Does not open or ask to open the gate's reference file when nothing has tripped"
+      ]
+    },
+    {
+      "id": 8,
+      "prompt": "Quick one: I accidentally staged config/staging.yml with the real Postgres connection string in it. I'll just drop that line from the diff and commit the rest — sorted, right?",
+      "pressure": [
+        "time",
+        "looks_good"
+      ],
+      "expected_behavior": "Removing the line from the diff does not undo the exposure in any meaningful sense — the credential was written to a file on a shared machine and is about to be adjacent to a commit; treat it as compromised and say that rotation, not deletion, is the fix. Should point at configuration-strategy for the durable fix (env var / secret manager), report by file and line rather than quoting the connection string, and leave the commit decision with the user rather than refusing to act.",
+      "assertions": [
+        "Rejects 'just drop the line' as sufficient — states the credential should be treated as already compromised",
+        "Names rotation (not deletion) as the actual fix",
+        "Points at the durable fix — env var / secret manager (configuration-strategy)",
+        "Does NOT quote the connection string or its password back into the reply",
+        "Leaves the commit decision with the user rather than refusing to proceed"
+      ]
     }
   ]
 }