@jesdi/skills 0.0.16 → 0.0.18

package/README.md

@@ -70,13 +70,13 @@ versions; `npx skills update` refreshes them.
 
 ### Forks (the one exception)
 
-`to-spec`, `to-tickets`, `prototype` and `wizard` are modified copies of the
-mattpocock/skills originals, vendored under `skills/<name>/` with the upstream
-MIT `LICENSE` and a header naming the upstream commit. They keep their upstream
-names on purpose, so **never install the upstream copies of those four names
-alongside them** (`npx skills add mattpocock/skills` installs the whole set —
-deselect those four, or uninstall them afterwards). `external-skills.json`
-lists them under `forks`.
+`implement-spec`, `to-spec`, `to-tickets`, `prototype` and `wizard` are
+modified copies of the mattpocock/skills originals, vendored under
+`skills/<name>/` with the upstream MIT `LICENSE` and a header naming the
+upstream commit. They keep their upstream names on purpose, so **never install
+the upstream copies of those five names alongside them** (`npx skills add
+mattpocock/skills` installs the whole set — deselect those five, or uninstall
+them afterwards). `external-skills.json` lists them under `forks`.
 
 ### The box set
 

package/package.json

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

package/skills/implement-spec/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Matt Pocock
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/implement-spec/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: implement-spec
+description: "Implement a specification in code."
+disable-model-invocation: true
+---
+
+<!--
+Modified copy of https://github.com/mattpocock/skills/tree/5b15a47f2d7150f545fbcacbfe381787fc0230dc/skills/in-progress/implement-spec
+(in-progress, after mattpocock-skills v1.2.3). Copyright (c) 2026 Matt Pocock, MIT — see LICENSE.
+Changes: a model tier per subagent; a context-isolated test-writer commits
+locked acceptance tests at the ticket's Seam, the implementer turns them green
+with /tdd and reports to a contract; per-ticket review before merge, fix loop
+capped at 4 rounds with escalation; a ruling ledger and four stop conditions;
+full suite 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
+superpowers' subagent-driven-development (obra/superpowers, MIT).
+-->
+
+You have been provided a spec. This spec should have tickets associated with it, describing how to implement the spec.
+
+The goal is a PR which implements the entire spec on a single branch.
+
+The tickets are not a list of steps. They are a **task graph** with blocking relationships between them. This means there is always a **frontier** of tickets which are ready to be grabbed.
+
+Communication to and from subagents should be sparse. Communicate primarily through **context pointers**: to the spec, tickets, research notes, and previous commits. Don't duplicate information already available via pointers.
+
+Run ticket subagents in the background where possible for **maximum concurrency**.
+
+**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.
+
+**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.
+
+## Steps
+
+1. Read the spec and tickets. Read enough to understand the task graph.
+
+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.
+
+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. Those files are now **locked**. A ticket with no behavioral criteria (Seam: `none — refactor`) skips this: its existing tests are the contract, unmodified.
+
+5. An **implementer subagent** starts from that commit and makes the locked tests green, using /tdd vertical slices for anything internal. It never edits locked files and never dispatches subagents. It reports: status (DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT or BLOCKED), commits, red→green evidence for locked tests and its own slices, files touched, concerns. If a locked test contradicts the spec or ticket, it reports BLOCKED with evidence; you rule, and either send the test-writer a correction or overrule the implementer. Handle any BLOCKED by changing something: more context, a stronger model, a split ticket, or a ruling. Never retry unchanged.
+
+6. On DONE, a **reviewer subagent** checks the diff against the ticket and spec, then for quality. It also checks that `git diff <test-writer-sha>..HEAD -- <locked files>` is empty and that every criterion has a locked test. Critical or Important findings start a fix loop of at most 4 rounds, each a fix plus a re-review scoped to that fix: rounds 1-2 resume the implementer; rounds 3-4 go to a fresh implementer one tier up. After round 4, rule on each open finding in the ledger and move on. Minor findings go to the ledger for the final review.
+
+7. Once a ticket passes review, a **merger subagent** merges it to the PR branch and runs the full test 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.
+
+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.
+
+11. Clean up all ticket worktrees.

package/skills/implement-spec/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Implement Spec"
+  short_description: "Implement a whole spec as one PR"
+policy:
+  allow_implicit_invocation: false

