@jesdi/skills 0.0.17 → 0.0.18

package/package.json

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

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-24T09:54:20.128Z",
   "skills": [
     {
       "name": "backlog",
@@ -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",