@jesdi/skills 0.0.16 → 0.0.17

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -70,13 +70,13 @@ versions; `npx skills update` refreshes them.
70
70
 
71
71
  ### Forks (the one exception)
72
72
 
73
- `to-spec`, `to-tickets`, `prototype` and `wizard` are modified copies of the
74
- mattpocock/skills originals, vendored under `skills/<name>/` with the upstream
75
- MIT `LICENSE` and a header naming the upstream commit. They keep their upstream
76
- names on purpose, so **never install the upstream copies of those four names
77
- alongside them** (`npx skills add mattpocock/skills` installs the whole set —
78
- deselect those four, or uninstall them afterwards). `external-skills.json`
79
- lists them under `forks`.
73
+ `implement-spec`, `to-spec`, `to-tickets`, `prototype` and `wizard` are
74
+ modified copies of the mattpocock/skills originals, vendored under
75
+ `skills/<name>/` with the upstream MIT `LICENSE` and a header naming the
76
+ upstream commit. They keep their upstream names on purpose, so **never install
77
+ the upstream copies of those five names alongside them** (`npx skills add
78
+ mattpocock/skills` installs the whole set — deselect those five, or uninstall
79
+ them afterwards). `external-skills.json` lists them under `forks`.
80
80
 
81
81
  ### The box set
82
82
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@jesdi/skills",
3
- "version": "0.0.16",
3
+ "version": "0.0.17",
4
4
  "description": "jesdi's agent skills (content package consumed by @jesdi/skills-cli)",
5
5
  "license": "MIT",
6
6
  "repository": {
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2026 Matt Pocock
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.
@@ -0,0 +1,55 @@
1
+ ---
2
+ name: implement-spec
3
+ description: "Implement a specification in code."
4
+ disable-model-invocation: true
5
+ ---
6
+
7
+ <!--
8
+ Modified copy of https://github.com/mattpocock/skills/tree/5b15a47f2d7150f545fbcacbfe381787fc0230dc/skills/in-progress/implement-spec
9
+ (in-progress, after mattpocock-skills v1.2.3). Copyright (c) 2026 Matt Pocock, MIT — see LICENSE.
10
+ Changes: a model tier per subagent; a context-isolated test-writer commits
11
+ locked acceptance tests at the ticket's Seam, the implementer turns them green
12
+ with /tdd and reports to a contract; per-ticket review before merge, fix loop
13
+ capped at 4 rounds with escalation; a ruling ledger and four stop conditions;
14
+ full suite after each merge; final /review-diff on the most capable model, one
15
+ fixer; closes tickets only if they are issues. Review loop and ledger adapt
16
+ superpowers' subagent-driven-development (obra/superpowers, MIT).
17
+ -->
18
+
19
+ You have been provided a spec. This spec should have tickets associated with it, describing how to implement the spec.
20
+
21
+ The goal is a PR which implements the entire spec on a single branch.
22
+
23
+ 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.
24
+
25
+ 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.
26
+
27
+ Run ticket subagents in the background where possible for **maximum concurrency**.
28
+
29
+ **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.
30
+
31
+ **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.
32
+
33
+ ## Steps
34
+
35
+ 1. Read the spec and tickets. Read enough to understand the task graph.
36
+
37
+ 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.
38
+
39
+ 3. Create a branch, and a draft PR. If the spec and tickets are issues, mark the PR as 'closing' them.
40
+
41
+ 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.
42
+
43
+ 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.
44
+
45
+ 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.
46
+
47
+ 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.
48
+
49
+ 8. If this changes the **frontier** of available tickets, start the next tickets. This allows for maximum concurrency.
50
+
51
+ 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.
52
+
53
+ 10. Mark the PR as ready for review. List every ruling from the ledger in your final message.
54
+
55
+ 11. Clean up all ticket worktrees.
@@ -0,0 +1,5 @@
1
+ interface:
2
+ display_name: "Implement Spec"
3
+ short_description: "Implement a whole spec as one PR"
4
+ policy:
5
+ allow_implicit_invocation: false
@@ -8,7 +8,8 @@ Modified copy of https://github.com/mattpocock/skills/tree/3cca18b368ae95cdbdebb
8
8
  (mattpocock-skills v1.2.3). Copyright (c) 2026 Matt Pocock, MIT — see LICENSE.
9
9
  Changes: tickets always go to `.agent/tickets/<NN>-<slug>.md` (no tracker path);
10
10
  numbering is contiguous from 01 in dependency order; acceptance criteria must state
11
- observable behavior; the approval quiz is skipped when unattended; model
11
+ observable behavior; every ticket names its **Seam** (the public interface its
12
+ acceptance tests hit); the approval quiz is skipped when unattended; model
12
13
  invocation is allowed.
13
14
  -->
14
15
 
@@ -51,6 +52,7 @@ When a human is in the loop, present the proposed breakdown as a numbered list.
51
52
 
52
53
  - **Title**: short descriptive name
53
54
  - **Blocked by**: which other tickets (if any) must complete first
55
+ - **Seam**: the public interface its acceptance tests hit
54
56
  - **What it delivers**: the end-to-end behaviour this ticket makes work
55
57
 
56
58
  Ask the user:
@@ -81,6 +83,8 @@ Do NOT close or modify any parent issue.
81
83
 
82
84
  **Blocked by:** the numbers/titles of the tickets that gate this one, or "None (can start immediately)".
83
85
 
86
+ **Seam:** the public interface the acceptance tests hit (a function, an HTTP route, a CLI command, a config loader…), or `none — refactor`.
87
+
84
88
  - [ ] Acceptance criterion 1
85
89
  - [ ] Acceptance criterion 2
86
90
 
@@ -92,4 +96,10 @@ Every acceptance criterion states **observable behavior**: something a reviewer
92
96
 
93
97
  </acceptance-criteria-rule>
94
98
 
99
+ <seam-rule>
100
+
101
+ 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.
102
+
103
+ </seam-rule>
104
+
95
105
  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.
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "schemaVersion": 1,
3
- "generatedAt": "2026-09-23T16:36:43.907Z",
3
+ "generatedAt": "2026-09-24T09:06:27.178Z",
4
4
  "skills": [
5
5
  {
6
6
  "name": "backlog",
@@ -44,6 +44,12 @@
44
44
  "hash": "sha256-916ea397cd74d91c4b6060672088b9c54353c915b98bcaef3514815694842e5a",
45
45
  "description": "Minimal example skill proving the distribution pipeline works. Responds to \"test my skills setup\" by confirming the skill is loaded."
46
46
  },
47
+ {
48
+ "name": "implement-spec",
49
+ "version": "0.1.0",
50
+ "hash": "sha256-95c4889bd41cbb8eb6522cbea5b074779b0964e521e6decbe801d52734921ecb",
51
+ "description": "Implement a specification in code."
52
+ },
47
53
  {
48
54
  "name": "pr-visual-diff",
49
55
  "version": "0.1.0",
@@ -70,8 +76,8 @@
70
76
  },
71
77
  {
72
78
  "name": "to-tickets",
73
- "version": "0.1.0",
74
- "hash": "sha256-23e1381b40dd4ffa151a2f89dcb82462464ea424228b45a31e6656406d34fedc",
79
+ "version": "0.1.1",
80
+ "hash": "sha256-4c838fa240c742353f77b3a3c1246a0948140587e81c9bc587f84c648e552bba",
75
81
  "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."
76
82
  },
77
83
  {