@jesdi/skills 0.0.12 → 0.0.13
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
|
@@ -37,6 +37,16 @@ python3 <skill-dir>/crap.py --base main --threshold-new 7 # local what-ifs
|
|
|
37
37
|
`~/.my-skills/crap-gate`, …). Projects usually
|
|
38
38
|
wrap it (`make crap`); prefer the wrapper when one exists.
|
|
39
39
|
|
|
40
|
+
When you point a wrapper at an agent symlink, that symlink only exists after
|
|
41
|
+
`skills-cli sync` if the matching agent is declared for the skill in
|
|
42
|
+
`.my-skills.json` — `claude` → `.claude/skills/crap-gate`, `opencode` →
|
|
43
|
+
`.agents/skills/crap-gate`. A wrapper that runs `.agents/skills/crap-gate/crap.py`
|
|
44
|
+
therefore needs `"agents": ["opencode"]` (or `["claude", "opencode"]`) on the
|
|
45
|
+
`crap-gate` entry, or a fresh checkout/worktree will lack that path after `sync`.
|
|
46
|
+
The store copy `.my-skills/crap-gate/crap.py` is always materialized regardless
|
|
47
|
+
of declared agents, so wrapping against it avoids the agent/path coupling
|
|
48
|
+
entirely.
|
|
49
|
+
|
|
40
50
|
By default the engine runs each target's coverage command only when that
|
|
41
51
|
target has changed files, so a backend-only change never runs the frontend
|
|
42
52
|
suite. Coverage command output goes to `.crap/<target>.log`.
|
|
@@ -36,7 +36,7 @@ finding). Everything else belongs in a different review.
|
|
|
36
36
|
|
|
37
37
|
## The smells
|
|
38
38
|
|
|
39
|
-
Run every meaningful change through this table, top
|
|
39
|
+
Run every meaningful change through this table, top to bottom. Each row is one
|
|
40
40
|
concept; the *Ask* is the question that exposes it, the *Remedy* is what to
|
|
41
41
|
push for.
|
|
42
42
|
|
|
@@ -52,7 +52,7 @@ push for.
|
|
|
52
52
|
| 8 | **Needless sequencing / non-atomic update** — independent work serialized, related updates that can leave state half-applied | Is this actually dependent? Can it be observed half-done? | Parallelize independent work; group related updates. Not micro-optimization — brittleness. |
|
|
53
53
|
| 9 | **Short-horizon change** — "temporary", TODO-later, quick patch, deferred cleanup, a shape chosen because it is the smallest diff | What does this look like when its reason is gone? What does removing it cost? | Do the durable fix now, or structure the stopgap so removal is a pure deletion (one branch, one file), never a refactor of live callers. |
|
|
54
54
|
|
|
55
|
-
|
|
55
|
+
Short-horizon change is the long-term rule and it applies to every other smell: prefer
|
|
56
56
|
consolidating now over a third copy later; prefer the simplification that
|
|
57
57
|
still makes sense after the migration; never trade a durable simplification
|
|
58
58
|
for a smaller diff.
|
|
@@ -61,27 +61,36 @@ for a smaller diff.
|
|
|
61
61
|
|
|
62
62
|
1. Read the full diff, then the files it touches and the canonical helpers it
|
|
63
63
|
should have reused. Structural problems are only visible in context.
|
|
64
|
-
2. For each meaningful change, ask the table's questions in order.
|
|
65
|
-
|
|
64
|
+
2. For each meaningful change, ask the table's questions in order.
|
|
65
|
+
Duplicated concept and Complexity rearranged are where the big wins hide;
|
|
66
|
+
spend most of the effort there.
|
|
66
67
|
3. For every finding, write the *restructuring*, not the patch. "Extract a
|
|
67
68
|
shared helper" is a patch; "one `Message` model with a renderer per channel,
|
|
68
69
|
so channels become data" is a restructuring.
|
|
69
70
|
|
|
70
|
-
## Output
|
|
71
|
+
## Output Expectations
|
|
71
72
|
|
|
72
73
|
Write the review in this shape:
|
|
73
74
|
|
|
74
|
-
1. **Findings**,
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
75
|
+
1. **Findings**, in the table's order (Duplicated concept first,
|
|
76
|
+
Short-horizon change last). Lead each finding with the smell's **name**
|
|
77
|
+
in bold (e.g. **Duplicated concept**, **Weak contract**), never a row
|
|
78
|
+
number — the table's numbers only sequence the review; the names carry
|
|
79
|
+
the meaning to a reader who has not seen the table. A finding that spans
|
|
80
|
+
two smells names both (**Weak contract + Short-horizon change**). Then:
|
|
81
|
+
where, and the concrete restructuring.
|
|
82
|
+
Keep to the few high-conviction findings — structural findings displace
|
|
83
|
+
cosmetic ones, and a cosmetic finding never appears while a structural
|
|
84
|
+
one exists.
|
|
78
85
|
2. **Verdict**: `APPROVE` or `REQUEST CHANGES`, one line of justification.
|
|
79
86
|
|
|
80
|
-
## Approval
|
|
87
|
+
## Approval Bar
|
|
81
88
|
|
|
82
|
-
Working code is not the bar. `REQUEST CHANGES` when any
|
|
83
|
-
|
|
84
|
-
|
|
89
|
+
Working code is not the bar. `REQUEST CHANGES` when any of Duplicated
|
|
90
|
+
concept, Complexity rearranged, Special case in a shared flow, Wrong layer,
|
|
91
|
+
Indirection without clarity, Weak contract, or Short-horizon change is present
|
|
92
|
+
and unjustified, or when a visible code-judo move was skipped. File sprawl and
|
|
93
|
+
Needless sequencing block when the cleaner structure is obvious.
|
|
85
94
|
|
|
86
95
|
## Author pushback
|
|
87
96
|
|
package/skills-manifest.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schemaVersion": 1,
|
|
3
|
-
"generatedAt": "2026-09-
|
|
3
|
+
"generatedAt": "2026-09-03T09:39:52.864Z",
|
|
4
4
|
"skills": [
|
|
5
5
|
{
|
|
6
6
|
"name": "backlog",
|
|
@@ -22,14 +22,14 @@
|
|
|
22
22
|
},
|
|
23
23
|
{
|
|
24
24
|
"name": "crap-gate",
|
|
25
|
-
"version": "0.1.
|
|
26
|
-
"hash": "sha256-
|
|
25
|
+
"version": "0.1.2",
|
|
26
|
+
"hash": "sha256-6f1e0de08917f0b0166959dd25328ed098ce1185cf52996093f2b18b151a9c0a",
|
|
27
27
|
"description": "Score every function a branch changed with CRAP (cyclomatic complexity × untested fraction), fail on existing functions > 15 and new functions > 9, and drive a fixer + independent reviewer loop until the gate passes. Use when implementation is done and before pushing, when the user says \"run the crap gate\", \"check CRAP\", \"is this change tested enough\", or when a push gate reports CRAP violations."
|
|
28
28
|
},
|
|
29
29
|
{
|
|
30
30
|
"name": "deep-quality-review",
|
|
31
|
-
"version": "0.1.
|
|
32
|
-
"hash": "sha256-
|
|
31
|
+
"version": "0.1.1",
|
|
32
|
+
"hash": "sha256-da5ce29dc5349bcbed74589f3475fa12907ae7eed385e4ecc680bf67edae7e43",
|
|
33
33
|
"description": "Extremely strict maintainability review of a branch's changes: duplicated concepts, complexity that got rearranged instead of deleted, spaghetti branching, boundary leaks, weak type contracts, file sprawl, and \"temporary\" fixes that will outlive their reason. Use when the user asks for a \"deep code quality review\", \"thermonuclear review\", \"harsh maintainability review\", \"code judo\", \"is this making the codebase messier\", or before merging a change that touches shared code. Not a correctness, security, or test-coverage review."
|
|
34
34
|
},
|
|
35
35
|
{
|