From session
現在のセッションをforkして新しいtmuxウィンドウで起動。 会話履歴を引き継いだ別セッションを並行実行できる。 Use when user wants to: fork session, create parallel session, branch conversation, open forked session in new window, says 「fork」「フォーク」「並行セッション」「別窓で続き」 says 「監視して」「完了したら教えて」「投げっぱなし」
How this skill is triggered — by the user, by Claude, or both
Slash command
/session:forkThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
現在のClaude Codeセッションをforkし、新しいtmuxウィンドウで起動する。
現在のClaude Codeセッションをforkし、新しいtmuxウィンドウで起動する。
claude --continue --fork-session で最新セッションの会話履歴を引き継ぎつつ新しいセッションIDを発行| 意図 | 検出パターン例 | 動作 |
|---|---|---|
| 即実行 | 引数なし | cld-fork を実行 + 完了監視(デフォルト) |
| prompt | テキスト | fork 先の初期プロンプト + 完了監視(デフォルト) |
| 詳細監視 | 「監視して」「経過も教えて」「見ていて」 | 完了監視に加え途中経過も逐次報告 |
| 監視なし | 「投げっぱなし」「監視不要」 | 完了監視を省略 |
tmux内か確認(tmux外はエラー終了)
意図を推定する
PROMPT にWATCH=offWATCH=detailedWATCH=completion(デフォルト)cld-fork を実行
SCRIPT_DIR="${CLAUDE_PLUGIN_ROOT}/scripts"
bash "$SCRIPT_DIR/cld-fork" "$PROMPT" # PROMPT が空なら引数なしで実行
cld-fork の stdout からウィンドウ名を取得(forked → tmux window 'WINDOW_NAME' の形式)。
完了監視(WATCH=off 以外)— 後述の「完了監視」を実行する。
WATCH=off 以外では、spawn 元のこのセッションが fork 先の完了を監視し報告する。
Bash tool の run_in_background: true で以下を起動する。状態を逐次 stdout に出すため経過を追える:
SCRIPT_DIR="${CLAUDE_PLUGIN_ROOT}/scripts"
WINDOW_NAME="<Step 3 で取得したウィンドウ名>"
TIMEOUT=300; ELAPSED=0
until bash "$SCRIPT_DIR/session-state.sh" state "$WINDOW_NAME" 2>/dev/null | grep -qx "input-waiting"; do
STATE=$(bash "$SCRIPT_DIR/session-state.sh" state "$WINDOW_NAME" 2>/dev/null || echo exited)
echo "[${ELAPSED}s] $STATE"
{ [ "$STATE" = "exited" ] || [ "$ELAPSED" -ge "$TIMEOUT" ]; } && break
sleep 10; ELAPSED=$((ELAPSED + 10))
done
echo "[final] $(bash "$SCRIPT_DIR/session-state.sh" state "$WINDOW_NAME" 2>/dev/null || echo exited)"
bash "$SCRIPT_DIR/session-comm.sh" capture "$WINDOW_NAME" --lines 30
WATCH=detailed では sleep 10 を短く(例 5)して途中経過(processing 状態)も報告に含める。run_in_background の完了通知を受けたら、capture を下記フォーマットで要約報告する。npx claudepluginhub shuu5/cc-session --plugin sessionGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Implements work from a spec or tickets using TDD at agreed seams, with regular typechecking and test runs, followed by code review.