Files
BMAD-METHOD/docs/_archive/how-to-workflows/run-code-review.md
Alex Verkhovsky 91f6c41be1 docs: radical reduction of documentation scope for v6 beta (#1406)
* 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>
2026-01-25 14:00:26 -06:00

2.4 KiB

title, description
title description
How to Run Code Review 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