waypoint-codex 1.0.12 → 1.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
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: legibility-pass
|
|
3
|
+
description: Improve code legibility within a defined scope without changing intended behavior. Use when code is correct but hard to read, reason about, or safely modify. Focus on making intent, control flow, state, boundaries, and important behavior easier to see through better naming, clearer structure, reduced indirection, and simpler local reasoning.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Refactor the given scope to make the current truth easier to see.
|
|
7
|
+
|
|
8
|
+
Preserve behavior unless the user asked for functional change.
|
|
9
|
+
|
|
10
|
+
Focus on:
|
|
11
|
+
- clearer names for modules, functions, variables, and states
|
|
12
|
+
- making the main flow easy to follow
|
|
13
|
+
- making failure paths and edge conditions explicit
|
|
14
|
+
- reducing indirection that hides important behavior
|
|
15
|
+
- making state, contracts, and boundaries easier to understand
|
|
16
|
+
- collapsing unnecessary wrappers or pass-through helpers
|
|
17
|
+
- improving local reasoning so a reader needs less cross-referencing
|
|
18
|
+
|
|
19
|
+
Within the requested scope:
|
|
20
|
+
1. Identify the parts that are hardest to understand or easiest to misread.
|
|
21
|
+
2. Improve naming so intent is obvious.
|
|
22
|
+
3. Restructure code so the main path is visible and important branches are easy to spot.
|
|
23
|
+
4. Make hidden assumptions, state transitions, and invariants more explicit.
|
|
24
|
+
5. Remove low-value indirection that makes behavior harder to trace.
|
|
25
|
+
6. Keep comments rare; prefer making the code itself explain the behavior.
|
|
26
|
+
7. Add a brief clarifying comment only when the underlying rule or constraint is not obvious from the code alone.
|
|
27
|
+
|
|
28
|
+
Rules:
|
|
29
|
+
- Do not preserve confusing structure just because it already exists.
|
|
30
|
+
- Do not add abstractions that make reading harder.
|
|
31
|
+
- Do not replace clear code with clever code.
|
|
32
|
+
- Do not rely on comments to explain code that should be rewritten instead.
|
|
33
|
+
- Prefer fewer mental hops.
|
|
34
|
+
- Prefer one obvious reading of the code over multiple plausible interpretations.
|
|
@@ -16,10 +16,11 @@ Use this skill at final closeout, right before you would report the work complet
|
|
|
16
16
|
5. Compare expected scope vs actual outcome and list any missing or partially completed items.
|
|
17
17
|
6. Run a scope-discipline pass: identify additions that were not requested or approved. Remove/simplify them before completion, or explicitly ask the user to approve keeping them.
|
|
18
18
|
7. Run a cleanup pass on changed files: remove duplicated logic, unnecessary abstractions/files, and low-value comments that create maintenance bloat.
|
|
19
|
-
8.
|
|
20
|
-
9. Run a
|
|
21
|
-
10.
|
|
22
|
-
11.
|
|
19
|
+
8. If changed code is still hard to read or reason about, run `legibility-pass` before completion and apply the resulting readability cleanup.
|
|
20
|
+
9. Run a file-footprint sanity pass: collapse avoidable tiny-file fragmentation and keep code that changes together in the same place when boundary/reuse/size reasons are weak.
|
|
21
|
+
10. Run a test-signal sanity pass: remove redundant or brittle tests and keep the smallest high-signal set that still protects the contract.
|
|
22
|
+
11. Before commit/final handoff, run the full checks required by the plan (for example full typecheck/test/build sweep) once, unless explicitly blocked or the user asks for a different cadence.
|
|
23
|
+
12. If any approved item is missing, incomplete, or silently deferred, do not report completion. Continue working until the agreed scope is fully satisfied or discuss a scope change explicitly.
|
|
23
24
|
|
|
24
25
|
## Completion gate
|
|
25
26
|
|
|
@@ -42,6 +43,7 @@ Before final status, summarize briefly:
|
|
|
42
43
|
- files re-read for final verification
|
|
43
44
|
- completed items
|
|
44
45
|
- removed unapproved extras or bloat cleanup applied
|
|
46
|
+
- legibility cleanup applied (if run)
|
|
45
47
|
- file-collapsing or test-pruning done during sanity passes
|
|
46
48
|
- remaining gaps (if any)
|
|
47
49
|
- next action (continue execution or complete)
|