Skip to content

Sync Claude Code Review Workflow #1773

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
tarrencev wants to merge 1 commit into from
Closed

Sync Claude Code Review Workflow #1773

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
113 changes: 80 additions & 33 deletions .github/workflows/claude-code-review.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,26 +1,44 @@
name: claude-code-review
name: claude
Copy link
Contributor

@claude claude bot Jun 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The workflow name change from "claude-code-review" to "claude" makes it less descriptive. Consider keeping the more specific name or using "claude-code-review" to clearly indicate the workflow's purpose.


on:
pull_request:
types: [opened, synchronize]

jobs:
claude-review:
# Optional: Filter by PR author
# if: |
# github.event.pull_request.user.login == 'external-contributor' ||
# github.event.pull_request.user.login == 'new-developer' ||
# github.event.pull_request.author_association == 'FIRST_TIME_CONTRIBUTOR'

runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: read
pull-requests: write
Copy link
Contributor

@claude claude bot Jun 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing from read to write permissions for pull-requests increases the security surface. This is necessary for Claude to add review comments, but ensure this is documented and justified in the PR description.

issues: read
id-token: write

steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 1
fetch-depth: 2
Copy link
Contributor

@claude claude bot Jun 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fetch-depth change from 1 to 2 should be documented. This is likely needed for the Claude bot detection (git log -1) to work properly, but it's not immediately clear why 2 commits are needed instead of just 1.


- name: Check if commit is from Claude
id: check-author
run: |
AUTHOR_EMAIL=$(git log -1 --pretty=format:'%ae')
AUTHOR_NAME=$(git log -1 --pretty=format:'%an')
if [[ "$AUTHOR_EMAIL" == *"claude[bot]"* ]] || [[ "$AUTHOR_NAME" == *"claude[bot]"* ]]; then
echo "skip=true" >> $GITHUB_OUTPUT
else
echo "skip=false" >> $GITHUB_OUTPUT
fi

- name: Run Claude Code Review
id: claude-review
if: steps.check-author.outputs.skip != 'true'
uses: anthropics/claude-code-action@beta
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
Expand All @@ -30,33 +48,62 @@ jobs:

# Direct prompt for automated review (no @claude mention needed)
Copy link
Contributor

@claude claude bot Jun 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The direct_prompt is extremely long (60+ lines) and embedded directly in the YAML. This creates several issues:

  1. Maintainability: Hard to modify or version control the prompt separately
  2. YAML complexity: Risk of syntax errors with complex multi-line strings
  3. Reusability: Can't reuse this prompt across repositories

Consider extracting the prompt to a separate file:

Suggested change
# Direct prompt for automated review (no @claude mention needed)
# Direct prompt for automated review (no @claude mention needed)
direct_prompt_file: .github/claude/review-prompt.md

Or at minimum, use a more concise prompt and reference external documentation for detailed instructions.

direct_prompt: |
Please review this pull request and provide feedback on:
- Code quality and best practices
- Potential bugs or issues
- Performance considerations
- Security concerns
- Test coverage

Be constructive and helpful in your feedback.

# Optional: Customize review based on file types
# direct_prompt: |
# Review this PR focusing on:
# - For TypeScript files: Type safety and proper interface usage
# - For API endpoints: Security, input validation, and error handling
# - For React components: Performance, accessibility, and best practices
# - For tests: Coverage, edge cases, and test quality

# Optional: Different prompts for different authors
# direct_prompt: |
# ${{ github.event.pull_request.author_association == 'FIRST_TIME_CONTRIBUTOR' &&
# 'Welcome! Please review this PR from a first-time contributor. Be encouraging and provide detailed explanations for any suggestions.' ||
# 'Please provide a thorough code review focusing on our coding standards and best practices.' }}

# Optional: Add specific tools for running tests or linting
# allowed_tools: "Bash(npm run test),Bash(npm run lint),Bash(npm run typecheck)"

# Optional: Skip review for certain conditions
# if: |
# !contains(github.event.pull_request.title, '[skip-review]') &&
# !contains(github.event.pull_request.title, '[WIP]')
Please review this TypeScript/React PR and provide inline feedback using the GitHub review system. Follow these steps:

1. **Check for existing reviews**: First, use `mcp__github__get_pull_request_reviews` to check if you have any existing pending or submitted reviews on this PR
2. **Check existing comments**: Use `mcp__github__get_pull_request_comments` to see what comments have already been made to avoid redundancy
3. **Start a fresh review**: Use `mcp__github__create_pending_pull_request_review` to begin a new pending review
4. **Get diff information**: Use `mcp__github__get_pull_request_diff` to understand the code changes
5. **Add unique inline comments**: Only add comments for issues that haven't been addressed in existing reviews
6. **Add inline comments**: Use `mcp__github__add_pull_request_review_comment_to_pending_review` for each specific piece of feedback on particular lines, including code change suggestions where appropriate using multiline comments and the suggestion syntax:

```suggestion
const handleSubmit = useCallback(async (data: FormData) => {
// Implementation here
}, []);
```

7. **Submit the review**: Use `mcp__github__submit_pending_pull_request_review` with event type "COMMENT" (not "REQUEST_CHANGES") to publish all comments as a non-blocking review

Only comment when something is off, wrong, or could be improved but don't be overly pedantic; if a given implementation is already good, do not comment on it.

Focus your review on:

**TypeScript & Code Quality:**
- Type safety and proper interface/type definitions
- Proper use of TypeScript features (generics, union types, etc.)
- Code organization and module structure
- Import/export patterns and dependency management

**React & Frontend Best Practices:**
- Component design and reusability
- Hook usage patterns and custom hooks
- State management and data flow
- Performance optimizations (memoization, lazy loading)
- Proper cleanup and memory leak prevention

**Gaming & Web3 Integration:**
- Starknet integration best practices
- WebAuthn implementation security
- iframe security considerations
- Gaming API integrations and error handling

**Security & Performance:**
- Input validation and sanitization
- XSS prevention and secure coding practices
- Bundle size and loading performance
- Accessibility (a11y) compliance
- Mobile responsiveness and touch interactions

**Testing & Quality:**
- Test coverage and quality
- Component testing strategies
- Integration test completeness
- Mock and fixture appropriateness

Provide specific, actionable feedback with inline comments and suggestions for line-specific issues. Include an concise overall summary when submitting the review.

**Important**: Submit as "COMMENT" type so the review doesn't block the PR.

# Add MCP GitHub tools for inline comments and project-specific testing
allowed_tools: "mcp__github__create_pending_pull_request_review,mcp__github__get_pull_request_comments,mcp__github__get_pull_request_reviews,mcp__github__add_pull_request_review_comment_to_pending_review,mcp__github__submit_pending_pull_request_review,mcp__github__get_pull_request_diff,Bash(pnpm test),Bash(pnpm lint),Bash(pnpm build)"
Loading