git:20260925.09696c0 to git:20260925.6f9390f

---

name: code-review-judge

description: Decide with the user which review findings to fix

---

# Code Review Judge

Discuss each code-review finding with the user in this session. The general framework:

1. Identify the review scope: working tree, commit, branch, pull request, or path.

2. If scope is unknown or missing, ask the user.

3. Log the scope and current HEAD SHA at the top of the decision log.

**Start a decision log** in a scratch file outside the repository. It should contain the full

original context of every finding, including its source — the finder, agent, or reviewer that

reported it — when the review names one. A long walk can outlive the context window; the log is

what survives. Write each decision as soon as it is made.

For each finding:

- Describe the conditions under which it happens, and rate their **likelihood**.

- Describe its impact, and rate the **impact**.

- Describe what the fix would look like.

- Rate the **fix cost**.

- Rate the **architecture friction** of the fix.

- Summarize.

- Recommend one option, with a one-line reason.

- Ask the user to decide. Offer these options:

- **Fix** — when there are several ways, list them.

- **Defer** — an issue for later. Record only where it goes: a kotgent task, Jira, or GitHub. The

plan creates it; for kotgent, through `kotgent:create-tasks`.

- **Do nothing** — record why: false positive, won't fix, or accepted risk.

- **Dig deeper** — discuss the finding with the user, then ask again.

- Do not move on without an answer.

Each rating is 1–5, and 5 means more of what the name says:

| Rating | 1 | 3| 5|

|---|---|---|---|

| Likelihood | needs an unusual mix of input, state, or timing | needs a specific but ordinary condition: a setting, a retry, a concurrent call | happens easily and often in normal use |

| Impact | cosmetic, or recovers by itself | a feature is wrong or down until someone fixes it by hand | loss of data or reputation that cannot be undone |

| Fix cost | a local one-line change | several files or new test setup within one module | a redesign across modules, or a migration |

| Architecture friction | uses existing patterns as they are | needs a new helper or a small exception to a pattern | breaks the architecture, or needs it changed first |

High likelihood and impact argue for fixing; high fix cost and friction argue against.

Based on the answers for all findings, propose a plan that carries them out:

- Sequential or parallel.

- Separate commits or a single commit, and whether to amend when the review covered a single commit.

- Which deferred issues to create, and where.

Safety Policy:

- Never rewrite remote history without explicit user approval.

- If a plan requires amending pushed commits or 'git push --force-with-lease', obtain specific approval first.

- On the default branch, only use new commits.

- If approval is withheld, use new commits and do not push.

Store the plan in the scratchpad. It must contain the full context of the findings and the decisions

the user made. Print the absolute path to the plan, and suggest clearing the context and running it.