[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-refactoroperations
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:
- It's unclear if
Stopin frontmatter fires at command completion vs session end - There's no way to conditionally skip global hooks based on active command
- 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
- Test automation: Run tests after implementation commands complete, but not after exploration/research commands
- Conditional validation: Apply strict security checks during
deploycommands, relaxed checks duringexplorecommands
- Context-aware feedback: Different Stop hook behavior for review workflows vs implementation workflows
- 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
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