mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-01-30 04:32:02 +00:00
* docs: radical reduction of documentation scope for v6 beta Archive and basement unreviewed content to ship a focused, minimal doc set. Changes: - Archive stale how-to workflow guides (will rewrite for v6) - Archive outdated explanation and reference content - Move unreviewed content to basement for later review - Reorganize TEA docs into dedicated /tea/ section - Add workflow-map visual reference page - Simplify getting-started tutorial and sidebar navigation - Add explanation pages: brainstorming, adversarial-review, party-mode, quick-flow, advanced-elicitation - Fix base URL handling for subdirectory deployments (GitHub Pages forks) The goal is a minimal, accurate doc set for beta rather than comprehensive but potentially misleading content. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * refactor: restructure BMM and agents documentation by consolidating and flattening index files. --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
90 lines
2.4 KiB
Markdown
90 lines
2.4 KiB
Markdown
---
|
|
title: "How to Run Code Review"
|
|
description: How to run code review for quality assurance
|
|
---
|
|
|
|
Use the `code-review` workflow to perform a thorough quality review of implemented code.
|
|
|
|
## When to Use This
|
|
|
|
- After dev-story completes implementation
|
|
- Before marking a story as DONE
|
|
- Every story goes through code review — no exceptions
|
|
|
|
:::note[Prerequisites]
|
|
- BMad Method installed
|
|
- DEV agent available
|
|
- Story implementation complete
|
|
- Tests written and passing
|
|
:::
|
|
|
|
## Steps
|
|
|
|
### 1. Load the DEV Agent
|
|
|
|
Start a fresh chat (or continue from dev-story) and load the DEV agent.
|
|
|
|
### 2. Run the Workflow
|
|
|
|
```
|
|
*code-review
|
|
```
|
|
|
|
### 3. Provide Context
|
|
|
|
Point the agent to:
|
|
- The story file
|
|
- Files changed during implementation
|
|
- Test files
|
|
|
|
### 4. Review Findings
|
|
|
|
The agent performs a senior developer code review and reports findings.
|
|
|
|
### 5. Address Issues
|
|
|
|
If issues are found:
|
|
1. Fix issues using dev-story
|
|
2. Re-run tests
|
|
3. Run code-review again
|
|
|
|
## What Gets Reviewed
|
|
|
|
| Category | Checks |
|
|
|----------|--------|
|
|
| **Code Quality** | Clean code, appropriate abstractions, no code smells, proper error handling |
|
|
| **Architecture Alignment** | Follows ADRs, consistent with patterns, proper separation of concerns |
|
|
| **Testing** | Adequate coverage, meaningful tests, edge cases, follows project patterns |
|
|
| **Security** | No hardcoded secrets, input validation, proper auth, no common vulnerabilities |
|
|
| **Performance** | No obvious issues, appropriate data structures, efficient queries |
|
|
|
|
## Review Outcomes
|
|
|
|
**Approved** — Code meets quality standards, tests pass. Mark story as DONE in sprint-status.yaml.
|
|
|
|
**Changes Requested** — Issues identified that need fixing. Fix issues in dev-story, then re-run code-review.
|
|
|
|
## Quality Gates
|
|
|
|
Every story goes through code-review before being marked done. This ensures:
|
|
|
|
- Consistent code quality
|
|
- Architecture adherence
|
|
- Test coverage
|
|
- Security review
|
|
|
|
## Tips
|
|
|
|
- **Don't skip for "simple" changes** — Simple changes can have subtle bugs
|
|
- **Address all findings** — Not just critical ones
|
|
- **Use findings as learning opportunities** — Improve over time
|
|
- **Re-run review after fixes** — Verify issues are resolved
|
|
|
|
## Next Steps
|
|
|
|
After code review:
|
|
|
|
1. **If approved** — Update sprint-status.yaml to mark story DONE
|
|
2. **If changes requested** — Fix issues and re-run review
|
|
3. **Move to next story** — Run create-story for the next item
|