Fix prompt extraction in Stop hook notifications

[RonAmihai]

Problem

The Stop hook in on-stop.sh produces broken or missing notifications in all terminals — both Warp and terminals that support OSC 777 (like Ghostty).

Root cause

The prompt extraction on line 19-21 uses .message.content which returns the raw JSON content blocks array rather than extracting the text:

# Current (broken)
PROMPT=$(jq -rs '
    [.[] | select(.type == "user")] | first | .message.content // empty
' "$TRANSCRIPT_PATH" 2>/dev/null)

Claude Code transcripts store user messages as content block arrays:

{"type": "user", "message": {"content": [{"type": "text", "text": "my prompt"}]}}

So .message.content returns the entire array [{"type":"text","text":"my prompt"}] instead of the string "my prompt".

The response extraction on lines 24-27 already handles this correctly by iterating .message.content[] and selecting .text — the prompt extraction just needs the same pattern.

How this manifests per terminal

Terminal	Before fix	After fix
Warp	Falls back to generic "Task completed" — the raw JSON array causes jq to silently fail downstream	Shows actual "prompt" → response content
Ghostty (and other OSC 777 terminals)	Displays raw JSON: "[ { "type": "text", "text": "my prompt" ..." → response	Shows clean "my prompt" → response

Fix

One-line change — apply the same content block parsing pattern already used for response extraction:

     PROMPT=$(jq -rs '
-        [.[] | select(.type == "user")] | first | .message.content // empty
+        [.[] | select(.type == "user")] | first |
+        [.message.content[] | select(.type == "text") | .text] | join(" ")
     ' "$TRANSCRIPT_PATH" 2>/dev/null)

The fallback to "Task completed" is preserved — if extraction fails for any reason, the default message still applies.