From b5a5b9fb5f8f0abdb87553882ce26cd2ad5792bc Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Fri, 1 May 2026 14:34:49 -0500 Subject: docs(commits): add post-review Slack notify + approve-vs-merge note Step 8 of the PR review/publish flow now sends a one-line message to channel C0AM2MWHCJU after every approve or changes-requested verdict. The new step skips humanizer and personal-style passes since the message is short and templated. The approve case sends "Approved on PR #N." with the PR URL on the next line. The changes-requested case sends "Changes Requested on PR #N" with the PR URL on the next line. I also added an explicit line saying approve doesn't authorize a merge. That keeps the merge decision with the PR author. The team's practice is approve-then-author-merges, not approve-and-merge. --- claude-rules/commits.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/claude-rules/commits.md b/claude-rules/commits.md index 21037f0..a932777 100644 --- a/claude-rules/commits.md +++ b/claude-rules/commits.md @@ -285,6 +285,13 @@ enough to skip review" exemption on top of it. - Issue-thread comment (general PR discussion, not a formal review): `gh pr comment --body-file /tmp/pr--comment.md`. - Inline code comment pinned to a specific line/hunk: no direct `gh` flag — use `gh api /repos///pulls//comments -F body=@/tmp/pr--comment.md -F commit_id=... -F path=... -F line=...`. 7. Verify the comment landed. `gh api /repos///pulls//reviews` for review-shaped comments, `gh api /repos///issues//comments` for issue-thread comments. +8. **Notify the PR author on Slack** (review-shaped comments only — `--approve` or `--request-changes`). After the review posts, send a one-line Slack message to channel `C0AM2MWHCJU` via the `slack-deepsat` MCP. No humanizer or personal-style passes — the message is short and templated. Two cases: + - Approved: `Approved on PR #N.\n` + - Changes requested: `Changes Requested on PR #N\n` + Replace `#N` with the PR number and `` with the GHE URL of the PR. The URL goes on its own line, immediately after the message. If the MCP doesn't have a post-message tool registered (for example, in a project where the Slack MCP is read-only), surface that to the user and skip the post — don't fall back to a different channel or asking the user to paste it. + Skip this step for plain `--comment` reviews (informal feedback, not a verdict) and for issue-thread or inline code comments. Approve and request-changes are the only verdicts that warrant the notification. + +**Approve does not authorize a merge.** The team's practice is approve-then-author-merges, not approve-and-merge. The Slack notification in Step 8 hands the merge decision to the PR author. Anything in `## Merge Strategy` below applies only to merges *you* are about to perform on your own branches — and even then, the merge needs its own explicit user confirmation per the rules there. **Exception:** trivial one-liners the user dictated verbatim in the conversation (e.g. "commit this as `chore: bump version`", "reply just -- cgit v1.2.3