diff --git a/.github/workflows/claude-code-review.yml b/.github/workflows/claude-code-review.yml deleted file mode 100644 index 6ddf5f3..0000000 --- a/.github/workflows/claude-code-review.yml +++ /dev/null @@ -1,146 +0,0 @@ ---- -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:*)" diff --git a/.github/workflows/claude.yml b/.github/workflows/claude.yml index 0dfdf2c..4ef3344 100644 --- a/.github/workflows/claude.yml +++ b/.github/workflows/claude.yml @@ -36,9 +36,9 @@ jobs: needs.check-team-member.outputs.is-team-member == 'true' && github.actor != 'github-actions[bot]' && ( - (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude') && !contains(github.event.comment.body, '@claude /full-review')) || - (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude') && !contains(github.event.comment.body, '@claude /full-review')) || - (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude') && !contains(github.event.review.body, '@claude /full-review')) || + (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) || + (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) || + (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) || (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude'))) ) runs-on: ubuntu-latest @@ -51,7 +51,7 @@ jobs: pull-requests: read issues: read id-token: write - actions: read # Required for Claude to read CI results on PRs + actions: read steps: - name: Checkout repository uses: actions/checkout@v5 @@ -65,15 +65,102 @@ jobs: with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} track_progress: true - - # This is an optional setting that allows Claude to read CI results on PRs additional_permissions: | actions: read + prompt: | + You are a helpful assistant for the ZenML React Component Library. Help the user with whatever they asked. + + If the user is asking for a code review (e.g., "@claude /full-review", "@claude review this", or similar), follow the detailed review guidelines below. Otherwise, just help them with their question or request. + + --- + CODE REVIEW GUIDELINES (use when reviewing PRs): + + 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. - # Optional: Give a custom prompt to Claude. If this is not specified, Claude will perform the instructions specified in the comment that tagged it. - # prompt: 'Update the pull request description to include a summary of changes.' + 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. - # Optional: Add claude_args to customize behavior and configuration - # See https://github.com/anthropics/claude-code-action/blob/main/docs/usage.md - # or https://docs.claude.com/en/docs/claude-code/cli-reference for available options + 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:*)" diff --git a/.github/workflows/codex-comment.yml b/.github/workflows/codex-comment.yml index f10b0a7..e3445d7 100644 --- a/.github/workflows/codex-comment.yml +++ b/.github/workflows/codex-comment.yml @@ -1,5 +1,5 @@ --- -name: Codex Comment +name: Codex on: issue_comment: types: [created] @@ -23,7 +23,7 @@ jobs: uses: actions/checkout@v5 with: fetch-depth: 1 - - name: Check if actor is on OSS team + - name: Check if actor is on team id: check run: | ACTOR="${{ github.actor }}" @@ -45,7 +45,7 @@ jobs: permissions: contents: read outputs: - final_message: ${{ steps.codex_comment.outputs.final-message || steps.codex_full_review.outputs.final-message }} + final_message: ${{ steps.codex.outputs.final-message }} steps: - name: Checkout PR merge commit uses: actions/checkout@v5 @@ -58,52 +58,30 @@ jobs: ${{ github.event.issue.pull_request.base.ref }} \ +refs/pull/${{ github.event.issue.number }}/head \ +refs/pull/${{ github.event.issue.number }}/merge - - name: Determine Codex mode - id: mode - run: | - COMMENT="${{ github.event.comment.body }}" - if echo "$COMMENT" | grep -qi '/codex /full-review'; then - echo "mode=full-review" >> "$GITHUB_OUTPUT" - else - echo "mode=comment" >> "$GITHUB_OUTPUT" - fi - - name: Run Codex (quick reply) - id: codex_comment - if: steps.mode.outputs.mode == 'comment' - uses: openai/codex-action@v1 - with: - openai-api-key: ${{ secrets.OPENAI_API_KEY }} - prompt: | - You are Codex assisting on pull request #${{ github.event.issue.number }} in ${{ github.repository }}. - Base SHA: ${{ github.event.issue.pull_request.base.sha }} - Head SHA: ${{ github.event.issue.pull_request.head.sha }} - - Comment from @${{ github.actor }}: - ---- - ${{ github.event.comment.body }} - ---- - - Follow the instructions from the commenter and limit work to this PR's changes. Provide actionable output suitable for posting back to the PR conversation. - - name: Run Codex (full review) - id: codex_full_review - if: steps.mode.outputs.mode == 'full-review' + - name: Run Codex + id: codex uses: openai/codex-action@v1 with: openai-api-key: ${{ secrets.OPENAI_API_KEY }} codex-args: --max-turns 5 --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:*)" prompt: | - You are Codex performing a comprehensive review for the ZenML React Component Library. + You are Codex assisting on pull request #${{ github.event.issue.number }} in ${{ github.repository }}. REPO: ${{ github.repository }} PR NUMBER: ${{ github.event.issue.number }} BASE SHA: ${{ github.event.issue.pull_request.base.sha }} HEAD SHA: ${{ github.event.issue.pull_request.head.sha }} - Triggering comment from @${{ github.actor }}: + Comment from @${{ github.actor }}: ---- ${{ github.event.comment.body }} ---- + Help the user with whatever they asked. If they're asking for a code review (e.g., "/codex /full-review", "/codex review this", or similar), follow the detailed review guidelines below. Otherwise, just help them with their question or request. + + --- + CODE REVIEW GUIDELINES (use when reviewing PRs): + Context: - Fetch PR metadata via: gh pr view ${{ github.event.issue.number }} --json title,body,author,headRefName,baseRefName,commits - Inspect the diff via: gh pr diff ${{ github.event.issue.number }} --name-only @@ -127,7 +105,7 @@ jobs: - List critical issues (blocking) with file references. - Provide minor suggestions and celebrate strengths. - Suggest concrete next steps or TODOs. - - Use `gh pr comment` if inline discussion is required (allowed via codex-args). + - Use `gh pr comment` if inline discussion is required. post-comment: name: Post Codex reply @@ -144,7 +122,6 @@ jobs: echo "Issue number: ${{ github.event.issue.number }}" env: FINAL_MESSAGE: ${{ needs.run-codex.outputs.final_message }} - - name: Reply with Codex output if: needs.run-codex.outputs.final_message uses: actions/github-script@v7