@iceinvein/agent-skills 0.13.0 → 0.14.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@iceinvein/agent-skills",
-  "version": "0.13.0",
+  "version": "0.14.0",
   "description": "Install agent skills into AI coding tools",
   "author": "iceinvein",
   "license": "MIT",

package/skills/index.json

@@ -283,7 +283,7 @@
     "name": "sluice",
     "description": "Routes work by change shape into four channels (bypass, fast, main, deep) and applies only the rules each channel needs, so a one-line fix does not pay the cost of a multi-subsystem build. Carries seven rules as one-liners in the router and the full treatment in references read only on friction. Checks the finished plan with plan.sh validate rather than trusting it to memory, seeds the run state from it, keeps a deep run's task breakdown in .sluice/run.json so a statusline segment and one status command can answer where the run is, and closes each run with a ledger read out of the session transcript: elapsed, tools, tokens, and what each dispatched agent cost where the transcript recorded it. Claude Code only; stands down where the superpowers pipeline governs the repo.",
     "type": "prompt",
-    "version": "0.14.0"
+    "version": "0.15.0"
   },
   {
     "name": "temporal-coupling-detector",

package/skills/sluice/SKILL.md

@@ -56,8 +56,8 @@ yourself wanting to skip the rule, or arguing that this one is the exception.
   it down. `references/intent.md`
 - **Test first.** The test comes before the code; run it while it should
   still be failing, then write the least code that turns it green. Skip that
-  watching step and a green result is only an unchecked guess.
-  `references/test-first.md`
+  watching step and a green result is only an unchecked guess. A test no
+  plausible change could turn red is not one you owe. `references/test-first.md`
 - **Root cause** before fix. A fix that only hides the symptom has not fixed
   anything. Three failed fixes point at the design, not your guesswork.
   `references/root-cause.md`

package/skills/sluice/references/deep-channel.md

@@ -353,7 +353,7 @@ and it fails by printing success rather than by erroring.
 
 | Tier | Task shape | Review |
 |------|------------|--------|
-| 0 | Created files only, executable tests exist and pass, Contract matches | No dispatch. Read the commit stat yourself. |
+| 0 | Created files only, tests that meet `references/test-first.md` exist and pass, Contract matches | No dispatch. Read the commit stat yourself. |
 | 1 | Modified existing code, or later tasks build on it | One reviewer dispatch |
 | 2 | No executable test covers it: prose, config, docs | One reviewer dispatch; a stat cannot confirm the words are right |
 | 3 | Auth, data, money, concurrency, or the plan flags it | One reviewer dispatch; the task may not be downshifted |
@@ -382,6 +382,13 @@ number, not the row order and not which shape sounds more serious. A task that
 only creates files but ships prose is tier 2, and a suite re-bless paired with
 an ADR is tier 2 rather than the free row it resembles.
 
+**A test written to earn tier 0 does not earn it.** The row is a discount on
+review, and a task whose only executable test fails
+`references/test-first.md`'s question, that some plausible change to the code
+turns it red, is a tier 2 task carrying a green line rather than a covered
+one. Price it as tier 2. Buying this table's savings with the one kind of test the rest of the
+skill argues against is the cheapest way to lose them.
+
 Ordering inert tasks first is what keeps this affordable. An inert task that
 only creates files takes tier 0, so a nine-task plan usually buys three
 or four dispatches rather than nine. If most of your plan qualifies for a

package/skills/sluice/references/test-first.md

@@ -10,26 +10,64 @@ alone cannot tell you which. A test that passes the first time you run it is
 not testing your change, it is testing behaviour that already existed. When
 that happens, fix the test, not the code.
 
-A test is only a test if some change to the implementation would turn it red.
-Work out which change before you write the body; if there isn't one, what you
-have is an assertion that stays green whatever you build.
-
-Assertions belong on what the run actually produced: the value returned, the
-state left behind, the output written. Never point one at a mock: a green
-result then proves only that you called the mock the way you meant to, which
-you knew already. Before a mock stands in for a dependency, learn what the real
-one does on the paths your test never exercises; one that quietly drops a side
-effect will hold a broken change green.
-
-Keep helpers that exist only for tests inside the test files. If a production
-class grows a method whose only caller is a test reaching inside it, the test
-has started reshaping your design.
-
-Three cases are worth asking to skip: generated or scaffolded code, a config
-file with no logic in it, and a prototype headed for the bin before anyone
-sees it. Ask rather than assume, and treat that list as closed.
-
-The friction line: "this case is obvious enough to skip straight to the
-code." A test written once the code already works can only confirm what you
-already believe about it. By that point you have stopped hunting for the cases
-you never thought of, so the test does not find them either.
+**Name the change that would turn it red.** A test is only a test if some
+change to the implementation makes it fail, so work out which change before you
+write the body, and hold the answer to being one a person would plausibly make
+to this code later. An answer nobody would ever write, or one the type checker,
+the linter or the framework already rejects on your behalf, means there is no
+test to write here. Write nothing and move on. What you were reaching for is an
+assertion that stays green whatever you build, and it bills a run on every
+commit from now on to keep saying so.
+
+**Some shapes never survive that question.** A getter, a constant, a
+framework's own behaviour, a mock's call log. Coverage is a smoke detector,
+not a target, and a test added to move the number is the purest case of the
+thing this rule refuses.
+
+**Skipping is a judgement, not a list.** Generated or scaffolded code, a config
+file with no logic in it, and a prototype headed for the bin are the usual
+cases that fail the question outright, but they are instances of the criterion
+rather than the whole of it. What you owe in exchange for the judgement is one
+sentence in your reply naming the behaviour you left untested and why: a skip
+nobody hears about cannot be told apart from an oversight.
+
+**Assertions belong on what the run actually produced**: the value returned,
+the state left behind, the output written. Never point one at a mock, because
+a green result then proves only that you called the mock the way you meant to,
+which you knew already. Before a mock stands in for a dependency, learn what
+the real one does on the paths your test never exercises; one that quietly
+drops a side effect will hold a broken change green. Where the wiring is what
+breaks, one real integration test is worth five mocked unit ones.
+
+**Expected values are written by hand or taken from the spec.** Never produce
+one by running the code under test and keeping what came back: a blessed
+snapshot checks the implementation against itself, so it stays green whatever
+that implementation does, which is the same as having no test at all. The
+re-bless is where this goes wrong at scale, the diff too large to read and
+every value in it exactly as authoritative as the bug you are freezing.
+
+**One behaviour per test**, named for the behaviour it pins rather than for the
+function it calls. Keep helpers that exist only for tests inside the test
+files. If a production class grows a method whose only caller is a test
+reaching inside it, the test has started reshaping your design.
+
+**A test goes when the behaviour it pinned is gone.** Delete it alongside the
+code, in the same commit, like anything else the change orphaned. Two tests
+pinning one behaviour are a test and a maintenance bill, so keep the clearer.
+None of that reaches a red test. A failure is the suite claiming your change
+broke something, and deleting it, skipping it, loosening the assertion or
+special-casing the input it feeds answers the claim by silencing the witness.
+Believe the test itself is wrong and you say so and get agreement first.
+
+Two friction lines, one in each direction:
+
+"This case is obvious enough to skip straight to the code." A test written
+once the code already works can only confirm what you already believe about
+it. By that point you have stopped hunting for the cases you never thought of,
+so the test does not find them either.
+
+"Better add a test here to be safe." Safe against what? You are one sentence
+away from the answer, so finish it and name the change this would catch. If
+the sentence will not finish, what moved you was diligence rather than
+evidence, and what it buys is a permanently green line nobody later dares
+delete.

package/skills/sluice/skill.json

@@ -1,6 +1,6 @@
 {
   "name": "sluice",
-  "version": "0.14.0",
+  "version": "0.15.0",
   "description": "Routes work by change shape into four channels (bypass, fast, main, deep) and applies only the rules each channel needs, so a one-line fix does not pay the cost of a multi-subsystem build. Carries seven rules as one-liners in the router and the full treatment in references read only on friction. Checks the finished plan with plan.sh validate rather than trusting it to memory, seeds the run state from it, keeps a deep run's task breakdown in .sluice/run.json so a statusline segment and one status command can answer where the run is, and closes each run with a ledger read out of the session transcript: elapsed, tools, tokens, and what each dispatched agent cost where the transcript recorded it. Claude Code only; stands down where the superpowers pipeline governs the repo.",
   "author": "iceinvein",
   "type": "prompt",