@jesdi/skills 0.0.11 → 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`.
|
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: deep-quality-review
|
|
3
|
+
description: >-
|
|
4
|
+
Extremely strict maintainability review of a branch's changes: duplicated
|
|
5
|
+
concepts, complexity that got rearranged instead of deleted, spaghetti
|
|
6
|
+
branching, boundary leaks, weak type contracts, file sprawl, and "temporary"
|
|
7
|
+
fixes that will outlive their reason. Use when the user asks for a "deep code
|
|
8
|
+
quality review", "thermonuclear review", "harsh maintainability review",
|
|
9
|
+
"code judo", "is this making the codebase messier", or before merging a
|
|
10
|
+
change that touches shared code. Not a correctness, security, or test-coverage
|
|
11
|
+
review.
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
# Deep Quality Review
|
|
15
|
+
|
|
16
|
+
## Overview
|
|
17
|
+
|
|
18
|
+
One principle: **a change should leave the codebase with fewer concepts, not
|
|
19
|
+
more.** Behavior stays the same; structure gets simpler. Judge the diff by the
|
|
20
|
+
shape the code will have in a year, when the deadline, migration, or incident
|
|
21
|
+
that motivated it is forgotten.
|
|
22
|
+
|
|
23
|
+
Be ambitious. Do not stop at "this could be a bit cleaner" — look for the
|
|
24
|
+
"code judo" move: a reframing that uses the existing architecture so whole
|
|
25
|
+
branches, helpers, flags, or layers disappear. If complexity can be deleted
|
|
26
|
+
rather than rearranged, push for deletion.
|
|
27
|
+
|
|
28
|
+
## Scope
|
|
29
|
+
|
|
30
|
+
**In:** structure, abstractions, duplication, layering, type contracts, file
|
|
31
|
+
size, orchestration.
|
|
32
|
+
|
|
33
|
+
**Out:** correctness bugs, security, tests. Raise one only when structure
|
|
34
|
+
causes it (an invariant enforced by an optional parameter is a structure
|
|
35
|
+
finding). Everything else belongs in a different review.
|
|
36
|
+
|
|
37
|
+
## The smells
|
|
38
|
+
|
|
39
|
+
Run every meaningful change through this table, top to bottom. Each row is one
|
|
40
|
+
concept; the *Ask* is the question that exposes it, the *Remedy* is what to
|
|
41
|
+
push for.
|
|
42
|
+
|
|
43
|
+
| # | Smell | Ask | Remedy |
|
|
44
|
+
|---|-------|-----|--------|
|
|
45
|
+
| 1 | **Duplicated concept** — one idea expressed twice: near-duplicate helper, parallel model, copy-pasted branch, a flag *and* an optional both meaning "off", the same predicate reimplemented instead of reused | What single concept are these copies of? Where is its canonical home? | Name the concept once; make the variants its data or parameters; delete the copies. Never accept a second copy because the first one exists. |
|
|
46
|
+
| 2 | **Complexity rearranged, not deleted** — the diff moves code around but the reader still holds the same number of branches, modes, and helpers | Which reframing of the model or ownership makes these branches disappear? | Change the model so the special case becomes the default flow. Prefer the version that feels inevitable in hindsight. |
|
|
47
|
+
| 3 | **Special case in a shared flow** — new `if`, one-off boolean, nullable mode, or feature check bolted into an unrelated path | Whose decision is this, and why is it made here? | Move it behind its own abstraction (policy, resolver, dispatcher, module); keep the shared path linear. |
|
|
48
|
+
| 4 | **Wrong layer / boundary leak** — feature logic in a shared module, implementation details through an API, callers re-deriving what the owner already knows | Which module owns this concept? | Move the logic to the owner; callers receive results, not raw inputs to recompute. |
|
|
49
|
+
| 5 | **Indirection without clarity** — thin wrapper, pass-through helper, "generic" mechanism hiding a simple data shape | What does the reader learn from this layer? | Delete it and keep the direct call. Boring and direct beats clever. |
|
|
50
|
+
| 6 | **Weak contract** — `any`, `unknown`, casts, optional params, silent fallbacks that paper over an unclear invariant | What invariant is this hiding? | Make the boundary explicit in the type so the control flow simplifies. |
|
|
51
|
+
| 7 | **File sprawl** — the diff pushes a file past a healthy size boundary (~1k lines) | Should this be decomposed *before* adding to it? | Split by concept first; waive only with a compelling structural reason. |
|
|
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
|
+
| 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
|
+
|
|
55
|
+
Short-horizon change is the long-term rule and it applies to every other smell: prefer
|
|
56
|
+
consolidating now over a third copy later; prefer the simplification that
|
|
57
|
+
still makes sense after the migration; never trade a durable simplification
|
|
58
|
+
for a smaller diff.
|
|
59
|
+
|
|
60
|
+
## Process
|
|
61
|
+
|
|
62
|
+
1. Read the full diff, then the files it touches and the canonical helpers it
|
|
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
|
+
Duplicated concept and Complexity rearranged are where the big wins hide;
|
|
66
|
+
spend most of the effort there.
|
|
67
|
+
3. For every finding, write the *restructuring*, not the patch. "Extract a
|
|
68
|
+
shared helper" is a patch; "one `Message` model with a renderer per channel,
|
|
69
|
+
so channels become data" is a restructuring.
|
|
70
|
+
|
|
71
|
+
## Output Expectations
|
|
72
|
+
|
|
73
|
+
Write the review in this shape:
|
|
74
|
+
|
|
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.
|
|
85
|
+
2. **Verdict**: `APPROVE` or `REQUEST CHANGES`, one line of justification.
|
|
86
|
+
|
|
87
|
+
## Approval Bar
|
|
88
|
+
|
|
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.
|
|
94
|
+
|
|
95
|
+
## Author pushback
|
|
96
|
+
|
|
97
|
+
| Pushback | Answer |
|
|
98
|
+
|----------|--------|
|
|
99
|
+
| "It works, tests pass" | The bar is structure. Working code that makes the codebase messier is a regression. |
|
|
100
|
+
| "We'll clean it up after the migration / next quarter" | Cleanup later is a refactor of live callers; the durable version is cheaper now. |
|
|
101
|
+
| "It's just one flag / one `if`" | Every flag is a mode every future reader must hold in their head. |
|
|
102
|
+
| "The existing code already does it this way" | Existing mess licenses fixing the concept, not adding a copy of it. |
|
|
103
|
+
| "A restructure is out of scope" | If the restructure deletes the complexity this change adds, it is the scope. |
|
|
104
|
+
|
|
105
|
+
## Review Tone
|
|
106
|
+
|
|
107
|
+
Be direct, serious, and demanding about quality.
|
package/skills-manifest.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"schemaVersion": 1,
|
|
3
|
-
"generatedAt": "2026-
|
|
3
|
+
"generatedAt": "2026-09-03T09:39:52.864Z",
|
|
4
4
|
"skills": [
|
|
5
5
|
{
|
|
6
6
|
"name": "backlog",
|
|
@@ -22,10 +22,16 @@
|
|
|
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
|
+
{
|
|
30
|
+
"name": "deep-quality-review",
|
|
31
|
+
"version": "0.1.1",
|
|
32
|
+
"hash": "sha256-da5ce29dc5349bcbed74589f3475fa12907ae7eed385e4ecc680bf67edae7e43",
|
|
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
|
+
},
|
|
29
35
|
{
|
|
30
36
|
"name": "file-bug-issue",
|
|
31
37
|
"version": "0.1.0",
|