SKILL: Prevent Continuation Stop Hook Messaging
Domain: tool-orchestration
Trigger: Use when stop hooks prevent continuation so you can surface a consistent attachment plus a summary notification that downstream UI/logging consumes.
Source Pattern: Distilled from reviewed tool-loop and result-shaping patterns.
Core Method
Capture every hook progress update while the stop-hook generator runs, track how many hooks fired, preserve per-hook command and prompt details, then attach later timing/error data to the matching hook entries. When a hook asks to prevent continuation, emit a machine-readable hook_stopped_continuation attachment with the hook name, tool use ID, and stop reason, then synthesize the concise StopHookSummary message that surfaces counts, errors, and whether the turn was blocked. This keeps UI banners, transcript log notifications, and verbose hooks in sync, with a single reusable pattern that works whenever any hook stops the turn.
Key Rules
- Gather
hookInfos from progress attachments (command, prompt, duration) and hookErrors from non-blocking or blocking attachments so you can summarize each hook’s outcome.
- Emit the
hook_stopped_continuation attachment exactly when preventContinuation becomes true, supplying toolUseID, hook name, and the stop reason so log processors and tool-tracking pipelines get a structured signal.
- After the generator completes, call
createStopHookSummaryMessage with counts, accumulated info, the prevented flag, and whether actual output already streamed; this keeps UI, transcript, and notification consumers aligned on the stop reason.
- Send the notification that references
stop-hook-error only when there are errors so verbose transcript/ctrl+o viewers know the details exist.
- Keep the machine-readable attachment and summary message in lockstep so telemetry and UI never disagree about whether continuation was blocked and why.
Example Application
When the Stop hook intercepts a red team command that would delete infrastructure, emit the hook_stopped_continuation attachment with hookEvent: 'Stop', then send the summary message so the REPL banner shows “Stop hook prevented continuation: ” while telemetry records how many hooks fired and what errors occurred.
Anti-Patterns (What NOT to do)
- Do not rely on inconsistent manual logs; the single attachment + summary pair is the structured contract.
- Do not record hook errors without feeding them into the summary message or notification; UI and logs must share the same explanation.
1---2name: prevent-continuation-stop-hook-messaging3description: Collect stop-hook progress/errors, emit a structured prevented-continuation attachment, and summarize the block for users and logs.4---56# SKILL: Prevent Continuation Stop Hook Messaging7**Domain:** tool-orchestration 8**Trigger:** Use when stop hooks prevent continuation so you can surface a consistent attachment plus a summary notification that downstream UI/logging consumes.9**Source Pattern:** Distilled from reviewed tool-loop and result-shaping patterns.1011## Core Method12Capture every hook progress update while the stop-hook generator runs, track how many hooks fired, preserve per-hook command and prompt details, then attach later timing/error data to the matching hook entries. When a hook asks to prevent continuation, emit a machine-readable `hook_stopped_continuation` attachment with the hook name, tool use ID, and stop reason, then synthesize the concise `StopHookSummary` message that surfaces counts, errors, and whether the turn was blocked. This keeps UI banners, transcript log notifications, and verbose hooks in sync, with a single reusable pattern that works whenever any hook stops the turn.1314## Key Rules15- Gather `hookInfos` from `progress` attachments (command, prompt, duration) and `hookErrors` from non-blocking or blocking attachments so you can summarize each hook’s outcome.16- Emit the `hook_stopped_continuation` attachment exactly when `preventContinuation` becomes true, supplying `toolUseID`, hook name, and the stop reason so log processors and tool-tracking pipelines get a structured signal.17- After the generator completes, call `createStopHookSummaryMessage` with counts, accumulated info, the prevented flag, and whether actual output already streamed; this keeps UI, transcript, and notification consumers aligned on the stop reason.18- Send the notification that references `stop-hook-error` only when there are errors so verbose transcript/ctrl+o viewers know the details exist.19- Keep the machine-readable attachment and summary message in lockstep so telemetry and UI never disagree about whether continuation was blocked and why.2021## Example Application22When the `Stop` hook intercepts a red team command that would delete infrastructure, emit the `hook_stopped_continuation` attachment with `hookEvent: 'Stop'`, then send the summary message so the REPL banner shows “Stop hook prevented continuation: <reason>” while telemetry records how many hooks fired and what errors occurred.2324## Anti-Patterns (What NOT to do)25- Do not rely on inconsistent manual logs; the single attachment + summary pair is the structured contract.26- Do not record hook errors without feeding them into the summary message or notification; UI and logs must share the same explanation.
vishuwa2004