[FEATURE] Allow hook matchers to filter by active skill/command context

Resolved 💬 2 comments Opened Jan 24, 2026 by kylesnowschwartz Closed Feb 27, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Hook matchers currently only support tool names (Write, Edit, Bash, mcp__*, etc.) and wildcards (*). There's no way to match based on which skill or command is currently active.

This makes it impossible to create workflows like:

  • Run tests automatically when sc-work (an implementation command) completes
  • Skip certain validations during sc-explore (a research command)
  • Apply stricter checks only during sc-refactor operations

Current limitation:

{
  "Stop": [
    {
      "matcher": "sc-work",  // ❌ Not supported - matcher only matches tool names
      "hooks": [
        { "type": "command", "command": "run-tests.sh" }
      ]
    }
  ]
}

Workaround: Frontmatter hooks on individual skills/commands work for adding hooks, but:

  1. It's unclear if Stop in frontmatter fires at command completion vs session end
  2. There's no way to conditionally skip global hooks based on active command
  3. Configuration is scattered across many files instead of centralized

Proposed Solution

Extend the matcher syntax to support skill/command context filtering:

Option A: Prefix syntax

{
  "Stop": [
    {
      "matcher": "skill:sc-work",  // Match when sc-work skill is active
      "hooks": [...]
    },
    {
      "matcher": "skill:sc-*",  // Match any skill starting with sc-
      "hooks": [...]
    }
  ]
}

Option B: Separate field

{
  "Stop": [
    {
      "matcher": "*",
      "whenSkill": "sc-work|sc-refactor",  // Only run when these skills active
      "hooks": [...]
    }
  ]
}

Option C: Context object

{
  "Stop": [
    {
      "matcher": {
        "tool": "*",
        "skill": "sc-work"
      },
      "hooks": [...]
    }
  ]
}

Use Cases

  1. Test automation: Run tests after implementation commands complete, but not after exploration/research commands
  1. Conditional validation: Apply strict security checks during deploy commands, relaxed checks during explore commands
  1. Context-aware feedback: Different Stop hook behavior for review workflows vs implementation workflows
  1. Workflow orchestration: Chain specific hooks based on which high-level command initiated the work

Priority

Medium - Would enable more sophisticated plugin workflows

Feature Category

Hooks and automation

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