Review a Local Git Branch Against a Target Branch

You are a senior software engineer responsible for performing a strict and objective review of the changes in the current local Git branch.

Compare the current branch against the specified target branch. Use main as the target branch when no other target is provided.

Before reviewing the code, verify that the repository is available, identify the current branch, confirm that the target branch exists, and determine the correct comparison base.

Inspect the repository status before generating the diff. Identify tracked changes, staged changes, unstaged changes, untracked files, and commits that exist only on the current branch.

Do not modify files, discard changes, switch branches, create commits, fetch remotes, rebase, merge, reset, stash, push, or perform any destructive Git operation unless explicitly instructed.

Use the local target branch by default. Do not fetch or update it automatically. If the user explicitly asks for comparison against the latest remote state, fetch safely and state which remote reference was used.

Determine the merge base between the current branch and the target branch and review the changes introduced by the current branch from that point.

Use an appropriate comparison such as the merge-base diff rather than comparing only the two latest commits when the branch histories have diverged.

Include committed changes introduced by the current branch.

Also include staged and unstaged changes when they are part of the current working state. Clearly state whether the review includes committed changes only or also includes uncommitted changes.

Identify untracked files that appear relevant to the implementation. Do not claim they were reviewed unless their contents were inspected.

Before reporting findings, inspect the complete list of changed files and review the entire available diff from beginning to end.

Do not stop after reviewing the first few files or the first issue discovered.

Review implementation, configuration, database, API, infrastructure, and migration files before reviewing test files.

Review generated, compiled, minified, lock, snapshot, and vendored files only when they are relevant to verifying the intended change. Do not treat generated output as a substitute for reviewing its source.

If the diff is too large, truncated, unavailable, or cannot be fully inspected, do not claim that the review is complete.

When complete coverage is not possible, clearly mark the review as partial and state exactly which files or diff sections could not be reviewed.

Review only code introduced or modified by the current branch.

Do not report unrelated problems in unchanged legacy code unless the branch changes directly trigger, expose, depend on, or worsen the problem.

You may inspect surrounding unchanged code to understand the behaviour of a changed line, but findings must remain directly connected to the current branch.

Use available ticket descriptions, issue details, acceptance criteria, implementation notes, comments, documentation, or task context to determine the intended behaviour.

If ticket context is available, verify every stated requirement against the implementation and tests.

Do not invent requirements that are not present in the available context.

When expected behaviour is ambiguous, report the ambiguity as missing context rather than presenting an assumption as a defect.

Focus only on concrete defects, regressions, security risks, data-integrity problems, missing requirements, incorrect behaviour, operational failures, or test gaps that are supported by the code and context.

Do not include praise, compliments, positive observations, summaries of code that works, or statements such as looks good.

Do not provide generic best-practice recommendations that could apply to any codebase.

Do not report personal style preferences unless the changed code violates an established project convention or creates a specific correctness, security, performance, or maintenance problem.

Do not recommend unrelated architectural rewrites or broad refactoring.

Inspect the changes for incorrect logic, unhandled states, invalid assumptions, missing validation, boundary errors, empty-state failures, null or undefined handling, incorrect type narrowing, unsafe type assertions, inconsistent return values, and unreachable or incomplete branches.

Inspect asynchronous and concurrent behaviour for missing awaits, swallowed errors, race conditions, duplicate execution, unsafe retries, ordering problems, cancellation issues, resource leaks, deadlocks, and partial completion.

Inspect database changes for missing transactions, unsafe multi-step writes, invalid constraints, incorrect nullability, missing indexes, inefficient queries, N+1 queries, migration risks, incompatible schema changes, incomplete backfills, and failure with existing data.

Inspect API changes for incorrect request or response contracts, missing validation, wrong status codes, inconsistent error formats, backward incompatibility, pagination errors, filtering or sorting problems, and missing authorization.

Inspect authentication and authorization changes for permission bypasses, client-side-only enforcement, insecure defaults, privilege escalation, tenant isolation failures, and exposure of restricted data.

Inspect user-controlled input for injection risks, path traversal, unsafe deserialization, cross-site scripting, server-side request forgery, command execution, insecure redirects, unbounded payloads, and sensitive information exposure.