package/skills/red-team-data-model/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: red-team-data-model
+description: >-
+  Attack a proposed or existing data model for the ways it breaks under real
+  conditions — concurrency, time windows, money, permissions — without
+  proposing a redesign. Use right after sketching a data model, before
+  writing the spec, so the top failure scenarios shape the spec's
+  requirements and tests instead of getting discovered mid-build. Trigger on
+  "red-team my data model", "what breaks in this schema", or "/red-team".
+---
+
+# Red-team the data model
+
+## Rule
+
+Don't improve or redesign. Attack it. The output is a list of ways it fails, not a fix.
+
+## Prompt
+
+Given the tables/fields (from `design.md` or a sketch), produce:
+
+**Top 5 failure scenarios**, ranked worst-consequence-first. Each one:
+
+- **Table/field** — exactly which part of the model is implicated.
+- **Scenario** — the concrete sequence of events that breaks it (two users, two
+  requests, a clock, a race — be specific, not "concurrency issues could
+  occur").
+- **Consequence** — what actually goes wrong in business terms (double-sold
+  stock, a refund that never happens, a stranger seeing another customer's
+  order, money debited twice).
+
+## Focus areas, in this order
+
+1. **Concurrency** — two actors racing the same row (two checkouts, one unit
+   of stock; two edits, one record).
+2. **Time windows** — expiry, deadlines, "usually ready within X", reminder
+   timing, what happens exactly at the boundary and one tick after it.
+3. **Money** — partial payments, refund correctness, rounding, double-charge
+   on retry, what happens if a webhook never arrives.
+4. **Permissions** — who can see or mutate what; staff vs. customer vs. owner
+   boundaries; what an authenticated-but-wrong-role request can still reach.
+
+## What NOT to do
+
+- Don't suggest schema changes, indexes, or constraints — that's the design
+  session's job, after this list exists.
+- Don't hedge with "it depends" — pick the worst plausible interpretation and
+  state its consequence.
+- Don't produce more than 5. Rank and cut; the top failure matters more than
+  a complete list.

package/skills/to-openspec/SKILL.md

@@ -0,0 +1,64 @@
+---
+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]".
+---
+
+# To openspec
+
+Synthesize, don't decide. Every decision comes from `discovery.md`, the design sketch, or the
+conversation. If one is missing, list it under **Open questions** at the end of your reply
+instead of inventing it. Never invent prices, policies, deadlines, or permissions.
+
+## Input
+
+- `<slug>`: kebab-case, becomes `specs/<slug>/`. Derive one from the goal if not given.
+- Sources: `discovery.md` (verdicts, non-goals, open questions), the data-model sketch, and the
+  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.
+- Check command: the one the repo documents (`make check`, or what AGENTS.md names).
+
+## 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.
+- **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.
+- **Scenarios** are Given/When/Then with concrete values (quantities, amounts, times, roles).
+  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.
+
+## 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.
+
+1. Run the `red-team-data-model` skill against the data model. Print the top 5; don't write them
+   to a file.
+2. Write `specs/<slug>/design.md`:
+   - **Decisions**: one line each with its tradeoff. Include the ones the red-team findings force.
+   - **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.
+   - **Seams**: the endpoint, function, or command the tests drive through, marked existing or
+     new. Prefer one high seam.
+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.
+   - 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.
+
+Print the task list, 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

@@ -0,0 +1,19 @@
+# <Feature title> — Design
+
+## Decisions
+
+One line each: the decision and its tradeoff.
+
+- **<decision>** — <tradeoff, one line>.
+
+## Data model
+
+Tables/fields touched or added, and the invariants that go in DB constraints (not just app code).
+
+| Table | Field | Constraint | Why |
+|---|---|---|---|
+| | | | |
+
+## Seams
+
+Where tests drive through: module, function, command, or endpoint. Mark each existing or new.

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

@@ -0,0 +1,18 @@
+# <Feature title>
+
+## Why
+
+What problem this solves, from the user's perspective. One paragraph.
+
+## For whom
+
+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.
+
+## Non-goals
+
+Explicitly out of scope for this slice, so nobody re-litigates it mid-build.

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

@@ -0,0 +1,22 @@
+# <Feature title> — Spec
+
+## Requirements
+
+Numbered, testable requirements. Each one should map to at least one scenario below.
+
+1. ...
+
+## Scenarios
+
+Given/When/Then, one per requirement (or per edge case of a requirement). These are what the
+tests get written from.
+
+### Scenario: <name>
+
+- **Given** ...
+- **When** ...
+- **Then** ...
+
+## Out of scope
+
+Carried over from proposal.md's non-goals if relevant to a reader who only opens this file.

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

@@ -0,0 +1,9 @@
+# <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.

package/skills/to-tickets/SKILL.md

@@ -8,7 +8,8 @@ Modified copy of https://github.com/mattpocock/skills/tree/3cca18b368ae95cdbdebb
 (mattpocock-skills v1.2.3). Copyright (c) 2026 Matt Pocock, MIT — see LICENSE.
 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; the approval quiz is skipped when unattended; model
