PR Review Handler

Purpose

This skill processes review comments generated by gemini-code-assist on a pull request. It evaluates the review threads in the Code Review section, determines whether the suggestions are valid, applies changes when appropriate, and resolves each review thread with a concise explanation.

This skill is intended to run after gemini-code-assist has posted its review.

Preconditions

Before executing the workflow, verify the following conditions.

1. The pull request exists.
2. gemini-code-assist has posted a review.
3. The review contains a Code Review section.

If the Code Review section does not exist yet, display the message to the user: "The gemini-code-assist review has not been generated yet. Waiting for the review to be created." Then send a request every 5 seconds to check whether the review has been generated. The message must be written in the user’s preferred language.

Review Structure

gemini-code-assist produces two sections:

• Summary of Changes
• Code Review

Only Code Review contains actionable review comments.

Each review thread may include:

• File path
• Diff
• Issue priority
• Review comment
• Optional suggested changes

Workflow

1. Collect review threads

Retrieve all PR review threads created by gemini-code-assist.

For each thread, collect:

• file path
• diff
• priority
• review comment
• suggested change (if present)
• resolved status

Ignore threads that are already resolved.

2. Check if all reviews are already resolved

If all review threads are resolved, stop execution and report:

> All reviews have already been resolved.

(or in the user's preferred language)

Do not leave additional PR comments.

3. Evaluate each review

For each unresolved review thread, verify the following:

Condition 1 — Review already resolved

If resolved -> ignore.

Condition 2 — Review is reasonable

Determine whether the comment:

• correctly identifies an issue
• improves correctness, clarity, maintainability, or safety
• is technically valid

If the suggestion is incorrect or irrelevant, mark it as not accepted.

Condition 3 — Specification conflict

Check whether the suggested change conflicts with:

• project specification
• existing architecture
• intended design decisions

If a conflict exists -> reject the suggestion.

4. Apply valid changes

If a review passes all conditions:

1. Modify the relevant code.
2. Ensure changes compile and are logically correct.
3. Commit the change.

Commit rules

Commits must follow atomic change principles.

• Each logical change -> separate commit.
• Documentation alone is not considered atomic work.

If documentation is created:

• Include related code changes in the same commit.

Exception:

• Pure specification updates without code changes may be committed alone,

but this should be applied conservatively.

5. Push changes

Push commits to the PR branch.

6. Resolve review threads

For each processed review thread:

If applied

Post a comment indicating the change was applied.

Format: {message} ({short_commit_hash})

Example: 변수 네이밍 규칙에 맞게 수정 (a1b2c3d)

If rejected

Explain the reason.

• When rejecting a review, you must include specific justification. For example:
• If it conflicts with the specification, include the exact relevant part of the specification.
• If it is judged to be unreasonable, include a clear and specific explanation of why it is considered unreasonable.

Format: {reason}

Example: 명세에서 요구하는 동작과 충돌하므로 변경하지 않음. 충돌하는 명세: "argument로 전달되는 timezone과 lat, lon 정보는 연관이 없음"

Writing style

Follow these rules:

• concise and factual
• noun-ending sentence style
• do not include gratitude phrases such as:
• "지적 감사합니다"
• "좋은 의견 감사합니다"

Tools

This skill may use the following tools.

GitHub CLI

Use gh for PR interaction.

Typical operations:

• list review threads
• read review comments
• reply to threads
• resolve threads
• push commits

Example capabilities:

gh pr view
gh pr comment
gh pr review
gh pr diff

Termination Conditions

Stop execution in the following cases:

1. gemini-code-assist Code Review not yet generated
2. all review threads already resolved

In both cases:

• do not modify the PR
• do not post comments
• report status to the user only