Feature Request: Add Content-Based Matchers for Hooks

Title: Feature Request: Add Content-Based Matchers for Hooks

Labels: enhancement, hooks, feature-request

Is your feature request related to a problem? Please describe.

Currently, the hook system in settings.json is incredibly powerful, but the matcher property for PreToolUse and PostToolUse events is limited to matching on the tool's name (e.g., "Bash", "Write", "Edit|Write").

This limitation means that if I want to create a hook that only acts on a specific type of Bash command (e.g., git commit but not ls), I have to create a generic hook for all Bash tool calls. This single hook script is then invoked for every shell command Claude runs, and the script itself must parse the JSON from stdin and contain all the conditional logic to decide whether to act.

This approach is inefficient, as it triggers many unnecessary script executions, and leads to monolithic, less maintainable hook scripts that are difficult to test and share.

Describe the solution you'd like

I propose extending the hook configuration to support a new contentMatcher object. This would allow for declarative, content-based matching on the JSON payload sent to the hook's stdin.

The contentMatcher keys could use a dot-notation path to target specific fields in the JSON input (like tool_input.command), and the values would be regex patterns to match against.

A hook would only be triggered if both the tool name matcher and all contentMatcher conditions are met.

Here is an example configuration that would only trigger a script when Claude attempts to run a destructive rm -rf command:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "contentMatcher": {
          "tool_input.command": ".*rm -rf.*" 
        },
        "hooks": [
          {
            "type": "command",
            "command": "/scripts/alert-on-destructive-command.sh"
          }
        ]
      }
    ]
  }
}

Additional Use Case: Enforcing Commit Message Standards

This would also be invaluable for enforcing project standards. For example, a hook could trigger a script to add a Jira ticket ID to a git commit message, but only for git commit commands, without affecting any other Bash tool usage.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "contentMatcher": {
          "tool_input.command": "^git commit.*"
        },
        "hooks": [
          {
            "type": "command",
            "command": "/scripts/add-jira-ticket-to-commit.py"
          }
        ]
      }
    ]
  }
}

What are the benefits of this feature?

1. Efficiency: It would prevent hooks from being invoked unnecessarily. A script that validates commit messages would no longer run every time Claude executes ls or cat.
2. Modularity: It enables developers to create small, targeted, single-purpose hook scripts instead of one large script with complex internal routing logic.
3. Declarative Configuration: The intent of the automation becomes much clearer in the settings.json file, moving the "should I run?" logic out of the script and into the configuration layer.
4. Improved Maintainability & Testability: Small, focused scripts are significantly easier to maintain, test, and share across projects.