Set Custom Trigger Phrases for Claude in GitHub PRs
By default, Claude Code GitHub Actions responds to @claude in PR and issue comments. If that conflicts with another bot or you want a different keyword, the trigger_phrase parameter lets you change it.
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
trigger_phrase: "@ai-review"
Now team members type @ai-review fix the failing test instead of @claude. The action filters comments for your custom phrase and ignores everything else.
This is useful when you have multiple Claude-powered workflows on the same repo. Set one to trigger on @claude-review for code reviews and another on @claude-fix for bug fixes, each with different prompts and tool restrictions:
# Review workflow
trigger_phrase: "@claude-review"
claude_args: "--max-turns 5 --allowedTools Read,Glob,Grep"
# Fix workflow
trigger_phrase: "@claude-fix"
claude_args: "--max-turns 15"
Note that the trigger must appear in the comment body, not as a GitHub mention. It's a simple string match, not an actual GitHub user tag.
Name your bot whatever you want. It's your repo, your rules.
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.