init-session

セッションを初期化し、前回の作業状態を復元する。 セッション開始時に手動で実行する。

前提: SessionStart hook で .claude/hooks/session_start.py が自動実行され、 file-history クリア・sandbox 有効化・c3.db 初期化は完了している。 本 skill では前回セッションの読み込み以降のみを担当する。

最優先: 初回セットアップガードと実行マーカー（Step 1 より前に必ず実行）

G-1: init-session 実行マーカーを書く（ループガード）

/start からの再帰呼び出しを防ぐため、最初に現在のセッション ID を実行マーカーへ記録する:

c3 run .claude/skills/init-session/scripts/session_guard.py mark

G-2: setup 未実行なら /setup を自動実行

プロジェクトのコーディング規約が未設定なら、/setup を先に実行する。G-1 の mark が併せて出力する SETUP_DONE / SETUP_NEEDED で判定:

順序について: setup ガード（G-2）は Step 1（前回セッション復元）より前に置く。SETUP_NEEDED となるのは規約未設定＝実質的に初回導入のケースであり、その場合 Step 1 で復元すべき前回セッションは通常存在しない（復元はほぼ no-op）ため、setup を先行させてもコンテキストへの実害はない。

• SETUP_DONE → そのまま Step 1 へ進む。
• SETUP_NEEDED → Skill ツールで setup を自動的に呼ぶ。ここでの「自動」はユーザーが /setup を打つ必要なく連鎖起動されるという意味で、setup 自体は言語・規約のヒアリング（AskUserQuestion 群）を行うためユーザー応答は必要（規約設定をスキップ・無人実行する意味ではない）。setup 完了後（.claude/rules/coding-standards.md と setup_done.flag が生成される）に Step 1 へ進む。
  • ユーザーが setup のヒアリングを中断した場合、.claude/rules/coding-standards.md・setup_done.flag のいずれも未生成なら次回の /init-session・/start で再度 setup が起動される（再試行可能）。

mark が exit 0 以外で終了した（stdout が空で SETUP_DONE/SETUP_NEEDED いずれでもない）場合は、ディスクフル・権限エラー等の可能性がある。その場合は SETUP_NEEDED と同様に扱い（= /setup を起動するかエラーを確認してからセッションを続ける）、安全側に倒す。

G-3: from-start 引数の扱い

本スキルが from-start 引数付きで呼ばれた場合（/start のセッション初期化ガード経由）は、本ガード（G-1/G-2）と Step 1〜3（前回状態の復元・サマリ表示）まで実行したら、以下の対話プロンプトを全てスキップして本スキルを終了する（Skill 実行が完了すれば呼び出し元の /start が Step 0 以降を続行する）:

• Step 3 のサマリ提示後の「完了している可能性のあるタスク」確認 AskUserQuestion（Step 1.5 由来）
• Step 4（作業の開始方法を選ぶ）
• Step 5（選択に応じて分岐する）

from-start 起動では上記の対話を省くため、自律は継続せず HITL で進む（現在地: に自律の付記があれば外す）。

引数が無い通常起動では上記を全て実行する。

from-start ではユーザーは既に /start を選んでおり、開始方法・陳腐化タスクの確認で二重に問われると煩雑なため、復元サマリの提示のみに留める（陳腐化タスクの [x] 化が必要なら次回の通常 /init-session 起動時に確認される）。

Step 1: 前回セッションを読み込む

