@jesdi/skills 0.0.25 → 0.0.26

package/package.json

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

package/skills/to-openspec/SKILL.md

@@ -2,10 +2,12 @@
 name: to-openspec
 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]".
+  in openspec shape (proposal, spec, design) under specs/<slug>/, plus ticket
+  files under .agent/tickets/ that implement-spec runs directly. Two stages:
+  stage 1 alone by default, with a human review before stage 2, or both at
+  once with "all". No interview, just synthesis of decisions already made.
+  Trigger on "write the spec", "to-openspec", or
+  "/to-openspec <slug> [stage 2 | all]".
 ---
 
 # To openspec
@@ -21,13 +23,16 @@ instead of inventing it. Never invent prices, policies, deadlines, or permission
   conversation.
 - Shape: read every file in the repo's `specs/_template/`, or in this skill's `templates/` when
   the repo has none. Keep the headings exactly; write "None." rather than dropping a section.
+  Ignore a `tasks.md` template: tickets replace it.
 - Check command: the one the repo documents (`make check`, or what AGENTS.md names).
+- Stages: no argument runs stage 1 and stops. `stage 2` runs stage 2 only. `all` runs both
+  without the stop in between.
 
 ## Stage 1: what and why
 
 Write `specs/<slug>/proposal.md` and `specs/<slug>/spec.md`.
 
-- **Goal** is one or two sentences. Every later task links back to it.
+- **Goal** is one or two sentences. Every ticket serves it.
 - **Non-goals** carry over every "later" or "never" verdict from discovery.
 - **Requirements** cover the v1 slice only: the smallest set that meets the goal. Each one is
   testable and maps to at least one scenario.
@@ -35,13 +40,14 @@ Write `specs/<slug>/proposal.md` and `specs/<slug>/spec.md`.
   Every invariant (overselling, expiry, refund permissions, and so on) gets a scenario for the
   boundary and one for the violation.
 
-Then **stop**. Print the requirement list and any open questions so the human can cut or correct
-the spec before the design is written. Don't write code.
+Then **stop**, unless invoked with `all`. Print the requirement list and any open questions so
+the human can cut or correct the spec before the design is written. Don't write code.
 
 ## Stage 2: how
 
-Run only when asked (for example "/to-openspec <slug> stage 2"), after the human has reviewed
-stage 1. Re-read `proposal.md` and `spec.md` first; the human may have edited them.
+Run only when asked: "/to-openspec <slug> stage 2" after the human has reviewed stage 1, or
+`all` straight after stage 1. On `stage 2`, re-read `proposal.md` and `spec.md` first; the
+human may have edited them.
 
 1. Run the `red-team-data-model` skill against the data model. Print the top 5, and its identity
    inventory when the change widens a key; don't write them to a file.
@@ -50,23 +56,24 @@ stage 1. Re-read `proposal.md` and `spec.md` first; the human may have edited th
    - **Data model**: every invariant a DB constraint can enforce (`CHECK`, `UNIQUE`, `NOT NULL`,
      FK, conditional `UPDATE ... WHERE`) goes in the table, not only in app code.
    - **Identities**: when the change widens a key, every item of the red-team's identity
-     inventory, marked covered (task IDs filled in step 3) or out of scope (why). Otherwise "None." Add the
+     inventory, marked covered (ticket numbers filled in step 3) or out of scope (why). Otherwise "None." Add the
      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
-     enough to write a black-box test against) and its **Blocked by** (task IDs, or none). That
-     makes the list a task graph `implement-spec` can run directly.
+     seam's signature) may appear; the function bodies that make the tickets pass may not.
+3. Run the `to-tickets` skill on `specs/<slug>/`, skipping its quiz (step 4): it writes
+   `.agent/tickets/<NN>-<slug>.md`, the task graph `implement-spec` runs directly. Don't write a
+   `tasks.md`. On top of its rules:
+   - Every scenario in `spec.md` is an acceptance criterion of some ticket.
+   - Each ticket's **Seam** is one of the seams from `design.md`.
    - A slice adds only the tables and columns its own scenarios need, not the whole model up front.
-   - No standalone "run the checks" task: every task already ends with the check command green.
-   - Then fill the task IDs into `design.md`'s **Identities**: every identity marked covered names
-     the task that rekeys it. A covered identity with no task is a missing task; add it.
+   - No standalone "run the checks" ticket: every ticket already ends with the check command green.
+   - Then fill the ticket numbers into `design.md`'s **Identities**: every identity marked covered
+     names the ticket that rekeys it. A covered identity with no ticket is a missing ticket; add it.
 
-Print the task list, then **Open questions**: every red-team finding the design leaves
+Print the ticket list (number, title, blocked by, seam, touches), then **Open questions**: every
+red-team finding the design leaves
 unresolved, and every input the design assumes but the sources don't provide. Then stop. Don't
 write code.

package/skills/to-openspec/templates/design.md

@@ -17,10 +17,10 @@ Tables/fields touched or added, and the invariants that go in DB constraints (no
 ## Identities
 
 When this change widens a key, each identity built from the old key (file names, hashes,
-dedupe keys, command args, dict keys): covered by which task, or out of scope and why. Otherwise
+dedupe keys, command args, dict keys): covered by which ticket, or out of scope and why. Otherwise
 "None."
 
-- `<identity>` — covered by <task> | out of scope: <why>.
+- `<identity>` — covered by <ticket> | out of scope: <why>.
 
 ## Seams
 

package/skills/to-openspec/templates/proposal.md

@@ -10,8 +10,7 @@ The actor(s) this serves (e.g. customer, staff, owner).
 
 ## Goal
 
-What "done" looks like for this slice. One or two sentences — this is what every task links back
-to.
+What "done" looks like for this slice. One or two sentences — this is what every ticket serves.
 
 ## Non-goals
 

package/skills-manifest.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-10-01T01:49:46.043Z",
+  "generatedAt": "2026-10-02T10:20:34.972Z",
   "skills": [
     {
       "name": "backlog",
@@ -76,9 +76,9 @@
     },
     {
       "name": "to-openspec",
-      "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]\"."
+      "version": "0.1.3",
+      "hash": "sha256-fa982c0960a4b07d6ec9c54076f831c1fb16a4e46b8ddd62acf86e5316345be7",
+      "description": "Turn settled discovery notes and a sketched data model into a spec folder in openspec shape (proposal, spec, design) under specs/<slug>/, plus ticket files under .agent/tickets/ that implement-spec runs directly. Two stages: stage 1 alone by default, with a human review before stage 2, or both at once with \"all\". No interview, just synthesis of decisions already made. Trigger on \"write the spec\", \"to-openspec\", or \"/to-openspec <slug> [stage 2 | all]\"."
     },
     {
       "name": "to-spec",

package/skills/to-openspec/templates/tasks.md

@@ -1,9 +0,0 @@
-# <Feature title> — Tasks
-
-Each task links to the goal in proposal.md. Work the frontier (tasks whose blockers are done);
-commit per task with its ID.
-
-- [ ] **T1** — <task>. _Goal: <one line, why this task serves proposal.md's goal>._
-  Seam: <endpoint / function / command from design.md>. Blocked by: none.
-- [ ] **T2** — <task>. _Goal: ..._
-  Seam: .... Blocked by: T1.