@jesdi/skills 0.0.27 → 0.0.28
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
|
@@ -47,8 +47,25 @@ npx @jesdi/skills-cli update [skill] [--all] [--global]
|
|
|
47
47
|
npx @jesdi/skills-cli sync
|
|
48
48
|
npx @jesdi/skills-cli list
|
|
49
49
|
npx @jesdi/skills-cli uninstall <skill> [--global]
|
|
50
|
+
npx @jesdi/skills-cli pin <skill> [--global] # keep the installed version
|
|
51
|
+
npx @jesdi/skills-cli unpin <skill> [--global]
|
|
52
|
+
npx @jesdi/skills-cli hook # register the session update hook
|
|
50
53
|
```
|
|
51
54
|
|
|
55
|
+
## Automatic updates
|
|
56
|
+
|
|
57
|
+
A global install registers a session-start hook in Claude Code
|
|
58
|
+
(`~/.claude/settings.json`) and Codex (`~/.codex/hooks.json`), for each one
|
|
59
|
+
that is present. The first session of a day runs
|
|
60
|
+
`skills-cli update --all --global` in the background; the result is in
|
|
61
|
+
`~/.my-skills/.session-update.log`. Project installs do not change: they stay
|
|
62
|
+
at the versions committed in `.my-skills.json`.
|
|
63
|
+
|
|
64
|
+
To keep a skill at its installed version, pin it: `skills-cli pin <skill>
|
|
65
|
+
--global`. No update touches a pinned skill until `unpin`. To stop all
|
|
66
|
+
automatic updates, remove the hook entry from the two config files; the next
|
|
67
|
+
global install or `skills-cli hook` adds it again.
|
|
68
|
+
|
|
52
69
|
## Third-party skills (not vendored)
|
|
53
70
|
|
|
54
71
|
Skills authored by other people are **not** copied into this repo — they keep
|
package/package.json
CHANGED
|
@@ -15,7 +15,8 @@ a per-ticket gate (check command + crap-gate) before DONE, re-run by the reviewe
|
|
|
15
15
|
already-green locked tests need a demonstrated mutation; a Codex correctness
|
|
16
16
|
pass per risky ticket; tickets touching the same functions run in sequence;
|
|
17
17
|
check command after each merge; final /review-diff on the most capable model, one
|
|
18
|
-
fixer;
|
|
18
|
+
fixer; ticket-grouped history with fixes folded in before review; closes
|
|
19
|
+
tickets only if they are issues; no push and no PR until every
|
|
19
20
|
ticket is merged and the final review has passed. Review loop and ledger adapt
|
|
20
21
|
superpowers' subagent-driven-development (obra/superpowers, MIT).
|
|
21
22
|
-->
|
|
@@ -57,14 +58,14 @@ Run ticket subagents in the background where possible for **maximum concurrency*
|
|
|
57
58
|
|
|
58
59
|
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.
|
|
59
60
|
|
|
60
|
-
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.
|
|
61
|
+
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. Record the ticket's commits and any integration fixes in the ledger. After the merge and checks pass, remove that ticket's worktree and delete its branch with `git branch -d` from the PR branch, while its commits are still ancestors of the PR tip. Cleanup is part of completing the ticket, before any rebase.
|
|
61
62
|
|
|
62
63
|
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.
|
|
63
64
|
|
|
64
|
-
9. Once all tickets are complete,
|
|
65
|
+
9. Once all tickets are complete, fetch and rebase the unpublished PR branch onto the latest base, then tidy its history by ticket using [history.md](history.md). A reviewer on the most capable model runs /review-diff on the resulting PR branch, given the ledger's minor findings and rulings. Record its resolved range and reviewed tip in the ledger. One **implementer subagent** fixes every finding as one batch, which may contain several working commits; it records the owning ticket for each fix. Use targeted checks during the fixes. Once the whole batch is complete, tidy it into the ticket commits, then run /review-diff on the full rewritten branch. If history was preserved, a scoped /review-diff on `<last-reviewed-tip>..HEAD` suffices. Its gate runs once for the completed batch. Record the new review's range and tip, marking superseded coverage, or `not needed` if there were no fixes. Rule on anything left.
|
|
65
66
|
|
|
66
|
-
10.
|
|
67
|
-
spec and tickets are issues, mark the PR as 'closing' them. List every ruling from the ledger in
|
|
68
|
-
your final message.
|
|
67
|
+
10. Before pushing, compare `git rev-parse HEAD` with the last reviewed tip and confirm the worktree is clean. Every commit through the branch tip must be covered by the full review plus any scoped re-reviews. Collect any later commits, including orchestrator changes, into one batch and follow step 9's tidy-and-review procedure. A rebase or history rewrite invalidates the recorded coverage: review the full rewritten branch, with one full gate for that completed batch. The push is ready only when the history is grouped by ticket, the clean branch tip equals the last reviewed tip, and every finding has a fix or a ledger ruling. If the review cannot finish, report the blocker and each unreviewed commit with its subject, and keep the branch local.
|
|
69
68
|
|
|
70
|
-
|
|
69
|
+
Now push the PR branch once and open the PR, ready for review (not draft), using /pr for the body when installed. If the spec and tickets are issues, mark the PR as 'closing' them. In your final message, list every ruling, the final ticket-to-commit map, and the review coverage: the latest full review's range and tip, any scoped re-review ranges and tips since it (or `not needed`), the current branch tip, and whether it equals the last reviewed tip. Earlier reviews of superseded history stay in the ledger.
|
|
70
|
+
|
|
71
|
+
11. Confirm every ticket worktree and branch was removed in step 7.
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
# History by ticket
|
|
2
|
+
|
|
3
|
+
Tidy the unpublished integration branch into one coherent commit per ticket,
|
|
4
|
+
ordered so each ticket follows its dependencies. Each commit contains that
|
|
5
|
+
ticket's acceptance tests, implementation, and all review or integration fixes.
|
|
6
|
+
The reviewer's commit list should tell the story of the tickets, with the
|
|
7
|
+
final behavior at each step.
|
|
8
|
+
|
|
9
|
+
## Before rewriting
|
|
10
|
+
|
|
11
|
+
- Confirm all ticket worktrees and branches were cleaned up after their merges,
|
|
12
|
+
and that the integration worktree is clean.
|
|
13
|
+
- Confirm the branch has never been pushed. Once pushed, preserve its history
|
|
14
|
+
and add reviewed follow-up commits; rewriting a published branch requires
|
|
15
|
+
explicit user authorization.
|
|
16
|
+
- Record the current tip and `HEAD^{tree}` in the ledger as the recovery point.
|
|
17
|
+
Use the ticket reports and ledger to map every working commit and every fix
|
|
18
|
+
to its owning ticket before editing history.
|
|
19
|
+
|
|
20
|
+
## Group the changes
|
|
21
|
+
|
|
22
|
+
Use an interactive rebase or reconstruct the commits in an isolated worktree,
|
|
23
|
+
operating only on branch-owned commits after the base. Fold red-test commits,
|
|
24
|
+
implementation commits, and later fixes into their ticket commit. Flatten
|
|
25
|
+
branch-only merge commits while preserving their conflict-resolution changes.
|
|
26
|
+
Keep the test-writer's acceptance files unchanged from their locked versions.
|
|
27
|
+
|
|
28
|
+
A fix touching several tickets is split by ownership when the resulting
|
|
29
|
+
commits can stand alone in dependency order. If it cannot be split safely,
|
|
30
|
+
combine the affected tickets into one coherent commit, name them in the
|
|
31
|
+
message, and record the reason in the ledger. Every final change has a ticket
|
|
32
|
+
owner; an out-of-scope change needs a ruling before inclusion.
|
|
33
|
+
|
|
34
|
+
Use a commit subject that names the ticket's delivered behavior and put its
|
|
35
|
+
ticket number or file pointer in the body. Keep a map from the old working
|
|
36
|
+
commits to the final ticket commits in the ledger; ticket reports and locked
|
|
37
|
+
test SHAs still refer to the original history.
|
|
38
|
+
|
|
39
|
+
## Completion
|
|
40
|
+
|
|
41
|
+
The rewritten tip's tree must equal the saved tree: history cleanup changes
|
|
42
|
+
the presentation of the work, not its files. A mismatch must be resolved
|
|
43
|
+
before review. Inspect each final commit's diff against its ticket to confirm
|
|
44
|
+
the tests, implementation, and fixes stayed together, dependencies precede
|
|
45
|
+
their consumers, and no temporary red-test or fix-only commits remain.
|
|
46
|
+
|
|
47
|
+
Use targeted checks where needed to verify a regrouped ticket. Run the full
|
|
48
|
+
gate once at the completed branch tip, through /review-diff. Rewriting changes
|
|
49
|
+
the review endpoints, so the next review covers the full rewritten branch;
|
|
50
|
+
mark the old coverage superseded even if the tip's tree is identical. After a
|
|
51
|
+
review requests fixes, finish the whole fix batch, fold it into these same
|
|
52
|
+
ticket commits, and repeat this completion check before the next review.
|
|
@@ -37,6 +37,15 @@ on one axis must not hide a failure on another.
|
|
|
37
37
|
Before anything else, confirm the range resolves and the diff is non-empty. A
|
|
38
38
|
bad ref fails here, not inside three reviewers.
|
|
39
39
|
|
|
40
|
+
Resolve the diff endpoints to commit SHAs once, before the gate, and use that
|
|
41
|
+
immutable range for every reviewer and the commit list. For a base ref, the
|
|
42
|
+
start is its merge-base with the captured `HEAD`; for an explicit range, keep
|
|
43
|
+
its requested diff semantics. Record the reviewed tip (the right endpoint)
|
|
44
|
+
and the branch tip at the start. Run the gate on that reviewed tip in a clean
|
|
45
|
+
worktree; an explicit range ending at another commit needs a worktree at that
|
|
46
|
+
commit. Local changes must be committed or removed before review so the range
|
|
47
|
+
accounts for everything checked.
|
|
48
|
+
|
|
40
49
|
## Step 0 — gate (sequential, a precondition, not a reviewer)
|
|
41
50
|
|
|
42
51
|
1. Run the repo's check command: `make check` if the Makefile has it,
|
|
@@ -70,7 +79,7 @@ paste one reviewer's output into another's prompt.
|
|
|
70
79
|
```bash
|
|
71
80
|
out=$(mktemp) && codex exec -s read-only --ephemeral -o "$out" \
|
|
72
81
|
"Read and follow <skill-dir>/correctness.md. Range: <range>. Commits: <list>.<quick>" \
|
|
73
|
-
>/dev/null 2>&1; cat "$out"
|
|
82
|
+
< /dev/null >/dev/null 2>&1; cat "$out"
|
|
74
83
|
```
|
|
75
84
|
|
|
76
85
|
No Codex → spawn a subagent with the same instruction and note "Correctness:
|
|
@@ -88,6 +97,7 @@ fresh context if you can, and say so.
|
|
|
88
97
|
|
|
89
98
|
```
|
|
90
99
|
Gate: `make check` green · crap-gate green
|
|
100
|
+
Coverage: <resolved range> · reviewed tip: <SHA> · current branch tip: <SHA> · tip matches: yes/no
|
|
91
101
|
|
|
92
102
|
## Spec
|
|
93
103
|
<report, verbatim or lightly cleaned>
|
|
@@ -107,6 +117,15 @@ A skipped step keeps its place with its one-line note (in the gate line, or
|
|
|
107
117
|
as the section body and summary line). `--quick` has no Structure section and
|
|
108
118
|
no Structure summary line. A clean reviewer's summary line is `0 findings`.
|
|
109
119
|
|
|
120
|
+
Read the original branch tip again when reporting. Include the coverage line
|
|
121
|
+
in full and quick reviews, and label a failed gate `review not run` rather
|
|
122
|
+
than calling its endpoint reviewed. Name skipped or failed reviewers so the
|
|
123
|
+
coverage line cannot imply they ran. If the branch tip changed, list each
|
|
124
|
+
commit in `<reviewed-tip>..<current-tip>` with its subject. If the reviewed tip
|
|
125
|
+
is no longer an ancestor (for example, after a rebase or history cleanup), state that this review
|
|
126
|
+
does not cover the current history. Report a dirty worktree as unreviewed
|
|
127
|
+
local changes even when the tips match.
|
|
128
|
+
|
|
110
129
|
Do not merge, dedupe or re-rank findings across reviewers, and do not pick an
|
|
111
130
|
overall winner. A finding two reviewers both raise stays in both reports; that
|
|
112
131
|
is signal.
|
package/skills-manifest.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schemaVersion": 1,
|
|
3
|
-
"generatedAt": "2026-10-
|
|
3
|
+
"generatedAt": "2026-10-08T10:41:10.504Z",
|
|
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.6",
|
|
50
|
+
"hash": "sha256-836f28be9230179d7389ef5ed8e1dacadd43d649a20a06f32adb891d5a4c1357",
|
|
51
51
|
"description": "Implement a specification in code."
|
|
52
52
|
},
|
|
53
53
|
{
|
|
@@ -70,8 +70,8 @@
|
|
|
70
70
|
},
|
|
71
71
|
{
|
|
72
72
|
"name": "review-diff",
|
|
73
|
-
"version": "0.1.
|
|
74
|
-
"hash": "sha256-
|
|
73
|
+
"version": "0.1.2",
|
|
74
|
+
"hash": "sha256-70beaf1478820d66e1831d45739ce97ced50224b46c5003d887ea62c8438f251",
|
|
75
75
|
"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."
|
|
76
76
|
},
|
|
77
77
|
{
|