@jesdi/skills 0.0.28 → 0.0.29
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
|
@@ -11,7 +11,7 @@ Changes: a model tier per subagent; a context-isolated test-writer commits
|
|
|
11
11
|
locked acceptance tests at the ticket's Seam, the implementer turns them green
|
|
12
12
|
with /tdd and reports to a contract; per-ticket review before merge, fix loop
|
|
13
13
|
capped at 4 rounds with escalation; a ruling ledger and four stop conditions;
|
|
14
|
-
a per-ticket gate (check command + crap-gate) before DONE,
|
|
14
|
+
a per-ticket gate (check command + crap-gate) before DONE, verified by the reviewer;
|
|
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
|
|
@@ -19,6 +19,11 @@ fixer; ticket-grouped history with fixes folded in before review; closes
|
|
|
19
19
|
tickets only if they are issues; no push and no PR until every
|
|
20
20
|
ticket is merged and the final review has passed. Review loop and ledger adapt
|
|
21
21
|
superpowers' subagent-driven-development (obra/superpowers, MIT).
|
|
22
|
+
Verification schedule (after a 44-hour run with 65 full gates for six tickets):
|
|
23
|
+
one gate record per candidate, verified by the reviewer instead of re-run;
|
|
24
|
+
mutation proofs once, then only for changed lines; a budget ruling after round 2;
|
|
25
|
+
fixture corrections outside the fix loop; a named fallback when codex exec is refused;
|
|
26
|
+
one report file per agent; plain-sentence ledger.
|
|
22
27
|
-->
|
|
23
28
|
|
|
24
29
|
You have been provided a spec. This spec should have tickets associated with it, describing how to implement the spec.
|
|
@@ -29,19 +34,19 @@ The tickets are not a list of steps. They are a **task graph** with blocking rel
|
|
|
29
34
|
|
|
30
35
|
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.
|
|
31
36
|
|
|
32
|
-
Run ticket subagents in the background where possible for **maximum concurrency**.
|
|
37
|
+
Run ticket subagents in the background where possible for **maximum concurrency**. Wait on a running subagent with one long wait, in minutes. Each subagent leaves one report file plus its gate log in the notes directory; mutation evidence is a table in the report, and a tree-hash manifest or a per-mutant log is a sign the agent is building its own procedure.
|
|
33
38
|
|
|
34
39
|
**Every dispatch prompt says: never `git stash`, reset or check out other branches; worktrees share one stash and one ref store.**
|
|
35
40
|
|
|
36
41
|
**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.
|
|
37
42
|
|
|
38
|
-
**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.
|
|
43
|
+
**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. Ledger entries are plain sentences, one line per event, written for a human who was not there. After a compaction, read the ledger and continue from its last state: a recorded green gate, review or merge stays settled. 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.
|
|
39
44
|
|
|
40
45
|
## Steps
|
|
41
46
|
|
|
42
47
|
1. Read the spec and tickets. Read enough to understand the task graph.
|
|
43
48
|
|
|
44
|
-
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.
|
|
49
|
+
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. It is the only exploration or preparation agent: a ticket starts with its test-writer, when its frontier turn comes.
|
|
45
50
|
|
|
46
51
|
3. Create the PR branch locally. Do **not** push it and do **not** open a PR yet: nothing leaves the
|
|
47
52
|
machine until every ticket is merged and the final review has passed (step 10). Intermediate
|
|
@@ -50,13 +55,21 @@ Run ticket subagents in the background where possible for **maximum concurrency*
|
|
|
50
55
|
|
|
51
56
|
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. A test that is already green before any implementation is vacuous until proven otherwise (an earlier guard or early return often satisfies it for an unrelated reason): the test-writer rewrites it to fail, or, when the criterion truly holds already, reports the production-code mutation that turns it red and the red output. Those files are now **locked**. A ticket with no behavioral criteria (Seam: `none — refactor`) skips this: its existing tests are the contract, unmodified.
|
|
52
57
|
|
|
53
|
-
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. Before reporting DONE it runs the **gate**
|
|
58
|
+
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. While working it runs targeted tests. Before reporting DONE it runs the **gate** once, on a clean tree at its final commit, as one **gate record**: the repo's check command (lint, typecheck, full test suite: `make check`, or what AGENTS.md documents) and, when the repo has `.crap-gate.json`, crap-gate scoped to the ticket (`run.sh --base <PR branch>`, or the repo's `make crap-gate` wrapper), wrapped so the log in the notes directory carries the start and end time, the commit, and the status:
|
|
54
59
|
|
|
55
|
-
|
|
60
|
+
```sh
|
|
61
|
+
{ date -u; git rev-parse HEAD; git status --short; <gate commands>; echo "gate exit $?"; date -u; } 2>&1 | tee <notes>/<ticket>-gate-$(git rev-parse --short HEAD).log
|
|
62
|
+
```
|
|
56
63
|
|
|
57
|
-
|
|
64
|
+
DONE means the record is green; a gate it can't turn green is BLOCKED, with the output. CRAP findings are the implementer's to resolve inside the ticket, within this same gate. It reports: status (DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT or BLOCKED), commits, red→green evidence for locked tests and its own slices, the gate record's path and final lines, 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.
|
|
58
65
|
|
|
59
|
-
|
|
66
|
+
6. On DONE, a **reviewer subagent** verifies the gate record first: the recorded commit is the ticket tip, the status was clean, and the tail is green. A missing, mismatched or red record is a Critical finding, and only then does the reviewer run the gate itself. It then 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; that one diff is the whole locked-file check. In the first review, for each locked test, it breaks the production line the test exists to protect (a temporary edit, reverted after) and confirms that test goes red; a test that stays green is Critical. It re-runs every mutation the test-writer reported. A mutation proof is keyed to its test and production line: a later round repeats it only when that line changed. Name your specific suspicions in the reviewer prompt (a sibling caller, a key built from the old identity, a guard another ticket added): named suspicions find regressions a generic review misses.
|
|
67
|
+
|
|
68
|
+
A **risky** ticket touches shared state, persistence keys or identities, concurrency, money or auth. For those, run the correctness pass from /review-diff yourself, in parallel with the reviewer: `codex exec` with that skill's `correctness.md` on range `<PR branch>...<ticket branch>` (three dots: from the merge-base, so tickets merged meanwhile don't show up), in quick mode (the command is in the review-diff skill). Its findings join the reviewer's, with the same severities. When `codex exec` is refused or unavailable, the reviewer's brief gains `correctness.md` for the ticket's risk; that reviewer is the correctness pass, with no second agent.
|
|
69
|
+
|
|
70
|
+
A finding that a locked test encodes a stale path, format, fixture layout or setup detail is a **fixture correction**, outside the fix loop: one test-writer dispatch fixes it, the ledger records the file and reason, and the review continues. A setup or environment failure (a missing dependency link, a cache permission, a leftover process) is fixed at its cause before any gate runs again.
|
|
71
|
+
|
|
72
|
+
Critical or Important findings start a fix loop of at most 4 rounds, each a fix plus a re-review scoped to that fix: the implementer uses targeted tests, ends the round with one gate record on its final commit, and the re-review verifies that record and the changed lines. Rounds 1-2 resume the implementer; rounds 3-4 go to a fresh implementer one tier up. After round 2, rule in the ledger before continuing: continue, split the ticket, or redesign it. After round 4, rule on each open finding in the ledger and move on. Minor findings go to the ledger for the final review.
|
|
60
73
|
|
|
61
74
|
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.
|
|
62
75
|
|
package/skills-manifest.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schemaVersion": 1,
|
|
3
|
-
"generatedAt": "2026-10-
|
|
3
|
+
"generatedAt": "2026-10-08T12:46:28.852Z",
|
|
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.7",
|
|
50
|
+
"hash": "sha256-dfcd2f6a13fd06dd4fb7a45bb0d85ae39228ec804dc94c845310afa72808d3d5",
|
|
51
51
|
"description": "Implement a specification in code."
|
|
52
52
|
},
|
|
53
53
|
{
|