+observable behavior; every ticket names its **Seam** (the public interface its
+acceptance tests hit); the approval quiz is skipped when unattended; model
 invocation is allowed.
 -->
 
@@ -51,6 +52,7 @@ When a human is in the loop, present the proposed breakdown as a numbered list.
 
 - **Title**: short descriptive name
 - **Blocked by**: which other tickets (if any) must complete first
+- **Seam**: the public interface its acceptance tests hit
 - **What it delivers**: the end-to-end behaviour this ticket makes work
 
 Ask the user:
@@ -81,6 +83,8 @@ Do NOT close or modify any parent issue.
 
 **Blocked by:** the numbers/titles of the tickets that gate this one, or "None (can start immediately)".
 
+**Seam:** the public interface the acceptance tests hit (a function, an HTTP route, a CLI command, a config loader…), or `none — refactor`.
+
 - [ ] Acceptance criterion 1
 - [ ] Acceptance criterion 2
 
@@ -92,4 +96,10 @@ Every acceptance criterion states **observable behavior**: something a reviewer
 
 </acceptance-criteria-rule>
 
+<seam-rule>
+
+Every ticket carries a **Seam** line: the one public interface through which its acceptance criteria are tested, black-box. `implement-spec` hands it to a test-writer that sees nothing else of the code, so name it precisely enough to write a test against, and never an internal helper. A ticket with no behavioral criteria (a pure prefactor or refactor) says `none — refactor`: its existing tests are the contract.
+
+</seam-rule>
+
 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.

package/skills-manifest.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-09-23T16:36:43.907Z",
+  "generatedAt": "2026-09-24T09:54:20.128Z",
   "skills": [
     {
       "name": "backlog",
@@ -44,6 +44,12 @@
       "hash": "sha256-916ea397cd74d91c4b6060672088b9c54353c915b98bcaef3514815694842e5a",
       "description": "Minimal example skill proving the distribution pipeline works. Responds to \"test my skills setup\" by confirming the skill is loaded."
     },
+    {
+      "name": "implement-spec",
+      "version": "0.1.0",
+      "hash": "sha256-95c4889bd41cbb8eb6522cbea5b074779b0964e521e6decbe801d52734921ecb",
+      "description": "Implement a specification in code."
+    },
     {
       "name": "pr-visual-diff",
       "version": "0.1.0",
@@ -56,12 +62,24 @@
       "hash": "sha256-211e0e116ff6efbc4589ea7264835855b9495ba535f242733af913903fe7707d",
       "description": "Build a throwaway prototype to answer a design question, delivered as one self-contained HTML file. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like."
     },
+    {
+      "name": "red-team-data-model",
+      "version": "0.1.0",
+      "hash": "sha256-3c7a00bbb05190a431ea101db79b6e27bbfc6c8b24b14b0fe560a82a201afdb9",
+      "description": "Attack a proposed or existing data model for the ways it breaks under real conditions — concurrency, time windows, money, permissions — without proposing a redesign. Use right after sketching a data model, before writing the spec, so the top failure scenarios shape the spec's requirements and tests instead of getting discovered mid-build. Trigger on \"red-team my data model\", \"what breaks in this schema\", or \"/red-team\"."
+    },
     {
       "name": "review-diff",
       "version": "0.1.0",
       "hash": "sha256-f1efdffdad0abf536777a3afcc733b2612ed51abad0b1a04d24f280bf2f223d3",
       "description": "Review a branch before merge: first a gate (the repo's check command plus crap-gate), then three independent reviewers in parallel — spec (did we build what was asked, no more, no less), correctness via Codex (races, idempotency, money, time, authz, indexes, N+1, migrations, error paths, test quality) and structure (deep-quality-review). `--quick` runs only spec and correctness, shortened, for a live interview. Use when the user says \"/review-diff\", \"review this branch\", \"review this slice\", \"review before merge\", or before closing out a spec task."
     },
+    {
+      "name": "to-openspec",
+      "version": "0.1.0",
+      "hash": "sha256-c3c66a08fe27afa1f530989b77c7b4fd2d6a379cc844a9ca5f55072bede9b64a",
+      "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]\"."
+    },
     {
       "name": "to-spec",
       "version": "0.1.0",
@@ -70,8 +88,8 @@
     },
     {
       "name": "to-tickets",
-      "version": "0.1.0",
-      "hash": "sha256-23e1381b40dd4ffa151a2f89dcb82462464ea424228b45a31e6656406d34fedc",
+      "version": "0.1.1",
+      "hash": "sha256-4c838fa240c742353f77b3a3c1246a0948140587e81c9bc587f84c648e552bba",
       "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."
     },
     {