From 44fa97ce901bbfc5957e6d9ba90a53086bb5950b Mon Sep 17 00:00:00 2001 From: Peter Stone Date: Sat, 7 Feb 2026 21:24:39 -1000 Subject: 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 --- REVIEWER_ROLE.md | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) (limited to 'REVIEWER_ROLE.md') 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. -- cgit v1.2.3