Feature Request: Expose Session Name to All Extension Points

[Niels-LNS-Research]

Summary

Session naming was added in #2112, but the session name is not accessible during the session. The session name should be available to the model and all extension points (hooks, commands, skills, rules).

Current State

Context	Session ID	Session Name
Model (during conversation)	No	No
Hooks (JSON input)	Yes	No
Commands ($SESSION_NAME)	No	No
Skills	No	No
Rules	No	No
CLI (resume)	Yes	Yes

Problem

Users can name sessions, but that name is inaccessible during the session itself. This limits the utility of session naming to just the resume workflow.

Example scenario: A user names a session "vendor-briefing-acme" but cannot:

• Reference the session name in output file names
• Log activity with the session name
• Have commands/skills behave differently based on session type
• Include session context in generated content

Proposed Solution

Expose session name consistently across all extension points:

1. Model Context

Include session info in the system context provided to the model:

Session name: vendor-briefing-acme
Session ID: 550e8400-e29b-41d4-a716-446655440000

2. Hooks (JSON Input)

Add session_name alongside existing session_id:

{
  "session_id": "550e8400-e29b-41d4-a716-446655440000",
  "session_name": "vendor-briefing-acme",
  "transcript_path": "...",
  "hook_event_name": "PreToolUse"
}

3. Commands (Variable Substitution)

Support $SESSION_NAME and $SESSION_ID variables in command files:

# Activity Log

Logging activity for session: $SESSION_NAME

Output file: logs/$SESSION_NAME-activity.md

4. Skills

Same variable substitution in SKILL.md files, or access via the model's system context.

5. Rules

Session context available when rules reference session-specific behavior.

Use Cases

1. Activity logging: Hooks log [session-name] Tool: Read file.md instead of [abc123] Tool: Read file.md

2. Output organization: Commands generate files like vendor-briefing-acme-prep.md based on session name

3. Session-aware workflows: A "research" session could auto-activate research-focused skills

4. Traceability: Generated content can reference which session produced it

5. Multi-session coordination: Skills could check if related sessions exist

Alternatives Considered

1. Hooks-only: Partial solution; doesn't help commands, skills, or model context
2. Environment variable: Would work for hooks/bash but not for model or variable substitution
3. Status quo: Session names remain decoration-only, limiting their utility

Additional Context

This builds on #2112 (session naming). The implementation likely requires:

• Adding session_name to hook input schema
• Adding session context to model system prompt
• Supporting variable substitution for $SESSION_NAME in commands/skills

Backward compatible: unnamed sessions could expose session_name: null or use the session ID as fallback.