Review PR #$ARGUMENTS. Use @~/.claude/skills/go-expert/SKILL.md for Go-specific review guidance.

Context Loading

Read ONLY these documents:

•The PR diff and description
•The linked issue (from the PR body)
•spec/<module>_reqs.md - to verify spec traceability
•spec/<module>_impl.md - to verify patterns are followed

DO NOT READ spec/*_arch.md, spec/*_plan.md — not needed for code review.

Review Process

•Read the PR description and linked issue
•Read the full diff
•Check spec traceability: does the code implement what the issue requires?
•Check test quality: do tests verify requirements, not just coverage?
•Check code quality: correctness, error handling, existing patterns followed
•Post review with inline comments

Posting Comments

When submitting GitHub PR reviews on the user's own PRs, always use event COMMENT (not APPROVE or REQUEST_CHANGES), as GitHub disallows approving or requesting changes on your own PRs.

Write a JSON file and pass it via --input. Do NOT use -f flags for reviews with inline comments — the nested comments array cannot be constructed with -f. Do NOT use the pulls/{number}/comments endpoint for individual comments — always use the reviews endpoint below.

The line field must be a line number present in the PR diff, not an absolute file line number.

bash

cat > /tmp/review.json << 'EOF'
{
  "event": "COMMENT",
  "body": "Brief summary of review findings.",
  "comments": [
    {
      "path": "internal/config/validate.go",
      "line": 42,
      "body": "Short, explicit comment with code example if needed."
    }
  ]
}
EOF
gh api repos/{owner}/{repo}/pulls/{number}/reviews --method POST --input /tmp/review.json

•Each comment should be short, explicit, and aligned with the code
•Include a code example if the fix isn't obvious
•The summary comment should be brief and not duplicate inline comments

What to Check

•Spec traceability: code maps to requirements, no unrelated changes, test names reference requirement IDs
•Correctness: error paths handled, edge cases, no resource leaks, context cancellation respected
•Patterns: follows existing conventions, no global state, errors wrapped with fmt.Errorf("...: %w", err)
•Tests: verify requirements not implementation details, failure cases tested, no flaky patterns