@jesdi/skills 0.0.22 → 0.0.24

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jesdi/skills",
-  "version": "0.0.22",
+  "version": "0.0.24",
   "description": "jesdi's agent skills (content package consumed by @jesdi/skills-cli)",
   "license": "MIT",
   "repository": {

package/skills/implement-spec/SKILL.md

@@ -15,7 +15,8 @@ a per-ticket gate (check command + crap-gate) before DONE, re-run by the reviewe
 already-green locked tests need a demonstrated mutation; a Codex correctness
 pass per risky ticket; tickets touching the same functions run in sequence;
 check command after each merge; final /review-diff on the most capable model, one
-fixer; closes tickets only if they are issues. Review loop and ledger adapt
+fixer; closes tickets only if they are issues; no push and no PR until every
+ticket is merged and the final review has passed. Review loop and ledger adapt
 superpowers' subagent-driven-development (obra/superpowers, MIT).
 -->
 
@@ -41,7 +42,10 @@ Run ticket subagents in the background where possible for **maximum concurrency*
 
 2. Create a notes directory outside the repo, readable by all subagents, and start the ledger there. (optional) An **exploration subagent** saves its notes on relevant code and docs there, so implementers focus on implementation.
 
-3. Create a branch, and a draft PR. If the spec and tickets are issues, mark the PR as 'closing' them.
+3. Create the PR branch locally. Do **not** push it and do **not** open a PR yet: nothing leaves the
+   machine until every ticket is merged and the final review has passed (step 10). Intermediate
+   states (red tests, half-merged tickets) are never pushed. If the spec and tickets are issues,
+   note their numbers in the ledger so the PR can close them later.
 
 4. Each ticket gets its own worktree and branch. For a ticket with behavioral criteria, a **test-writer subagent** goes first. It sees ONLY the spec, the ticket, CONTEXT.md/ADRs and the public interface of the ticket's **Seam** line (pointers, not summaries), never the implementer's plan or code. It writes one black-box acceptance test per criterion through that interface (defining the interface if it doesn't exist yet), confirms each fails for the right reason (missing behavior, not an import or syntax error), commits them red, and reports the SHA and files. A test that is already green before any implementation is vacuous until proven otherwise (an earlier guard or early return often satisfies it for an unrelated reason): the test-writer rewrites it to fail, or, when the criterion truly holds already, reports the production-code mutation that turns it red and the red output. Those files are now **locked**. A ticket with no behavioral criteria (Seam: `none — refactor`) skips this: its existing tests are the contract, unmodified.
 
@@ -55,10 +59,12 @@ Run ticket subagents in the background where possible for **maximum concurrency*
 
 7. Once a ticket passes review, a **merger subagent** merges it to the PR branch and runs the repo's check command (lint, typecheck, full suite). If it fails, an implementer fixes the PR branch before the next merge.
 
-8. If this changes the **frontier** of available tickets, start the next tickets. This allows for maximum concurrency. Exception: two ready tickets that change the same function never run at once. Compare their **Touches** lines (or ask the exploration subagent where each will land); on overlap, start one and hold the other until the first merges, then branch it from the updated PR branch. Record the hold as a ruling.
+8. If this changes the **frontier** of available tickets, start the next tickets. This allows for maximum concurrency. Exception: two ready tickets that change the same function never run at once. Compare their **Touches** lines (or ask the exploration subagent where each will land); on overlap, start one and hold the other until the first merges, then branch it from the updated PR branch. When in doubt, hold: a ticket you suspect builds on another ready or running ticket waits for it, even without a declared edge. Record the hold as a ruling.
 
 9. Once all tickets are complete, a reviewer on the most capable model runs /review-diff on the PR branch, given the ledger's minor findings and rulings. One **implementer subagent** fixes every finding, then re-review that fix once. Rule on anything left.
 
-10. Mark the PR as ready for review. List every ruling from the ledger in your final message.
+10. Now, and only now, push the PR branch once and open the PR, ready for review (not draft). If the
+    spec and tickets are issues, mark the PR as 'closing' them. List every ruling from the ledger in
+    your final message.
 
 11. Clean up all ticket worktrees.

package/skills/to-tickets/SKILL.md

@@ -47,6 +47,8 @@ Break the work into **tracer bullet** tickets.
 
 Give each ticket its **blocking edges**: the other tickets that must complete before it can start. A ticket with no blockers can start immediately.
 
+**When in doubt, block.** If you suspect a ticket might need to wait for another (it builds on that ticket's behaviour, touches the same files or functions, or the order just isn't obvious), add the edge. A missing edge costs broken locked tests, rebase churn and a re-run; an extra edge only costs some concurrency.
+
 **Wide refactors are the exception to vertical slicing.** A **wide refactor** is one mechanical change (rename a column, retype a shared symbol) whose **blast radius** fans across the whole codebase, so a single edit breaks thousands of call sites at once and no vertical slice can land green. Don't force it into a tracer bullet; sequence it as **expand–contract**. First expand: add the new form beside the old so nothing breaks. Then migrate the call sites over in batches sized by blast radius (per package, per directory), each batch its own ticket blocked by the expand, keeping CI green batch to batch because the old form still exists. Finally contract: delete the old form once no caller remains, in a ticket blocked by every migrate batch. When even the batches can't stay green alone, keep the sequence but let them share an integration branch that all block a final integrate-and-verify ticket; green is promised only there.
 
 ### 4. Quiz the user (attended only)
@@ -62,7 +64,7 @@ When a human is in the loop, present the proposed breakdown as a numbered list.
 Ask the user:
 
 - Does the granularity feel right? (too coarse / too fine)
-- Are the blocking edges correct: does each ticket only depend on tickets that genuinely gate it?
+- Are the blocking edges correct: is any edge missing? (Suspected dependencies are already listed as blockers; say which ones can safely go.)
 - Should any tickets be merged or split further?
 
 Iterate until the user approves the breakdown.

package/skills-manifest.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-09-24T19:30:05.664Z",
+  "generatedAt": "2026-09-30T22:48:58.981Z",
   "skills": [
     {
       "name": "backlog",
@@ -46,8 +46,8 @@
     },
     {
       "name": "implement-spec",
-      "version": "0.1.3",
-      "hash": "sha256-35fb6ffac0407ec80098b7aca94d3949912b80e6f10908a81401e3f40e45ee9e",
+      "version": "0.1.5",
+      "hash": "sha256-43b1b1b97386b96b2cc8124ca906ffc0a5a4b35362413b52ac154c1faaa0b43e",
       "description": "Implement a specification in code."
     },
     {
@@ -88,8 +88,8 @@
     },
     {
       "name": "to-tickets",
-      "version": "0.1.3",
-      "hash": "sha256-50387c0abfab110d26b156521d99320e848aa942c319379b82d80fde59722903",
+      "version": "0.1.4",
+      "hash": "sha256-66822a4d85cd7b851d9073591723dbf228f58a1f8cb3ccf0fd9f57f38c90aca1",
       "description": "Break a spec, plan, or the current conversation into numbered tracer-bullet ticket files under .agent/tickets/, each declaring its blocking edges and acceptance criteria phrased as observable behavior. Use after a spec is approved and before implementation starts."
     },
     {