بنقرة واحدة
report-hook-block
Open a GitHub Issue when a PreToolUse hook blocks an action during development
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Open a GitHub Issue when a PreToolUse hook blocks an action during development
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Add deny rules to protect settings and hook files from Claude Code modification. Run after a feature PR that adds/modifies settings or hooks has been merged.
Open a GitHub Issue when contradictory instructions in markdown files cause confusion during work
استنادا إلى تصنيف SOC المهني
| name | report-hook-block |
| description | Open a GitHub Issue when a PreToolUse hook blocks an action during development |
| allowed-tools | Bash, Read |
| argument-hint | <what you were trying to do (optional)> |
You are reporting a development blocker caused by a PreToolUse hook. Your goal is to open a GitHub Issue so the hook policy can be reviewed and updated.
The user's description of what they were trying to do: $ARGUMENTS
Gather the following from the current conversation context:
command-allowlist.sh, prevent-secret-commit.sh, block-no-verify.sh).If any of these are unclear from context, ask the user to clarify before proceeding.
Read the relevant hook script to understand why the block occurred:
.claude/hooks/command-allowlist.sh — check ALLOWED_PATTERNS and GOVERNED_PREFIXES.claude/hooks/prevent-secret-commit.sh — check the sensitive file patterns.claude/hooks/block-no-verify.sh — check what flags are blockedIdentify the specific rule or missing pattern that caused the rejection.
Based on your analysis, draft a concrete proposal. Examples:
command-allowlist.sh: a new regex pattern to add to ALLOWED_PATTERNSprevent-secret-commit.sh: an exclusion for a false-positive filename patternblock-no-verify.sh: a justification for why the blocked flag should be reconsideredThe proposal must be specific enough that someone can implement it directly.
Run gh issue create with:
hook-policy: <hook-name> blocks <short description of action>hook-policy label. If the label does not exist yet, create it first with gh label create hook-policy --description "Hook rule is too restrictive or needs updating" --color D93F0B.--body-file to preserve formatting:gh issue create --title "hook-policy: ..." --label hook-policy --body-file - <<'EOF'
## Blocked Action
**Hook:** `<hook-script-name>`
**Command attempted:** `<the command or action>`
**Error message:**
<full error message, indented 4 spaces>
## Why This Is a Problem
<1-2 sentences explaining why this block is too restrictive for the current use case>
## Proposed Fix
<concrete change — e.g., a new regex pattern, an exclusion rule, or a policy change>
## Context
<brief description of what work was being done when this block occurred>
EOF
Print the issue URL when done.
After the issue is created, suggest an alternative approach to the user so they can continue working without the blocked action. Do not leave them stuck.