subagent-driven-development: review-package renders commit subjects only, so the task reviewer reports commit-body disclosures as undisclosed changes

Found during a subagent-driven-development run (2026-09-13), comparing a task reviewer's findings against the implementer's commits. Version: superpowers 6.3.0; the quoted lines are from that copy and are unchanged on main at b36e082.

Related but, I believe, distinct — close as duplicate if you read them as the same thing:

• #2054 — reviewer prompts make the reviewer spend turns establishing mechanical facts the controller could settle in one command. That is about facts the reviewer can obtain at a cost; this is about a fact the prompt forbids it from obtaining at all.
• #2293 / PR #2297 — the ledger records no in-flight task, so an outage re-dispatches committed work. Same skill, different window (recovery, not review).
• PR #2136 — adds BASE..HEAD range validation to review-package. Same script, different block; the one-line change proposed here does not touch it.
• #2264 — seven additive rules; none concerns what the review package contains.

The gap

scripts/review-package renders the commit list with --oneline:

35   echo "## Commits"
36   git log --oneline "${base}..${head}"

task-reviewer-prompt.md then tells the reviewer that this file is the whole of what it may look at (lines 38-42):

Read the diff file once — it contains the commit list, a stat summary, and the full diff with surrounding context, and it is your view of the change. […] Do not re-run git commands.

re-review-prompt.md (line 38) carries the same "Do not re-run git commands."

So a commit body — written by the author, inside the range under review — is unreachable to the reviewer, and the reviewer is not told it is missing. The implementer's short reply to the controller has the same shape (implementer-prompt.md, Report Format: "Commits created (short SHA + subject)"), so no channel between author and reviewer carries a body.

Concrete shape of the failure

Sequential SDD, build-tooling task. The implementer had to make two small mechanical changes the brief did not ask for and — following the project's commit convention, a body whenever the why is not obvious — itemised both, with reasons, in the commit body. The report file did not repeat them; nothing in the Report Format asks for a deviations list, only "what you implemented", "self-review findings" and "issues or concerns".

The task reviewer read the package, found the two hunks in the diff, found no mention of them in the report or in the subject-only commit list, and reported them as undisclosed changes, downgrading the implementer's self-assessment for inaccuracy. The finding was false, and false in the most expensive way: it was a finding about the author's candour, built from evidence the process had withheld from the reviewer. It took the controller reading the commit body itself to establish that nothing had been hidden.

Why it matters more than one missing line

The defect scales with commit hygiene. An author who writes one-line commits and puts every explanation in the report file is unaffected. An author who follows the convention the skill ecosystem itself promotes — atomic commits, subject plus explanatory body — puts the most disclosure exactly where the reviewer cannot see it. The better the commits, the more "undisclosed" findings the process manufactures.

And the finding is not a wrong severity or a missed bug; it is an accusation. The reviewer is told to treat the report as "unverified claims" and to "verify the claims against the diff" (task-reviewer-prompt.md, lines 64-68) — correct instructions — while the package removes the author's own account of the change before that check runs.

Why the existing artifacts do not close it

• The report file. The Report Format does not ask for deviations from the brief, and nothing tells the implementer that an explanation belongs in the report rather than the commit body. Two legitimate channels, one of them invisible.
• git log in the reviewer's hands. Forbidden by the prompt, and rightly: the package exists so the reviewer reads one file instead of re-deriving the range. The fix belongs in the package, not in relaxing the prohibition.
• The final whole-branch review (requesting-code-review/code-reviewer.md) lets its reviewer use git show, git diff and git log, so bodies are reachable there. The task review is the only seat with the blind spot — and it is the one that runs after every task.

Proposal

Minimal fix — render bodies into the package. One line in scripts/review-package:

   echo "## Commits"
-  git log --oneline "${base}..${head}"
+  git log --format='%h %s%n%w(0,4,4)%b' "${base}..${head}"

The subject stays on the hash line, so a subject-only scan reads as before; the body follows indented four spaces; a commit without a body contributes one blank line. Checked against a real range: a three-line body renders as three indented lines under its subject. --format=%B also works but drops the short hash and the visual separation between commits. A body is a handful of lines, and the package already carries the full diff at -U10, so the size cost is noise.

Fallback — declare the omission in the prompt. If the package must stay subject-only, add one sentence to task-reviewer-prompt.md directly after "it is your view of the change" (and the equivalent in re-review-prompt.md):

The commit list shows subjects only; commit bodies are not included. Absence of a disclosure in the report or the commit list is not evidence of concealment — do not raise a candour or self-assessment finding on that basis.

The general rule behind both: before a prompt tells a reviewer that an artifact is its view of the change, enumerate what the artifact drops relative to what the author produced, and either restore it or name the omission. A reviewer's conclusions are bounded by its inputs; its confidence is not.

Scope note

One occurrence plus a read of the 6.3.0 script and prompts, not a survey. The --format string was run against a real repository to confirm the rendering; it has not been run through a full SDD loop.

Happy to send a PR — one line in the script, optionally one sentence in each reviewer prompt.