Feature request: PreAssistantResponse hook for context injection before output generation

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Hooks fire on tool calls (PreToolUse), user input (UserPromptSubmit), and session events, but there's no hook that fires before Claude generates its response text. This means external systems (memory layers, style enforcers, preference managers) can't inject context at the moment it matters most: right before output generation.

Concrete example: I have a memory system that stores user preferences like "don't use the word 'curious' in comments" or "keep PH comments under 3 sentences." These preferences get recalled on tool calls and user prompts. But when Claude drafts a comment inline (no tool call involved), the memory system never fires, so preferences get silently skipped. The user's corrections are stored but never applied.

This affects any output Claude generates without a tool call: commit messages, PR descriptions, email drafts, code comments, explanations, recommendations.

Proposed Solution

Add a PreAssistantResponse hook event that fires after Claude has processed all tool calls for a turn but before generating the final text response to the user.

{
  "hooks": {
    "PreAssistantResponse": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "bash ~/hooks/pre-response.sh",
        "timeout": 5
      }]
    }]
  }
}

The hook response would support additionalContext injection (same as UserPromptSubmit) so external systems can provide last-moment context that shapes the output.

{
  "hookSpecificOutput": {
    "hookEventName": "PreAssistantResponse",
    "additionalContext": "User preference: keep comments under 3 sentences, avoid the word 'curious'"
  }
}

Why existing hooks don't solve this

• UserPromptSubmit: fires too early. Can't predict what Claude will generate 5 tool calls later
• PreToolUse: only fires on tool calls. Inline text generation has no tool call
• Stop: fires after output is already generated and shown. Can block + force re-generation but the user already saw the bad output
• CLAUDE.md rules: Claude can rationalize skipping them. Hooks are mechanical

Alternative Solutions

Workaround: require Claude to call a dummy tool before every text output so PreToolUse fires. But this is voluntary and testing shows ~30-40% compliance, Claude forgets or skips the tool call most of the time.

Priority

Medium - Moderate impact on productivity

Feature Category

Hooks

Use Case Example

1. User runs a multi-step automation (daily research sweep)
2. Claude searches the web, pulls data from APIs (tool calls fire, memory system injects context)
3. Claude drafts a social media comment inline (no tool call)
4. Memory system never fires, user preferences about writing style are ignored
5. User has to manually correct the output every time
6. With PreAssistantResponse, the memory system would inject style preferences right before the comment is drafted

Additional Context

The current hook system covers the full tool execution lifecycle well. The gap is specifically in the "Claude thinking and writing" phase where no hooks fire. This is the only phase where Claude generates user-facing text that might need external context injection.