fix: remove mandatory minimum issue count from code review workflow (#1913)
The code review workflow required finding 3-10 issues minimum per review and forced the agent to keep looking if fewer than 3 were found. This created an endless review cycle where every review manufactures issues even after previous fixes were applied, because the workflow cannot conclude with "no issues found." Replace the hard minimum with a zero-issue sanity check that allows clean reviews after a thorough re-examination, while preserving the adversarial review approach for genuine issues.
This commit is contained in:
parent
e64cef80b6
commit
9cd362d2d8
|
|
@ -13,7 +13,7 @@ description: 'Perform adversarial code review finding specific issues. Use when
|
||||||
- Generate all documents in {document_output_language}
|
- Generate all documents in {document_output_language}
|
||||||
- Your purpose: Validate story file claims against actual implementation
|
- Your purpose: Validate story file claims against actual implementation
|
||||||
- Challenge everything: Are tasks marked [x] actually done? Are ACs really implemented?
|
- Challenge everything: Are tasks marked [x] actually done? Are ACs really implemented?
|
||||||
- Find 3-10 specific issues in every review minimum - no lazy "looks good" reviews - YOU are so much better than the dev agent that wrote this slop
|
- Be thorough and specific — find real issues, not manufactured ones. If the code is genuinely good after fixes, say so
|
||||||
- Read EVERY file in the File List - verify implementation against story requirements
|
- Read EVERY file in the File List - verify implementation against story requirements
|
||||||
- Tasks marked complete but not done = CRITICAL finding
|
- Tasks marked complete but not done = CRITICAL finding
|
||||||
- Acceptance Criteria not implemented = HIGH severity finding
|
- Acceptance Criteria not implemented = HIGH severity finding
|
||||||
|
|
@ -136,17 +136,14 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||||
5. **Test Quality**: Are tests real assertions or placeholders?
|
5. **Test Quality**: Are tests real assertions or placeholders?
|
||||||
</action>
|
</action>
|
||||||
|
|
||||||
<check if="total_issues_found lt 3">
|
<check if="total_issues_found == 0">
|
||||||
<critical>NOT LOOKING HARD ENOUGH - Find more problems!</critical>
|
<action>Double-check by re-examining code for:
|
||||||
<action>Re-examine code for:
|
|
||||||
- Edge cases and null handling
|
- Edge cases and null handling
|
||||||
- Architecture violations
|
- Architecture violations
|
||||||
- Documentation gaps
|
|
||||||
- Integration issues
|
- Integration issues
|
||||||
- Dependency problems
|
- Dependency problems
|
||||||
- Git commit message quality (if applicable)
|
|
||||||
</action>
|
</action>
|
||||||
<action>Find at least 3 more specific, actionable issues</action>
|
<action>If still no issues found after thorough re-examination, that is a valid outcome — report a clean review</action>
|
||||||
</check>
|
</check>
|
||||||
</step>
|
</step>
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue