ci(social-review): edit comments in place + freshness footer

[adamgordonbell]

Summary

• The social-review workflow currently posts a new `## Social Media Review` comment on every push, drowning active PRs in noise. (Recent example: PR Compostable blog #18804 has 4+ stacked review comments at the time of this PR.)
• This PR switches to the edit-in-place pattern that pulumi-bot's preview-link uses: one comment per PR, replaced in-body each run.
• Skip-case behavior (no review needed) was already moved to log + Step Summary in a prior commit on the blog branch — included here as well so this branch can be tested standalone.

Changes

• `.github/workflows/claude-social-review.yml`:

  • Claude writes review to `.social-review.md` (allowed-tools: `Write` + `Bash(date:)`; removed `Bash(gh pr comment:)`).
  • Body starts with `` marker.
  • Footer line records commit SHA + UTC time.
  • New step `peter-evans/find-comment@v3` looks up existing comment by marker.
  • New step `peter-evans/create-or-update-comment@v4` replaces body in place (or creates fresh on first run).
  • `Fail if copy exceeds character limits` step preserved — objective failures still kill the build.

• `content/blog/test-social-review-edit-in-place/` (will delete before merge):

  • Throwaway draft post that triggers the workflow's `paths:` filter.
  • Twitter copy deliberately over 280 chars → exercises the char-limit fail path.
  • LinkedIn copy deliberately AI-toned → exercises Claude's PASS/FAIL judgment.
  • Bluesky copy clean → should PASS.

Test plan

• First push: workflow runs, single `## Social Media Review` comment appears with marker + footer; build fails on Twitter char limit.
• Second push (tweak LinkedIn copy): same comment is edited in place; footer SHA/time updates; no second comment created.
• Third push touching only post body (not social block): skip-case fires; `::notice::` line in run log; no PR comment.
• Before merge: remove `content/blog/test-social-review-edit-in-place/` in a final commit so the merged delta is workflow-only.

Notes

• The cherry-picked `055bdec8c2` (skip-case → log) also lives on `agb/compostable-blog` (PR Compostable blog #18804). Whichever PR merges second will see that commit drop as a no-op during rebase.
• Stale `## Social Media Review` comments on existing PRs (Compostable blog #18804) won't be auto-cleaned. The first push after merge edits the most-recent existing comment if it happens to contain the marker (it won't, until this PR lands), otherwise creates a fresh one. Old comments persist until manually deleted.

[claude]

Social Media Review

content/blog/test-social-review-edit-in-place/index.md

X — FAIL

• Over character limit: 335 body chars vs. 255 limit
• Single paragraph — X requires at least 2 paragraphs separated by a blank line
• Body is AI filler unrelated to the article; original is unsalvageable (multiple compounding hard-rule breaks)

LinkedIn — PASS

Bluesky — PASS

---

Suggested copy

X (205/255 chars) — drafted from scratch; original had compounding hard-rule breaks and AI-filler content unrelated to the article:

The social-review CI workflow now edits its PR comment in place rather than posting a new one on every push.

One comment per PR, updated each push — same pattern pulumi-bot already uses for preview links.

---

Suggestions (advisory)

These are stylistic notes — they don't block the post.

LinkedIn

• "Pushed a workflow change" opens on process, not benefit — consider leading with what changes for the reader
• "Validating the path with a throwaway test post on a side PR" closes the hook before the reader clicks; the article has nothing left to reveal

Bluesky

• "Quick test post for the new social-review CI workflow" describes the post's meta-context rather than what the workflow change does
• Missing a pointer line to invite the reader further

---

To apply these suggestions, comment: @claude please update the social posts in the frontmatter with the suggested copy from the social media review above

To re-run the social media review after updates, comment: /social-review

Updated for commit d80c7fbfdc3fe6d4eaad33e78383fffa7f8d87da (short: d80c7fb) at 2026-05-05 20:22 UTC.

[pulumi-bot]

Your site preview for commit 05bbc53 is ready! 🎉

http://www-testing-pulumi-docs-origin-pr-18807-05bbc53a.s3-website.us-west-2.amazonaws.com

[adamgordonbell]

@claude please review

[pulumi-bot]

Claude finished @adamgordonbell's task in 1m 35s —— View job

---

PR Review

• Gather context
• Read workflow file
• Analysis complete

---

The implementation is clean and correct. The test run confirms it works end-to-end. A few notes below.

The short-SHA expansion in the footer prompt (line 275)

The footer instruction embeds this shell substitution:

$(echo "${{ github.event.pull_request.head.sha || ... }}" | cut -c1-7)

Claude has Bash(date:*) but not Bash(echo:*) or Bash(cut:*) — so this can't actually be executed. It works because Claude infers the first 7 chars from the full SHA baked into the prompt. That's correct behaviour in practice (confirmed by the test comment), but it's an implicit contract with the model's reasoning rather than an explicit workflow guarantee.

A more robust alternative — pre-compute the short SHA in a step before Claude runs, then reference it directly in the prompt string:

- name: Compute short SHA
  id: sha
  run: echo "short=${{ github.event.pull_request.head.sha }}" | cut -c-7 >> "$GITHUB_OUTPUT"

Then in the prompt: (short: \${{ steps.sha.outputs.short }}`)`. Not a blocker, but worth noting if this prompt ever needs to run against a weaker model.

Action version pinning (lines 283, 291)

peter-evans/find-comment@v3 and peter-evans/create-or-update-comment@v4 are pinned to major version tags, not commit SHAs. GitHub's security hardening guide recommends SHA-pinning third-party actions in workflows that touch pull-requests: write (the permission is present at line 48). Reasonable to address in a follow-up if you're tightening supply-chain posture.

Gate-to-comment SHA ordering is sound

The preference order (comment footer SHA → last successful run SHA) is correct. The comment SHA is set atomically with the comment write, so it's always in sync with what the reviewer sees. The || true guard on the grep pipeline (line 119) properly prevents set -e from killing the script when there's no footer yet.

Minor: PRIOR_RUN_ID unset in comment-baseline skip path

When BASELINE_SOURCE == "comment" and the code skips (line 173), PRIOR_RUN_ID is the empty string. The NOTICE_TAIL / VERDICT_LINK branches already handle this correctly (no run link is emitted). Just noting it's intentional and correct.

Overall

Implementation is solid. The two-baseline design is well-thought-out, the skip case is genuinely quieter now, and the test run confirms it works. The short-SHA issue is the only thing that's even slightly fragile, and it's not blocking.