Add /fork skill — parallel sessions from one conversation

[andyed]

Summary

Adds a new /fork skill that opens a new terminal tab with a forked copy of the current Claude Code conversation. The forked session auto-connects to the parent via the bridge.

• New file: plugins/session-bridge/skills/fork/SKILL.md
• Updated: README.md — added /fork to commands table and plugin structure

How it works

1. Finds the current session ID from transcript files
2. Registers the parent with the bridge via register.sh
3. Writes a pending-connect breadcrumb for the child's SessionStart hook
4. Opens a new terminal tab via AppleScript and launches claude -r <session> --fork-session
5. Child session auto-connects to parent on startup

Terminal support (macOS)

• Ghostty
• iTerm2
• Terminal.app

Use cases

• Branch off an experiment without losing your main thread
• Parallelize work across two agents that share full conversation context
• Both sessions can /bridge ask each other immediately after fork

Test plan

• /fork from a Ghostty session — new tab opens with forked conversation
• /fork experiment — new tab with named session
• Verify bridge auto-connect — /bridge peers shows both sessions
• /bridge ask from parent → child responds with context from the forked conversation

Generated with Claude Code

[PatilShreyas]

Thanks for the PR and the creative idea! Forking a conversation and auto-connecting via bridge is a cool concept. However, I have a few concerns that lead me to request changes:

1. Conflicts with built-in Claude Code /fork

Claude Code already has a native fork/worktree mechanism. Adding a /fork skill to this plugin would shadow or conflict with that built-in command. Users would get confused about which /fork they're invoking.

2. Scope of session-bridge

session-bridge is specifically about cross-project, cross-repo communication between separate Claude Code sessions. The core use case: a library session and a consumer app session talking to each other about breaking changes, API migrations, etc.

Forking is a different concern. It's about session management and parallelization within the same project. It doesn't fit the plugin's purpose.

3. Technical issues

A few things in the implementation that would need fixing if this were in scope:

• Skill vs Command: The file uses argument-hint and allowed-tools in SKILL.md frontmatter, but those are command fields, not skill fields. This should be a command if anything.
• Session ID lookup: Uses ls -t *.jsonl | head -1 which we specifically moved away from because claude -p creates small session files that ls -t picks over the real conversation. We built get-session-id.sh for this.
• pending-connect breadcrumb has no reader: There's no SessionStart hook in our hooks.json to read ~/.claude/session-bridge/pending-connect. The child session wouldn't actually auto-connect.
• macOS only: No OS detection or guard for Linux users.

Suggestion

This would work better as a standalone plugin rather than part of session-bridge. That way it can own the /fork UX without conflicting with Claude Code's built-in mechanism or overloading this plugin's scope.

Appreciate the contribution though!