@jesdi/skills 0.0.17 → 0.0.19

package/package.json

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

package/skills/implement-spec/SKILL.md

@@ -11,7 +11,7 @@ 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
+a per-ticket gate (check command + crap-gate) before DONE, re-run by the reviewer; 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
 superpowers' subagent-driven-development (obra/superpowers, MIT).
 -->
@@ -40,11 +40,11 @@ Run ticket subagents in the background where possible for **maximum concurrency*
 
 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.
+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. Before reporting DONE it runs the **gate** in its worktree: the repo's check command (lint, typecheck, full test suite: `make check`, or what AGENTS.md documents) and, when the repo has `.crap-gate.json`, crap-gate scoped to the ticket (`run.sh --base <PR branch>`, or the repo's `make crap-gate` wrapper). DONE means both are green; a gate it can't turn green is BLOCKED, with the output. It reports: status (DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT or BLOCKED), commits, red→green evidence for locked tests and its own slices, the gate's final lines, 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.
+6. On DONE, a **reviewer subagent** re-runs the gate first (a red gate is a Critical finding; don't trust the report), then 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.
+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.
 

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-manifest.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-09-24T09:06:27.178Z",
+  "generatedAt": "2026-09-24T15:29:01.254Z",
   "skills": [
     {
       "name": "backlog",
@@ -46,8 +46,8 @@
     },
     {
       "name": "implement-spec",
-      "version": "0.1.0",
-      "hash": "sha256-95c4889bd41cbb8eb6522cbea5b074779b0964e521e6decbe801d52734921ecb",
+      "version": "0.1.1",
+      "hash": "sha256-678f3481bce18448d0d27ef33c096d4b64faf8dd7254dd8d0bc73f8c134a7f58",
       "description": "Implement a specification in code."
     },
     {
@@ -62,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",