PR Risk Assessment and Reviewer Recommendation Prompt

This prompt is designed for platform engineering teams building automated code review assignment systems. Its primary job is to analyze a pull request's diff to produce a structured risk assessment and a list of recommended reviewers. The ideal user is a CI/CD pipeline, a code review bot, or a developer tool that needs to programmatically route PRs to the right people based on objective signals rather than manual assignment. The required context includes the full PR diff, a CODEOWNERS file, and ideally a historical contribution graph or expertise map for the repository.

Use this prompt when you need a consistent, auditable method for triaging incoming pull requests before human review begins. It is appropriate for repositories where code ownership is well-defined and where change complexity correlates with review effort. Do not use this prompt for repositories without a CODEOWNERS file or where the team structure is too fluid for ownership to be meaningful. It is also not a substitute for a security-focused static analysis pipeline; this prompt assesses process risk and reviewer fit, not vulnerability detection. The output is a machine-readable risk score with rationale and a suggested reviewer list, designed to be consumed by an assignment system rather than displayed directly to end users.

Before implementing this prompt, ensure you have a reliable method for extracting the PR diff and the CODEOWNERS file. The prompt's effectiveness depends entirely on the quality of these inputs. For high-risk repositories, always pair this automated assessment with a human-in-the-loop approval step for the final reviewer assignment, especially when the model recommends reviewers who have not recently contributed to the affected code paths. The next step after reading this section is to review the prompt template and understand the required input schema.

This section provides the core prompt template for the PR Risk Assessment and Reviewer Recommendation system. The template is designed to be copied directly into your prompt management tool, IDE, or orchestration layer. It accepts a structured diff, repository context, and team configuration to produce a risk score, rationale, and a ranked list of recommended reviewers. Every placeholder is enclosed in square brackets and must be replaced with real data at runtime by your application harness. The prompt is self-contained enough to be tested in a playground before integration, but it assumes the caller has already assembled the necessary inputs.

textCopy
You are a code review risk analyst. Your task is to analyze a pull request diff and produce a structured risk assessment with reviewer recommendations.

## INPUTS

