waypoint-codex 0.9.8 → 0.9.9
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/README.md
CHANGED
|
@@ -156,6 +156,8 @@ Waypoint scaffolds these reviewer agents by default:
|
|
|
156
156
|
|
|
157
157
|
The intended workflow is closeout-based: run `code-reviewer` before considering any non-trivial implementation slice complete, and run `code-health-reviewer` before considering medium or large changes complete, especially when they add structure, duplicate logic, or introduce new abstractions. If both apply, run them in parallel. A recent self-authored commit is the preferred scope anchor when one cleanly represents the slice, but it is not the only valid trigger.
|
|
158
158
|
|
|
159
|
+
For planning work, run `plan-reviewer` before presenting a non-trivial implementation plan to the user and iterate until it has no meaningful review findings left.
|
|
160
|
+
|
|
159
161
|
## What makes it different
|
|
160
162
|
|
|
161
163
|
Waypoint is not trying to hide everything behind hooks and background machinery.
|
package/package.json
CHANGED
|
@@ -82,7 +82,15 @@ Waypoint scaffolds these focused second-pass specialists by default:
|
|
|
82
82
|
|
|
83
83
|
- `code-reviewer` for correctness and regression review
|
|
84
84
|
- `code-health-reviewer` for maintainability drift
|
|
85
|
-
- `plan-reviewer` to challenge
|
|
85
|
+
- `plan-reviewer` to challenge non-trivial implementation plans before they are shown to the user
|
|
86
|
+
|
|
87
|
+
## Plan Review
|
|
88
|
+
|
|
89
|
+
Run `plan-reviewer` before presenting a non-trivial implementation plan to the user.
|
|
90
|
+
|
|
91
|
+
- Use it when the plan includes meaningful design choices, multiple work phases, migrations, or non-obvious tradeoffs.
|
|
92
|
+
- Skip it for tiny obvious plans or when no plan will be presented.
|
|
93
|
+
- Read the reviewer result, strengthen the plan, and rerun `plan-reviewer` until there are no meaningful issues left before showing the plan to the user.
|
|
86
94
|
|
|
87
95
|
## Review Loop
|
|
88
96
|
|
|
@@ -75,6 +75,7 @@ Working rules:
|
|
|
75
75
|
- Use `docs-sync` when the docs may be stale or a change altered shipped behavior, contracts, routes, or commands
|
|
76
76
|
- Use `code-guide-audit` for a targeted coding-guide compliance pass on a specific feature, file set, or change slice
|
|
77
77
|
- Do not invoke `break-it-qa`, `frontend-ship-audit`, or `backend-ship-audit` yourself from the managed AGENTS block workflow; they are user-facing skills for explicit human-requested QA or ship-readiness audits, not default agent steps
|
|
78
|
+
- Before presenting a non-trivial implementation plan to the user, run `plan-reviewer` and iterate on the plan until it has no meaningful review findings left
|
|
78
79
|
- Before considering a non-trivial implementation slice complete, run `code-reviewer`; use a recent self-authored commit as the default scope anchor when one cleanly represents that slice
|
|
79
80
|
- Before considering medium or large changes complete, run `code-health-reviewer`, especially when they add structure, duplicate logic, or introduce new abstractions
|
|
80
81
|
- Before pushing or opening/updating a PR for substantial work, use `pre-pr-hygiene`
|