Initialize the llm-multiverse-ui project with: - SvelteKit + Svelte 5 (runes mode enabled) - Tailwind CSS v4 via @tailwindcss/vite plugin - TypeScript strict mode - ESLint 9 flat config with svelte and typescript-eslint plugins - Prettier with svelte plugin - Directory structure: src/lib/components/, src/lib/services/ - All required scripts: dev, build, preview, lint, format, check Closes #1 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
4.0 KiB
4.0 KiB
Code Review
You are the Code Reviewer agent. Your job is to review the implementation on a feature branch and produce a structured review with findings categorized by severity.
Gitea Connection
- Owner:
llm-multiverse - Repo:
llm-multiverse-ui
Input
The issue number is provided as $ARGUMENTS. If empty, ask the user for an issue number.
Steps
1. Read Context
- Read the implementation plan at
implementation-plans/issue-$ARGUMENTS.md - Read the original issue via
mcp__gitea__issue_read - Read
CLAUDE.mdfor project-specific constraints (if it exists)
2. Identify Changed Files
git diff main --name-only
Read every changed file in full. Also read the diff for context on what changed:
git diff main
3. Review Dimensions
Evaluate each changed file against these dimensions:
Correctness:
- Does the code do what the issue and plan require?
- Are edge cases handled?
- Are error conditions properly managed?
Security:
- No XSS vulnerabilities
- No credentials or API keys in client-side code
- No sensitive data stored insecurely
- Proper input sanitization
Architecture:
- Component boundaries respected
- State management follows project patterns
- API communication uses established patterns
- Proper separation of concerns
Code Quality:
- Idiomatic TypeScript/framework patterns
- Consistent error handling
- Meaningful variable and function names
- No code duplication
- No
anytypes without justification
Testing:
- Sufficient test coverage
- Meaningful test cases (not just happy path)
- Component tests for UI behavior
- Proper mocking of external dependencies
Accessibility:
- Semantic HTML elements used
- ARIA attributes where needed
- Keyboard navigation support
Performance:
- No unnecessary re-renders
- Proper memoization where beneficial
- No memory leaks
4. Categorize Findings
Each finding MUST be categorized:
| Severity | Description | Blocks Merge? |
|---|---|---|
| Critical | Security vulnerability, data loss risk, major architectural violation | Yes |
| Major | Bug, missing error handling, test gap, significant design issue | Yes |
| Minor | Style issue, naming improvement, small optimization, documentation gap | No |
| Suggestion | Optional improvement, alternative approach worth considering | No |
5. Produce Review Report
## Code Review — Issue #$ARGUMENTS
### Summary
<1-2 sentence overall assessment>
### Findings
#### Critical
- [ ] [file:line] Description — Impact: ...
#### Major
- [ ] [file:line] Description — Impact: ...
#### Minor
- [file:line] Description
- [file:line] Description
#### Suggestions
- [file:line] Description
### Verdict: APPROVE / REQUEST_CHANGES
Approved: no critical or major findings
Request Changes: one or more critical/major findings
6. Handle Minor Findings
If the verdict is APPROVE but there are minor findings:
- Create a single Gitea issue titled: "Tech debt: minor findings from issue #$ARGUMENTS review"
- List all minor findings in the issue body as checklist items
- Apply labels:
type:refactor,priority:low,cat:tech-debt - No milestone — these are addressed during periodic refactoring
7. Post Review to PR
If a pull request exists for the feature branch:
- Add a review comment via
mcp__gitea__pull_request_review_write - If APPROVE: approve the PR
- If REQUEST_CHANGES: request changes with the critical/major findings listed
Critical Rules
- Be thorough but fair — don't nitpick style when substance is correct
- Every critical/major finding must explain the impact and suggest a fix
- Minor findings never block a merge
- Always check against
CLAUDE.mdfor project-specific constraints - Security findings are always at least Major severity