public-posts.md 3.0 KB

Public Posts — preview before sending

Companion to release-review. That rule covers the release page; this one covers the rest of the same family: anything that posts text to a third-party surface other humans will read.

The rule

Quote the draft body in chat and wait for explicit approval before invoking any command that posts to a public surface. The user's authorisation to do the post ("comment on #4", "open a PR", "draft the release") is not authorisation to send the specific words you came up with — those they still need to see and approve.

Applies to (non-exhaustive):

  • gh issue comment, gh issue create, gh issue edit
  • gh pr comment, gh pr create, gh pr edit (title and body)
  • gh release create, gh release edit (covered also by release-review)
  • Slack / Discord / email sends
  • Any MCP tool that publishes a comment / message / canvas to an external service (Asana, Notion, Apollo, Linear, Tessitura, etc.)

Does not apply to:

  • Local git operations (git commit, git tag) — commit messages are reviewable in the diff before push, and the user authorises the push separately.
  • git push itself — that's covered by the push-gate skill and per-task authorisation.
  • Reading public surfaces (gh issue view, gh pr checks, etc.).

Why

A comment, PR description, or release note is a one-way visibility commitment. Once sent it shows up in someone else's notifications, gets indexed by search engines, and stays in the project's history. Editing it later leaves a visible "edited" marker; deleting it leaves a gap.

The cost of pausing to surface the draft is one extra message. The cost of sending the wrong tone, a misattribution, a stale claim, or a typo to a third party is real and not fully reversible.

The user (2026-05-29) corrected this on a gh issue comment to issue #4 that they had authorised in concept but had not seen the text of.

How to apply

  1. Compose the post in chat as a quoted block (the exact body that would be sent, verbatim — not paraphrased).
  2. Name the command that would send it (gh issue comment 4 ..., gh pr create ..., etc.).
  3. Wait for explicit approval ("yes", "send it", "looks good", an edit request, etc.). Silence is not approval.
  4. If the user edits, apply the edit and re-surface — don't ship a guess.
  5. Only then run the send command.

When to bend the rule

If the user has already pasted the exact body they want sent, or said something like "post this verbatim" / "ship it as-is" / "send my words", the approval is in-band — proceed.

If the post is a trivial mechanical action with no author voice (e.g. gh pr edit --add-label ready, gh issue close), no preview needed. The rule is about text Claude wrote hitting a public surface.

Cross-reference

  • ~/.claude/rules/release-review.md — the release-creation specific half of this pattern
  • ~/.claude/skills/push-gate/SKILL.md — pre-push gate (different concern: secrets / forbidden files, not message review)