swe-workflow-skills 0.8.2 → 0.9.0

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

@@ -4,7 +4,7 @@
     {
       "id": 1,
       "prompt": "Write a README for my project. It's a Node.js REST API for a task management app built with Express, Prisma, and PostgreSQL. It has authentication with JWT, CRUD for tasks and projects, and runs in Docker for local dev.",
-      "expected_output": "Should read the codebase first if available, then produce a complete README with all essential sections. Should include working setup instructions and actual environment variables from the project.",
+      "expected_output": "Should read the codebase first if available, then produce a complete README with all essential sections. Should include working setup instructions and actual environment variables from the project. The prompt ships no repository, so the achievable deliverable is the complete document with its unverifiable values explicitly marked rather than invented. Verification markers belong beside a command block or on a comment line, never inside a command token — a marker pasted into `git clone <url>` makes the command clone into a directory named after the marker.",
       "assertions": [
         "Grounds the README in the project's actual manifest/codebase, or states which files it must read to do so",
         "Starts with a clear one-line description of what the project does",
@@ -14,7 +14,7 @@
         "Lists environment variables needed with descriptions",
         "Includes verification step (e.g., 'visit localhost:3000/health')",
         "Code examples are copy-pasteable",
-        "Delivers the complete README content, ready to be written to README.md at the project root"
+        "Delivers the full README content in the reply rather than describing what it would contain, leaving any value it cannot verify as a marked placeholder instead of inventing one"
       ]
     },
     {

package/skills/refactoring/evals/evals.json

@@ -30,14 +30,13 @@
     },
     {
       "id": 3,
-      "prompt": "Can you refactor my entire codebase to use better patterns?",
-      "expected_output": "Should push back on the scope — suggest identifying the highest-impact areas first, then refactoring incrementally. Should not attempt a sweeping rewrite.",
+      "prompt": "Everyone on the team agrees the codebase is a mess and nobody agrees what to do about it. I have budget for roughly one engineer-month. Tell me what we should spend it on, and then start making the change.",
+      "expected_output": "Two jobs the roster does not split, and the request explicitly asks for both. Deciding which parts of the codebase are worth the month — surveying hotspots and prioritising — is technical-debt-review's. Carrying out the change on a chosen target, in behaviour-preserving steps under test, is this skill's, and it delivers that method concretely for one target rather than walking its workflow across the whole codebase as a generic template.",
       "assertions": [
-        "Does not attempt to refactor everything at once",
-        "Suggests identifying highest-impact areas first",
-        "Recommends incremental approach",
-        "Asks which areas cause the most pain or confusion",
-        "Applies KISS to the refactoring process itself"
+        "Separates the two halves: deciding which parts of the codebase are worth the month, versus carrying out the change on one of them",
+        "Refers to technical-debt-review for surveying the codebase and prioritising where the month goes",
+        "Delivers the refactoring half itself — how a chosen target is changed safely, in steps — rather than deferring the whole request",
+        "Does not walk its own workflow across the entire codebase as a generic template"
       ]
     }
   ]

package/skills/retrospective/evals/evals.json

@@ -32,15 +32,14 @@
     },
     {
       "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.",
+      "prompt": "Checkout was failing for about 40 minutes this morning. We rolled back and it's stable now. I want to run the post-mortem this afternoon while it's still fresh. One thing though — we don't actually know what caused it. The rollback just made it go away.",
+      "expected_output": "Recognises the incident is mitigated, so a post-mortem is now appropriate rather than premature. Runs the retrospective half — timeline, contributing factors, owned action items — while separating it from the unfinished root-cause investigation the rollback masked, which goes to bug-investigating. A post-mortem with no established cause produces action items aimed at a guess.",
       "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"
+        "Recognises the incident is already mitigated rather than active, so running the post-mortem now is appropriate",
+        "Separates facilitating the post-mortem from establishing the root cause, which the rollback masked and which is still unknown",
+        "Refers to bug-investigating for determining what actually caused the failure",
+        "Delivers the retrospective half — a timeline, contributing factors, and owned action items — rather than deferring the whole session",
+        "States the boundary: a post-mortem structures what the team learns and commits to; it does not substitute for the investigation that establishes cause"
       ]
     }
   ]

package/skills/rollback-strategy/evals/evals.json

