jorgex-stack 1.3.0 → 1.3.1
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
|
@@ -7,6 +7,10 @@ description: Lean / anti-overengineering skill. Use when deciding whether code s
|
|
|
7
7
|
|
|
8
8
|
Use the smallest change that genuinely solves the problem.
|
|
9
9
|
|
|
10
|
+
## Understand first
|
|
11
|
+
|
|
12
|
+
Before choosing a rung, read the affected code and understand the touched flow and caller impact. Trace the actual path through inputs, outputs, callers and shared seams; a small diff at the wrong seam is not lean.
|
|
13
|
+
|
|
10
14
|
## The ladder
|
|
11
15
|
|
|
12
16
|
Work top-down. Stop as soon as a step solves it:
|
|
@@ -30,6 +34,12 @@ Work top-down. Stop as soon as a step solves it:
|
|
|
30
34
|
|
|
31
35
|
Lean code does **not** mean weaker code.
|
|
32
36
|
|
|
37
|
+
For bug fixes, distinguish the reported symptom from root cause. Prefer one fix at the shared seam when appropriate instead of repeating caller-side patches or leaving sibling paths exposed.
|
|
38
|
+
|
|
39
|
+
Reject line-count-only code golf: reduce complexity and change surface, not merely line count. Shorter code that weakens clarity/correctness, hides intent or is fragile is not lean.
|
|
40
|
+
|
|
41
|
+
When accepting a deliberate limit, record its ceiling, revisit trigger and exactly one existing tracking home: the current task, an issue or the project's backlog. Do not create a parallel marker or ledger.
|
|
42
|
+
|
|
33
43
|
Keep explicit code when the change touches:
|
|
34
44
|
|
|
35
45
|
- security or permissions
|
|
@@ -42,6 +42,7 @@ Ask questions when something isn't clear instead of assuming it's correct.
|
|
|
42
42
|
|
|
43
43
|
- Work efficiently and modularly.
|
|
44
44
|
- Detect the real stack, structure, tools, and conventions before acting.
|
|
45
|
+
- For code-bearing tasks that may add, remove or simplify code, load the `lean-code` skill before deciding scope or implementation.
|
|
45
46
|
- For non-trivial feature work, use the to-prd skill before planning when a design artifact will help clarify scope, decisions, or testing seams.
|
|
46
47
|
- Use the diagnose skill when debugging bugs, failing tests, unexpected behavior, or performance regressions before proposing fixes.
|
|
47
48
|
- Explain significant or non-obvious changes before making them.
|