Add active_skill/command context to Stop hook stdin

Resolved 💬 3 comments Opened Apr 11, 2026 by Handtomouse Closed Apr 14, 2026

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:

  1. An explicit <!-- grimoire:skip --> HTML comment injected via skill template instructions (soft contract, Claude may skip it)
  2. 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.

View original on GitHub ↗

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