### Pull Request Diff
```diff
[PR_DIFF]

Repository Context

• Repository: [REPOSITORY_NAME]
• Base branch: [BASE_BRANCH]
• Target branch: [TARGET_BRANCH]
• Changed files: [CHANGED_FILE_LIST]

Team Configuration

• CODEOWNERS file:

textCopy
[CODEOWNERS_CONTENT]

• Historical reviewer expertise (file path -> reviewer mapping):

jsonCopy
[HISTORICAL_EXPERTISE_JSON]

• Available reviewers with current workload:

jsonCopy
[AVAILABLE_REVIEWERS_JSON]

Risk Thresholds

• High risk: changes to [HIGH_RISK_PATHS], files > [HIGH_RISK_FILE_SIZE] lines changed, or [HIGH_RISK_PATTERNS]
• Medium risk: changes to [MEDIUM_RISK_PATHS] or files > [MEDIUM_RISK_FILE_SIZE] lines changed
• Low risk: everything else

OUTPUT SCHEMA

Return a single JSON object with this exact structure:

jsonCopy
{
  "risk_assessment": {
    "risk_level": "high|medium|low",
    "risk_score": 0-100,
    "rationale": "string explaining the risk factors identified",
    "risk_factors": [
      {
        "factor": "string describing the risk factor",
        "severity": "high|medium|low",
        "evidence": "specific file paths, line counts, or patterns observed"
      }
    ]
  },
  "reviewer_recommendations": {
    "primary_reviewers": [
      {
        "reviewer": "string username or team name",
        "reason": "string explaining why this reviewer is recommended",
        "expertise_match": ["file paths or patterns they own"],
        "workload_note": "string describing current workload if relevant"
      }
    ],
    "optional_reviewers": [
      {
        "reviewer": "string username or team name",
        "reason": "string explaining secondary relevance"
      }
    ],
    "required_approvals": 1-3
  },
  "warnings": [
    "string describing any concerns that don't fit the risk factors above"
  ]
}

CONSTRAINTS

1. Every risk factor must cite specific evidence from the diff or changed file list. Do not speculate.
2. Primary reviewers must be drawn from CODEOWNERS or historical expertise data. Do not recommend reviewers without evidence of ownership or past contributions to the changed files.
3. If a changed file has no clear owner, flag it in warnings and recommend a reviewer based on adjacent file ownership or team lead.
4. The risk_score must be derived from the risk thresholds provided, not from general intuition.
5. If the diff exceeds [MAX_DIFF_SIZE] lines, note in warnings that the analysis may be incomplete and recommend human triage.
6. Do not include reviewers who are the PR author. Check [PR_AUTHOR] against all recommendations.
7. If the PR touches files in [REQUIRED_REVIEWER_PATHS], ensure at least one primary reviewer is from the required reviewer list.

EXAMPLES

Example 1: Low-risk documentation change

Input: 3 files changed, all in /docs/, 45 total lines added Output risk_level: low, risk_score: 10, primary_reviewers: [docs-team]

Example 2: High-risk auth change

Input: 12 files changed, includes /auth/, /middleware/, /config/secrets, 340 lines changed Output risk_level: high, risk_score: 85, primary_reviewers: [auth-team-lead, security-oncall]

Example 3: Medium-risk API change with unclear ownership

Input: 5 files changed, includes /api/v2/handlers/ with no CODEOWNERS entry Output risk_level: medium, risk_score: 55, warnings: ["No CODEOWNERS entry for /api/v2/handlers/"]

INSTRUCTIONS

Analyze the PR diff against the provided context and thresholds. Return only the JSON object. Do not include explanations outside the JSON.

To adapt this template for your team, replace the risk threshold patterns with your actual high-risk paths, file size limits, and pattern definitions. The historical expertise JSON should be populated from your git history analysis pipeline — map file paths to reviewers who have previously authored or reviewed changes in those paths. The available reviewers JSON should include current workload signals from your project management or code review queue system. If your team uses a different risk taxonomy, adjust the risk_level enum and risk_score range accordingly. Always test the prompt with known PRs where you already know the correct risk level and reviewer assignments before deploying to production.

This prompt is designed to sit inside a code review automation pipeline, not as a standalone chat interaction. The primary integration point is a webhook handler or CI job that receives a pull request event, extracts the diff and relevant metadata, and passes it to the model. The harness is responsible for assembling the [PR_DIFF], [PR_METADATA], [CODEOWNERS_FILE], and [HISTORICAL_REVIEW_DATA] placeholders before the model call. The model's structured output is then parsed and used to update the PR with a risk label, a reviewer recommendation comment, or an assignment via the platform's API.

Input Assembly and Validation: Before calling the model, validate that the diff is non-empty and under the model's context window. For large PRs, truncate the diff to changed files with the highest risk signals (e.g., files matching **/*.sql, **/auth/**, or **/*.tf) and include a summary of the remaining files. The [CODEOWNERS_FILE] should be the raw content from the repository's CODEOWNERS file at the target branch. [HISTORICAL_REVIEW_DATA] should be a pre-computed mapping of file paths to reviewers who have previously approved changes in those areas, extracted from the platform's API. If this data is unavailable, the prompt will still function but the harness should log a warning that reviewer recommendations are based solely on CODEOWNERS and diff analysis. Output Parsing and Validation: The model returns a JSON object with risk_score, risk_rationale, and recommended_reviewers. The harness must validate that risk_score is an integer between 1 and 5, risk_rationale is a non-empty string, and recommended_reviewers is an array of strings matching valid platform usernames. If validation fails, retry once with a repair prompt that includes the validation errors. If the retry also fails, fall back to a default risk label of 3 and assign reviewers from the CODEOWNERS file only.

Human Review and Escalation Gates: For PRs with a risk score of 4 or 5, the harness should not automatically assign reviewers. Instead, it should post a comment tagging the team's lead or the relevant code owners and request a manual review of the risk assessment. The comment should include the model's rationale and the suggested reviewer list. This human-in-the-loop step prevents high-risk changes from being auto-assigned to reviewers who may not have the bandwidth or context for an urgent review. Logging and Observability: Log the full prompt, model response, validation results, and final action taken (assignment, comment, or escalation) to your observability platform. Include the PR number, repository, and a timestamp. This trace is essential for debugging incorrect risk scores, missed reviewer assignments, and for auditing the system's behavior over time. Model Choice: Use a model with strong structured output capabilities and a context window large enough for your typical PR diffs. For cost-sensitive pipelines, consider routing low-complexity PRs (fewer than 5 files changed) to a smaller, faster model and reserving a more capable model for complex or high-risk changes.