@jesdi/skills 0.0.21 → 0.0.23
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/package.json
CHANGED
|
@@ -31,7 +31,7 @@ Run ticket subagents in the background where possible for **maximum concurrency*
|
|
|
31
31
|
|
|
32
32
|
**Every dispatch prompt says: never `git stash`, reset or check out other branches; worktrees share one stash and one ref store.**
|
|
33
33
|
|
|
34
|
-
**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
|
|
34
|
+
**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 for a small, fully specified ticket; most capable for design judgment or broad codebase work. Merger: cheapest. Escalations: one tier above the agent that got stuck. Final reviewer: most capable.
|
|
35
35
|
|
|
36
36
|
**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.
|
|
37
37
|
|
|
@@ -55,7 +55,7 @@ Run ticket subagents in the background where possible for **maximum concurrency*
|
|
|
55
55
|
|
|
56
56
|
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.
|
|
57
57
|
|
|
58
|
-
8. If this changes the **frontier** of available tickets, start the next tickets. This allows for maximum concurrency. Exception: two ready tickets that change the same function never run at once. Compare their **Touches** lines (or ask the exploration subagent where each will land); on overlap, start one and hold the other until the first merges, then branch it from the updated PR branch. Record the hold as a ruling.
|
|
58
|
+
8. If this changes the **frontier** of available tickets, start the next tickets. This allows for maximum concurrency. Exception: two ready tickets that change the same function never run at once. Compare their **Touches** lines (or ask the exploration subagent where each will land); on overlap, start one and hold the other until the first merges, then branch it from the updated PR branch. When in doubt, hold: a ticket you suspect builds on another ready or running ticket waits for it, even without a declared edge. Record the hold as a ruling.
|
|
59
59
|
|
|
60
60
|
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.
|
|
61
61
|
|
|
@@ -54,6 +54,9 @@ stage 1. Re-read `proposal.md` and `spec.md` first; the human may have edited th
|
|
|
54
54
|
heading when the repo's template lacks it.
|
|
55
55
|
- **Seams**: the endpoint, function, or command the tests drive through, marked existing or
|
|
56
56
|
new. Prefer one high seam.
|
|
57
|
+
- No implementation code anywhere in the spec folder. `implement-spec`'s test-writer reads it
|
|
58
|
+
and must not know the solution. A decision's shape (a type, a schema, a state machine, a
|
|
59
|
+
seam's signature) may appear; the function bodies that make the tasks pass may not.
|
|
57
60
|
3. Write `specs/<slug>/tasks.md`: vertical slices, each small enough for one commit and one green
|
|
58
61
|
check command. Tests come first in each slice.
|
|
59
62
|
- Every task has its `_Goal:_` line, its **Seam** (one of the seams from `design.md`, precise
|
|
@@ -10,7 +10,8 @@ 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
11
|
observable behavior; every ticket names its **Seam** (the public interface its
|
|
12
12
|
acceptance tests hit) and what it **Touches** (files and functions, for
|
|
13
|
-
scheduling);
|
|
13
|
+
scheduling); trivial slices fold into a neighbour; tickets never carry the
|
|
14
|
+
implementation; the approval quiz is skipped when unattended; model invocation is
|
|
14
15
|
allowed.
|
|
15
16
|
-->
|
|
16
17
|
|
|
@@ -40,11 +41,14 @@ Break the work into **tracer bullet** tickets.
|
|
|
40
41
|
- A completed slice is demoable or verifiable on its own
|
|
41
42
|
- Each slice is sized to fit in a single fresh context window
|
|
42
43
|
- Any prefactoring should be done first
|
|
44
|
+
- No trivial tickets: when a slice's whole change is a small guard or fix (a few lines) and no other ticket is blocked by it, fold its acceptance criteria into the neighbouring ticket that touches the same behaviour. Every ticket costs a test-writer, implementer, reviewer and merger; a two-line guard doesn't earn four agents
|
|
43
45
|
|
|
44
46
|
</vertical-slice-rules>
|
|
45
47
|
|
|
46
48
|
Give each ticket its **blocking edges**: the other tickets that must complete before it can start. A ticket with no blockers can start immediately.
|
|
47
49
|
|
|
50
|
+
**When in doubt, block.** If you suspect a ticket might need to wait for another (it builds on that ticket's behaviour, touches the same files or functions, or the order just isn't obvious), add the edge. A missing edge costs broken locked tests, rebase churn and a re-run; an extra edge only costs some concurrency.
|
|
51
|
+
|
|
48
52
|
**Wide refactors are the exception to vertical slicing.** A **wide refactor** is one mechanical change (rename a column, retype a shared symbol) whose **blast radius** fans across the whole codebase, so a single edit breaks thousands of call sites at once and no vertical slice can land green. Don't force it into a tracer bullet; sequence it as **expand–contract**. First expand: add the new form beside the old so nothing breaks. Then migrate the call sites over in batches sized by blast radius (per package, per directory), each batch its own ticket blocked by the expand, keeping CI green batch to batch because the old form still exists. Finally contract: delete the old form once no caller remains, in a ticket blocked by every migrate batch. When even the batches can't stay green alone, keep the sequence but let them share an integration branch that all block a final integrate-and-verify ticket; green is promised only there.
|
|
49
53
|
|
|
50
54
|
### 4. Quiz the user (attended only)
|
|
@@ -60,7 +64,7 @@ When a human is in the loop, present the proposed breakdown as a numbered list.
|
|
|
60
64
|
Ask the user:
|
|
61
65
|
|
|
62
66
|
- Does the granularity feel right? (too coarse / too fine)
|
|
63
|
-
- Are the blocking edges correct:
|
|
67
|
+
- Are the blocking edges correct: is any edge missing? (Suspected dependencies are already listed as blockers; say which ones can safely go.)
|
|
64
68
|
- Should any tickets be merged or split further?
|
|
65
69
|
|
|
66
70
|
Iterate until the user approves the breakdown.
|
|
@@ -112,4 +116,6 @@ The **Touches** line is a best guess, for scheduling: `implement-spec` never run
|
|
|
112
116
|
|
|
113
117
|
</touches-rule>
|
|
114
118
|
|
|
115
|
-
|
|
119
|
+
Never write the implementation into a ticket. `implement-spec`'s test-writer reads the ticket and must not know the solution, or its acceptance tests stop being independent of the code they judge. Describe behaviour, not the fix.
|
|
120
|
+
|
|
121
|
+
Outside the **Touches** line, 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, the shape of the decision, never the code that implements the ticket.
|
package/skills-manifest.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schemaVersion": 1,
|
|
3
|
-
"generatedAt": "2026-09-
|
|
3
|
+
"generatedAt": "2026-09-30T22:33:10.162Z",
|
|
4
4
|
"skills": [
|
|
5
5
|
{
|
|
6
6
|
"name": "backlog",
|
|
@@ -46,8 +46,8 @@
|
|
|
46
46
|
},
|
|
47
47
|
{
|
|
48
48
|
"name": "implement-spec",
|
|
49
|
-
"version": "0.1.
|
|
50
|
-
"hash": "sha256-
|
|
49
|
+
"version": "0.1.4",
|
|
50
|
+
"hash": "sha256-2912e2fef79d278bb7c59bd72e9d3705cfe4597f20c95fd8f839604cc7cd4ea0",
|
|
51
51
|
"description": "Implement a specification in code."
|
|
52
52
|
},
|
|
53
53
|
{
|
|
@@ -76,8 +76,8 @@
|
|
|
76
76
|
},
|
|
77
77
|
{
|
|
78
78
|
"name": "to-openspec",
|
|
79
|
-
"version": "0.1.
|
|
80
|
-
"hash": "sha256-
|
|
79
|
+
"version": "0.1.2",
|
|
80
|
+
"hash": "sha256-80d168bfb69993b2977f6b6bcec9657e020f79e7cd61347a0f514755014e4c38",
|
|
81
81
|
"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]\"."
|
|
82
82
|
},
|
|
83
83
|
{
|
|
@@ -88,8 +88,8 @@
|
|
|
88
88
|
},
|
|
89
89
|
{
|
|
90
90
|
"name": "to-tickets",
|
|
91
|
-
"version": "0.1.
|
|
92
|
-
"hash": "sha256-
|
|
91
|
+
"version": "0.1.4",
|
|
92
|
+
"hash": "sha256-66822a4d85cd7b851d9073591723dbf228f58a1f8cb3ccf0fd9f57f38c90aca1",
|
|
93
93
|
"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."
|
|
94
94
|
},
|
|
95
95
|
{
|