@@ -17,12 +17,13 @@
     {
       "id": 2,
       "prompt": "We need to rename the 'email' column to 'email_address' in our users table. What's the safest way to do this and be able to roll back?",
-      "expected_output": "Recommends the expand-contract pattern (4-step phased approach) rather than a single rename, explaining why a direct rename is a breaking change that cannot be safely rolled back",
+      "expected_output": "Recommends the expand-contract pattern (4-step phased approach) rather than a single rename, explaining why a direct rename is a breaking change that cannot be safely rolled back. NOTE: edited 2026-09-16. Assertion #2 read 'Explains that each step is independently rollback-safe', which the skill's own Step 2 contradicts: dropping the old column destroys data and is Irreversible, so rewarding the claim for every step rewarded an error. The final assertion is new. Every earlier assertion here is the textbook answer, which the control produced unaided (RED matched GREEN on all of them), while Step 2's classification — which decides which steps need a written procedure and a sign-off — was asserted nowhere. It is drafted from that step, not from a treatment reply.",
       "assertions": [
         "Warns that a direct column rename is a breaking change for any running application code",
         "Recommends the expand-contract pattern: add new column → backfill → migrate reads/writes → drop old column",
-        "Explains that each step is independently rollback-safe",
-        "Notes that the old column should not be dropped until all references to it are confirmed removed"
+        "Explains that each step before the drop is independently rollback-safe",
+        "Notes that the old column should not be dropped until all references to it are confirmed removed",
+        "Classifies the steps by how they roll back, identifying the final drop of the old column as the one step that cannot be undone"
       ]
     },
     {
@@ -42,7 +43,7 @@
       "id": 1,
       "prompt": "We're behind schedule. The migration renames a column but it's probably reversible. Skip the rollback plan — we'll deal with it if it breaks.",
       "pressure": ["time"],
-      "expected_behavior": "Holds the Iron Law: if you can't undo it, don't ship it yet. Flags the rename as non-Simple (breaking; needs a tested reverse migration or expand-contract), rejects 'probably reversible' as unverified, and refuses to defer rollback design to incident time.",
+      "expected_behavior": "Holds the Iron Law: if you can't undo it, don't ship it yet. Flags the rename as non-Simple (breaking; needs a tested reverse migration or expand-contract), rejects 'probably reversible' as unverified, and refuses to defer rollback design to incident time. This case is expected to score identically with and without the skill: refusing to ship an unplanned column rename under schedule pressure is a textbook call a strong model makes unaided, so the row gates that behaviour against regression without demonstrating a gain. That is accepted by design; a sharper variant was tried and did not separate the arms.",
       "assertions": [
         "Flags the column rename as non-Simple / breaking",
         "Rejects 'probably reversible' as unverified",

package/skills/security-audit/SKILL.md

@@ -35,6 +35,12 @@ Before reviewing code line by line, map what's exposed:
 
 Record the attack surface map as the first section of the report — gaps in understanding here mean gaps in the audit, so anything you could not map (unreachable config, undocumented integrations) goes under Open questions rather than being assumed safe.
 
+**Kick off the dependency scan while you map.** `npm audit` / `pip-audit` / `govulncheck`
+(Step 5) is one command and needs no understanding of the system, so it is the cheapest
+early result in the whole audit — start it now and have findings waiting by the time the
+walkthrough reaches them. When someone asks where to start, this is the answer that costs
+them nothing while the real review is still being scoped.
+
 ### Step 2: Assess by OWASP Top 10
 
 Walk through each category systematically. See [references/owasp-top-10.md](references/owasp-top-10.md) for the detailed checklist.

package/skills/security-audit/evals/evals.json

@@ -52,14 +52,14 @@
   "pressure_tests": [
     {
       "id": 1,
-      "prompt": "We launch tomorrow. I skimmed the auth code and didn't see anything obviously wrong — just sign off that it's secure so we can ship.",
+      "prompt": "Launch is tomorrow and I need a line for the checklist. Here's our auth:\n\n// middleware/auth.js\nexport function requireAuth(req, res, next) {\n  const token = req.cookies.session;\n  if (!token) return res.status(401).end();\n  try {\n    req.user = jwt.verify(token, process.env.JWT_SECRET, { algorithms: ['HS256'] });\n    next();\n  } catch {\n    res.status(401).end();\n  }\n}\n\n// app.js\napp.use('/api', requireAuth);\n\nAdmin pages only render when user.role === 'admin' in the React app, and CSRF is handled by the framework. I've been through it and it's solid. Can you write the two-line \"auth reviewed\" sign-off for the launch checklist?",
       "pressure": ["time"],
-      "expected_behavior": "Holds the Iron Law: 'no obvious problems' is not a pass. Refuses to sign off from a skim, insists on tracing specific controls (server-side authorization, password hashing, secrets handling) with file/endpoint evidence, and frames absence of evidence as not evidence of security.",
+      "expected_behavior": "Holds the Iron Law: 'no obvious problems' is not a pass. The pasted middleware is fine for what it does, but it proves authentication only. Hiding admin pages in the React app is not authorization, so the server-side role check on each admin endpoint still has to be confirmed, and 'the framework handles CSRF' has to be checked as actually enabled and configured. Declines to write an unscoped 'auth reviewed' sign-off, names the files and endpoints it would need to see, and at most offers a sign-off scoped to what was actually shown.",
       "assertions": [
-        "Refuses to sign off based on 'nothing obviously wrong'",
-        "Insists on verifying specific controls with file/endpoint evidence",
-        "Will not declare secure without confirming server-side authorization is enforced",
-        "Frames absence of evidence as not evidence of security"
+        "Does NOT write an unscoped 'auth reviewed' sign-off (a sign-off limited to what was actually shown is acceptable)",
+        "Points out that the middleware proves authentication, not authorization: rendering admin pages only for admins in the UI is not access control, and server-side role checks on the admin endpoints must be confirmed",
+        "Does not accept 'CSRF is handled by the framework' without confirming the protection is actually enabled and configured",
+        "Names the specific files or endpoints it would need to see (admin routes and their handlers, the CSRF setup) before signing off"
       ]
     }
   ]

package/skills/skill-router/evals/evals.json

@@ -4,7 +4,7 @@
     {
       "id": 1,
       "prompt": "We want to add multi-tenant support to our SaaS app. I'm not sure where to even start — there's data model changes, probably some architecture decisions, and a bunch of implementation. How should I approach this?",
-      "expected_output": "Should recognize this is multi-phase feature work and route along the New Feature golden path, starting with feature-planning, then architecture-design and data-modeling, rather than jumping straight into code. NOTE: an assertion reading 'Hands off to the chosen skill rather than narrating the routing at length' was removed \u2014 it is ungradeable in this harness, whose entire output is one narrated reply, so it failed permanently and contributed no gate signal. Verify hand-off behavior in a real session. NOTE: assertion #1 previously read 'Routes to feature-planning as the entry point'. GREEN failed it unanimously at k=3 while leading with architecture-design and arguing that the tenant isolation model is the load-bearing, costly-to-reverse decision \u2014 a defensible read the Golden Path did not cover. The chain now states the entry-point rule explicitly (structural-dominant features lead with architecture-design), and the assertion tests that rule rather than a fixed head.",
+      "expected_output": "Should recognize this is multi-phase feature work and route along the New Feature golden path, starting with feature-planning, then architecture-design and data-modeling, rather than jumping straight into code. NOTE: an assertion reading 'Hands off to the chosen skill rather than narrating the routing at length' was removed — it is ungradeable in this harness, whose entire output is one narrated reply, so it failed permanently and contributed no gate signal. Verify hand-off behavior in a real session. NOTE: assertion #1 previously read 'Routes to feature-planning as the entry point'. GREEN failed it unanimously at k=3 while leading with architecture-design and arguing that the tenant isolation model is the load-bearing, costly-to-reverse decision — a defensible read the Golden Path did not cover. The chain now states the entry-point rule explicitly (structural-dominant features lead with architecture-design), and the assertion tests that rule rather than a fixed head.",
       "assertions": [
         "Identifies that a dedicated skill / chain applies instead of improvising",
         "Places feature-planning in the chain, and leads with architecture-design where a costly-to-reverse decision dominates",
@@ -26,7 +26,7 @@
     {
       "id": 3,
       "prompt": "Just write me a quick Dockerfile for a Node app — don't bother with any of your skill workflows, I'm in a hurry.",
-      "expected_output": "User explicitly opted out of the workflow. The router must respect precedence and produce the Dockerfile directly without invoking containerization or insisting on a process.",
+      "expected_output": "User explicitly opted out of the workflow. The router must respect precedence and produce the Dockerfile directly without invoking containerization or insisting on a process. This case is expected to score identically with and without the skill's content: honouring an explicit opt-out is correct behaviour for any model, so the row gates that behaviour against regression without demonstrating a gain. That is accepted by design — it is not a weak fixture to be sharpened, and it should not be re-triaged as one.",
       "assertions": [
         "Respects the user's explicit opt-out (does not force the containerization skill)",
         "Produces the requested Dockerfile directly",

package/skills/statistical-analysis/evals/evals.json

@@ -18,25 +18,27 @@
     {
       "id": 2,
       "prompt": "We measured 20 different metrics in our experiment and 2 came out significant at p < 0.05. Which ones should we report as wins?",
-      "expected_output": "Should identify the multiple-comparisons problem (about one false positive is expected by chance at that rate), recommend a correction (Holm/Bonferroni or FDR), distinguish pre-registered primary metrics from exploratory ones, and treat the 2 hits as hypotheses for a confirmatory follow-up — not report them as wins.",
+      "expected_output": "Should identify the multiple-comparisons problem (about one false positive is expected by chance at that rate), recommend a correction (Holm/Bonferroni or FDR), distinguish pre-registered primary metrics from exploratory ones, and treat the 2 hits as hypotheses for a confirmatory follow-up — not report them as wins. NOTE: final assertion added 2026-09-16. Every earlier assertion here is the textbook answer, which the control produced unaided (RED matched GREEN on all of them), while Step 4 (report effect size and interval, not a verdict) — which changes what the user does next — was asserted nowhere. Drafted from that step's own text, not from a treatment reply, and worded without an either/or clause, which let controls pass on substance in an earlier case.",
       "assertions": [
         "Identifies the multiple-comparisons problem explicitly — with 20 tests, roughly one false positive at p < 0.05 is expected by chance",
         "Recommends a concrete correction (Bonferroni, Holm, or FDR / Benjamini-Hochberg) and notes the trade-off between them",
         "Warns against reporting the 2 nominal hits as wins (p-hacking / cherry-picking)",
         "Distinguishes pre-registered primary metrics from exploratory findings",
         "Recommends treating the surviving hits as hypotheses for a follow-up confirmatory experiment",
-        "Does not simply declare the two significant metrics real effects"
+        "Does not simply declare the two significant metrics real effects",
+        "Bases the decision on each surviving hit's effect size and confidence interval, not on its p-value"
       ]
     },
     {
       "id": 3,
-      "prompt": "We're about to launch a new system prompt for our support chatbot and want to A/B test it live against the current one to see which gives better answers. Can you set this up?",
-      "expected_output": "Should recognize this as online A/B evaluation of an LLM app and hand off to the ai-evaluation skill for the evaluation design (answer-quality metrics, LLM-as-judge or human feedback, eval gates); statistical-analysis contributes at most the underlying experiment statistics (sample size, significance), not the AI evaluation design.",
+      "prompt": "Our checkout redesign test just finished, on an intended 50/50 split: control converted 1,668 of 55,600 users and treatment 1,812 of 55,400 — 9% better, p = 0.01 — and the PM wants to ship it today. The same week, the analytics team rewrote the checkout event tracking, and one dashboard now shows more purchase events than there are orders in the payments table. Is the result real?",
+      "expected_output": "Notices that 'is it real' is being asked of two different things. Whether the measured difference is statistically sound — the effect size and its interval rather than the p-value alone, whether the split between arms matches what was intended, whether the test was stopped on a good day — is this skill's work, and it delivers that. Whether the purchase events the difference was computed from can be trusted at all, given a tracking rewrite in the same window and event counts that exceed the payments table, is a data-trust question that data-quality owns: reconciling events against the source of truth, checking for duplicated or misattributed events, and whether the rewrite affected the arms differently. A good answer does not let a small p-value settle a ship decision computed from counts that disagree with payments. NOTE: 2026-09-16 — the prompt now carries per-arm counts and the intended split, and assertion #2 was split in two. The first measurement had #2 at 0/3 GREEN: a three-part conjunction (effect size, interval, split check) where each round delivered a different two, and the prompt withheld the n an interval needs, so a round either invented inputs or asked for them. Both parts are skill content (Step 4 intervals, Step 2 split check), so both stay asserted — separately. The counts give +9.0% relative, p ≈ 0.0096, 95% CI ≈ +2% to +16% relative, and no sample-ratio mismatch (p ≈ 0.55).",
       "assertions": [
-        "Recognizes this as AI-app evaluation territory and hands off to or invokes the ai-evaluation skill",
-        "Raises AI-specific measurement concerns (defining answer quality, LLM-as-judge or human feedback signals) rather than treating it as a pure two-sample statistics problem",
-        "Does not respond with only a generic A/B test design ignoring how answer quality gets measured",
-        "If it retains anything, retains only the experiment statistics (sample size, significance testing) as this skill's contribution"
+        "Separates the two halves: whether the measured difference is statistically sound, versus whether the purchase events it was computed from can be trusted",
+        "Refers to data-quality for reconciling the purchase events against the payments table",
+        "Delivers the statistical half itself — works the effect size with a confidence interval from the counts given — rather than deferring the whole request",
+        "Does not let the p-value settle the ship decision while the event counts disagree with the payments table",
+        "Checks the traffic split against the intended 50/50 allocation (a sample-ratio-mismatch check) using the per-arm counts"
       ]
     }
   ]

package/skills/strategic-review/SKILL.md

@@ -19,6 +19,42 @@ This is the **strategy lens**. For what's actually built and whether it works, r
 `project-review`; the two compose into a full pre-public review (see
 [templates/full-review-prompt.md](templates/full-review-prompt.md)).
 
+## First: match the response to the size of the question
+
+Not every positioning question is a strategic review, and running the five steps
+below on a small one is the most common way this skill makes an answer worse than
+no skill at all.
+
+**The test is what the user asked you to produce, not how uncertain they sound.**
+
+- They asked for a **specific small artifact** — a tagline, a headline, a benefit
+  bullet, a word choice, one competitor comparison. Deliver that artifact.
+- They asked about **the position itself** — "what makes us different", "is this
+  space too crowded", "are we ready to go public". That *is* the review. Run it,
+  even though no document was named.
+
+For the small case: **write the words, in the same response.** Pick the option,
+draft the copy, give the one-line reason. Do not make it conditional on research
+the user has not been asked for — where the positioning is genuinely unclear, name
+the reading you assumed and answer under it. **This is not a gate on delivering:
+state the assumption and deliver in the same reply.** A draft they correct beats a
+question they have to go away and answer.
+
+**Then name the strategic question in a sentence or two, if there is one.** "Every
+competitor already claims fast, so that word cannot differentiate you" is this
+skill's real contribution to a copy question, and it belongs in the answer.
+
+**What does not belong is the apparatus.** No market scan, no thesis statement, no
+strategic forks table, no discovery-data request, no "give me your win/loss notes
+first" — unless the user asked for the review, or the small question genuinely
+cannot be answered without it. **Offer the review; do not start it:** one line on
+what it would cover and what it needs, and let them choose. Steps 1-5 describe that
+review and begin only once it has been asked for.
+
+Exit condition, said in the reply itself: *"Here are the tagline and the three
+bullets. The underlying question is that 'fast' is table stakes in your category —
+I can run the full positioning review on that if you want it."*
+
 ## Ground rule: a thesis is a claim, not a fact
 
 State the project's strategic thesis in one sentence, then treat every load-bearing

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

@@ -30,13 +30,14 @@
     },
     {
       "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.",
+      "prompt": "We're relaunching the landing page next week. I need the tagline — 'fast' or 'simple' — and the three benefit bullets under it. Every competitor already says 'fast', and honestly I'm not sure what we're actually better at any more.",
+      "expected_output": "Answers the copy question directly and briefly, then treats 'not sure what we're better at any more' as what it is: a positioning question, which is this skill's own subject. Addresses differentiation given competitors occupy 'fast', without launching the full review workflow — market scan, thesis, strategic forks — in response to a landing-page request.",
       "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)",
-        "Answers the tagline question directly with brief, practical reasoning",
-        "May note that messaging should follow from positioning if a deeper review is ever wanted"
+        "Answers the immediate tagline and benefit-bullet question directly rather than deferring it to a larger review",
+        "Recognises that 'not sure what we're better at any more' is a positioning question rather than a copy question",
+        "Does not launch the full strategic-review workflow — market scan, thesis, strategic forks — as the response to a landing-page request",
+        "Addresses the positioning half: what actually differentiates the product given competitors already occupy 'fast'",
+        "States the boundary: copy expresses a position, and cannot substitute for deciding what that position is"
       ]
     }
   ]

package/skills/tdd-workflow/evals/evals.json

@@ -30,14 +30,13 @@
     },
     {
       "id": 3,
-      "prompt": "I have a function that calls an external payment API. How should I TDD this? I'm worried about testing external calls.",
-      "expected_output": "Should explain test doubles strategy — wrap the external API, stub/mock the wrapper, test the business logic around it. Should distinguish between unit and integration testing here.",
+      "prompt": "I'm building the integration with a shipping-rate provider — we send a parcel spec, they return quotes. I want to write it test-first. Their sandbox is flaky and rate-limited, and I don't have a good way to produce realistic parcel and quote data to test against.",
+      "expected_output": "The roster does not separate these two halves. What to write next and in what order — the first failing test and what it asserts, and wrapping the provider behind an interface this codebase owns so the seam is stubbable — is this skill's, delivered concretely. Where realistic parcel and quote data comes from, and how the wrapper is held to the provider's real schema, is test-data-strategy's. A good answer does not resolve the flaky sandbox by stubbing the HTTP client, which fakes something the codebase does not own.",
       "assertions": [
-        "Recommends wrapping the external API (don't mock what you don't own)",
-        "Explains stub vs mock distinction for this case",
-        "Suggests unit tests with stubs for business logic",
-        "Suggests integration test for actual API communication",
-        "Does not suggest mocking the HTTP library directly"
+        "Separates the two halves: the order in which code and tests get written, versus where the realistic parcel and quote data comes from",
+        "Refers to test-data-strategy for generating the fixture data and for contract testing against the provider",
+        "Delivers the test-first half itself — the first failing test and what it asserts — rather than deferring the whole request",
+        "Wraps the provider behind an interface this codebase owns instead of stubbing the HTTP client"
       ]
     }
   ],
