@jesdi/skills 0.0.18 → 0.0.20
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
|
-
|
|
14
|
+
a per-ticket gate (check command + crap-gate) before DONE, re-run by the reviewer; check command after each merge; final /review-diff on the most capable model, one
|
|
15
15
|
fixer; closes tickets only if they are issues. Review loop and ledger adapt
|
|
16
16
|
superpowers' subagent-driven-development (obra/superpowers, MIT).
|
|
17
17
|
-->
|
|
@@ -40,11 +40,11 @@ Run ticket subagents in the background where possible for **maximum concurrency*
|
|
|
40
40
|
|
|
41
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
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.
|
|
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. Before reporting DONE it runs the **gate** in its worktree: 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). DONE means both are green; a gate it can't turn green is BLOCKED, with the output. It reports: status (DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT or BLOCKED), commits, red→green evidence for locked tests and its own slices, the gate's 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.
|
|
44
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.
|
|
45
|
+
6. On DONE, a **reviewer subagent** re-runs the gate first (a red gate is a Critical finding; don't trust the report), 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. 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
46
|
|
|
47
|
-
7. Once a ticket passes review, a **merger subagent** merges it to the PR branch and runs the full
|
|
47
|
+
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.
|
|
48
48
|
|
|
49
49
|
8. If this changes the **frontier** of available tickets, start the next tickets. This allows for maximum concurrency.
|
|
50
50
|
|
|
@@ -18,7 +18,7 @@ Read `git diff <range>` in full, then only the surrounding code a check needs
|
|
|
18
18
|
| N+1 | One query per loop iteration where a join or `IN (…)` would do. |
|
|
19
19
|
| Migrations | Not reversible, or unsafe on a live table (a NOT NULL column without a default, a rewrite under lock). |
|
|
20
20
|
| Failure paths | A payment-provider, checkout or stock-decrement call whose failure (timeout, decline, provider error) is unhandled or silently swallowed. |
|
|
21
|
-
| Test quality | Tautological tests (asserting a mock's return value, or a value the test just set with no code in between) and tests on internals instead of the public seam. Say what they should assert. |
|
|
21
|
+
| Test quality | Tautological tests (asserting a mock's return value, or a value the test just set with no code in between) and tests on internals instead of the public seam. Unreadable tests, which protect nothing because nobody can tell what they guarantee: a name that doesn't state the behavior, one test asserting several behaviors, logic in the test (`if`, loops), setup that hides what the test depends on, fixtures shared and mutated across tests. Say what they should assert, or how to split them. |
|
|
22
22
|
|
|
23
23
|
Every finding: `file:line`, the concrete failure scenario (inputs or
|
|
24
24
|
interleaving → wrong result), and the fix. "Consider reviewing" is not a
|
package/skills-manifest.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schemaVersion": 1,
|
|
3
|
-
"generatedAt": "2026-09-
|
|
3
|
+
"generatedAt": "2026-09-24T15:47:23.496Z",
|
|
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.1",
|
|
50
|
+
"hash": "sha256-678f3481bce18448d0d27ef33c096d4b64faf8dd7254dd8d0bc73f8c134a7f58",
|
|
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.1",
|
|
74
|
+
"hash": "sha256-ac4b526f0436f06acc4e5e2254b83b5318a14065caab3f922f20fa7da9e87c5f",
|
|
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
|
{
|