Update claude_review.sh to collapse findings and cover whole diff (#279)

* Update claude_review.sh to collapse findings and cover whole diff

* Fix whitespace-only line and typo in review prompt

Line 94 was a whitespace-only separator, which the trailing-whitespace
pre-commit hook rejects. Also fixes "cenario" -> "scenario".

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Require &lt; escaping in review finding summary lines

The <summary> line is raw HTML, so GitHub's sanitizer deletes anything
that parses as an unknown tag. A finding about <plugin>:<agent> rendered
as ":" with no sign that text was dropped, and a quoted <!-- hid the rest
of the line. Backticks do not help: inline markdown is not processed in
<summary>.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Correct the summary escaping rule and extend it to the body

Three defects in the rule added by a0dd0f2:

- The body claim was wrong. A bare <plugin> is dropped from a finding
  body exactly as from a summary; only backticks make it safe.
- "every literal <" read as covering the template's own <b>/<code> tags,
  which render as visible tag text if escaped. Scoped to the finding's
  own words.
- & was uncovered, so a summary quoting an entity rendered it decoded.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

.github/scripts/claude_review.sh

@@ -78,6 +78,14 @@ snippet that could not compile, a pytest suite with a fabricated pass count, and
 shell script nobody executed. Each conclusion was right and each proof was invented,
 which is worse than showing no proof, because a reader cannot tell the two apart.
 
+Cover the whole diff on every run, including files no recent commit touched:
+this job re-reviews from scratch each push, so a file you did not open this
+time is a file nobody has reviewed since the push where you last opened it.
+State your coverage above the findings — how many files the diff touches, and
+which of them you did not open. If the diff is too large to open in full, open
+what you can and name the rest there rather than letting a partial review read
+as a complete one.
+
 Go beyond the diff where the diff depends on it: read the files it touches, read the
 scripts it adds, and check its claims against the repository rather than taking them
 at face value. When the PR states a number, a limit, or a cost, verify it against the
@@ -92,15 +100,40 @@ nothing; a P4 that turns out not to matter costs one line.
 Rank on consequence, not on diff size. A one-character fault in a checker that makes
 it silently miss what it exists to catch is not a nit, however small the patch.
 
-For each finding give: file:line, one sentence on the defect, and a concrete failure
-scenario — the input or state that produces the wrong behaviour. If you cannot state
-a failure scenario, say so and rank it lower.
-
 Prioritise, in order: anything that makes the plugin fail to run at all; anything
 that produces a wrong result while reporting success; anything that puts untrusted
 content into an artifact shared outside the company; and anything whose documented
 usage does not work as written.
 
+Write each finding as its own collapsible block, so the comment reads as a
+scannable list of one-liners and a reader expands only what they care about:
+
+  <details>
+  <summary><b>P1</b> · <code>path/to/file.sh:42</code> — one sentence on the defect</summary>
+
+  Failure: the input or state that produces the wrong behaviour.
+
+  </details>
+
+The summary line carries the severity, the location and the defect; everything
+else goes inside. Order the blocks P1 first. The blank line after `</summary>`
+is required or the markdown inside will not render. If you cannot state a failure
+scenario, say so in the body and rank the finding lower.
+
+In a summary line, escape the angle brackets in your own words: write
+`&lt;plugin&gt;:&lt;agent&gt;`, never `<plugin>:<agent>`. That line is raw HTML,
+not markdown, and GitHub deletes anything it reads as an unknown tag, so the
+unescaped form renders as `:` with nothing to show the reader that two words were
+dropped, and a quoted `<!--` hides the rest of the line outright. Escape a literal
+`&` as `&amp;` for the same reason. This applies to the words of your finding only
+— the `<summary>`, `<b>` and `<code>` tags around them are markup and must stay
+unescaped. Backticks do not help here, because inline markdown is not processed
+inside `<summary>`.
+
+The body below the blank line is markdown, so backticks work there — and you need
+them: a bare `<plugin>` is dropped from a body exactly as it is from a summary.
+Wrap angle brackets in backticks, or escape them as above.
+
 This repository is a marketplace of Claude Code plugins. Most content is markdown
 that instructs a model, so "does this text cause correct behaviour" matters as much
 as code correctness. Weight these classes especially, because each has reached main
@@ -129,10 +162,9 @@ in repositories like this one and none is visible on a casual read:
    result in the artifact a human actually reads, especially when the warning goes
    only to stderr.
 
-Say plainly when a dimension is clean rather than manufacturing a finding to look
-thorough. If the diff is small or purely editorial, a short review is correct output.
-Finish with an explicit list of what you checked and found clean, so a reader can
-tell the difference between a dimension you cleared and one you never looked at.
+Say plainly and concisely when a dimension is clean rather than manufacturing a finding to
+look thorough. If the diff is small or purely editorial, a short review is the
+correct output.
 PROMPT
 )