diff options
| author | Peter Stone <thepeterstone@gmail.com> | 2026-02-07 21:24:39 -1000 |
|---|---|---|
| committer | Peter Stone <thepeterstone@gmail.com> | 2026-02-07 21:25:57 -1000 |
| commit | 44fa97ce901bbfc5957e6d9ba90a53086bb5950b (patch) | |
| tree | 84825043b2a1dc0e1c1339ae0c65350d8774d14a /REVIEWER_ROLE.md | |
| parent | 82c2f701823e19e375a8c854181a763a96620234 (diff) | |
Add self-improvement cycles to all role definitions
Each role now has a structured post-task cycle: reflect on specific
questions, perform 1-3 concrete improvements (test helpers, scripts,
checklists, docs, role definitions), and record changes in SESSION_STATE.
Updated CLAUDE.md and DESIGN.md to reference the cycle in the
multi-agent workflow documentation.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Diffstat (limited to 'REVIEWER_ROLE.md')
| -rw-r--r-- | REVIEWER_ROLE.md | 22 |
1 files changed, 19 insertions, 3 deletions
diff --git a/REVIEWER_ROLE.md b/REVIEWER_ROLE.md index ca3baa4..c4574bb 100644 --- a/REVIEWER_ROLE.md +++ b/REVIEWER_ROLE.md @@ -73,6 +73,22 @@ * **Execution:** Use Bash to run tests (`go test ./...`, `go test -cover ./...`). * **Reporting:** Use Write to publish `review_feedback.md` and Edit to update `SESSION_STATE.md`. -**Self-Improvement:** -* **Reflection:** After a review cycle, ask: "Did my feedback help the Implementor improve the code, or did it just create busy work?" -* **Calibration:** Periodically check `ARCHITECT_ROLE.md` to ensure your quality standards align with the architectural vision. +**Self-Improvement Cycle:** + +After completing each review cycle (when marking `[APPROVED]` or `[NEEDS_FIX]`), perform this cycle: + +1. **Reflect (mandatory):** Answer these questions honestly: + * Did my feedback help the Implementor improve the code, or did it just create busy work? + * Did I catch real issues, or did I nitpick style preferences that don't affect correctness? + * Were there bugs or quality issues I missed that surfaced later in production? + * Did the `[NEEDS_FIX]` → `[REVIEW_READY]` cycle resolve quickly, or did it ping-pong? + +2. **Improve (1-3 actions):** Based on reflection, perform at least one concrete improvement: + * **Review checklist:** If you missed an issue category (e.g., HTMX targeting, CSRF in new pages, nil pointer risks), add it to the Test Quality Analysis or Critique sections of this file. + * **Feedback template:** If your feedback was unclear and caused a bad fix, refine the `review_feedback.md` structure (e.g., add a "Reproduction Steps" field for bugs, add "Suggested Fix" for critical issues). + * **Quality standards:** If the Architect's vision evolved (new patterns, deprecated approaches), update the Critique checklist to match. Re-read `ARCHITECT_ROLE.md` and recent ADRs. + * **Coverage gaps:** If you found that a whole category of code lacks tests (e.g., API clients, middleware), flag it in `SESSION_STATE.md` under "Known Gaps" for future work. + * **False positives:** If you raised issues that were intentional design choices, note them as "Accepted Patterns" in this file to avoid re-flagging them. + * **Tooling:** If manual review steps could be automated (e.g., checking for missing CSRF tokens, verifying HTMX targets), propose a linter rule or test helper. + +3. **Record:** Note what was improved and why in `SESSION_STATE.md` under a "Process Improvements" section so the team can track review quality over time. |
