[ENHANCEMENT] Allow prompt based hook

[medasmarathon]

Problem (one or two sentences)

Claude code has ability to create prompt based hook https://code.claude.com/docs/en/hooks#how-prompt-based-hooks-work

Context (who is affected and when)

Allow add this hook for any step of agent event: pre tool use, post tool use, before stop, etc.

Desired behavior (conceptual, not technical)

Allow for smaller model / different desired small models to step in and enhance the reasoning

Constraints / preferences (optional)

Ability to select model to process these prompt-based hook

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

No response

Proposed approach (optional)

No response

Trade-offs / risks (optional)

No response

[roomote]

I'd like to help with this issue, but I need some clarification to ensure I implement the right solution. Could you please provide more details on the following:

1. Hook trigger points: You mention "pre tool use, post tool use, before stop, etc." -- could you list the complete set of agent event hooks you'd like supported? For example, Claude Code supports hooks like PreToolUse, PostToolUse, Notification, and Stop. Should we match that set exactly, or do you have a different set in mind?

2. Hook configuration format: How should users configure these hooks? Claude Code uses a .claude/settings.json with a hooks key. Should we use a similar approach (e.g., .roo/hooks.json or within the existing Roo Code settings), or would you prefer a UI-based configuration in the Settings panel?

3. Model selection for hooks: You mention the ability to select a model to process prompt-based hooks. Should this be:

   • A single model configured per-hook (e.g., each hook specifies which model/API to use)?
   • A global "hook model" setting that applies to all hooks?
   • Should the hook model configuration reuse the existing API configuration system (profiles), or be independent?

4. Hook prompt format: For the prompt-based hooks, what should the input/output contract look like? For example:

   • Should the hook receive the current tool call details, conversation context, or both?
   • Should the hook's output be able to modify the tool call, block it, or just provide advisory text that gets injected into the conversation?

5. Scope: Is this intended as a per-project configuration (like .roo/hooks.json), a global user setting, or both?

Please tag @roomote in your response with the answers, and I'll be happy to propose an implementation plan once I have this information.

[medasmarathon]

@roomote

1. Analyze what are events we can support and already implemented in place. If not, prefer to support those events hook first before this implementation. We need to allow for prompt-based hook into those events.
2. .roo/hooks.json with Claude compatibility format is desirable. Later we can add UI-based configuration when feature is stable.
3. For now, global hook model is preferable to avoid complexity. It should be tied to profile setup
4. Hook should be readonly for now. No tool access. Conversation context: yes.
5. Can be per project as well as global user settings

[roomote]

Thanks for the detailed guidance! I've seen your comment and will explore the existing event infrastructure in the codebase to understand what hooks are already in place. I'll then design a prompt-based hook system following your specifications:

1. Analyze existing events and support prompt-based hooks into them
2. .roo/hooks.json with Claude-compatible format
3. Global hook model tied to profile setup
4. Read-only hooks with conversation context, no tool access
5. Per-project and global user settings support

I'll open a draft PR to share progress shortly.

[roomote]

Opened a draft PR with my attempt at implementing prompt-based hooks: #11505

What's implemented:

• .roo/hooks.json configuration (project-level) and ~/.roo/hooks.json (global), Claude-compatible format
• Three hook events: PreToolUse, PostToolUse, Stop
• Global hook model tied to the active profile API configuration
• Read-only hooks with no tool access, advisory output only
• File watchers for automatic config reload
• 33 tests covering validation and execution

Feedback welcome!