Add active_skill/command context to Stop hook stdin
Feature Request
Add an active_skill or command_context field to the Stop hook stdin JSON payload.
Current behavior
Stop hooks receive: last_assistant_message, transcript_path, session_id, cwd, hook_event_name.
There is no way for a stop hook to know whether the response was generated while executing a skill/command (e.g. /radar, /status) or as a free-form conversational response.
Use case
I have a stop hook (grimoire_guard.py) that enforces structured options (ABCD+E) on conversational responses. Report-producing skills like /radar and /status should be exempt because their output is structured data, not conversation.
Currently I work around this with:
- An explicit
<!-- grimoire:skip -->HTML comment injected via skill template instructions (soft contract, Claude may skip it) - A regex-based heuristic that detects structured report patterns (fragile, requires ongoing maintenance)
If the stop hook knew a skill was active, both workarounds become unnecessary.
Proposed solution
Add to Stop hook stdin JSON:
{
"active_skill": "radar", // or null if no skill active
"skill_source": "commands/radar.md" // optional: file path
}
Alternatives considered
- Parsing the transcript for skill loading markers ("Launching skill:") — unreliable, depends on Claude mentioning it
- Injecting markers in skill templates — soft contract, not enforceable
- Regex heuristics on response content — fragile, high maintenance
Impact
This would enable stop hooks to make reliable decisions based on response context rather than content pattern matching. Any hook that needs different behavior for skill vs. conversational responses would benefit.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