Files
llm-multiverse-ui/.claude/commands/code-review.md
shahondin1624 978325565d feat: scaffold SvelteKit project with Tailwind, TypeScript, ESLint, Prettier
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>
2026-03-12 11:03:46 +01:00

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.md for 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 any types 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:

  1. Create a single Gitea issue titled: "Tech debt: minor findings from issue #$ARGUMENTS review"
  2. List all minor findings in the issue body as checklist items
  3. Apply labels: type:refactor, priority:low, cat:tech-debt
  4. 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.md for project-specific constraints
  • Security findings are always at least Major severity