@iceinvein/agent-skills 0.8.2 → 0.8.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@iceinvein/agent-skills",
-  "version": "0.8.2",
+  "version": "0.8.4",
   "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, 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.5.0"
+    "version": "0.7.0"
   },
   {
     "name": "temporal-coupling-detector",

package/skills/sluice/SKILL.md

@@ -90,15 +90,45 @@ Design to `docs/specs/YYYY-MM-DD-<topic>.md`, plan to
 `docs/plans/YYYY-MM-DD-<topic>.md`, unless the repo has a convention or
 your partner states a preference. Get the design signed off before code.
 
+**Read `references/deep-channel.md` before you write the plan.** It carries the
+plan format, the pre-flight questions, the run record, the dispatch rules and
+the review tiers, and none of those are derivable from what is on this page.
+Take the plan file's first character as the trigger, not this sentence's
+position: design sign-off can be days and a context window away from here, by
+which point this paragraph is a thousand messages back and reads as something
+already handled. A plan written without that file comes out as prose with a
+sequencing note, which reads fine to its author and cannot be dispatched,
+reviewed or resumed.
+
+The skeleton it fills in, so that a plan written without it is at least still a
+plan:
+
+```
+# Plan: <topic>
+## Ground Rules
+- <exact value>
+### Task N: <name>
+**Contract:** Needs: <sig> | Offers: <sig>
+**Touches:** <path> (new) | <path> (edit) | <path> (test)
+**Flips:** <what changes, from what, or omit>
+**Review:** <reason, or omit>
+- [ ] <action> -> <proof>
+```
+
+Read that as a graph rather than a list. `Needs` and `Offers` are dependency
+edges and `Touches` says what cannot overlap, so which tasks may run at once is
+derivable rather than guessed. Fan out wherever that graph allows; serial is the
+fallback for where it doesn't, not the default.
+
 The second stop is the plan's, whoever executes it. Dispatched agents each see
 only their own task, so nobody reads it whole; executing it yourself is the
 weaker case rather than the exempt one, because then nobody reads it but its
 author.
 
 Order the plan so the tasks that change nothing come first, and mark the one
-task that turns the new behaviour on. Then a late re-baseline, re-blessed
-snapshots, regenerated fixtures, attributes to that one point instead of to
-the branch at large.
+task that turns the new behaviour on with `Flips`. Then a late re-baseline,
+re-blessed snapshots, regenerated fixtures, attributes to that one point
+instead of to the branch at large.
 
 Pre-flight rides in that same stop: which flagged tasks get a reviewer, and
 whether the work runs in a worktree. Ask them as choices with the counts in
@@ -109,17 +139,15 @@ this question the place to ask; genuine unavailability is the tool not being
 there at all, which `references/deep-channel.md` handles separately. Review that
 turns out to be missing is only actionable while the plan can still change.
 
-Read the plan as a graph rather than a list. `Needs` and `Offers` are
-dependency edges and `Touches` says what cannot overlap, so which tasks may
-run at once is derivable rather than guessed. Fan out wherever that graph
-allows; serial is the fallback for where it doesn't, not the default.
-
-Then read `references/deep-channel.md` for the plan format, that stop, the run
-record, the dispatch rules, and when a task actually needs a reviewer. Three that
-catch people out: concurrent implementers need a worktree each and the flip
-runs alone, review is tiered rather than automatic, and a `deep` run that
-cannot dispatch has to replace the review tier with something, not quietly
-ship without one.
+Both answers go into the run record before Task 1's first edit, each with the
+reason it went that way. Those rows are what discharge pre-flight, not the
+approval: one reply arrives for two obligations, so a "yes" with no rows behind
+it signed off the plan and nothing else.
+
+Three from that file that catch people out: concurrent implementers need a
+worktree each and the flip runs alone, review is tiered rather than automatic,
+and a `deep` run that cannot dispatch has to replace the review tier with
+something, not quietly ship without one.
 
 ## Conflicts
 

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

@@ -64,9 +64,11 @@ A `deep` run outlives its own context, so what it learns has to sit on disk
 rather than in the session. Open one file for the run before pre-flight and
 write it as you go. It holds what a stranger resuming tomorrow would need and
 you would otherwise be recalling: the base each task was dispatched from, each
-task with its status and its commits, the review decisions pre-flight settled
-and the reason each one was settled that way, and any finding belonging to a
-task other than the one that surfaced it.
+task with its status and its commits, both answers pre-flight settled, review
+and workspace alike, with the reason each one went that way, and any finding
+belonging to a task other than the one that surfaced it. Those pre-flight rows
+come first and open the file, because they are also what says the stop happened
+at all.
 
 Where it goes follows the repo if the repo has a convention, and
 `docs/plans/YYYY-MM-DD-<topic>-record.md` if it does not. It belongs to you
@@ -122,9 +124,29 @@ repo, a lint target that resolves through a symlink, a build that needs its own
 install, belongs in the option text where it can affect the answer, not in a
 footnote after they have chosen.
 
+That question settles where the implementers run, not whether a task may be
+dispatched at all, and the shared-tree and current-branch options have to say
+so: under either, a single task still goes to its own agent where the reading
+would otherwise land here, announced when it happens. Put it in the option text
+rather than leaving it to be inferred. Unsaid, it is not in what your partner
+agreed to, and a session that dispatches only when asked then has to stop
+mid-run to ask for the one dispatch that would have paid. Do not name the tasks
+here: which one turns out read-heavy is not knowable yet, and a list written now
+is the declared schedule the dispatch rules reject.
+
 If one of the two has only one live answer, say which and ask the other. A stop
 down to a single question is still a stop.
 
+**Write the answers into the run record before Task 1's first edit.** Both of
+them, each with the reason it went that way. This is what discharges pre-flight,
+rather than the approval you got, and the distinction is the whole point: a stop
+that carries the plan and pre-flight together has one reply for two obligations,
+so a bare "yes" satisfies the plan and leaves no trace either way of the
+questions. Rows in a file leave that trace. If Task 1 is about to open and the
+record has nothing in it, you did not ask, however clearly you remember
+intending to, and the questions are still cheap here and unaskable an hour from
+now.
+
 A session that forbids subagents does not skip this; it changes what the
 review options are. Skipping it is how "review outstanding" first appears in
 the closing summary, at the one moment your partner can no longer do anything
@@ -151,6 +173,14 @@ blocking finding. A derived one just recomputes.
 - **Fan out wherever the graph allows.** Work that does not write is always
   safe and always parallel: investigations, searches and reviewers, one agent
   per question, all in one message so they run at once.
+- **A single task can still be dispatched from a shared tree.** What that
+  answer bought was serial implementers, and one agent at a time satisfies it,
+  so the escalation stays open per task instead of being foreclosed at
+  pre-flight. Take it where the reading dwarfs the diff: the task's own text
+  calls for a survey before the edit, its gates are the noisy ones, or this
+  session has already been summarised once and what is left is scarce. Say it
+  out loud and put the row in the run record with its reason, because otherwise
+  the record says controller-run and the transcript says otherwise.
 - **Concurrent implementers need a worktree each.** Disjoint `Touches` is
   necessary and no longer sufficient: agents commit their own tasks, so two
   in one tree contend on the git index and on `HEAD` even when their files

package/skills/sluice/skill.json

@@ -1,6 +1,6 @@
 {
   "name": "sluice",
-  "version": "0.5.0",
+  "version": "0.7.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, 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",