chore: scrub /pr-status references + fix hook regex false-positive#18
Merged
Merged
Conversation
Follow-up to PR #16 (which dropped /pr-status). Two surfaces still referenced the removed command: the git-guard.py PreToolUse hook (which warned globally on every `gh pr merge`, telling Claude to run /pr-status first — a command that no longer exists) and the README (workflow tables, command list, "The PR Readiness Check" section). git-guard.py: - Rewrite the `gh pr merge` warning text to point at the SHA-anchored verification protocol instead of /pr-status. New message lists the inline steps (gh pr checks --watch, parse Reviewed commit sha, compare to headRefOid) and refers to project CLAUDE.md / memory for the full protocol - Update module docstring to match README.md: - Drop /pr-status from the Slash Commands table (only context-recovery remains) - Update Feature Development Path and Bug Fix Path tables to reference native gh ops instead of /pr-status - Update mermaid flowchart's merge subgraph - Update Git Guards table for the new `gh pr merge` warning text - Rewrite "The PR Readiness Check" section into "PR Review Verification" with the SHA-anchored protocol (matching CLAUDE.md and plan-execution SKILL) - Update Usage Examples to describe the inline flow - Fix Installation Options to use the new repo name `claude-code-workflows` (was `claude-code-pr-workflow`; GitHub redirects but canonical URL is the rename) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The git-guard hook's warning trigger was matching the literal substring anywhere in the command, including inside HEREDOC bodies of unrelated commands (e.g., a git-commit whose message body happens to mention the merge command verbatim). False warnings on `git commit` are noisy and misleading. Mirror the anchor pattern already used by the on-main commit-block check: require start-of-command or a shell-operator boundary (&&, ;, |) before the match. Common invocations still warn; commit messages and other quoted strings don't trigger. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Claude finished @tombakerjr's task in 1m 44s —— View job Reviewed commit: 90aa847 CONSIDER: The regex anchor fix is correct and consistent with the existing |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up cleanup to #16. Two surfaces still referenced
/pr-status, plus a regex bug in the hook itself surfaced during the cleanup commit.Changes
1.
hooks/git-guard.py— warning textThe hook globally warned on PR-merge invocations, telling Claude to run
/pr-statusfirst — but that command no longer exists. Rewritten to describe the SHA-anchored verification protocol inline (CI watch, sticky-comment SHA match againstheadRefOid, blocker scan) and point at project CLAUDE.md / memory for full details.2.
hooks/git-guard.py— anchor the warning regexDiscovered the hard way: the prior regex matched the literal command substring anywhere in the command, including inside HEREDOC bodies. A
git commit -m "$(cat <<EOF ... gh pr merge ... EOF)"would falsely trigger the merge warning. Mirror the anchor pattern already used by the on-main commit-block check ((?:^|&&|;|\|)before the match) so only real invocations trigger.3.
README.md— broad cleanup/pr-statusfrom the Slash Commands table (only/context-recoveryremains).ghops instead of/pr-status.plan-executionSKILL).claude-code-workflows(wasclaude-code-pr-workflow; GitHub redirects, but the canonical URL is the rename).Why this isn't in #16
The hook fired during this session as I was merging #16, surfacing the stale warning. The README staleness was noted as out of scope at the time. The regex false-positive only became visible when this commit's message body (which references the merge command verbatim) triggered the hook on an unrelated
git commit— caught and fixed in the same PR.Test plan
gh pr merge ...invocation surfaces the new warning textgit commit -m "...mentions gh pr merge..."does NOT trigger the warningclaude plugin update: warning behavior takes effect locally🤖 Generated with Claude Code