majiayu000 Review Changes
Review the changes for: $ARGUMENTS.
Instructions
Perform a two-phase review:
- Code review - Review quality, architecture, and best practices.
- QA review - Create manual test cases to validate behavior.
Phase 1: Code review
Analyze the code changes for:
PR checklist
Required for all PRs
- Small diff - One logical change. If the PR does multiple things, split it.
- Tests included - New functionality has tests. Bug fixes have regression tests.
- No secrets - No tokens, passwords, or credentials in the code.
If user-facing changes
- Docs updated - The README or relevant documentation reflects the change.
- Examples work - Code examples in the documentation are tested and copy-paste ready.
- Error messages helpful - New errors explain what went wrong and how to fix it.
If breaking changes
- Migration notes - Provide clear before and after examples showing how to upgrade.
- Changelog entry - Follow conventional commits for release notes.
- Deprecation warnings - If keeping an old API temporarily, warn users.
If adding dependencies
- Justified - No existing solution exists in the codebase.
- License compatible - Use MIT or a compatible license.
- Maintained - Use an active project with recent updates.
- Size reasonable - Avoid adding significant bundle weight.
Quality and clean code
- Functions are small and single-purpose.
- Variable and function names are descriptive.
- No dead code or commented-out blocks exist.
- No magic numbers exist (use constants).
- Error messages are helpful.
Architecture and design
- Changes fit existing patterns in the codebase.
- No unnecessary coupling exists between modules.
- Proper separation of concerns exists (actions vs. commands vs. utils).
- Types and interfaces are defined appropriately.
Reusability and centralization
- Duplicated logic is extracted to shared utilities.
- Existing helpers are used where applicable.
- New utilities are generic enough for reuse.
- Constants are centralized (not scattered).
Best practices
- Async and await are used consistently (no mixed patterns).
- Errors are propagated correctly (not swallowed).
- Edge cases are handled (null, empty, invalid input).
- No security issues exist (injection, secrets exposure).
Output format (code review)
## Code review summary
[LGTM / Needs changes / Blocking issues]
## Issues found
### [Critical/Major/Minor]: Issue title
**File:** `path/to/file.ts:123`
**Problem:** Description.
**Suggestion:** How to fix.
Phase 2: QA review
Test case structure
Refer to the Test Plan Template and the Test Plan Example for test plan structure guidance.
Coverage requirements
Create test cases for:
- Happy path - Normal successful operation.
- Negative cases - Invalid input, unauthorized access, and missing data.
- Edge cases - Empty input, large input, and special characters.
- Error recovery - What happens when things fail mid-operation.