# Prevent Continuation Stop Hook Messaging

> Collect stop-hook progress/errors, emit a structured prevented-continuation attachment, and summarize the block for users and logs.

- Skill: `vishuwa2004/prevent-continuation-stop-hook-messaging` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add vishuwa2004/prevent-continuation-stop-hook-messaging`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vishuwa2004/prevent-continuation-stop-hook-messaging/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: vishuwa2004 (https://skillmd.com/u/vishuwa2004)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vishuwa2004/prevent-continuation-stop-hook-messaging

---


# 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: <reason>” 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.