review

The user wants pi to review: $ARGUMENTS

This is the one part of pi-delegate that is not delegation. Everywhere else pi writes characters you would otherwise type. Here pi writes nothing — it reads, and gives an opinion, and your job is to judge that opinion, not to relay it.

That distinction decides the whole shape of this skill. A reviewer whose findings get pasted through unexamined is worse than no reviewer: it launders a guess into something that looks adjudicated. What makes a second model worth running is that it notices different things than you do — and that only pays off after you have checked which of those things are real.

1. Work out the scope

With no $ARGUMENTS, review uncommitted work:

git diff HEAD --stat && git diff HEAD

If $ARGUMENTS names a ref, compare against it (git diff <ref>...HEAD). If it names files or directories, restrict to those. If the diff comes back empty, say so and stop — do not invent a scope.

Note the size. A diff over ~1500 lines is worth splitting into two reviews: pi's attention degrades across a long diff the same way anyone's does, and two focused passes beat one distracted one.

2. Write the task book

Put it in a temp file, and have pi write its findings to a temp path too — an absolute one. pi resolves absolute paths straight through (resolveToCwd applies no sandbox), so the findings land outside the repo and nothing needs gitignoring or cleaning up:

DIR=$(mktemp -d)
cat > "$DIR/TASK.md" <<EOF
Review the change below. You are a second reviewer: the author has already read it, so
say what they would not have noticed themselves.

Write your findings to $DIR/FINDINGS.md and nothing else. Do not modify any source file.

Use exactly this format, one block per finding, most serious first:

### <relative/path.ts>:<line>
主張: <one sentence — what is wrong>
理由: <why it breaks, concretely: what input, what happens>
信心: 高 / 中 / 低

Rules:
- A finding needs a concrete failure. "Could be clearer" is not a finding.
- 信心: 低 is fine and useful — say it rather than dropping the finding or overselling it.
- If you find nothing worth reporting, write "(no findings)" and stop. An empty review is
  a real result; padding it is not.

--- THE CHANGE ---
$(git diff HEAD)
EOF
echo "$DIR"