gradle-code-review

# Code Review Apply the repository's review judgement — the source of truth for *what* to look for and *what* to ignore is **`contributing/CodeReview.md`**. All git access goes through the companion script **`gradle-code-review.sh`**, so only that one script needs execute permission — never call `git` directly. It is read-only and exposes: - `.claude/skills/gradle-code-review/gradle-code-review.sh scope [TARGET_REF]` — summary of what is in scope - `.claude/skills/gradle-code-review/gradle-code-review.sh diff [TARGET_REF]` — full review diff (committed + working tree) - `.claude/skills/gradle-code-review/gradle-code-review.sh log PATH [TARGET_REF]` — commit history with patches for a path - `.claude/skills/gradle-code-review/gradle-code-review.sh blame PATH` — `git blame` for a path **Always invoke it by exactly that repo-relative path** — Bash runs from the repo root, so it resolves — and do **not** rewrite it to an absolute path. The project permission rule allows the relative form; an absolute path would not match it and would trigger a prompt. `TARGET_REF` is auto-detected when omitted — the base branch of an open PR for the current branch (via `gh`), else the canonical remote's default branch. Pass it explicitly only to override (e.g. `origin/release`); `scope` prints which target it used and how it was chosen. The actual analysis is delegated to a **sub-agent with a fresh context window** so that reading the diff and the touched files does not fill up this session's context. This session only resolves scope, launches the sub-agent, and relays its findings. ## Step 1 — Resolve scope (this session) Run `.claude/skills/gradle-code-review/gradle-code-review.sh scope <target>` to see the target branch, fork point, the commits since it, the files changed, and whether the working tree is dirty. The principle: **everything that will reach the target branch needs review** — the commits since the fork point plus any uncommitted/untracked changes. Some commits may already have been pushed and reviewed, so the intended range can be narrower. **If scope is ambiguous — or it's unclear whether to include uncommitted work — ask the user which range to review before continuing.** (This must happen here: the sub-agent cannot ask questions.) End this step knowing the target ref and whether uncommitted work is in scope. ## Step 2 — Delegate the analysis to a fresh-context sub-agent Launch one sub-agent (Agent tool) to perform the review in its own context. Give it a self-contained prompt containing: - The scope from step 1: the target ref, and whether uncommitted/untracked changes are in scope. - Instructions to gather the change via the companion script — run `.claude/skills/gradle-code-review/gradle-code-review.sh diff <target>` for the full diff, and `gradle-code-review.sh log <path> <target>` / `gradle-code-review.sh blame <path>` for historical context on subtle code. It must not call `git` directly. - An instruction to **read `contributing/CodeReview.md` first** and apply its focus areas and exclusions, plus any relevant `CLAUDE.md` files and `contributing/` guides. - The read-only constraint: only the companion script, Read, Glob, and Grep — do not build, type-check, or modify code (CI handles build signal separately). - The output contract below — the sub-agent must return **only** the findings, not its intermediate reading or reasoning and not a summary of the change, so this session's context stays small. Do not read the diff or the touched files in this session yourself — that is the sub-agent's job, and doing it here defeats the purpose. The Agent tool call returns the sub-agent's findings directly as its result; use that return value — there is nothing to wait or poll for. ## Step 3 — Relay the findings (this session) Present the sub-agent's findings to the user verbatim (lightly formatted). Each finding: - **`path:Lstart-Lend`** from the repo root (e.g. `platforms/jvm/scala/.../ScalaForkOptions.java:L40-L52`), - a clear description — quoting the offending code or including relevant data flow paths, preconditions, unexpected sideeffects, - a severity: `critical` / `major` / `minor` / `suggestion`. Output findings only — no preamble, no summary of the change, no overall verdict or wrap-up. If the sub-agent found no correctness issues, report a single line that there is nothing to report and stop — do not invent findings or pad the output.