Describe the feature or problem you'd like to solve
Invoke a skill foreach new session
Proposed solution
The sessionStart hook name strongly implies it fires whenever a new "session" (conversation) begins — including via /new and /clear . In practice:
- Hook entries of "type": "prompt" only fire on true CLI process startup ( source: "startup" ), not on /new ( source: "new" ) or /clear , per the docs note: "Prompt hooks fire only for new interactive sessions... They do not fire on resume." This is confusing because /new is documented as "Start a new conversation" and intuitively should count as a "new interactive session."
- /clear ("Abandon this session and start fresh") doesn't appear to trigger sessionStart at all — it's not listed among the source values ( "startup" | "resume" | "new" ).
This creates a real usability gap: a user-level hook meant to re-apply a session-scoped customization (e.g., auto-running a skill/mode via a prompt hook) silently stops working after /new or /clear , with no indication in /env that anything is "missing" — the hook config is loaded, it just never fires again for these transitions.
Suggestions:
• Either make "type": "prompt" hooks fire for source: "new" (matching user expectation and documented /new behavior), or rename the event/restrict the docs wording so it's unambiguous that sessionStart (for prompt hooks) really means "process startup only."
• Clarify/confirm whether /clear fires sessionStart at all, and add it explicitly to the source enum if so.
• Consider a distinct event (e.g., conversationStart ) for /new / /clear transitions, separate from true process-level sessionStart , so hook authors can target the semantics they actually need.
Example prompts or workflows
No response
Additional context
No response
Describe the feature or problem you'd like to solve
Invoke a skill foreach new session
Proposed solution
The sessionStart hook name strongly implies it fires whenever a new "session" (conversation) begins — including via /new and /clear . In practice:
This creates a real usability gap: a user-level hook meant to re-apply a session-scoped customization (e.g., auto-running a skill/mode via a prompt hook) silently stops working after /new or /clear , with no indication in /env that anything is "missing" — the hook config is loaded, it just never fires again for these transitions.
Suggestions:
• Either make "type": "prompt" hooks fire for source: "new" (matching user expectation and documented /new behavior), or rename the event/restrict the docs wording so it's unambiguous that sessionStart (for prompt hooks) really means "process startup only."
• Clarify/confirm whether /clear fires sessionStart at all, and add it explicitly to the source enum if so.
• Consider a distinct event (e.g., conversationStart ) for /new / /clear transitions, separate from true process-level sessionStart , so hook authors can target the semantics they actually need.
Example prompts or workflows
No response
Additional context
No response