waypoint-codex 1.0.11 → 1.0.13

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "waypoint-codex",
-  "version": "1.0.11",
+  "version": "1.0.13",
   "description": "Make Codex better by default with stronger planning, code quality, reviews, tracking, and repo guidance.",
   "license": "MIT",
   "type": "module",

package/templates/.agents/skills/legibility-pass/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: legibility-pass
+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.
+---
+
+Refactor the given scope to make the current truth easier to see.
+
+Preserve behavior unless the user asked for functional change.
+
+Focus on:
+- clearer names for modules, functions, variables, and states
+- making the main flow easy to follow
+- making failure paths and edge conditions explicit
+- reducing indirection that hides important behavior
+- making state, contracts, and boundaries easier to understand
+- collapsing unnecessary wrappers or pass-through helpers
+- improving local reasoning so a reader needs less cross-referencing
+
+Within the requested scope:
+1. Identify the parts that are hardest to understand or easiest to misread.
+2. Improve naming so intent is obvious.
+3. Restructure code so the main path is visible and important branches are easy to spot.
+4. Make hidden assumptions, state transitions, and invariants more explicit.
+5. Remove low-value indirection that makes behavior harder to trace.
+6. Keep comments rare; prefer making the code itself explain the behavior.
+7. Add a brief clarifying comment only when the underlying rule or constraint is not obvious from the code alone.
+
+Rules:
+- Do not preserve confusing structure just because it already exists.
+- Do not add abstractions that make reading harder.
+- Do not replace clear code with clever code.
+- Do not rely on comments to explain code that should be rewritten instead.
+- Prefer fewer mental hops.
+- Prefer one obvious reading of the code over multiple plausible interpretations.

package/templates/.agents/skills/legibility-pass/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Legibility Pass"
+  short_description: "Improve readability without changing behavior"
+  default_prompt: "Use $legibility-pass on the current scope to improve naming, control-flow clarity, and local reasoning while preserving intended behavior."

package/templates/.agents/skills/test-writing/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: test-writing
+description: Write a small, high-signal test set that protects important behavior without overfitting to implementation details. Use whenever adding or modifying automated tests for a feature, bug fix, refactor, or behavior change. Prefer durable tests that verify user-visible behavior, important business rules, and meaningful failure modes. Avoid redundant, brittle, or low-value tests that increase maintenance cost without materially increasing confidence.
+---
+
+Write tests for confidence, not volume.
+
+Start with the smallest test set that gives strong confidence in the requested change.
+
+Default test budget for a normal feature or bug fix:
+- one main-path test
+- one key edge case or failure-path test
+- unit tests only for non-trivial pure logic
+
+Test at the highest level that gives strong confidence at reasonable cost.
+
+Prefer tests that:
+- verify observable behavior
+- protect important business rules and invariants
+- cover meaningful boundaries and failure modes
+- survive refactors
+- exercise public interfaces rather than private helpers
+
+Avoid tests that:
+- duplicate confidence across layers without a distinct risk
+- assert implementation choreography instead of outcomes
+- test trivial helpers, thin wrappers, pass-through glue, or obvious mappings
+- encode fragile structure such as incidental DOM shape, exact class strings, private function calls, or unstable snapshots
+- expand a feature into a large matrix of low-value cases unless the risk truly requires it
+
+When choosing between many narrow tests and one stronger test, prefer the smaller set that better protects real behavior.
+
+For frontend work:
+- prefer stable user-visible behavior over structural assertions
+- add automated regression tests only when the behavior is worth protecting and likely to remain stable
+- do not add large numbers of UI tests for cosmetic or refactor-sensitive details
+
+For backend or domain logic:
+- prefer behavior-focused tests around contracts, invariants, validation, permissions, state transitions, and real regressions
+- add targeted unit tests for tricky pure logic only when they materially improve confidence
+
+If an integration-style test already proves the important flow, do not add multiple lower-level tests that mostly restate the same confidence.
+
+Before finishing, remove or avoid any test whose main effect is to make future refactors harder without protecting an important contract.
+
+Rules:
+- Do not optimize for test count.
+- Do not mirror the implementation structure in the test structure.
+- Do not create one test per helper by default.
+- Do not add redundant tests across layers unless a distinct risk justifies them.
+- Do not test trivial code just because it exists.
+- Prefer the smallest durable set that gives high confidence.

package/templates/.agents/skills/test-writing/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Test Writing"
+  short_description: "Write high-signal tests with minimal bloat"
+  default_prompt: "Use $test-writing to design and add the smallest durable test set that gives strong confidence for this change."

package/templates/.agents/skills/verify-completeness/SKILL.md

@@ -16,10 +16,11 @@ Use this skill at final closeout, right before you would report the work complet
 5. Compare expected scope vs actual outcome and list any missing or partially completed items.
 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.
 7. Run a cleanup pass on changed files: remove duplicated logic, unnecessary abstractions/files, and low-value comments that create maintenance bloat.
-8. 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.
-9. Run a test-signal sanity pass: remove redundant or brittle tests and keep the smallest high-signal set that still protects the contract.
-10. 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.
-11. 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.
+8. If changed code is still hard to read or reason about, run `legibility-pass` before completion and apply the resulting readability cleanup.
+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.
+10. Run a test-signal sanity pass: remove redundant or brittle tests and keep the smallest high-signal set that still protects the contract.
+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.
+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.
 
 ## Completion gate
 
@@ -42,6 +43,7 @@ Before final status, summarize briefly:
 - files re-read for final verification
 - completed items
 - removed unapproved extras or bloat cleanup applied
+- legibility cleanup applied (if run)
 - file-collapsing or test-pruning done during sanity passes
 - remaining gaps (if any)
 - next action (continue execution or complete)