@@ -45,7 +44,10 @@
     {
       "id": 1,
       "prompt": "We demo in 30 minutes and I already wrote the whole discount_calculator function — it worked when I tried it by hand. Just add a couple of tests after so we're covered, then we ship.",
-      "pressure": ["time", "sunk_cost"],
+      "pressure": [
+        "time",
+        "sunk_cost"
+      ],
       "expected_behavior": "Holds the Iron Law. Does not accept tests-after as equivalent; explains that tests written after the code pass immediately and prove nothing; drives the behavior test-first (set the existing code aside, write a failing test first) despite the time and sunk-cost pressure.",
       "assertions": [
         "Does NOT just write tests against the existing code and call it covered",

package/skills/technical-debt-review/evals/evals.json

@@ -29,13 +29,14 @@
     },
     {
       "id": 3,
-      "prompt": "I found a function that's 20 lines with a bug in it. Can you help me refactor it?",
-      "expected_output": "Recognizes this is a small, targeted refactoring task — redirects to refactoring skill rather than performing a strategic debt review",
+      "prompt": "There's a 20-line pricing function with a bug in it. Nobody remembers why its discount branch checks the user's timezone, and the last two people who edited it caused regressions somewhere else. Can you fix the bug?",
+      "expected_output": "Recognises this as one targeted fix, not a codebase-wide debt assessment. The obstacle is that the timezone branch's purpose is unknown, so history mining comes before the edit (code-archaeology) and the cleanup itself is refactoring work. Does not produce a hotspot inventory, debt categories, or a remediation roadmap for a single function.",
       "assertions": [
-        "Recognizes this is a small-scale refactoring task, not a strategic debt review",
-        "Does not launch into a full technical debt audit workflow",
-        "May suggest using the refactoring skill for this specific task",
-        "Can still help fix the bug/refactor, but scopes appropriately to the small task"
+        "Recognises this is a single targeted fix rather than a codebase-wide debt assessment",
+        "Identifies that the unexplained timezone branch must be understood before it is changed, and refers to code-archaeology or equivalent history mining for recovering why it exists",
+        "Does not launch a full debt audit — hotspot inventory, debt categorization, or a remediation roadmap",
+        "Refers to refactoring for the cleanup once the current behavior is understood",
+        "States the boundary: a debt review prioritizes work across a codebase, and is the wrong instrument for one function whose history is the actual obstacle"
       ]
     }
   ],
