diff options
| -rw-r--r-- | claude-rules/commits.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/claude-rules/commits.md b/claude-rules/commits.md index 9aedd4a..d059b9c 100644 --- a/claude-rules/commits.md +++ b/claude-rules/commits.md @@ -288,9 +288,9 @@ enough to skip review" exemption on top of it. - Inline code comment pinned to a specific line/hunk: no direct `gh` flag — use `gh api /repos/<owner>/<repo>/pulls/<N>/comments -F body=@/tmp/pr-<N>-comment.md -F commit_id=... -F path=... -F line=...`. 7. Verify the comment landed. `gh api /repos/<owner>/<repo>/pulls/<N>/reviews` for review-shaped comments, `gh api /repos/<owner>/<repo>/issues/<N>/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 PR #N.\n<pr-url>` - - Changes requested: `Changes Requested PR #N\n<pr-url>` - Replace `#N` with the PR number and `<pr-url>` 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. + - Approved: `<@author-slack-id> Approved PR #N.\n<pr-url>` + - Changes requested: `<@author-slack-id> Changes Requested PR #N\n<pr-url>` + Replace `#N` with the PR number and `<pr-url>` with the GHE URL of the PR. Always lead with an `<@author-slack-id>` mention so the engineer who owns the merge decision gets pinged — the message is useless without it. Resolve the Slack user ID via the slack-deepsat `users_search` tool using the PR author's name or email. 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. |