@jesdi/skills 0.0.22 → 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
|
@@ -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
|
|
|
@@ -47,6 +47,8 @@ Break the work into **tracer bullet** tickets.
|
|
|
47
47
|
|
|
48
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.
|
|
49
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
|
+
|
|
50
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.
|
|
51
53
|
|
|
52
54
|
### 4. Quiz the user (attended only)
|
|
@@ -62,7 +64,7 @@ When a human is in the loop, present the proposed breakdown as a numbered list.
|
|
|
62
64
|
Ask the user:
|
|
63
65
|
|
|
64
66
|
- Does the granularity feel right? (too coarse / too fine)
|
|
65
|
-
- 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.)
|
|
66
68
|
- Should any tickets be merged or split further?
|
|
67
69
|
|
|
68
70
|
Iterate until the user approves the breakdown.
|
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
|
{
|
|
@@ -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
|
{
|