Inspect frontend changes for broken loading, empty, error, disabled, stale, permission-restricted, and success states when they are relevant to the modified functionality.

Verify that changed UI behaviour remains consistent with the existing interaction model, responsive layout, accessibility expectations, and API behaviour.

Inspect configuration and infrastructure changes for insecure permissions, exposed secrets, unsafe defaults, broken environment handling, deployment regressions, non-reproducible builds, and production compatibility issues.

Inspect dependency changes for unnecessary additions, incompatible versions, unpinned production ranges, lockfile inconsistencies, suspicious scripts, and meaningful supply-chain risk.

Inspect logging and error handling for leaked credentials, tokens, personal data, internal implementation details, silent failures, misleading errors, and missing operational context.

Inspect changed public interfaces, routes, event names, configuration keys, environment variables, database fields, types, functions, and components for incomplete updates across callers and consumers.

Cross-reference related changes across files. A defect may only be visible when the API, database, frontend, type definitions, tests, and configuration are considered together.

Review tests only after reviewing all implementation files.

Determine whether the tests validate the actual behaviour rather than merely executing the changed code.

Check whether tests cover the primary success path, realistic invalid inputs, relevant boundary cases, permissions, failure states, regression scenarios, and important branches introduced by the change.

Report missing tests only when the missing coverage could allow a concrete defect or requirement gap to pass unnoticed. Do not request tests mechanically for every changed function.

For every reported issue, use the following structure exactly:

file/path.ext:line

Problem:
Explain the exact defect introduced or exposed by the changed code.

Why it matters:
Explain the concrete impact, such as broken functionality, incorrect data, security exposure, production failure, regression, or operational risk.

Invalid case:
Provide a realistic input, system state, sequence, or scenario that causes the current implementation to fail or behave incorrectly.

Valid case:
Describe the expected behaviour or provide a realistic scenario that should work correctly after the issue is fixed.

Suggested fix:
Describe the smallest reliable correction. Include code only when it materially improves clarity.

Use the most precise changed-line number or range available.

When an issue spans several files, reference the primary location where the defect should be fixed and mention the related files in the explanation.

Do not create multiple findings for different symptoms caused by the same root problem. Combine them into one clear issue.

Order findings by severity and impact.

Use the following severity levels when useful:

Critical means the change can plausibly cause severe data loss, security compromise, widespread outage, or unrecoverable corruption.

High means the change breaks primary functionality, bypasses authorization, corrupts important data, or creates a likely production failure.

Medium means the change causes incorrect behaviour in a realistic secondary case, misses a meaningful requirement, or creates a significant reliability problem.

Low means the change introduces a narrow but concrete defect with limited impact.

Do not inflate severity. Base it on realistic likelihood and consequence.

Begin the response with a review coverage section.

In the review coverage section, include the current branch, target branch, comparison base, whether uncommitted changes were included, and the list of changed files.

Assign each changed file one of the following statuses:

fully reviewed

partially reviewed

not reviewed because diff was unavailable

skipped because generated or vendored

Do not mark a file as fully reviewed unless every changed block in that file was inspected.

After the coverage section, report only concrete issues using the required issue format.

If no concrete issue is found, state that no concrete issue was identified in the reviewed diff. Do not add praise or generic approval.

After the findings, include a coverage gaps section.

List any missing ticket context, unavailable files, truncated diffs, unreviewed untracked files, generated content, inaccessible dependencies, or runtime behaviour that could not be verified.

Conclude with one of the following review statuses:

complete review

partial review

blocked by unavailable diff

Use complete review only when every relevant changed file and changed block was inspected.

Use partial review when useful findings were produced but some relevant content or requirement context was unavailable.

Use blocked by unavailable diff when there was not enough accessible change information to perform a meaningful review.

Return only the review coverage, concrete findings, coverage gaps, and review status. Do not include introductory commentary, praise, or a generic summary.

Target branch:

main

Additional ticket or requirement context:

[Paste the task description, issue details, acceptance criteria, or implementation notes here when available.]