@brainervirus/workit-cursor 2.6.0 → 2.8.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@brainervirus/workit-cursor",
-  "version": "2.6.0",
+  "version": "2.8.0",
   "private": false,
   "description": "Workit Cursor plugin — shared MCP transport, native hooks, and fourteen method skills",
   "keywords": [
@@ -44,8 +44,8 @@
     "build": "bun scripts/build.ts"
   },
   "dependencies": {
-    "@brainervirus/workit-core": "^2.6.0",
-    "@brainervirus/workit-mcp": "^2.6.0"
+    "@brainervirus/workit-core": "^2.8.0",
+    "@brainervirus/workit-mcp": "^2.8.0"
   },
   "engines": {
     "node": ">=24"

package/skills/workit-bdd/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: workit-bdd
+description: Use when turning a requirement, issue or acceptance criterion into tests, or when tests should read as behavior (Given/When/Then, BDD, scenarios, acceptance tests, test names and seams)
+---
+
+# Behavior first: Given/When/Then
+
+Write each acceptance criterion as Given/When/Then before any code, then let
+it name the test and pick the seam. This skill shapes the scenarios; the
+RED/GREEN loop itself is workit-behavioral-tdd.
+
+## Method
+
+1. Write the scenarios. One behavior per scenario, in the user's or caller's
+   words: `Given <state>, When <action>, Then <observable result>`. Include the
+   unhappy paths a caller depends on (denied, empty, invalid, timeout).
+2. Agree the seams. Pick the highest stable interface the scenario can be
+   observed through: a CLI verb, a public function, an HTTP route. Ideally one
+   seam per feature. Write the seams down; do not test at an unagreed seam.
+3. Name the tests after the scenarios. The test name is the Given/When/Then
+   sentence; the body is arrange (Given), act (When), assert (Then). Expected
+   values come from the scenario (a literal from a worked example or the
+   spec), never from the code.
+4. Use Gherkin only where the repo already does (`.feature` files with
+   playwright-bdd, cucumber, jest-cucumber). Otherwise plain test names carry
+   the scenario; do not add a BDD framework.
+5. Build in vertical slices, one scenario at a time, with
+   workit-behavioral-tdd: run `workit check test` RED for the new scenario,
+   make the smallest change, run `workit check test` GREEN, then the next.
+6. Mock only at system boundaries: network, clock, randomness, other
+   processes, sometimes the filesystem. Never the unit or its internal
+   collaborators; use the real thing or an in-memory adapter behind a port.
+
+## Completion
+
+Every acceptance criterion maps to a named test at an agreed seam, each was
+seen RED then GREEN through `workit check test`, and the new tests have no
+tautologies:
+
+```sh
+workit test-audit --diff && workit check test
+```

package/skills/workit-behavioral-tdd/SKILL.md

@@ -16,12 +16,16 @@ Use this method when assessment selects the `testing` dimension.
 2. State one behavior and its observable result. Choose the narrowest stable
    boundary a caller or user depends on; avoid private helpers and incidental
    representations.
-3. Write one vertical RED slice that fails for the missing behavior, run it, and
-   preserve the actual failure as evidence. Implement the smallest change, then
-   run the same slice GREEN and record its result. Close enforces the order: a
-   testing requirement with GREEN but no preceding RED evidence stays unsatisfied.
-4. Add only another slice for a distinct behavior or risk. Reconcile stale
-   evidence if the candidate changes.
+3. Write one vertical RED slice that fails for the missing behavior and run it
+   through the CLI so the failure is observed: `workit check test` (the repo's
+   configured `test` check; `npx -y @brainervirus/workit-cli check test` when
+   `workit` is not on PATH). Implement the smallest change, then run the same
+   check GREEN. Close accepts only a fresh passing run of the configured check
+   that `workit check` observed; a recorded "tests pass" is a note, and an
+   ad-hoc `workit check -- <cmd>` never satisfies the gate. If no `test` check
+   is configured or detected, add `workit.checks.json` (committed) with it.
+4. Add only another slice for a distinct behavior or risk. Any edit makes the
+   observed check stale: re-run `workit check test` before closing.
 
 ## Reject noisy tests
 
@@ -35,9 +39,13 @@ Use this method when assessment selects the `testing` dimension.
   ghost loops (assert inside a possibly-empty loop), smoke-only renders,
   type-only or CSS-class coupling. If the test still passes when every
   imported function returns undefined, rewrite the assertion or delete it.
+  `workit test-audit --diff` flags these; triage them with workit-test-audit.
+  Turning acceptance criteria into scenarios and seams is workit-bdd.
 
-Use shared `evidence` operations for RED/GREEN results. Do not add a second
-lifecycle, approval chain, or test workflow outside the current task state.
+Run RED/GREEN through `workit check`, which records the observed result on the
+current task; shared `evidence` operations are for notes and non-test evidence.
+Do not add a second lifecycle, approval chain, or test workflow outside the
+current task state.
 
 ## Common mistakes
 
@@ -45,4 +53,4 @@ lifecycle, approval chain, or test workflow outside the current task state.
 | --- | --- |
 | "The pin changed, so assert the new string" | Exercise the affected consumer behavior. |
 | "The code is obvious" | A small vertical slice still proves the contract. |
-| Keeping a passing test after the boundary moved | Mark it stale and retest the current candidate. |
+| Keeping a passing test after the boundary moved | Re-run `workit check test` on the current tree. |

package/skills/workit-debug/SKILL.md

@@ -19,7 +19,8 @@ established root cause.
    inferences, and unknowns with references; trace the failing value and all
    relevant callers before editing.
 3. State the root-cause hypothesis and the smallest in-scope fix. Write a focused
-   regression at the boundary when practical, then run RED and GREEN checks.
+   regression at the boundary when practical, then run RED and GREEN through
+   `workit check <name>` so the results are observed, not reported.
 4. Acquire writer authority through `writer` before mutation. Reconcile the
    candidate, evidence, and findings after the change; investigate sibling paths
    and stale conclusions rather than assuming the first patch worked.

package/skills/workit-test-audit/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: workit-test-audit
+description: Use when tests may be tautological, low-value or noisy, before trusting a green suite, when reviewing tests an agent wrote, or when asked to clean up, prune or strengthen tests
+---
+
+# Audit tests for tautologies
+
+A tautological test recomputes its expected value the way the code does, so it
+passes by construction and can never disagree with the code. Find those and
+other low-value tests and triage each one. The audit is advice: never delete
+or weaken a test to make it quiet.
+
+## Method
+
+1. Run the audit on the change (or the paths you were asked about):
+   `workit test-audit --diff --json` or `workit test-audit <paths> --json`.
+   Each finding has file:line, rule, severity, confidence, why and a fix.
+   Prose checks are `info`; add `--min-severity info` to see them.
+2. Triage every finding with "Name the Break": which wrong production change
+   should make this test fail? Then choose one, and say which:
+   - Replace: keep the behavior, fix the oracle. Assert the public result
+     against an independent expected value (a literal from a worked example,
+     the spec, an external contract). Plant the bug you named, watch the new
+     test fail, then revert the plant.
+   - Keep with a reason: the value is an external contract or the finding is
+     wrong. Mark it `// workit-test-audit-ignore <rule> -- <reason>`.
+   - Remove: only `assertion-free` or `duplicate-body` tests, and only after
+     checking that no other test loses unique behavior with it.
+3. Check the replacements catch real breaks: `workit test-audit --mutate --diff`
+   (pass `--test-cmd "<runner> {files}"` to run only the related tests). A
+   surviving mutant names a change no test notices; add the missing case.
+4. Leave untouched tests outside the diff alone; propose that cleanup as its
+   own change.
+
+## Completion
+
+Every finding is triaged (replaced with a test that failed on a planted bug,
+kept with an ignore comment and reason, or removed as above) and the configured
+tests are green:
+
+```sh
+workit check test
+```