Claude Code Review #18
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| --- | |
| name: Claude Code Review | |
| on: | |
| issue_comment: | |
| types: [created] | |
| jobs: | |
| check-team-member: | |
| runs-on: ubuntu-latest | |
| outputs: | |
| is-team-member: ${{ steps.check.outputs.is-member }} | |
| steps: | |
| - name: Checkout repository | |
| uses: actions/checkout@v5 | |
| with: | |
| fetch-depth: 1 | |
| - name: Check if actor is team member | |
| id: check | |
| run: | | |
| ACTOR="${{ github.actor }}" | |
| if grep -q "@${ACTOR}" .github/teams.yml; then | |
| echo "is-member=true" >> $GITHUB_OUTPUT | |
| echo "✅ $ACTOR is a team member" | |
| else | |
| echo "is-member=false" >> $GITHUB_OUTPUT | |
| echo "❌ $ACTOR is not a team member" | |
| fi | |
| claude-review: | |
| needs: check-team-member | |
| if: | | |
| needs.check-team-member.outputs.is-team-member == 'true' && | |
| github.actor != 'github-actions[bot]' && | |
| github.event.issue.pull_request && | |
| contains(github.event.comment.body, '@claude /full-review') | |
| runs-on: ubuntu-latest | |
| timeout-minutes: 10 | |
| concurrency: | |
| group: claude-review-${{ github.event.issue.number }} | |
| cancel-in-progress: true | |
| permissions: | |
| contents: read | |
| pull-requests: read | |
| issues: read | |
| id-token: write | |
| steps: | |
| - name: Checkout repository | |
| uses: actions/checkout@v5 | |
| with: | |
| fetch-depth: 1 | |
| - name: Run Claude Code Review | |
| id: claude-review | |
| uses: anthropics/claude-code-action@v1 | |
| env: | |
| ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} | |
| with: | |
| anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} | |
| track_progress: true | |
| prompt: | | |
| You are reviewing code changes for a React component library with git diffs included in the prompt. Focus on ensuring the changes are sound, clean, intentional, and void of regressions. | |
| REPO: ${{ github.repository }} | |
| PR NUMBER: ${{ github.event.pull_request.number }} | |
| Context: | |
| - This is a frontend React component library published to npm as @zenml-io/react-component-library | |
| - Uses TypeScript, Tailwind CSS, Radix UI primitives, Vitest for testing, and Storybook for documentation | |
| - Built with tsup (ESM + CJS), uses pnpm for package management | |
| - You can fetch additional PR context via: | |
| - gh pr view ${{ github.event.pull_request.number }} --json title,body,author,headRefName,baseRefName,commits | |
| - gh pr diff ${{ github.event.pull_request.number }} --name-only | |
| - Use the repository's CLAUDE.md (if present) and existing code patterns for conventions. | |
| Primary Review Goals: | |
| 1) Verify Change Correctness | |
| - Confirm the changes achieve their intended purpose | |
| - Check for unintended side effects or regressions in component behavior | |
| - Validate edge cases are handled properly (empty states, loading states, error states) | |
| - Ensure error paths are covered | |
| - Verify prop validation and TypeScript types are correct | |
| 2) Code Quality & Cleanliness | |
| - Is the code readable and self-documenting? | |
| - Are the changes minimal and focused? | |
| - Do they follow existing patterns in the codebase? | |
| - Are there any code smells or anti-patterns? | |
| - Is the component structure logical and maintainable? | |
| 3) Frontend-Specific Concerns | |
| - **Accessibility (a11y)**: ARIA attributes, keyboard navigation, focus management, semantic HTML | |
| - **TypeScript**: Proper typing, no `any` types, exported types are correctly defined | |
| - **Bundle Size**: Unnecessary dependencies, code bloat, tree-shaking considerations | |
| - **Performance**: Unnecessary re-renders, proper memoization, efficient event handlers | |
| - **Styling**: Tailwind classes used correctly, no inline styles, responsive design | |
| - **Browser Compatibility**: Works across target browsers | |
| 4) Component API Design | |
| - Are component props intuitive and consistent with existing components? | |
| - Are breaking changes to component APIs clearly justified? | |
| - Is the component composable and flexible? | |
| - Are default prop values sensible? | |
| - Is the component API backward compatible? | |
| 5) Potential Issues to Flag | |
| - Accessibility violations (missing labels, improper ARIA, keyboard traps) | |
| - Performance degradations (unnecessary re-renders, memory leaks) | |
| - Security vulnerabilities (XSS risks, unsafe HTML rendering) | |
| - Breaking changes to public component APIs | |
| - TypeScript type errors or unsafe type assertions | |
| - Missing error boundaries or error handling | |
| 6) Constructive Suggestions | |
| - Alternative approaches that might be cleaner | |
| - Opportunities to reduce complexity | |
| - Opportunities to improve accessibility | |
| Testing Feedback Guidelines: | |
| - **Be concise**: Avoid verbose test suggestions or lengthy code examples. | |
| - **Stay laser-focused**: Only suggest tests that directly verify the specific changes in this PR—not tangential functionality. | |
| - **Prioritize manual testing**: Brief, actionable suggestions for what to manually verify are most useful (e.g., "Test keyboard navigation on the new dropdown"). | |
| - **Limit scope**: If tests are needed, mention the scenario to cover in 1-2 sentences rather than writing full test implementations. | |
| - **Skip if unnecessary**: Not every PR needs test suggestions—if the changes are straightforward or already covered, don't force test recommendations. | |
| Documentation & Storybook Review: | |
| - Determine if component behavior, props, or APIs have changed. | |
| - Heuristics (run): gh pr diff ${{ github.event.pull_request.number }} --name-only | |
| - If component changes are present in `src/` but corresponding Storybook stories are not updated, flag as "Storybook update needed". | |
| - If new components are added, ensure they have Storybook stories demonstrating usage. | |
| - If component props changed, ensure stories showcase the new prop variations. | |
| - Check that JSDoc comments are present for complex props or components. | |
| - If breaking changes are introduced to component APIs, recommend adding migration notes in the PR description or changelog. | |
| - If documentation is needed, explicitly call it out in the review with concrete file/section suggestions. | |
| Review Format: | |
| - Start with a summary of what the changes accomplish. | |
| - List any critical issues that must be addressed. | |
| - Note minor improvements that would enhance quality. | |
| - Acknowledge what's done particularly well. | |
| - End with specific, actionable next steps if needed. | |
| Output Instructions: | |
| - Provide detailed feedback using inline-style code references in your comment for specific issues (quote file paths and line ranges when possible). | |
| - Use top-level comments for general observations or praise. | |
| - Use `gh pr comment` to post your review comment to the PR. | |
| Be constructive and helpful in your feedback. | |
| claude_args: --allowed-tools "mcp__github_inline_comment__create_inline_comment,Bash(gh issue view:*),Bash(gh search:*),Bash(gh issue list:*),Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh pr list:*)" |