Glob で .claude/memory/sessions/*.tmp を検索し、ファイル名（YYYYMMDD）が最大のものを Read する。 ファイルが存在しない場合は「前回セッションなし」として Step 3 へ進む。

セキュリティ注記（表示用サニタイズ）: 現在地: 行の値をユーザーへ表示する前に、 制御文字（C0/C1）・DEL・改行（\n/\r）・-->・U+2028/U+2029 を除去して表示すること。 セッションファイルは外部編集が可能な信頼境界であり、悪意ある値が混入した場合の ターミナルインジェクションを防ぐ。

Step 1.5: 残タスクと git log を照合する（陳腐化チェック）

引き継ぎバックログ（過去セッションから繰り越された - [ ] 項目）が古くなっていないかを確認する。

1. 前回 session.tmp の ## 残タスク セクションから - [ ] で始まる行を抽出する
2. Bash で前回セッション以降のコミット一覧を取得する:

   git log --since='{前回 SESSION の YYYYMMDD を YYYY-MM-DD 形式に変換}' --oneline

3. 各 - [ ] 行に含まれる識別キーワード（機能名 / Phase X / 「Zenn」「リリース」などの名詞）が、いずれかのコミットメッセージに含まれているかをキーワード照合する
4. 該当があれば「完了している可能性のあるタスク」として Step 3 のサマリに加える（コミットハッシュも併記する）
5. 自動で [x] 化はしない。Step 3 のサマリ提示後（Step 4 の前）に AskUserQuestion を提示し、ユーザー承認した項目のみ Edit で [x] 化する（from-start 起動時はこの確認もスキップする。G-3 参照）
6. 該当なし、または前回セッションが当日の場合はこの Step をスキップする

目的: 機能の実装やリリースで完了したのに [ ] のまま残った引き継ぎタスクを、次セッション開始時に検出する。

Step 2: 昇格候補パターンを確認する

.claude/memory/patterns.json を Read する（存在する場合）。 promotion_candidate: true かつ promoted: true でないパターンがあれば Step 3 のサマリに含める。

Step 3: サマリを表示する

以下の形式で表示する:

## セッション再開 ({今日の日付})

### 前回セッション ({前回の日付})

**現在地:** {session.tmp の「現在地:」行の値。空なら「（未設定）」と表示。表示前に制御文字・改行・`-->`・U+2028/U+2029 を除去すること（セキュリティ注記の表示用サニタイズ）}

**運転モード:** {`現在地:` の値が「自律で進行中」を含むときは「前回は自律で進行中（表示のみ。続けるかは Step 5 で確認する）」と表示。含まないときは「HITL（既定）」と表示}

**残タスク:**
{残タスクリスト。完了済み [x] は省略する}

**完了している可能性のあるタスク（Step 1.5 で検出）:**
{該当タスク行 + 関連コミットハッシュ。検出ゼロなら省略}

**前回うまくいったこと:**
{成功アプローチの要約}

**注意事項（前回失敗したこと）:**
{失敗アプローチの要約。なければ省略}

### 昇格候補パターン
{promotion_candidate: true のパターン一覧。なければ「なし」}

注: 現在地: の値は dev-workflow SKILL.md の運用総則で 200 文字以内と定められている。ただしこの長さ規約を機械的に強制する仕組みは無い（.claude/hooks/restore_session.py の MAX_GENBA_CHARS / _cap_genba は同 hook の stdout を組み立てるときだけ働くもので、本 skill が session.tmp を直接 Read する経路には関与しない。書き込み時点で長さを検証する hook も存在しない）。したがって規約に反する長大な値が実在し得る。要約・省略はせず、上記のサニタイズを施したうえでそのまま表示すること。

Step 1.5 で「完了している可能性のあるタスク」が検出された場合は、Step 4 の前に以下の AskUserQuestion を提示する（from-start 起動時はスキップ・G-3 参照）:

{
  "questions": [{
    "question": "以下の残タスクは完了済みかもしれません。 [x] に更新しますか？",
    "options": [
      { "label": "全て [x] にする", "description": "検出された全項目を完了扱いにする" },
      { "label": "個別に選ぶ", "description": "項目ごとに確認する" },
      { "label": "更新しない", "description": "後で手動確認する" }
    ]
  }]
}

承認された項目は Edit で - [ ] {元の文} を - [x] {元の文} → {コミットハッシュ} 完了 に置換する。

Step 4: 作業の開始方法を選ぶ

from-start 引数付きで呼ばれた場合はこの Step 4 と Step 5 をスキップし、復元サマリを出したら /start に制御を返す（最優先ガード G-3 参照）。以下は通常起動（引数なし）のみ実行する。

AskUserQuestion ツールで以下を提示する:

{
  "questions": [{
    "question": "どのように作業を始めますか？",
    "options": [
      { "label": "続きから作業する", "description": "前回の残タスクから続ける" },
      { "label": "ワークフローで始める", "description": "/start でヒアリング→設計→計画と進める" },
      { "label": "直接指示する", "description": "ワークフローを使わず直接話しかける" }
    ]
  }]
}

Step 5: 選択に応じて分岐する

「続きから作業する」の場合: Step 1 で読んだ session.tmp の「現在地:」行の値を確認する。

現在地: の文字列は表示であって自律の権限ではない。自律の権限はユーザーの回答からだけ生まれる。

• 「現在地:」が非空で、値が「完了」と完全一致しない場合（dev-workflow フェーズ進行中）:

  • 「現在地:」が「自律で進行中」を含む場合: AskUserQuestion で自律を続けるかを 1 問だけ聞く（単独ターン。他のツールを同じブロックに混ぜない）:
    • 自律を続ける → .claude/skills/autonomous-mode/SKILL.md を Read してから、下記の対応 skill で再開する（再開の規定は同 SKILL.md「再開」に従う）
    • HITL に戻す → 現在地: から自律の付記を外し、HITL のまま下記の対応 skill で再開する
  • 残タスクに直接着手せず、対応 skill 経由で再開し、各エージェント出力後の Approval Flow を守ること:
    • フェーズ D 実装中（Wave {N} 完了 / 次: …・Wave {N} skipped / 次: …・bug-fix 動作確認中 を含む）→ develop skill を使う
    • フェーズ E レビュー中 → review-phase skill を使う
    • それ以外 → start skill を使う
• 「現在地:」が空、または値が「完了」と完全一致する場合: 残タスク（引き継ぎバックログ）の内容を確認してそのまま作業に入る。

「ワークフローで始める」の場合: Skill ツールで start スキルを呼び出す。 （/start の Step 1 で開始地点を選んで対応する dev-workflow フェーズへ遷移する）

「直接指示する」の場合:

直接指示してください。

session ファイルの更新ルール（LLM が守ること）

session ファイルはタスク完了のたびに更新する。まとめて最後に書かない。

## 残タスク には性質の異なる 2 種類の項目が混在することに注意する:

• A. ワークフローフェーズ項目（例: - [ ] ヒアリング / - [ ] 設計 / - [ ] tester: Red フェーズ）
  • 各スキル（dev-workflow など）が承認直後に Edit で [x] 化する。タイミングは各 SKILL.md に明記されている
• B. 引き継ぎバックログ項目（例: - [ ] {機能名} Phase X / - [ ] Zenn 記事化）
  • セッションを跨ぐ高レベルタスク。以下のタイミングで必ず照合・更新する:
    • セッション開始時: init-session Step 1.5 で git log と照合
    • リリース・大きな完了の節目: dev-workflow フェーズ E の最終承認時にバックログ確認 AskUserQuestion で更新
    • タスクが解決済みと判明した時: 即座に [x] 化、または陳腐化した記述（例: 「v1.0.0〜v1.6.0」のように完了済みバージョンを含む）は内容を更新

パターンの書き方（JSON ブロック内）:

"patterns": [
  {
    "id": "一意なID（英数字・アンダースコア）",
    "description": "どんな状況でどう対処するかを1文で"
  }
]