coderabbit-multi-env-setup
Configures environment-specific CodeRabbit review settings based on branch targets.
Install
mkdir -p .claude/skills/coderabbit-multi-env-setup && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4690" && unzip -o skill.zip -d .claude/skills/coderabbit-multi-env-setup && rm skill.zipInstalls to .claude/skills/coderabbit-multi-env-setup
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Configure CodeRabbit review behavior per branch and environment usingKey capabilities
- →Configure different review profiles per branch
- →Set stricter review requirements for production branches
- →Define relaxed review settings for development branches
- →Apply security-focused instructions for release branches
- →Use `path_instructions` for environment-specific review guidance
- →Configure GitHub branch protection rules based on review policies
How it works
CodeRabbit reads the `.coderabbit.yaml` file from the pull request's base branch, allowing different review configurations for development, production, and release branches. This enables varied review profiles and instructions based on the target environment.
Inputs & outputs
When to use coderabbit-multi-env-setup
- →Configuring per-branch review profiles
- →Implementing strict reviews for main branches
- →Setting up dev-specific review settings
- →Managing environment-based review workflows
About this skill
CodeRabbit Multi-Environment Setup
Overview
Configure CodeRabbit review behavior based on branch targets and environments. CodeRabbit reads .coderabbit.yaml from the PR's base branch, allowing different review configurations per branch. This enables stricter reviews for production branches, relaxed reviews for development, and custom instructions per environment.
Prerequisites
- CodeRabbit GitHub App installed on repository
- Branch strategy defined (e.g., GitFlow, trunk-based, GitHub Flow)
.coderabbit.yamlcommitted to each relevant branch
How Branch-Based Config Works
Developer opens PR: feature/auth → develop
CodeRabbit reads: .coderabbit.yaml from develop branch
Profile: "chill" (development, quick iteration)
Developer opens PR: develop → main
CodeRabbit reads: .coderabbit.yaml from main branch
Profile: "assertive" (production, thorough review)
Developer opens PR: hotfix/fix → release/v2.1
CodeRabbit reads: .coderabbit.yaml from release/v2.1 branch
Profile: "assertive" + security-focused instructions
Instructions
Step 1: Configure Development Branch (Relaxed)
# .coderabbit.yaml on develop branch
language: "en-US"
reviews:
profile: "chill" # Fewer comments for rapid iteration
request_changes_workflow: false # Don't block merges to develop
high_level_summary: true
sequence_diagrams: false # Skip diagrams for dev PRs
auto_review:
enabled: true
drafts: false
base_branches:
- develop
ignore_title_keywords:
- "WIP"
- "DO NOT MERGE"
- "experiment"
path_filters:
- "!**/*.lock"
- "!**/*.snap"
- "!dist/**"
- "!**/*.generated.*"
path_instructions:
- path: "**"
instructions: |
Development branch review:
- Only flag bugs, security issues, and obvious errors
- Do NOT comment on code style, naming, or formatting
- Do NOT suggest refactoring unless it fixes a bug
chat:
auto_reply: true
Step 2: Configure Production Branch (Strict)
# .coderabbit.yaml on main branch
language: "en-US"
reviews:
profile: "assertive" # Thorough review for production
request_changes_workflow: true # Block merge on issues
high_level_summary: true
high_level_summary_in_walkthrough: true
sequence_diagrams: true
review_status: true
auto_review:
enabled: true
drafts: false
base_branches:
- main
path_filters:
- "!**/*.lock"
- "!**/*.snap"
- "!dist/**"
- "!vendor/**"
path_instructions:
- path: "**"
instructions: |
Production review checklist:
1. Flag any hardcoded secrets, API keys, or credentials
2. Check error handling: no empty catch blocks, proper error propagation
3. Verify input validation on all API endpoints
4. Check for proper logging (structured, no PII)
- path: "src/api/**"
instructions: |
API review (production):
- Verify proper HTTP status codes
- Check auth middleware is applied to protected routes
- Validate request bodies with schema validation
- Ensure error responses follow RFC 7807 format
- Flag missing rate limiting
- path: "src/db/**"
instructions: |
Database review (production):
- All queries MUST use parameterized statements
- Transactions required for multi-table mutations
- Check for N+1 query patterns
- Verify index usage for complex queries
- Flag any raw SQL string concatenation
- path: ".github/workflows/**"
instructions: |
CI/CD review (production):
- Pin ALL action versions to SHA (not tags)
- Never echo or log secrets
- Include timeout-minutes on all jobs
- Use OIDC for cloud provider authentication
chat:
auto_reply: true
Step 3: Configure Release Branch (Security-Focused)
# .coderabbit.yaml on release/* branches
language: "en-US"
reviews:
profile: "assertive"
request_changes_workflow: true # Block merges on issues
auto_review:
enabled: true
drafts: false
base_branches:
- "release/*"
path_instructions:
- path: "**"
instructions: |
RELEASE BRANCH - Security and stability focus:
1. Flag ANY security vulnerability (priority over all other feedback)
2. Check for backward compatibility
3. Verify no debug code (console.log, debugger statements)
4. Ensure proper error messages (no stack traces exposed to users)
5. Check for feature flags guarding unreleased features
Only provide feedback on bugs and security. Skip style comments entirely.
- path: "src/auth/**"
instructions: |
CRITICAL PATH for release. Check:
- Token validation and expiry
- Session management security
- CSRF protection
- No auth bypass vulnerabilities
chat:
auto_reply: true
Step 4: Maintain Branch Configs with a Script
#!/bin/bash
# update-coderabbit-configs.sh - Keep branch configs in sync
set -euo pipefail
CURRENT_BRANCH=$(git branch --show-current)
# Update develop branch config
git checkout develop 2>/dev/null || git checkout -b develop
cp configs/coderabbit-develop.yaml .coderabbit.yaml
git add .coderabbit.yaml
git diff --cached --quiet || git commit -m "chore: update CodeRabbit config for develop"
# Update main branch config
git checkout main
cp configs/coderabbit-main.yaml .coderabbit.yaml
git add .coderabbit.yaml
git diff --cached --quiet || git commit -m "chore: update CodeRabbit config for main"
# Return to original branch
git checkout "$CURRENT_BRANCH"
echo "CodeRabbit configs updated on develop and main"
echo "Push both branches to apply: git push origin develop main"
Step 5: Verify Per-Branch Configuration
# On a PR targeting develop:
@coderabbitai configuration
# Should show: profile: "chill", request_changes_workflow: false
# On a PR targeting main:
@coderabbitai configuration
# Should show: profile: "assertive", request_changes_workflow: true
# If both show the same config, the branch-specific .coderabbit.yaml
# is not committed to the base branch. Verify with:
# git show main:.coderabbit.yaml
# git show develop:.coderabbit.yaml
Step 6: Branch Protection per Environment
set -euo pipefail
OWNER="your-org"
REPO="your-repo"
# Main: require CodeRabbit approval
gh api "repos/$OWNER/$REPO/branches/main/protection" \
--method PUT \
--field 'required_status_checks={"strict":true,"contexts":["coderabbitai"]}' \
--field 'required_pull_request_reviews={"required_approving_review_count":1}' \
--field 'enforce_admins=true' \
--field 'restrictions=null'
# Develop: CodeRabbit review optional (not required)
gh api "repos/$OWNER/$REPO/branches/develop/protection" \
--method PUT \
--field 'required_status_checks={"strict":false,"contexts":[]}' \
--field 'required_pull_request_reviews={"required_approving_review_count":0}' \
--field 'enforce_admins=false' \
--field 'restrictions=null'
echo "Branch protection configured"
echo " main: CodeRabbit required"
echo " develop: CodeRabbit optional"
Output
- Branch-specific
.coderabbit.yamlconfigs committed - Development branch with relaxed review profile
- Production branch with strict review and security instructions
- Release branches with security-focused review
- Branch protection rules aligned with review policies
Error Handling
| Issue | Cause | Solution |
|---|---|---|
| Same review profile on all branches | Config only on one branch | Commit different .coderabbit.yaml to each base branch |
| Config changes not applied | YAML not on the base branch | Merge config changes to the target branch first |
| PR to main gets "chill" review | .coderabbit.yaml on main has wrong profile | Check config with git show main:.coderabbit.yaml |
| Release branch not reviewed | base_branches doesn't include release/* | Add glob pattern release/* to base_branches |
Resources
Next Steps
For deployment and org-wide rollout, see coderabbit-deploy-integration.
When not to use it
- →When a single review profile is desired across all branches
- →When the branch strategy is not clearly defined
- →When the `.coderabbit.yaml` is not committed to each relevant branch
Prerequisites
Limitations
- →Review profiles will be the same across all branches if config is only on one branch
- →Configuration changes are not applied until merged to the target base branch
- →Release branches may not be reviewed if `base_branches` does not include the pattern
How it compares
This skill allows for dynamic review behavior based on the target branch, providing more granular control than a single, static CodeRabbit configuration for all pull requests.
Compared to similar skills
coderabbit-multi-env-setup side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| coderabbit-multi-env-setup (this skill) | 1 | 27d | Review | Intermediate |
| shellcheck-configuration | 9 | 2mo | No flags | Intermediate |
| wolf-scripts-core | 5 | 9mo | Review | Intermediate |
| final-release-review | 5 | 4mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
shellcheck-configuration
wshobson
Master ShellCheck static analysis configuration and usage for shell script quality. Use when setting up linting infrastructure, fixing code issues, or ensuring script portability.
wolf-scripts-core
Nice-Wolf-Studio
Core automation scripts for archetype selection, evidence validation, quality scoring, and safe bash execution
final-release-review
openai
Perform a release-readiness review by locating the previous release tag from remote tags and auditing the diff (e.g., v1.2.3...<commit>) for breaking changes, regressions, improvement opportunities, and risks before releasing openai-agents-python.
fix
Use when you have lint errors, formatting issues, or before committing code to ensure it passes CI.
verify
Use when you want to validate changes before committing, or when you need to check all React contribution requirements.
bash-defensive-patterns
wshobson
Master defensive Bash programming techniques for production-grade scripts. Use when writing robust shell scripts, CI/CD pipelines, or system utilities requiring fault tolerance and safety.