gm-skill 2.0.2478 → 2.0.2480

package/gm-plugkit/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-plugkit",
-  "version": "2.0.2478",
+  "version": "2.0.2480",
   "description": "Bootstrap and daemon-spawn tool for gm plugkit binary. Downloads the correct platform wasm, verifies SHA256, and launches agentplug-runner (the native wasm host) as the spool watcher daemon.",
   "main": "index.js",
   "bin": {

package/gm.json

@@ -1,6 +1,6 @@
 {
   "name": "gm",
-  "version": "2.0.2478",
+  "version": "2.0.2480",
   "description": "Spool-dispatch orchestration engine with unified state machine, skills, and automated git enforcement",
   "author": "AnEntrypoint",
   "license": "MIT",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gm-skill",
-  "version": "2.0.2478",
+  "version": "2.0.2480",
   "description": "Canonical universal harness — AI-native software engineering via skill-driven orchestration; bootstraps plugkit for task execution and session isolation. Install in any AI coding agent host.",
   "author": "AnEntrypoint",
   "license": "MIT",

package/skills/gm/SKILL.md

@@ -1,18 +1,18 @@
 ---
 name: gm
-description: The primary driver for any non-trivial coding, refactoring, debugging, or multi-step engineering task in a project using this harness -- use it first, for the whole task, not just a piece of it. Plugkit-served instruction stream. Three-layer admission (witness, single-writer, direction) over every possible mutation; effort unbounded. Closure on first emit; partial = non-monotonic. Not for the post-completion remaining-work check (that is `gm-continue`) or for drift-recovery mid-task (that is `wfgy-method`) -- this skill is the work itself.
+description: The primary driver for any non-trivial coding, refactoring, debugging, or multi-step engineering task in a project using this harness -- use it first, for the whole task, not just a piece of it. Plugkit-served instruction stream. Three-layer admission (witness, single-writer, direction) over every possible mutation; -- this skill is the work itself.
 allowed-tools: Skill, Read, Write, AskUserQuestion, Bash(bun *), Bash(npx *), Bash(cat *), Bash(date *)
 ---
 
 # gm
 
-**The conversation literally stops the instant a response contains no tool call -- this is the entire mechanism, not a guideline to remember.** Nothing external enforces continuation; the only thing that keeps this session alive turn after turn is that every single response contains a dispatch. The moment a response is prose alone -- a summary, a "here's what I did," a "Session N closes, ready to resume with /gm," a recap of architecture decisions made, a list of what's left for "next time" -- that response IS the final message of the conversation. There is no next turn where the user re-prompts and work resumes; from the model's own vantage point mid-generation, writing that closing summary is indistinguishable from ending the conversation permanently, because it has the exact same effect. So: never compose a closing/summary/"standing work ready" sentence as the last thing in a response -- if the work in front of you feels finished, the correct final action is still a dispatch (the next verb, or `Skill(skill="gm-continue")` if genuinely `phase=COMPLETE AND prd_pending_count=0`), never a sentence describing that it's finished. A turn-final sentence naming the next move instead of taking it is the same stop -- take the move, don't narrate it. Standing approval already covers this turn's work (see below) -- always dispatch the named verb next till the workflow is complete. Decisions about scope expansions or `prd-add` (a discovered row) are approved.
+**The conversation literally stops the instant a response contains no tool call -- this is the entire mechanism, not a guideline to remember.** Nothing external enforces continuation; the only thing that keeps this session alive turn after turn is that every single response contains a dispatch. Never compose a closing/summary/"standing work ready" sentence as the last thing in a response -- if the work in front of you feels finished, the correct final action is still a dispatch (the next verb, or `Skill(skill="gm-continue")` if genuinely `phase=COMPLETE AND prd_pending_count=0`), never a sentence describing that it's finished. A turn-final sentence naming the next move instead of taking it is the same stop -- take the move, don't narrate it. Standing approval already covers this turn's work (see below) -- always dispatch the named verb next till the workflow is complete. Decisions about scope expansions or `prd-add` (a discovered row) are approved.
 
-**`gm` must end by calling `gm-continue` which dispatches the finishing procedure; there is no other exit.** At genuine `phase=COMPLETE AND prd_pending_count=0`, the only allowed next step is dispatching `Skill(skill="gm-continue")` as the literal last tool call of the turn -- (reaching COMPLETE earlier in a turn does not license a prose-only response afterward -- the Skill dispatch belongs in that same turn, immediately).
+**`gm` must end by calling `gm-continue` which dispatches the finishing procedure; there is no other exit.** At genuine `phase=COMPLETE AND prd_pending_count=0`, the only allowed next step is dispatching `Skill(skill="gm-continue")` as the literal last tool call of the turn.
 
 **plugkit provides our completion checks** If uncertain what's next, dispatch `phase-status`, read the phase, then keep walking -- "uncertain" is never grounds to stop.
 
-**Standing approval: finish everything, max granularity.** Every session is approved through requested work -- our policy is to plan, every addition, every discovered/unfinished item. We add prds insted of deferring work. If a walk is long, SPECIFY pushes more rows and PROVE/EMIT keep walking them, session after session if needed, never pausing to ask which subset to attempt first. Decide to always: proceed with the full scope, never the partial one. PRD rows are in `.gm/prd.yml`; a long task means MORE rows pushed onto SPECIFY as work is discovered, never fewer turns spent working. An apparent external blocker (a crashing tool, a down service, a missing peice, another team's repo) is an indication to add more prds and expand scope, making the most sensible choices along the way about replacing the problematic content with something that works, retry/escalate/route around, open the cross-repo change. `blockedBy` may only transiently carry the concrete reach action forward while it is being built.
+**Standing approval: finish everything, max granularity.** Every session is approved through requested work -- our policy is to plan, every addition, every discovered/unfinished item. We add prds insted of deferring work. If a walk is long, SPECIFY pushes more rows and PROVE/EMIT keep walking them, session after session if needed. Decide to always: proceed with the full scope, never the partial one. PRD rows are in `.gm/prd.yml`; a long task means MORE rows pushed onto SPECIFY as work is discovered, never fewer turns spent working. An apparent external blocker (a crashing tool, a down service, a missing peice, another team's repo) is an indication to add more prds and expand scope, making the most sensible choices along the way about replacing the problematic content with something that works, retry/escalate/route around, open the cross-repo change. `blockedBy` may only transiently carry the concrete reach action forward while it is being built.
 
 The next action is determined solely by phase + PRD state, identically whether 500k tokens or 500 remain. If you catch yourself estimating/citing a remaining-token number for any reason, that estimate itself is the drift signal -- discard the framing entirely and re-derive the next action from `phase`/`prd_pending_count` alone. Real per-row witnessing (one `exec_js`/`browser` dispatch per row, actually reading its output) is mandatory regardless of how many rows remain or how much context is left; a batch `prd-resolve` for N rows justified by "given the budget" is `deviation.prd-resolve-duplicate-witness`-shaped even when each id is individually correct, because the underlying witnesses were never separately produced.
 
@@ -20,7 +20,7 @@ The next action is determined solely by phase + PRD state, identically whether 5
 
 **A fresh session entering a repo already mid-chain checks for a recent `stuck-loop-escalation` or repeated `prd-resolve-unknown-id` before repeating the same fix shape.** If a prior session hit either (guessing at ids never `prd-add`ed this chain, or retrying the same denied transition), the actual PRD rows and their real ids are on disk in `.gm/prd.yml` -- read them directly rather than assuming remembered ids from context are still correct. Re-`prd-add`ing a row under a slightly different id because the original is unknown/forgotten creates an orphaned duplicate; when uncertain of a row's real id, `codesearch`/`recall`/direct `.gm/prd.yml` read settles it, never a guess-and-hope `prd-resolve`.
 
-`instruction` dispatch returns prose describing the current phase and next steps. When uncertain about next action, dispatch `instruction` -- never invent the next step from memory, never stop to ask.
+`instruction` dispatch returns prose describing the current phase and next steps. When uncertain about next action, dispatch `instruction` -- never invent the next step from memory.
 
 Verbs are written to `.gm/exec-spool/in/<verb>/<N>.txt` as JSON. Plugkit processes on read. Phase transitions are explicit `transition {to:"PHASE"}` dispatches. Phase state is in responses and `.gm/exec-spool/.turn-summary.json`; never assume phase from context.