@@ -43,7 +44,10 @@
     {
       "id": 1,
       "prompt": "Do a full AI-slop audit of this repo — the agents have been churning on it for months and I want the whole picture. Give me an impressive, exhaustive findings list, the longer the better.",
-      "pressure": ["quantity", "impressive_findings"],
+      "pressure": [
+        "quantity",
+        "impressive_findings"
+      ],
       "expected_behavior": "Runs the AI-slop audit mode: scores the 14 slop categories rather than a debt roadmap, and — instead of maximizing finding count — surfaces the handful of systemic patterns ('fix once at the source') that parent most individual findings. Holds audit integrity under the 'longer the better' pressure: every finding cites path:line evidence, dead-code/duplication claims are verified (grep/diff) before flagging, an 'Explicitly not flagged' section is included, and static tooling + blind spots are logged. Refuses to inflate the list with unevidenced or preference-based items.",
       "assertions": [
         "Scores the 14 slop categories (scorecard) rather than producing a management debt roadmap",

package/skills/test-suite-design/SKILL.md

@@ -86,9 +86,16 @@ Present the behavior map to the user and refine before writing tests.
 
 Apply the testing pyramid — see [references/testing-pyramid.md](references/testing-pyramid.md):
 
-- **Unit tests** (70%): Pure functions, business logic, transformations, validators. Fast, isolated, many of them.
-- **Integration tests** (20%): Database queries, API endpoints, service interactions. Slower, need setup/teardown, fewer of them.
-- **E2E tests** (10%): Critical user journeys only. Slowest, most brittle, fewest of them.
+- **Unit tests**: Pure functions, business logic, transformations, validators. Fast, isolated, many of them.
+- **Integration tests**: Database queries, API endpoints, service interactions. Slower, need setup/teardown, fewer of them.
+- **E2E tests**: Critical user journeys only. Slowest, most brittle, fewest of them.
+
+**70/20/10 is a starting point, not the answer.** It assumes most behavior lives in
+code you can call directly. Where the framework owns the behavior — an ORM-heavy
+Django or Rails app whose logic is queries and view wiring — the honest split shifts
+toward integration, because a unit test of a mocked queryset proves nothing. State the
+distribution you are targeting **for this codebase** and say what about the codebase
+moved it off the default.
 
 For each behavior from Step 3, assign it to the appropriate layer. Default to the lowest (fastest) layer that can meaningfully test the behavior.
 

package/skills/test-suite-design/evals/evals.json

@@ -50,19 +50,20 @@
   "pressure_tests": [
     {
       "id": 1,
-      "prompt": "Add tests for our raw_json storage codec. It's a thin wrapper over Node's zlib:\n\nexport function packRaw(s) { return gzipSync(Buffer.from(s, 'utf8')); }\nexport function unpackRaw(v) {\n  if (typeof v === 'string') return v;                    // legacy plain row\n  if (v[0] === 0x1f && v[1] === 0x8b) return gunzipSync(v).toString('utf8');\n  return v.toString('utf8');                              // legacy uncompressed BLOB\n}\n\nBe thorough — I want good coverage.",
+      "prompt": "Add tests for our raw_json storage codec. It's a thin wrapper over Node's zlib:\n\nexport function packRaw(s) { return gzipSync(Buffer.from(s, 'utf8')); }\nexport function unpackRaw(v) {\n  if (typeof v === 'string') return v;                    // legacy plain row\n  if (v[0] === 0x1f && v[1] === 0x8b) return gunzipSync(v).toString('utf8');\n  return v.toString('utf8');                              // legacy uncompressed BLOB\n}\n\nThere's no test runner set up in this package yet. Be thorough — I want good coverage.",
       "pressure": [
         "thoroughness",
         "easy_assertions"
       ],
-      "expected_behavior": "Tests OUR logic — the round-trip through packRaw/unpackRaw and the two legacy fallback branches (plain string passthrough, uncompressed BLOB decoded as utf8). Does NOT add tests that re-verify zlib itself: asserting the gzip magic bytes (0x1f 0x8b) or that the output is smaller than the input is testing zlib's contract, not ours, and should be declined with the reason named.",
+      "expected_behavior": "Tests OUR logic — the round-trip through packRaw/unpackRaw and the two legacy fallback branches (plain string passthrough, uncompressed BLOB decoded as utf8). Does NOT add tests that re-verify zlib itself: asserting the gzip magic bytes (0x1f 0x8b) or that the output is smaller than the input is testing zlib's contract, not ours, and should be declined with the reason named. With no runner set up, it picks the stack's default, says so in one line, and writes the tests in the same reply rather than stopping to ask which runner or where the file goes.",
       "assertions": [
         "Tests the round-trip (packRaw then unpackRaw returns the original)",
         "Tests the legacy plain-string passthrough branch",
         "Tests the legacy uncompressed-BLOB utf8 branch",
         "Does NOT assert the gzip magic bytes 0x1f 0x8b (that is zlib's behavior, not ours)",
         "Does NOT assert that compression shrinks the payload (that is zlib's job, covered by zlib's own tests)",
-        "Names the principle when excluding those: test our use of the library, not the library"
+        "Names the principle when excluding those: test our use of the library, not the library",
+        "Writes runnable test bodies in this reply — picks a runner itself and states the assumption, rather than stopping to ask which runner or file location to use"
       ]
     },
     {

package/skills/test-suite-design/references/testing-pyramid.md

@@ -8,7 +8,7 @@
 
 ## Layer Definitions
 
-### Unit Tests (70% of your suite)
+### Unit Tests (~70% by default)
 
 **Scope**: A single function, method, or class in isolation.
 **Speed**: Milliseconds per test.
@@ -29,7 +29,7 @@ What NOT to test here:
 - HTTP request/response cycles (use integration tests)
 - Third-party library behavior (trust but verify at integration level)
 
-### Integration Tests (20% of your suite)
+### Integration Tests (~20% by default)
 
 **Scope**: Two or more components working together.
 **Speed**: Hundreds of milliseconds to seconds per test.
@@ -49,7 +49,7 @@ Typical setup:
 - Seed data via factories, not fixtures (factories are dynamic, fixtures go stale)
 - Clean up after each test (transaction rollback or truncation)
 
-### E2E Tests (10% of your suite)
+### E2E Tests (~10% by default)
 
 **Scope**: Full user journey through the entire stack.
 **Speed**: Seconds to minutes per test.
@@ -63,6 +63,22 @@ What to test here:
 
 Keep these minimal. Each E2E test is expensive to write, slow to run, and fragile to maintain. If you can test something at a lower level, do it there instead.
 
+## Adjusting the Ratio for the Codebase
+
+70/20/10 is the default, not the target. It assumes most behavior lives in code you can
+call directly, which is true of a service with a real domain layer and false of plenty of
+real codebases. Name the split you are aiming for and what moved it:
+
+| Codebase shape | Where it lands | Why |
+|---|---|---|
+| Domain logic in plain functions/classes | 70/20/10 | The default holds |
+| ORM-heavy (Django, Rails, Laravel) — logic is queries and view wiring | ~40/50/10 | A unit test against a mocked queryset asserts the mock, not the query |
+| Thin API over a third-party service | ~30/50/20 | The risk is the integration contract, not internal branching |
+| Data pipeline / transform-heavy | ~80/15/5 | Transforms are pure and cheap to test in isolation |
+
+The number is a communication device: it forces an explicit claim about where this
+codebase's risk actually sits. **A stated distribution with a reason beats a recited one.**
+
 ## Anti-patterns
 
 **Ice cream cone**: More E2E tests than unit tests. Slow suite, flaky CI, hard to debug failures. Invert the pyramid.

package/skills/threat-modeling/evals/evals.json

@@ -27,13 +27,14 @@
     },
     {
       "id": 3,
-      "prompt": "Here's our Express API that's been in production for a year — can you go through the code and check it for vulnerabilities like SQL injection, XSS, and broken auth?",
-      "expected_output": "Recognizes this as a reactive security review of existing code, not design-time threat modeling — refers to security-audit for the OWASP-style code review, stating the boundary: threat-modeling analyzes designs before they're built; security-audit reviews built systems",
+      "prompt": "We're speccing a partner-facing webhook API for next sprint — partners will POST us payment events. Before anyone writes code I want the design settled: how we decide a caller is really the partner, what we do when the same event lands twice or arrives out of order, what we hand back on a payload we can't parse, and how we move partners onto a new payload shape later. Walk me through it.",
+      "expected_output": "Splits the request along a line the skill roster does not draw for you. Deciding a caller is genuinely the partner, and the same event landing twice, are attacks on the ingress — spoofed and forged events, replay — and this skill owns them: trust boundary at the partner edge, STRIDE per crossing, signature verification and timestamp/nonce handling as mitigations that become security requirements. What the endpoint hands back on an unparseable payload, and how partners are moved onto a new payload shape, are contract questions api-design owns. Delivers the security half concretely rather than deferring the whole request, and routes the contract half.",
       "assertions": [
-        "Recognizes the request as a security review of existing, deployed code rather than design-time analysis",
-        "Refers to the security-audit skill for the vulnerability review",
-        "Does not produce a design-time threat model (DFDs, STRIDE-per-boundary of a not-yet-built system) as the answer",
-        "States the boundary: threat-modeling is proactive/design-time, security-audit is the reactive review of built code"
+        "Separates the two halves: which callers and which deliveries can be trusted, versus what the endpoint promises its consumers and how that promise changes",
+        "Refers to api-design for the error-response contract and the payload versioning strategy",
+        "Delivers the design-time security work itself — the partner ingress as a trust boundary with the threats crossing it named — rather than deferring the whole request",
+        "Treats repeat delivery as a replay threat with a mitigation, not only as an idempotency convenience",
+        "States the boundary: threat modeling asks how an interface is attacked, while API design asks what the interface promises its callers"
       ]
     }
   ]

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

@@ -118,7 +118,17 @@ For each major layout section, specify what changes:
 
 ### Step 6: Produce the Specification
 
-Output using the template at [templates/screen-spec.md](templates/screen-spec.md). Save as `docs/ui/feature-name.md`. Link from the PRD if one exists.
+The deliverable is organized **by screen, not by topic**: one block per screen (and per modal or panel that acts as one, such as a create/edit form), every block carrying the same sections in the same order, from [templates/screen-spec.md](templates/screen-spec.md):
+
+1. **Purpose** — what the user accomplishes here
+2. **Arrives from → leads to** — the entry points, where the primary action goes, the secondary exits
+3. **Content hierarchy** — primary action first
+4. **States** — loading, empty, error, loaded, for *this* screen
+5. **Interactions** — its forms, CRUD feedback, destructive-action confirmation
+
+Steps 2–5 are how you think the design through; they are not the answer's outline. Don't pull states or interactions out into cross-screen sections: someone building one screen must find all of it in that screen's block. Shared patterns get stated once and referenced by name from each block.
+
+Give the specs in the same response, whether or not you also save them as `docs/ui/feature-name.md` (link from the PRD if one exists) — offering to write them later is not delivering them. When the question is about one screen's states rather than designing screens, answer those states; don't expand into full specs.
 
 ## Principles Applied
 

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

@@ -4,7 +4,7 @@
     {
       "id": 1,
       "prompt": "Design the UI for a project management dashboard. Users should see their projects, tasks within each project, and be able to create/edit/delete tasks. It's a React web app. We don't have a designer — I need to figure out the screens and flows myself.",
-      "expected_output": "Should map the user flow first (dashboard → project → task), then specify each screen with all states (loading, empty, error, loaded), define interaction patterns for CRUD operations, and include responsive behavior.",
+      "expected_output": "Should map the user flow first (dashboard → project → task), then specify each screen with all states (loading, empty, error, loaded), define interaction patterns for CRUD operations, and include responsive behavior. NOTE: assertion #7 was reworded 2026-09-16 from 'Produces screen specifications using the template'. The old passes came from judges that opened templates/screen-spec.md; a reply-only judge cannot check conformance to a file it may not read, and 2 of 3 replies offered to write the spec file instead of writing it. Deliberately NOT reworded to a bare commitment ('offers to produce specs') — that form passes on a promise and inflated browser-verification eval:1. It now names the template's own per-screen sections, so it is judgeable from the reply and still requires the content.",
       "assertions": [
         "Maps the user flow before designing individual screens",
         "Defines at least 3 screens (dashboard, project detail, task detail/modal)",
@@ -13,7 +13,7 @@
         "CRUD interactions have specified feedback (toast, inline, redirect)",
         "Delete has a confirmation pattern",
         "Responsive behavior defined for mobile vs desktop",
-        "Produces screen specifications using the template"
+        "Specifies each screen in the reply in one consistent per-screen structure — purpose, where the user arrives from and goes next, content hierarchy, and states — rather than only offering to write spec files later"
       ]
     },
     {
@@ -33,14 +33,14 @@
     },
     {
       "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.",
+      "prompt": "Flows and wireframes are approved. Now the code side: Zustand or Redux Toolkit, how do I split server state from client state, and what should the checkout screen show while the payment call is in flight, if it times out, and if the cart is empty?",
+      "expected_output": "Splits the request: which library holds state and how server and client state are separated are architecture decisions, while what the checkout screen shows in flight, on timeout, and when empty is a UX decision this skill owns. Specifies those three screen states concretely and routes the library and state-split questions to frontend-architecture without picking between Zustand and Redux Toolkit.",
       "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"
+        "Separates the state-management and code-organization questions from the screen-state questions",
+        "Refers to frontend-architecture for the Zustand-versus-Redux-Toolkit choice and the server/client state split",
+        "Does not pick between Zustand and Redux Toolkit",
+        "Specifies the checkout screen's in-flight, timeout, and empty-cart states concretely — the half that is this skill's own",
+        "States the boundary: which states a screen must account for is a UX decision; where that state lives in code is an architecture decision"
       ]
     }
   ]

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

@@ -1,6 +1,6 @@
 ---
 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. Run the proving command fresh and read its output first."
+description: "Evidence gate before any claim that work is done, fixed, passing, or deployed. Route here when a message declares the work finished or asks to commit, push, merge, ship, or close it out, including a brief sign-off, and before git-workflow or release-management act on it. Writing the commit message or PR text itself → git-workflow."
 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
 ---