@jesdi/skills 0.0.21 → 0.0.22

package/package.json

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

package/skills/implement-spec/SKILL.md

@@ -31,7 +31,7 @@ Run ticket subagents in the background where possible for **maximum concurrency*
 
 **Every dispatch prompt says: never `git stash`, reset or check out other branches; worktrees share one stash and one ref store.**
 
-**Name the model on every dispatch.** Omitted, it inherits yours. Exploration, test-writer, reviewer: mid tier (reviewer higher for risky diffs). Implementer: mid tier; cheapest when the ticket carries the complete code; most capable for design judgment or broad codebase work. Merger: cheapest. Escalations: one tier above the agent that got stuck. Final reviewer: most capable.
+**Name the model on every dispatch.** Omitted, it inherits yours. Exploration, test-writer, reviewer: mid tier (reviewer higher for risky diffs). Implementer: mid tier; cheapest for a small, fully specified ticket; most capable for design judgment or broad codebase work. Merger: cheapest. Escalations: one tier above the agent that got stuck. Final reviewer: most capable.
 
 **Rule, don't stall.** Keep a **ledger** file in the notes directory: every decision as `Ruling: <what> — <why> — <cost if wrong>`, and each ticket's state, so you can resume after compaction. Don't check in between tickets. Stop and ask only for: an irreversible or destructive operation, a security-sensitive action, a side effect outside the worktrees (a push to a shared branch, a publish), or a spec so broken that every path forward is a guess.
 

package/skills/to-openspec/SKILL.md

@@ -54,6 +54,9 @@ stage 1. Re-read `proposal.md` and `spec.md` first; the human may have edited th
      heading when the repo's template lacks it.
    - **Seams**: the endpoint, function, or command the tests drive through, marked existing or
      new. Prefer one high seam.
+   - No implementation code anywhere in the spec folder. `implement-spec`'s test-writer reads it
+     and must not know the solution. A decision's shape (a type, a schema, a state machine, a
+     seam's signature) may appear; the function bodies that make the tasks pass may not.
 3. Write `specs/<slug>/tasks.md`: vertical slices, each small enough for one commit and one green
    check command. Tests come first in each slice.
    - Every task has its `_Goal:_` line, its **Seam** (one of the seams from `design.md`, precise

package/skills/to-tickets/SKILL.md

@@ -10,7 +10,8 @@ Changes: tickets always go to `.agent/tickets/<NN>-<slug>.md` (no tracker path);
 numbering is contiguous from 01 in dependency order; acceptance criteria must state
 observable behavior; every ticket names its **Seam** (the public interface its
 acceptance tests hit) and what it **Touches** (files and functions, for
-scheduling); the approval quiz is skipped when unattended; model invocation is
+scheduling); trivial slices fold into a neighbour; tickets never carry the
+implementation; the approval quiz is skipped when unattended; model invocation is
 allowed.
 -->
 
@@ -40,6 +41,7 @@ Break the work into **tracer bullet** tickets.
 - A completed slice is demoable or verifiable on its own
 - Each slice is sized to fit in a single fresh context window
 - Any prefactoring should be done first
+- No trivial tickets: when a slice's whole change is a small guard or fix (a few lines) and no other ticket is blocked by it, fold its acceptance criteria into the neighbouring ticket that touches the same behaviour. Every ticket costs a test-writer, implementer, reviewer and merger; a two-line guard doesn't earn four agents
 
 </vertical-slice-rules>
 
@@ -112,4 +114,6 @@ The **Touches** line is a best guess, for scheduling: `implement-spec` never run
 
 </touches-rule>
 
-Outside the **Touches** line, avoid specific file paths or code snippets: they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits.
+Never write the implementation into a ticket. `implement-spec`'s test-writer reads the ticket and must not know the solution, or its acceptance tests stop being independent of the code they judge. Describe behaviour, not the fix.
+
+Outside the **Touches** line, avoid specific file paths or code snippets: they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it and note briefly that it came from a prototype. Trim to the decision-rich parts, the shape of the decision, never the code that implements the ticket.

package/skills-manifest.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-09-24T19:16:41.414Z",
+  "generatedAt": "2026-09-24T19:30:05.664Z",
   "skills": [
     {
       "name": "backlog",
@@ -46,8 +46,8 @@
     },
     {
       "name": "implement-spec",
-      "version": "0.1.2",
-      "hash": "sha256-ae8c88981b359c9b19ba285bacc38264ba11dca163be7b1fde4ff73ac278465b",
+      "version": "0.1.3",
+      "hash": "sha256-35fb6ffac0407ec80098b7aca94d3949912b80e6f10908a81401e3f40e45ee9e",
       "description": "Implement a specification in code."
     },
     {
@@ -76,8 +76,8 @@
     },
     {
       "name": "to-openspec",
-      "version": "0.1.1",
-      "hash": "sha256-223f00ac309e5365e77708e8f3fc22c36a02e52f4c071af54ea25ea4d9461965",
+      "version": "0.1.2",
+      "hash": "sha256-80d168bfb69993b2977f6b6bcec9657e020f79e7cd61347a0f514755014e4c38",
       "description": "Turn settled discovery notes and a sketched data model into a spec folder in openspec shape (proposal, spec, design, tasks) under specs/<slug>/. Runs in two stages with a human review between them. No interview, just synthesis of decisions already made. Trigger on \"write the spec\", \"to-openspec\", or \"/to-openspec <slug> [stage 2]\"."
     },
     {
@@ -88,8 +88,8 @@
     },
     {
       "name": "to-tickets",
-      "version": "0.1.2",
-      "hash": "sha256-13e639c6412c6d875d285e452fd0f8c64597c4653cedbbe0e7aa0c19cd717ec1",
+      "version": "0.1.3",
+      "hash": "sha256-50387c0abfab110d26b156521d99320e848aa942c319379b82d80fde59722903",
       "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."
     },
     {