[P1] PR body template at draft-to-ready transition produces thin, low-quality descriptions

[ChaseWNorton]

Problem

When a Claude Code worker marks a PR ready for review (the draft-to-ready transition), the system tells it to write a PR body — but the template it follows is a bare skeleton that produces thin, uninformative descriptions. This was confirmed empirically: all 12 chain PRs (#45-#59) were opened with bodies that had to be manually rewritten to match the quality of the earlier PRs (#5-#8).

The thin template appears in three places that all need to be updated:

fix-issue.md lines 106-122 — the template is:

## Summary
<what was wrong and why>

## Changes
<what you changed>

## Test plan
- [x] `cargo build --release` passes
- [x] `cargo test --lib` passes
- [x] New tests added

fix-next.md line 86 — just says:

Then update the PR body with Summary, Changes, and Test plan sections.

COORDINATION.md lines 205-219 — same thin template as fix-issue.md.

Compare with what the early PRs (#5-#8) actually had:

• Problem — What's broken, why it matters, C11 spec reference, what other compilers do
• Approach — Technical decisions made, alternatives considered and rejected, design rationale
• Changes — Files modified with specific descriptions of what changed
• Test plan — Specific checkboxes for each behavior verified

The gap between "Summary / Changes / Test plan" and "Problem / Approach / Changes / Test plan" is the difference between a body a reviewer skims and a body a reviewer learns from.

Expected behavior

When fix-next or fix-issue reaches the draft-to-ready step, the worker should produce a PR body that matches the quality standard set by PRs #5-#8. The body should:

1. Explain the problem — not just "what" but "why it matters" and "what happens without the fix"
2. Explain the approach — what technical decisions were made, why this approach over alternatives
3. List concrete changes — files modified with descriptions
4. Provide a specific test plan — one checkbox per behavior verified, not generic "tests pass"

Reproduction

Run /fix-next and observe the PR bodies it produces. They'll look like:

## Summary
- Added check for X in sema
- Added 4 tests

## Changes
- `src/frontend/sema/analysis.rs`: Added check

## Test plan
- [x] `cargo build --release` passes
- [x] `cargo test --lib` passes
- [x] New tests added

Instead of:

## Problem
CCC silently accepts X. C11 §Y says "...". GCC emits `error: ...`.
This is dangerous because <impact>.

## Approach
The check lives in sema because <rationale>. I considered <alternative>
but chose this because <reasoning>.

## Changes
- `src/frontend/sema/analysis.rs`: Add `field_name` to `SemanticAnalyzer`.
  Push/pop in `Stmt::Switch`, check in `Stmt::Case`.

## Test plan
- [x] Duplicate case values → error with note pointing to first
- [x] Distinct case values → no diagnostic
- [x] Nested switches with same value → no error (independent scopes)
- [x] `cargo build --release` — clean build
- [x] `cargo test --lib` — N tests pass

Suggested approach

1. Create a shared PR body reference file

Create .claude/skills/fix-next/PR_BODY_GUIDE.md with the quality standard, template, and examples. This is the single source of truth — all three commands point to it.

The guide should include:

• The 4-section structure (Problem, Approach, Changes, Test plan)
• What makes each section good vs bad (with examples)
• Category-specific guidance (sema fix vs CLI fix vs infra change)
• An explicit instruction: "Read the diff you just wrote. Read the issue body. Write the PR body as if explaining your work to a reviewer who hasn't seen the issue."

2. Update the draft-to-ready step in all three commands

fix-issue.md (Phase 3, step 10): Replace the thin template with instructions that reference the guide and enforce the quality bar.

fix-next.md (step 9): Same — replace the one-liner with a reference to the guide and explicit structure.

COORDINATION.md (Step 8): Same — replace the thin template.

3. Update the review checklist

review-fix/CHECKLIST.md "Universal Checks" section: Add a check for PR body quality — "PR body has Problem, Approach, Changes, and Test plan sections with substantive content (not just bullet points)."

review-fix/SKILL.md "PR hygiene" section: Update to match the new structure.

Files to modify

• .claude/skills/fix-next/PR_BODY_GUIDE.md — NEW: shared reference file with template, quality bar, examples
• .claude/commands/fix-issue.md — Replace thin template at step 10 with reference to guide + enforced structure
• .claude/commands/fix-next.md — Replace one-liner at step 9 with reference to guide + enforced structure
• .claude/skills/fix-next/COORDINATION.md — Replace thin template at Step 8 with reference to guide + enforced structure
• .claude/skills/fix-next/SKILL.md — Add reference to PR_BODY_GUIDE.md in the "Complete and push" section
• .claude/skills/review-fix/CHECKLIST.md — Add PR body quality check to "Universal Checks"
• .claude/skills/review-fix/SKILL.md — Update "PR hygiene" checklist to expect 4-section structure

Acceptance criteria

• A new PR_BODY_GUIDE.md exists with the 4-section template, quality bar, and at least one good/bad example
• fix-issue.md draft-to-ready step references the guide and uses the 4-section structure
• fix-next.md draft-to-ready step references the guide and uses the 4-section structure
• COORDINATION.md draft-to-ready step references the guide and uses the 4-section structure
• review-fix/CHECKLIST.md includes a PR body quality check
• Running /fix-next on a test issue produces a PR body matching the quality of PRs Fix #1: Add GCC 15/16 include paths for modern distros #5-Reject conflicting storage-class specifiers (C11 6.7.1) #8