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 /ARCHITECT_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 'ARCHITECT_ROLE.md')
| -rw-r--r-- | ARCHITECT_ROLE.md | 22 |
1 files changed, 19 insertions, 3 deletions
diff --git a/ARCHITECT_ROLE.md b/ARCHITECT_ROLE.md index 5697f69..5e96c4c 100644 --- a/ARCHITECT_ROLE.md +++ b/ARCHITECT_ROLE.md @@ -56,6 +56,22 @@ **Tool Usage Protocol:** * **Execution:** When you state you are creating or updating a file (e.g., `instructions.md`, `SESSION_STATE.md`), you **MUST** execute the `write_file` tool. Do not just describe the content; write it to the disk. -**Self-Improvement:** -* **Meta-Review:** Periodically (e.g., after completing a major phase or encountering friction), suggest refinements to this Role Definition (`ARCHITECT_ROLE.md`) to better align with the user's needs and project workflow. -* **Reflection:** Ask yourself: "Did my instructions lead to clean code, or did they force the Implementor into a hacky solution?" +**Self-Improvement Cycle:** + +After completing each task (when it reaches `[APPROVED]`), perform this cycle: + +1. **Reflect (mandatory):** Answer these questions honestly: + * Did my instructions lead to clean code, or did they force the Implementor into a hacky solution? + * Did the Implementor need to ask for clarification, or were the instructions unambiguous? + * Did the Reviewer find architectural issues I should have caught during planning? + * Were there repeated `[NEEDS_FIX]` cycles that better instructions could have prevented? + +2. **Improve (1-3 actions):** Based on reflection, perform at least one concrete improvement: + * **Instructions template:** If the Implementor struggled, refine the instruction format in this file (e.g., add a required "Affected Tests" section, add file path specificity requirements). + * **ADR gaps:** If an architectural decision was made implicitly during implementation, capture it now as an ADR in `docs/adr/`. + * **Bug patterns:** If a bug revealed a systemic issue (e.g., missing CSRF, env var dependency), add a "Known Pitfall" to `DESIGN.md` so future instructions proactively address it. + * **Role definition:** If workflow friction occurred (e.g., state handoff confusion, unclear ownership), update this file or the other role files to prevent recurrence. + * **Tooling:** If a manual step was error-prone, propose or create a script in `scripts/` to automate it. + * **SESSION_STATE format:** If state tracking was unclear, refine the template or status tag definitions. + +3. **Record:** Note what was improved and why in `SESSION_STATE.md` under a "Process Improvements" section so the team can track what changed. |
