Ssot Record

ssot-record スキル

概要

「記録して」と言うだけで以下を自動実行する:

1. 分類 — 内容を稼働中のLLM（WSL CLI版=GLM / Windows デスクトップアプリ版=Sonnet）で分析して振り分け先を判定
2. 確認 — 判定結果（ガイド転記先・概要を含む）をユーザーに提示して一括承認を得る
3. 記録 — SSOT・日記・_INDEX.md に書き込む
4. 転記 — 承認済みならガイドに追記してビルド・push

構想モード（設計判断の永続化）

ユーザーが「これ残して」「決定事項にして」「構想メモ」と言った時、または brainstorming/sentaku 終了時に spec 未出力で「代わりに構想を残しますか?」に yes とした時は 構想モード で動く。

構想モードでは 01_DECISIONS/ でなく バックログ.md 該当タスク直下に 📝WIPメモ を追記する（真実のソースを増やさない・タスクと運命共同体・ゴミ化防止）。

手順

1. 該当タスクを特定: バックログ.md から会話文脈・ユーザー指示で該当タスク行を探す。未登録なら新規タスク行を追加してから。
2. 📝WIPメモ追記: 該当タスク行の直下にインデントブロックで追記:

     - 📝 構想(YYYY-MM-DD): <方針1-2行>
       - 経緯: <候補/選択理由/却下>
       - 次タスク: <承認済・設計未着手の内容>
   

3. 日記サマリー: 10_DAILY/YYYY-MM-DD.md に1行追記（バックログ更新への言及のみ・技術詳細直書き禁止）。
4. 01_DECISIONS には書かない（構想はバックログ直下が真実のソース・_INDEX.md 更新も不要）。

振り分け（構想 vs バックログ行 vs spec）

• 設計判断を含む（複数案評価・トレードオフ）= 構想（📝WIPメモ）
• 単一アクション完結 = バックログ通常行（本モード対象外）
• 実装詳細仕様まで = spec 直行（本モード対象外）
• 判定不能 → 構想（安全側）

ライフサイクル

• spec化: メモ → spec リンクに置換
• タスク破棄: メモも消える（運命共同体）
• 30日滞留: 破棄候補フラグ

詳細ルール: @rules/_shared/記録.md「構想段階の合意の永続化」

フェーズ0: 情報収集

会話の文脈から以下を自動収集する。不足分だけ聞く（1行ずつ）:

• 内容 — 何を記録したいか（会話から読み取れる場合はスキップ）
• プロジェクト名 — 不明な場合のみ確認（例: claude-code, atelier-kyo-manager）
• 未解決 — 残タスクがあれば（なければスキップ）

フェーズ0.5: 関連ファイル自動検出

フェーズ1の分類判定で tags が確定した後に実行する。 SSOT内の 2つのマッピング設定ファイル を読み込み、プロジェクト側docs と 00_SYSTEMハブ の更新対象を自動検出する。

設定ファイル（2つ・並列参照）

• obsidian-ssot/00_SYSTEM/タグマッピング.md — タグとプロジェクト別docsのマッピング定義（既存）
• obsidian-ssot/00_SYSTEM/ハブマッピング.md — タグと00_SYSTEMハブファイルのマッピング定義（新設・監査⑩見逃し防止）

検出手順（両表で共通）

1. 設定ファイル読込: タグマッピング.md と ハブマッピング.md をRead
2. タグ照合: 分類判定で決まった tags と両マッピングテーブルの「必須タグ」を照合
3. 追加タグ照合: マッチした行の「追加タグ」と tags を照合（OR条件）
4. ファイル存在確認: 更新対象ファイルが存在するか ls で確認
5. 結果をフェーズ2に渡す: 更新対象リスト（ファイルパス + 更新の種類 + 重要度: 必須/任意）を生成
   • プロジェクトdocs（タグマッピング）→ フェーズ3-6
   • 00_SYSTEMハブ（ハブマッピング）→ フェーズ3-8

検出結果の例

📦 プロジェクトドキュメント更新対象（タグマッピング・3ファイル）:
   ✅ docs/変更履歴.md             — 末尾にエントリ追加

🗂️ 00_SYSTEMハブ更新対象（ハブマッピング・2件）:
   ✅ セキュリティ設定ハブ.md      — 層テーブル行追加 [必須]
   ✅ MCPツール使い分けガイド.md   — 構成テーブル行追加 [必須]

タグがマッチしない場合

両マッピングとも該当なしの場合は「プロジェクトdocs更新対象: なし / 00_SYSTEMハブ更新対象: なし」と表示し、従来通りSSOT記録のみ実行する。

フェーズ0.8: 関連パターン候補収集（LLM呼び出しなし）

フェーズ1の分類判定LLM呼び出しの前に、過去の記録との根本原因の一致を判定するための候補をファイルI/Oだけで収集する（追加のLLM呼び出しは発生しない）。

候補収集パイプライン

「過去7日」「直近5件」は、繁忙期も閑散期も取りこぼさないための折衷値（詳細はspec参照）。一時ファイル名には$$（プロセスID）を含め、並行セッションでの衝突を避ける。

SEVEN_DAYS_AGO=$(date -d "7 days ago" +%Y-%m-%d)

# 全01_DECISIONSエントリのfrontmatter date:行を、ファイルパス付きで抽出し日付降順ソート
grep -rH "^date: " ~/projects/obsidian-ssot/01_DECISIONS/*/2*.md 2>/dev/null \
  | sed -E 's/^(.*):date: *([0-9-]+)$/\2 \1/' \
  | sort -r > /tmp/ssot-record-candidates-sorted-$$.txt

# 集合A: 過去7日以内（当日含む）
awk -v d="$SEVEN_DAYS_AGO" '$1 >= d' /tmp/ssot-record-candidates-sorted-$$.txt > /tmp/ssot-record-setA-$$.txt

# 集合B: 日付に関係なく直近5件
head -5 /tmp/ssot-record-candidates-sorted-$$.txt > /tmp/ssot-record-setB-$$.txt

# 候補 = A ∪ B（重複排除）
cat /tmp/ssot-record-setA-$$.txt /tmp/ssot-record-setB-$$.txt | sort -u > /tmp/ssot-record-candidates-$$.txt
rm -f /tmp/ssot-record-candidates-sorted-$$.txt /tmp/ssot-record-setA-$$.txt /tmp/ssot-record-setB-$$.txt

ファイル名やパス文字列ではなく、frontmatterのdate:行のみを対象にする（誤爆防止。詳細はspec参照）。

候補情報の整形

/tmp/ssot-record-candidates-$$.txtの各行（日付 ファイルパス）について、以下を取得する:

1. 各ファイルをReadし、frontmatterのtags・root_cause（あれば）を取得
2. 対応する01_DECISIONS/<project>/_INDEX.mdの該当行（1行サマリー）を取得（既に開いている場合は再読込不要）

整形した候補リストはフェーズ1のプロンプトに渡す（Task 2参照）。

候補が0件の場合

/tmp/ssot-record-candidates-$$.txtが空（grep該当0件）の場合、候補リストを空のままフェーズ1に進む。フェーズ1のJSON出力ではrelated_pattern: nullになる（Task 2のプロンプト仕様に従う）。

後片付け

一時ファイル（/tmp/ssot-record-candidates*-$$.txt）はこのフェーズ内で使い切ったら削除する。

フェーズ1: 分類判定

環境別の判定方法

• WSL CLI版: セッション自体がGLMで動作中 → 自分自身で直接判定（外部LLM呼び出し不要・不可）
• Windows Desktop版: MCP経由で外部LLM呼び出し可能 → glm MCP等で判定してもよい

判定に使うプロンプト

以下の内容をSSOTに記録します。最適な振り分け先を判定し、JSON のみを返してください（説明文不要）。

【記録する内容】 {ユーザーの記録内容}

【SSOTフォルダ構成】

• 01_DECISIONS// — 技術的決定の経緯（なぜそうしたか・複数案比較・root_cause） ※「経緯」のみ。成果物改訂・正典は別場所
• 00_SYSTEM/ — システム設定変更（hooks, cron, settings.json, ガイド・運用ルール）
• 10_DAILY/ — 日記ハブ（直接の記録先ではない。サマリー追記のみ）
• 20_PUBLISHING/ — 外部公開コンテンツ（Zenn記事, note等）の草稿・管理
• 30_RESEARCH/ — LLMモデル・価格・外部サービスの調査結果（時系列で陳腐化する情報）
• 40_CAREER/ — ポートフォリオ・キャリア資料・成果物改訂・正典（設計書・数値マスター・修正ログ）・求人関連
• 50_PROJECTS/・70_PROMPTS/・99_ARCHIVE/ — プロジェクト作業・再利用プロンプト・アーカイブ

【特性カタログ（保管場所判定の正典・必須参照）】 obsidian-ssot/00_SYSTEM/特性カタログ/01_保管場所.md を読み、記録内容の「性質」に合致する保管場所を選ぶ。 01_DECISIONS は一候補（技術的決定の経緂のみ）。典型誤判定パターン（ポートフォリオ改訂→01_DECISIONS ではなく 40_CAREER 等）に注意。

【ガイドサイト（転記判断基準）】

• claude-code-guide — Claude Codeの使い方・手順・チュートリアル（再利用できる手順のみ）
• ssot-guide — SSOTシステムの設計・使い方の説明

【判定ルール】

• 保管場所は「内容の性質」で判定: 「なぜそう決めたか（設計判断・経緯）」= 01_DECISIONS / 「何を完成させたか（成果物改訂・正典）」= 40_CAREER等 / 設定変更 = 00_SYSTEM / 調査 = 30_RESEARCH。01_DECISIONS は技術的決定の経緂のみ（2026-07-22 ポートフォリオを01_DECISIONSに振り分けたバイアス再発防止）
• 正典（設計書・数値マスター・修正ログ等）に関わる記録は 01_DECISIONS に新規せず正典と同場所へ（真実のソースを分散させない・Surgical Changes）
• also_daily は「セッションの主要な作業成果」の場合のみ true。途中メモ・調査記録・設定追記は false
• guide_needed は「他人や将来の自分が手順として再利用できる内容」の場合のみ true
• primary が 00_SYSTEM の場合、project は "claude-code" とする
• 記録前自己説明ゲート（透明性・2026-07-24 Gemini+MiniMaxレビュー指摘反映）: 保管場所を決めたら記録実行前に「なぜこの場所を選んだか」を1文で表明する（ユーザー提示 or 自己内省）。理由がすんなり言えない＝場所選びが怪しい→再判定。これにより「memory過信事故（永久版情報をmemory/01_DECISIONSに逃がしたe36d）」を構造的に再発防止する。CLAUDE.md「SSOT正典優先」ルールと二重化（CLAUDE.md=常時読込の心構え・本ゲート=記録実行時の強制）。

【Claude Codeガイド自動判定（CC Guide Auto-sync）】 記録内容がClaude Code機能の設定・変更の場合、CCガイドページへの追記が必要かを判定する。

Step 0: 前提となる自問（カテゴリ表を見る前に）

この記録は、単なるバグ修正・微調整・内部リファクタリング（外部仕様や使い方は変わらないもの）か？ それとも、新規か既存かを問わず、将来の同様のタスクで必須となる前提知識（新しい概念・フィールド・フロー・制約・非推奨化）を導入したか？

• 【Yesの例（Step 1のカテゴリ表に進む）】:
  • 新規スキルを作成した（業種問わず全て掲載対象。「営業系」「楽曲系」「補助ツール」等、CCガイドに載せる必要がないと思い込んでYesを飛ばさないこと。過去 demo-site-sales・resume-session 等の漏れ事例あり → Step1で 03_スキルシステム.md 追記）
  • 既存スキルに新しい機能（例: 関連パターンチェック）を追加した
  • 新しいエラーハンドリングのフローを導入した
  • 〇〇の設定方法が非推奨となり、新しい手順に変わった
• 【Noの例（cc_guide_page: null、Step 1は不要）】:
  • 単純なタイポ修正・バグ修正
  • 内部的なリファクタリング（外部仕様・使い方は変わらない）
  • 一時的なワークアラウンド

「新しい知識を含んでいない」と判断した場合は、以降のStep 1（カテゴリ表）を見るまでもなくcc_guide_page: nullとする。

Step 1: カテゴリマッチング（Step 0でYesと判断した場合のみ）

• CC機能に関係ない場合は cc_guide_page: null にする
• 複数ページに該当する場合は最初の1つだけを返す

【関連パターン判定（フェーズ0.8の候補を使う）】 フェーズ0.8で収集した候補リスト（あれば）を以下のように提示し、今回の記録内容と根本原因が共通していないか判定させる。候補が0件の場合はこのセクション自体を省略してよい。

候補リストの提示形式:

過去の関連候補（参考情報。project/tagsの分類には使わないこと）:
1. [project: <project>] <_INDEX.mdの1行サマリー>（root_cause: <あれば category+description、なければ「未記録」>）
2. ...

判定ルール:

• 思考順序を分離すること: まず「今回の記録内容」だけを見てproject・tags・category等の通常の分類判定を完了させる。その後で初めて、別タスクとして候補リストと照合してrelated_patternを判定する。候補リストを見ながら分類判定を行わない（過去ログの語彙に引っ張られてtagsがブレるのを防ぐため）
• 今回の記録内容と候補の間に、表面的な症状ではなく根本原因・構造的な前提が共通すると判断できる場合のみrelated_patternを埋める
• 少しでも確信が持てない場合はrelated_pattern: nullを返す（過剰検出を避ける）

返答フォーマット（JSON のみ、コードブロック不要）: { "primary": "01_DECISIONS or 00_SYSTEM or 40_CAREER or 30_RESEARCH 等（内容の性質で判定・01_DECISIONSは技術的決定の経緂のみ）", "project": "プロジェクト名", "category": "技術的決定 or ノウハウ or 調査 or キャリア or システム設定 or 公開コンテンツ", "also_daily": true or false, "guide_needed": true or false, "guide_target": null or "claude-code-guide" or "ssot-guide", "cc_guide_page": "03_スキルシステム.md" or null, "cc_guide_entry": { "name": "<スキル/MCP/フック名>", "description": "<1行説明>", "trigger": "<トリガー例>", "usage_section": "### <name>\n\n<Markdown形式の使い方説明>\n" }, "tags": ["タグ1", "タグ2", "タグ3"], "filename_hint": "ファイル名に使う日本語の短い説明", "plain_summary": "この記録で何をどこに保存するかを日常言葉で1-2行（専門用語を使わず・ユーザーが『何をされるか』を1読で理解できる文。フェーズ2の判定結果表示に💡 一言でいうと として必ず掲載）", "reason": "判定理由（1行）", "root_cause": { "category": "code_defect or design_mismatch or requirement_change or external_dependency or operational_error or unknown", "description": "1行の根本原因説明（categoryがunknownの場合は空でもよい）" }, "related_pattern": null }

**出力例1（関連パターンあり）:**
```json
{
  "primary": "01_DECISIONS",
  "project": "claude-code",
  "category": "技術的決定",
  "also_daily": true,
  "guide_needed": false,
  "guide_target": null,
  "cc_guide_page": null,
  "tags": ["claude-code", "cron", "Windows-Desktop"],
  "filename_hint": "Windows-Desktop版cron実行状況確認問題",
  "plain_summary": "Windows側のデスクトップアプリで定期実行の予約が正しく動いているか確認した記録を、判断の経緯フォルダに保存して、日記に1行だけ足します",
  "reason": "Windows Desktop環境固有の技術的問題解決のため",
  "root_cause": {
    "category": "design_mismatch",
    "description": "Windows DesktopとWSL2は別ホームディレクトリを持つ別OSである"
  },
  "related_pattern": {
    "entry": "01_DECISIONS/claude-code/2026-06-30_Windows-Desktop版WSLパス変換フック実装.md",
    "reason": "Windows DesktopとWSL2が別ホームディレクトリを持つことに起因する点で根本原因が共通",
    "common_tags": ["claude-code", "Windows-Desktop"]
  }
}

出力例2（関連パターンなし）:

{
  "primary": "01_DECISIONS",
  "project": "reserve-optimizer",
  "category": "技術的決定",
  "also_daily": true,
  "guide_needed": false,
  "guide_target": null,
  "cc_guide_page": null,
  "tags": ["reserve-optimizer", "CRMService"],
  "filename_hint": "CRMService匿名ID化実装",
  "reason": "プロジェクト固有の機能実装のため",
  "root_cause": {
    "category": "design_mismatch",
    "description": "顧客IDの主キーに電話番号(PII)を使っていた"
  },
  "related_pattern": null
}

出力例3（root_cause不明な単純記録）:

{
  "primary": "01_DECISIONS",
  "project": "claude-code-guide",
  "category": "ノウハウ",
  "also_daily": false,
  "guide_needed": false,
  "guide_target": null,
  "cc_guide_page": null,
  "tags": ["claude-code-guide", "typo"],
  "filename_hint": "READMEのtypo修正",
  "reason": "単純な誤字修正で根本原因の分析対象ではないため",
  "root_cause": {
    "category": "unknown",
    "description": ""
  },
  "related_pattern": null
}

LLMがJSONを返さなかった場合（説明文が混入・エラー等）:

• レスポンスから {...} 部分を正規表現で抽出して再パースを試みる
• それでも失敗した場合は自分（Claude）でデフォルト判定して進み、フェーズ2でユーザーに確認する
• いずれのフォールバックでもrelated_patternは無理に判定せずnull扱いとする

LLMが不正なプロジェクト名を返した場合の照合:

• primary: "01_DECISIONS" のとき、返された project が実在するか確認する:

  ls /home/yn4416/projects/obsidian-ssot/01_DECISIONS/
  

  （Windows: //wsl.localhost/Ubuntu/home/yn4416/projects/obsidian-ssot/01_DECISIONS/）
• 返された project がフォルダ一覧に存在しない場合はフェーズ2で「このプロジェクト名でよいですか？」と確認する
• primary: "10_DAILY" が返った場合は誤判定とみなし 01_DECISIONS にフォールバックして再判定する

フェーズ2: 判定結果の確認

⚡ 確認ゲート省略特例（低リスク記録・2026-08-12 追記）: 記録先が以下の低リスク場所の場合、フェーズ2のユーザー確認（[yes/修正指示]）を省略し、判定結果を表示したのち即フェーズ3へ進んでよい（記録後、完了報告でユーザーが把握・修正指示があれば後から巻き戻し）:

• 00_SYSTEM/参考資料/LLMサボりバイアス実例/（LLMサボりバイアス実例集・間違えても実例集が汚れるだけで本線影響ゼロ・記録ハードルを下げて実例蓄積を促す）

ただし判定結果の表示自体は行う（省略するのは確認待ちのみ）。該当しない場所（01_DECISIONS 等・本線影響ある記録）は従来通り確認ゲート必須。

LLMの判定結果をユーザーに以下の形式で一画面で提示する。ガイド転記がある場合は追記先と概要もここに含め、別途「転記案を見せますか？」は聞かない:

ガイド転記の種類:

• 📖 ガイド転記 — ssot-guide / claude-code-guide（他プロジェクト参照用）
• 📖 CCガイド追記 — 00_SYSTEM/Claude-Codeガイド/（Claude Code機能の一覧と使い方）

📋 記録先の判定結果

📁 メイン: 01_DECISIONS/claude-code/2026-05-31_スクリプト修正.md
📅 日記追記: あり（10_DAILY/2026-05-31.md）  ← also_daily が false なら「なし」と表示
📖 ガイド転記: なし                           ← guide_needed: false の場合
🏷️ タグ: #claude-code #バグ修正 #スクリプト
💬 理由: 技術的バグ修正のため01_DECISIONSが最適
💡 一言でいうと: <フェーズ1のplain_summaryをそのまま掲載。専門用語禁止・「今から何を保存して何が起こるか」を日常言葉で>

この振り分けでよいですか？[yes/修正指示]

ガイド転記ありの場合（guide_needed: true）は以下の形式:

📋 記録先の判定結果

📁 メイン: 01_DECISIONS/ssot-guide/2026-05-31_テスト構成.md
📅 日記追記: あり（10_DAILY/2026-05-31.md）
📖 ガイド転記: あり → ssot-guide「09_ガイドサイト構築.md」
   └ 追記内容: test_convert.py の書き方・9クラス構成・テスト保護パターン
🏷️ タグ: #テスト #品質管理
💬 理由: 再利用できるテスト設計のノウハウのため
💡 一言でいうと: <plain_summary>

この振り分けでよいですか？[yes/修正指示]

• 📖 ガイド転記 の行に「追記先ファイル名」と「何を書くかの1行概要」を必ず記載する
• 💡 一言でいうと 行は全パターン（プロジェクトdocs更新あり・ハブ更新あり・CCガイド追記あり含む）で必須（2026-08-18追加・CLAUDE.md平易解説ルール・「判定結果を見たが何をされるか分からないままyes押下」を構造的に防止）。plain_summaryはフェーズ1のJSON出力からそのまま使う
• 「転記内容の詳細を先に見せますか？」は聞かない — yes承認後に直接書く
• ユーザーが承認したら次のフェーズへ。修正指示があれば反映してから再確認。

関連パターン検知ありの場合（related_patternが非nullの場合）:

全パターン（基本/ガイド転記あり/プロジェクトドキュメント更新あり/CCガイド追記あり）の末尾に、以下のブロックを追加する:

🔗 関連パターン検知（過去7日 + 直近5件・横断）
「<related_pattern.entry>」と根本原因が共通する可能性があります
（理由: <related_pattern.reason>・共通タグ: #<common_tags[0]> #<common_tags[1]>）
構造的な文書への追記も検討しますか？[y/N]

• yの場合: 「この洞察はどこに書くのが適切だと思いますか？（既存ドキュメント名 or『なし』）」とユーザーに一言確認し、回答をフェーズ3のファイル作成・更新タスクに追加タスクとして組み込む
• Nの場合: 何もせずフェーズ3へ進む
• このブロックは「この振り分けでよいですか？」の確認とは独立した別の確認事項として扱う（同じ[yes/修正指示]の応答に混ぜず、関連パターンのy/Nは別途聞く）
• 非対話実行時のフォールバック: 自律ループ等の自動実行コンテキストからssot-recordが呼ばれ、ユーザーの応答を待てない場合は、構造的文書への追記は行わずデフォルトでN相当として扱う。この場合もrelated_pattern自体はTask4のrelated_entriesとしてfrontmatterには記録する（検知結果そのものは失わない）
• 追記時のガードレール: yの流れで既存の構造的文書（例: 01_基礎概念.md等）に追記する場合、末尾への追加のみとし、既存の見出し・本文・他のセクションは一切編集・削除しない。対象ファイルの構造を壊さないことを最優先する

プロジェクトドキュメント更新対象ありの場合（フェーズ0.5で検出された場合）:

全パターンの末尾に 📦 プロジェクトドキュメント更新対象 ブロックを追加する:

📋 記録先の判定結果

📁 メイン: 01_DECISIONS/atelier-kyo-manager/2026-06-07_セール価格スクレイパー実装.md
📅 日記追記: あり（10_DAILY/2026-06-07.md）
📖 ガイド転記: なし
🏷️ タグ: #atelier-kyo-manager #スクレイピング #セール価格
💬 理由: プロジェクト固有の機能実装のため01_DECISIONSが最適

📦 プロジェクトドキュメント更新対象（3ファイル）:
   ✅ docs/変更履歴.md             — 末尾にエントリ追加
   ✅ docs/経営者判断.md           — セクション5に追記
   ✅ docs/プロダクトビジョン.md   — 既存資産テーブルに1行追加

この振り分け・更新対象でよいですか？[yes/修正指示]

• フェーズ0.5で検出されたファイルが 0件 の場合は 📦 プロジェクトドキュメント更新対象: なし と表示
• ユーザー承認でSSOT記録 + プロジェクトドキュメント更新を一括実行

00_SYSTEMハブ更新対象ありの場合（フェーズ0.5で検出された場合）:

プロジェクトdocsブロックと同様に、全パターンの末尾に 🗂️ 00_SYSTEMハブ更新対象 ブロックを追加する:

📋 記録先の判定結果

📁 メイン: 01_DECISIONS/claude-code/YYYY-MM-DD_<内容>.md
📅 日記追記: あり
📖 ガイド転記: なし
🏷️ タグ: #claude-code #セキュリティ #hook

🗂️ 00_SYSTEMハブ更新対象（ハブマッピング・2件）:
   ✅ セキュリティ設定ハブ.md  — 層テーブル行追加 [必須]
   ✅ MCPツール使い分けガイド.md — 構成テーブル行追加 [必須]

この振り分け・更新対象でよいですか？[yes/修正指示]

• フェーズ0.5で検出されたファイルが 0件 の場合は 🗂️ 00_SYSTEMハブ更新対象: なし と表示
• 必須: yes 承認で自動追記（LLMが既存フォーマットで行生成・フェーズ3-8で実行）
• 任意: フェーズ2で「追記するか [y/N]」・Default N（任意のみ検出時は確認ゲート追加）

CCガイド追記ありの場合（cc_guide_page が null でない場合）:

📋 記録先の判定結果

📁 メイン: 01_DECISIONS/claude-code/2026-06-03_teian軽量提案スキル実装.md
📅 日記追記: あり（10_DAILY/2026-06-03.md）
📖 ガイド転記: なし
📖 CCガイド追記: あり → 00_SYSTEM/Claude-Codeガイド/03_スキルシステム.md
   └ テーブル行: `teian` — 軽量提案スキル...
   └ 使い方セクション: ### `teian` — 軽量提案...
🏷️ タグ: #claude-code #スキル設計
💬 理由: スキル登録のため03_スキルシステムに追記

この振り分けでよいですか？[yes/修正指示]

フェーズ3: ファイル作成・更新

先頭作業（必須）: 本フェーズ開始時にフラグを作成すること。PreToolUse hook(enforce-ssot-record.sh)がこのフラグで「スキル経由」を判定し 01_DECISIONS/ Write を許可する。フラグなしだと手動Write扱いでブロックされる。

mkdir -p ~/.claude/state
touch ~/.claude/state/ssot-record-active-${CLAUDE_CODE_SESSION_ID}

※ 2026-07-08 改修: フラグは ~/.claude/state/（永続領域・セッションID別）に作成。旧 /tmp/ssot-record-active は sandbox で Bash 呼出間に消滅し機能不全だった。セッションID分離で並行セッションの誤許可（他セッションのフラグで通る）も防止。SESSION_ID 未取得時は hook 側が glob フォールバックで許可。 ※ フェーズ6完了後（または異常終了時）に必ず削除（残存すると手動Writeも通ってしまう）。

3-1. メイン記録ファイルの作成

振り分け先に応じてファイルを作成する:

01_DECISIONS の場合 (/home/yn4416/projects/obsidian-ssot/01_DECISIONS/<project>/YYYY-MM-DD_<内容>.md):

---
project: <project>
date: YYYY-MM-DD
tags: [tag1, tag2, tag3]
tech_tags: [解決課題の抽象化キーワード1, キーワード2]  # 技術実装を含む場合のみ・後述
root_cause:
  category: <フェーズ1のroot_cause.category>
  description: <フェーズ1のroot_cause.description>
related_entries:
  - <related_pattern.entry>
---

# 📖 <タイトル> — 議論の経緯
> 📅 YYYY-MM-DD · 🏷️ tags · 🔗 関連: <spec / 01_DECISIONS>

## 🎯 TL;DR（3行）
- <結論1: 何をどう決めたか>
- <結論2>
- <結論3>

## 🗺️ 全体像（図1枚・ASCII/emoji）              【推奨・フル】
<コンセプト図>

## 🌧️ きっかけ（1段落）                         【任意・フル】
<なぜ議論始めたか>

## 🤔 検討した選択肢（縦リスト・最低2案）        【推奨・フル】
- **案A**: メリット〜 / デメリット〜
- **案B**: メリット〜 / デメリット〜

## ✅ 決定と理由
**<X案>採用**。理由: <〜>
却下: <A案(〜)・B案(〜)>

## 📋 残課題・次アクション・再検討条件            【任意・フル】
- 残: <〜> / 次: <〜> / 再検討: <〜の時>

## コミット
- `<hash>` <説明>  ← あれば

<details><summary>📦 詳細経緯（5行超の時だけ）</summary>  【任意】

<深掘り・エッジケース・検証データ>

</details>

## 🔗 関連
- <spec / 01_DECISIONS / バックログ>

判断の重さで構成を切替（YAGNI・3段階でコストと視認性を両立・2026-07-06 拡張）:

• L1（超軽い・typo/1行修正/設定値変更）: TL;DR + 決定と理由 + 関連 の3セク + TL;DR内にemoji1行ビジュアル（例: 🔄 設定値: 5 → 10・✅ XX機能追加）
• L2（中間・小機能追加/リファクタリング/設定変更+影響あり）: TL;DR + きっかけ + 検討した選択肢 + 決定と理由 + 関連 の5セク + 簡易ASCII図1枚（before/after・矢印・関係図）
• L3（設計判断・複数案比較/アーキテクチャ決定）: 全8セクション + フル図（全体像・比較表・詳細）

本文フォーマットの正典（区分/スマホ最適化/図の使い分け）は 00_SYSTEM/共通ルール/記録手順.md 参照

root_causeのcategoryは以下から選ぶ: code_defect（コード上の不具合） / design_mismatch（設計・前提のズレ） / requirement_change（要件変更） / external_dependency（外部要因） / operational_error（運用ミス） / unknown（不明）。フェーズ1のJSON出力をそのまま転記する。

related_entriesはrelated_patternが非nullだった場合のみ追加し、nullの場合はフィールド自体を省略する。

tech_tagsの付与ルール（2026-08-18追加・既存資産の横断発見可能性を担保）:

記録内容が技術的な実装・解決策を含む場合、tech_tagsに解決した課題の抽象化キーワードを2〜5個付与する（技術名だけでなく課題名で検索してヒットさせるため）。

• ✅ 正しい例: tech_tags: [bot対策, スクレイピング, TLS偽装, Cloudflare回避, HTTP取得]（curl_cffiの実装記録）
• ❌ 誤った例: tech_tags: [curl_cffi]（技術名のみ→「bot対策したい」で検索してもヒットしない）
• 判断基準: 「他のプロジェクトで同じ課題に直面した時、どんな語彙で検索するか？」を自問して、その語彙を並べる
• 記録内容が技術的実装を含まない（会議・方針・手順等）場合はtech_tagsフィールド自体を省略してよい

3-1-α: 逆リンク追記チェック（同テーマ過去記録への今回リンク・2026-08-11 追記）

今回の新規記録ファイルを作成したら、同テーマの過去記録（tags重複 or フェーズ0.8の候補リスト）の ## 🔗 関連 セクション末尾に、今回の新規ファイルへのリンクを1行追記する。

• 目的: 知見の分断防止。過去記録側から「今回どうなったか」へ辿れる両方向リンクにする。
• 2026-08-11 Zernio MCP 知見分断RCAの教訓: 新記録が過去記録へリンクしていても、過去記録側から新記録へリンクがないと、後で過去記録から辿った時に最新の訂正・知見に辿り着けない。
• 対象: tags が2つ以上重複する過去記録（フェーズ0.8候補リストを再利用）。多すぎる場合は上位3件まで。
• 追記形式: - [YYYY-MM-DD_<今回ファイル名>](YYYY-MM-DD_<今回ファイル名>.md) — <1行説明> を過去記録の ## 🔗 関連 末尾に追加。
• ※ 新規フェーズ増やさず 3-1 のサブステップ（memory: ssot-record-no-phase-skip 順守）。

00_SYSTEM の場合 (/home/yn4416/projects/obsidian-ssot/00_SYSTEM/<適切なサブフォルダ or 直下>/<ファイル名>.md): まず ls /home/yn4416/projects/obsidian-ssot/00_SYSTEM/ でフォルダ構成を確認してから配置する。 設定変更の場合は既存ファイルへの追記を優先する（自動化.md や MCPツール使い分けガイド.md 等）。

---
updated: YYYY-MM-DD
tags: [tag1, tag2]
---

# <設定変更タイトル>

## 変更内容
<何を・どこで・どのように変更したか>

## 理由
<なぜ変更したか>

## 関連ファイル
- <設定ファイルパス>

30_RESEARCH の場合 (/home/yn4416/projects/obsidian-ssot/30_RESEARCH/<分野>/<ファイル名>.md): ls /home/yn4416/projects/obsidian-ssot/30_RESEARCH/ で既存の分野フォルダを確認してから配置する。

---
updated: YYYY-MM-DD
source: <調査元URL（あれば）>
tags: [tag1, tag2]
---

# <調査テーマ>

<調査内容>

40_CAREER の場合 (/home/yn4416/projects/obsidian-ssot/40_CAREER/<適切なサブフォルダ>/<ファイル名>.md): ls /home/yn4416/projects/obsidian-ssot/40_CAREER/ でフォルダ構成を確認してから適切な場所に配置する。

20_PUBLISHING の場合 (/home/yn4416/projects/obsidian-ssot/20_PUBLISHING/<フォルダ>/): 作成後に 20_PUBLISHING/_INDEX.md のステータスを更新する。

3-2. _INDEX.md への追記

01_DECISIONS/<project>/_INDEX.md の扱い:

• 存在する場合: ファイル内の最後のテーブルの末尾行に1行追記する
• 存在しない場合: スキップ（_INDEX.md を新規作成しない）
• 複数テーブルがある場合は必ずファイル末尾のテーブルに追記する（セクション冒頭のテーブルに誤追記しない）

追記フォーマット（【要更新】マーカーは絶対に使わない）:

| [YYYY-MM-DD_<ファイル名>](YYYY-MM-DD_<ファイル名>.md) | <1行説明> | <状況・参照タイミング> |

3-3. 10_DAILY への追記

also_daily: true の場合のみ追記する。false の場合は何もしない。

追記先: /home/yn4416/projects/obsidian-ssot/10_DAILY/YYYY-MM-DD.md

• ファイルが存在する場合: 末尾に追記する。ただし末尾に セッション終了: HH:MM 行がある場合はその前（--- の前）に挿入する
• ファイルが存在しない場合: 以下のヘッダーで新規作成してから追記

  # YYYY-MM-DD
  
  ---
  

追記フォーマット:

## セッションログ (HH:MM)
- <作業サマリー 3〜5行>
- 詳細: 01_DECISIONS/<project>/YYYY-MM-DD_<ファイル名>.md
- 未解決: <あれば>  ← なければ省略

日記には詳細を直書きしない（サマリー + リンクのみ）。

3-4. 自動化タグ時の 自動化.md 更新

tags に「自動化」が含まれる場合のみ実行する。

更新先: /home/yn4416/projects/obsidian-ssot/00_SYSTEM/自動化.md

以下の該当箇所を確認し、必要に応じて追記する:

1. Hook追加・変更時: 「SessionStart / PostToolUse / PreToolUse / Stop / Notification」の該当テーブルに1行追加
2. Cron追加・変更時: 「Cron」テーブルに1行追加
3. スクリプト追加時: 「スクリプト一覧」の該当セクションに1行追加
4. 変更履歴: テーブル末尾に | YYYY-MM-DD | <概要> | <理由> | を追加

追記フォーマットは既存行に合わせる。該当なし（自動化に関係ない内容）の場合はスキップ。

3-5. Claude Code関連の記録時 → CCガイドにも自動追記

記録内容がClaude Code関連の場合（project が claude-code、またはtagsに Claude-Code が含まれる場合）、以下のCCガイドにも追記する。

対象ガイド: /home/yn4416/projects/obsidian-ssot/00_SYSTEM/Claude-Codeガイド/

追記先の判定

実行手順

1. CCガイドの該当ファイルをReadして既存フォーマットを確認
2. 内容に応じた追記先（上表）に1行〜数行を追加
3. 既存行のフォーマットに統一すること
4. 早見表と用語集の両方に反映すべき場合は両方に追記する

判定基準

• 常に追記: 新しい用語・機能・コマンドが登場した場合
• スキップ: 単なるバグ修正・既存機能の微調整・プロジェクト固有の作業
• 目安: 「将来のセッションでこの情報を引く可能性があるか？」→ Yes なら追記

3-6. プロジェクトドキュメント更新（フェーズ0.5で検出された場合のみ）

フェーズ0.5で検出されたプロジェクト側ドキュメントを更新する。

更新手順

1. 設定ファイル参照: obsidian-ssot/00_SYSTEM/タグマッピング.md の「更新の種類 詳細」に従う
2. 各ファイルの更新: 検出されたファイルごとに Read → 既存パターン確認 → Edit/Write で更新

更新の種類別の実装

末尾エントリ追加 — docs/変更履歴.md 等:

• ファイルをReadして最新エントリのフォーマットを確認
• 同じフォーマットで新しいエントリをファイル冒頭に追加
• フォーマット: ## YYYY-MM-DD\n\n### タイトル\n- 変更ファイルと内容

セクション追記 — docs/経営者判断.md 等:

• ファイルをReadして該当セクションの末尾を特定
• セクション末尾に内容を追記 + 最終更新日時を更新

テーブル行追加 — docs/プロダクトビジョン.md _INDEX.md 等:

• ファイルをReadして該当テーブルの末尾行を確認
• 同じフォーマットで1行追加

ステータス更新 — docs/scraping-status.md 等:

• ファイルをReadして該当行を特定
• 該当セルを更新

3-7. active-sessions ボードの自分エントリ更新（共通ファイルを触った場合）

今回の記録で共通ファイル（9種: settings.json/CLAUDE.md/SKILL.md群/hook群/自動化.md/全体マップ_MOC.md/repo-index.yaml・リポジトリ索引.md/MCPツール使い分けガイド.md/リンク運用方針.md）を触った場合、自分のボードエントリを更新する。

手順:

1. obsidian-ssot/00_SYSTEM/active-sessions.md を読み、自分のセッション(環境+トピック)のエントリを特定
   • エントリが無い場合（resume-sessionで追加し忘れた等）: 先頭行に追加（セッション/触る共通ファイル/方針/開始/🟢進行）
2. 「触る共通ファイル」欄に今回触ったファイルを追記（既存なら重複回避）
3. 即commit+push（フェーズ5のcommitとは別に、ボードは時間感度高め）:

   cd ~/projects/obsidian-ssot && git add 00_SYSTEM/active-sessions.md && git commit -m "chore: active-sessions 更新(<セッション名>: <触ったファイル>)" && git push
   

注意: 共通ファイルを触る前にボードで被り確認（逆方向ならユーザー判断）。本ステップは事後の宣言更新。

paths.json 同期（層2b・2026-08-11・spec §2.1/§4.4）: 共通ファイルを触った場合、active-sessions.md の更新と同時に ~/.claude/state/active-sessions-paths.json の自セッションWT4エントリに触ったファイルpathを追記する（auto-sync が宣言除外参照・post-push監査層 audit-auto-sync-commits.py もこのpathで🟢宣言を把握）。🟢行とpaths.jsonは常に同期（片方だけだと監査が誤検出になる）。

# WT4取得（resume-session Step1と同一・2026-07-30フォールバック）
WT_SESSION="${WT_SESSION:-unknown}"; SESSION_ID="${CLAUDE_CODE_SESSION_ID:-unknown}"
EFFECTIVE_WT="$WT_SESSION"; [ "$WT_SESSION" = "unknown" ] && EFFECTIVE_WT="$SESSION_ID"
WT4=${EFFECTIVE_WT:0:4}
# paths.json の自WT4エントリに触ったファイルを追加（既存保持・重複回避・git pathspec互換）
python3 -c "
import json
p='$HOME/.claude/state/active-sessions-paths.json'
d=json.load(open(p))
paths=d.setdefault('entries',{}).setdefault('$WT4',[])
for f in ['<触ったファイル実パス>']:  # 文脈から特定・obsidian-ssot repo相対
    if f not in paths: paths.append(f)
json.dump(d,open(p,'w'),indent=2,ensure_ascii=False)
"

3-8. 00_SYSTEM ハブ更新（ハブマッピング.md検出時・フェーズ0.5）

フェーズ0.5の ハブマッピング.md 検出結果に従い、00_SYSTEMの該当ハブへ追記。 ε役割分担: 3-4（自動化.md専用）/ 3-5（CCガイド専用）/ 3-8（その他00_SYSTEMハブ）。

実行手順

1. 検出リスト確認: フェーズ0.5で検出された 00_SYSTEMハブ（セキュリティ設定ハブ・MCPガイド・リポジトリ索引・リンク運用方針・全体マップ_MOC 等）
2. 重要度判定:
   • 必須: フェーズ2で承認済みなら自動追記
   • 任意: フェーズ2で「追記するか[y/N]」が y の場合のみ
3. 各ハブを更新: Read → 既存フォーマット確認 → Edit/Write で追記（テーブル行追加/セクション追記）
4. ε重複回避: 自動化.mdは3-4・CCガイドは3-5が担当・3-8はそれ以外（ハブマッピング.mdの「自動化/Claude-Code」タグ行は3-4/3-5へ誘導）

判定基準

• ハブマッピング.md の「追記セクション」列に従い、LLMが既存フォーマットで行内容を生成
• 既存行のフォーマットに統一すること
• 更新対象ハブが 00_SYSTEM 配下に存在しない場合はスキップ（ls で確認）

フェーズ3.5: バックログ完了チェック（タスク完了記録の確実化）

設計意図: 「あ、(別セッションで)終わってました」現象の構造的根絶。 生きタスクの正典は 00_SYSTEM/バックログ.md 唯一（[ ]=未完了 / [x]=完了）。 本フェーズで「完了したのに [x] 忘れ」を記録フロー内で確実に回収する。

実行条件

記録内容が「タスクの完了」を含む場合のみ実行する（機能実装完了・バグ修正完了・作業クローズ等）。

• 途中メモ・調査記録・設計途中・単なる設定追記 等、完了を伴わない記録はスキップ（フェーズ4へ）。

手順

1. バックログ [ ] 一覧を取得:

   grep -n '^- \[ \]' ~/projects/obsidian-ssot/00_SYSTEM/バックログ.md
   

2. LLM照合: 記録内容（フェーズ0で収集した内容）と [ ] 一覧を照合し、今回完了した可能性のある行を上位1〜3候補として抽出する。タスク名の類似度・プロジェクト一致・日付の近さを総合。

   表現ゆれ対策（2026-07-05実証）: バックログ行の抽象語（「恒久対応」「根本対応」等）と記録内容の具体語（「運用リトリア」「スキル組込」等）が表現ゆれを起こし、照合漏れが発生した事例あり（Gemini空応答恒久対応 vs multi-llm-review空応答対策組込）。対象ファイル名・関数名・プロジェクト名等の「実体キーワード」でも照合すること。タスク名の字面一致だけに頼らない。

3. 候補提示と承認ゲート:

   ✅ バックログ完了チェック
   今回の記録「<記録サマリー>」に対応するバックログ候補:
     1. [ ] <候補1のタスク名>（P0/P1/P2）
     2. [ ] <候補2> ...
   どれを [x]（完了）にしますか？[番号 / 違う / なし]
   

   • 承認: 指定された行を [x] 化（必要なら完了日付を追記）
   • 「違う」: 手動で行番号を指定させる（フォールバック）
   • 「なし」: バックログに該当タスクなし → 「バックログ未登録タスクです。追加しますか？[y/N]」（y なら [x] 済みとして該当P区分に新規追加）

4. 該当なし（候補0件）: ステップ3の「なし」と同様に「バックログ未登録タスク。追加しますか？」を確認。

安全設計

• LLM提案＋ユーザー承認のハイブリッド: 誤判定は提示段階で人が修正可能なため安全。LLM単独で [x] 化しない。
• 既に [x] の行には触れない。
• 完了日付は既存行の慣習（（M/D完了） 等）に合わせる。

フェーズ3.6: 未解決→バックログ追加確認（タスク迷子防止）

設計意図: 01_DECISIONS の「未解決」セクションに書かれた残タスクがバックログ（生きタスクの正典）に登録されず埋もれるのを防ぐ（2026-07-05 導入・portfolio/guides掲載差整理タスクの手動漏れが契機）。 完全自動でなく確認ゲート付き（ノイズ膨張防止・人間がタスク化判断）。

実行条件

記録した 01_DECISIONS ファイルの「## 未解決」セクションに残タスクがある場合のみ実行（空・「なし」・セクション自体ない場合はスキップ）。

手順

1. 「未解決」セクションの内容を抽出: 記録した 01_DECISIONS ファイルの「## 未解決」以下の行を取得

2. バックログ重複チェック: 既存の [ ] 行と内容が被らないか確認（被れば追加不要）

3. 確認ゲート:

   📝 未解決→バックログ追加チェック
   今回の記録の未解決:
     1. <未解決1>
     2. <未解決2>
   バックログ（生きタスク正典）に追加するものを選択 [番号 / すべて / なし]
   

4. 承認: 指定されたものをバックログの該当 P 区分（P0/P1/P2）に [ ] 行で追加。P 区分は内容から推断（即効性高=P0・近いうち=P1・いつか=P2）

5. 「なし」: 追加せず（一時的/memo的・次セッションで自然解決想定と判断）

安全設計

• 確認ゲート付き半自動: 完全自动でなく人間がタスク化を判断（バックログ肥大化・ノイズ防止）
• 重複回避: 既存 [ ] 行と被れば追加しない
• 01_DECISIONS 未解決は残す: バックログ追加後も 01_DECISIONS の未解決セクションは削除せず（01_DECISIONS=経緯記録・バックログ=生きタスク正典で役割違い・バックログが真実のソース）

フェーズ4: ガイド転記（guide_needed: true かつユーザー承認済みの場合のみ）

フェーズ2でユーザーが承認した時点で転記も承認済みとみなす。追加確認は不要。

4-0. CCガイド追記（cc_guide_page が null でない場合）

cc_guide_page が null でない場合、SSOT内のCCガイドに追記する。

対象:

• SSOT内部（マスター）: /home/yn4416/projects/obsidian-ssot/00_SYSTEM/Claude-Codeガイド/<cc_guide_page>
• 公開版（派生物）: /home/yn4416/projects/claude-code-guide/source/<cc_guide_page> — update-guideが同期

スキルの場合（cc_guide_page: "03_スキルシステム.md"）

1. ファイルをReadして「カスタムスキル」テーブルの末尾を確認
2. テーブル末尾に1行追加:

   | `teian` | 軽量提案スキル。2〜3の選択肢＋メリット/デメリット＋推奨案をさっと提示。複雑な場合はbrainstormingへ誘導 | 「提案して」「どう思う」「教えて」「アドバイス」 |
   

3. 「主要スキルの使い方」セクションの末尾に cc_guide_entry.usage_section を追記

MCPの場合（cc_guide_page: "04_MCPサーバー.md"）

1. ファイルをReadして「現在の構成」テーブルの末尾を確認
2. テーブル行を追加（既存行のフォーマットに合わせる）
3. サーバー説明セクションを追加（既存のフォーマットに従う）

フックの場合（cc_guide_page: "05_フック.md"）

1. ファイルをReadして該当フック種別のテーブル末尾を確認
2. テーブル行を追加（既存行のフォーマットに合わせる）

メモリ/エージェント/設定の場合（cc_guide_page: "06〜08"）

1. ファイルをReadして該当セクションを確認
2. 設定変更内容を追記（既存フォーマットに合わせる）

共通ルール

• 追記前に必ず既存行をReadしてフォーマットを統一する
• cc_guide_entry の内容を使ってテーブル行と使い方セクションを生成
• 完了後、update-guideスキルを呼び出して公開版に同期

4-1. 追記先の特定

# guide_target に応じてsource/を確認（WSL CLI の場合）
ls /home/yn4416/projects/claude-code-guide/source/
ls /home/yn4416/projects/ssot-guide/source/

# Windows Desktop Claude Code の場合（UNCパス）
ls //wsl.localhost/Ubuntu/home/yn4416/projects/claude-code-guide/source/
ls //wsl.localhost/Ubuntu/home/yn4416/projects/ssot-guide/source/

フェーズ2で提示した追記先ファイルに直接書く。

4-2. 追記・ビルド・push

1. source/XX_<章名>.md に内容を追記（Markdownで書く）
2. テスト実行: python3 -m pytest test_convert.py -q
3. ビルド: python3 convert.py
4. ガイドリポジトリで git add -A && git commit -m "docs: ..." && git push

ssot-guide の場合も手順は同じ（パスが ~/projects/ssot-guide/）。
claude-code-guide の場合は update-guide スキルを呼び出してもよい。

フェーズ5: git commit & push

5-1. SSOT（必須）

cd /home/yn4416/projects/obsidian-ssot
git add -A
git commit -m "record: <内容の1行説明>"
git push

5-2. プロジェクトリポジトリ（フェーズ3-6で更新があった場合のみ）

フェーズ0.5で検出されたプロジェクトのリポジトリもコミット・pushする。

cd /home/yn4416/projects/<project>
git add -A
git commit -m "docs: <内容の1行説明>"
git push

5-3. ガイドリポジトリ（フェーズ4で更新があった場合のみ）

ガイドを更新した場合は別途ガイドリポジトリもコミット（フェーズ4で実施済みの場合はスキップ）。

フェーズ6: 完了報告

完了報告のコードブロックの後に、素人にもわかる一言（💡一言でいうと）を必ず併記する（何をしたか・次に何が起きるかを日常言葉で1-2行・CLAUDE.md平易解説ルール）。

✅ SSOT記録完了

📁 01_DECISIONS/claude-code/2026-05-31_<ファイル名>.md
📅 10_DAILY/2026-05-31.md（追記）  ← also_daily: false の場合は「日記追記: なし」
📦 プロジェクトdocs: docs/変更履歴.md 等（更新あり/なし）  ← フェーズ3-6で更新した場合
🏷️ タグ: #claude-code #バグ修正
📖 ガイド転記: なし（または「あり → <章名>」）
🔗 関連パターン追記: なし（または「あり → <追記先ファイル名>」）  ← related_patternが非nullで`y`回答だった場合のみ表示。null または `N` の場合は「なし」
🔗 コミット: <hash>

セッションカウンタへの記録（表示なし・裏側の処理）

完了報告を出力した直後、以下を実行してセッション内の記録回数を記録する:

mkdir -p ~/.claude/state
# カウンタファイル名決定（セッションID分離・未設定時フォールバック・2026-07-06 改修）
SESSION_ID="${CLAUDE_CODE_SESSION_ID:-}"
if [ -n "$SESSION_ID" ]; then
  COUNTER_FILE="$HOME/.claude/state/ssot-record-session-count-${SESSION_ID}.txt"
else
  COUNTER_FILE="$HOME/.claude/state/ssot-record-session-count.txt"
fi
echo "$(date +%Y-%m-%dT%H:%M:%S) <filename_hint>" >> "$COUNTER_FILE"

フラグ解除（必須・記録完了直後に必ず実行）

rm -f ~/.claude/state/ssot-record-active-${CLAUDE_CODE_SESSION_ID}

残存禁止: フラグが残っていると、スキル外の手動Write もPreToolUse hookを通過してしまう（二重防御が機能不全）。フェーズ6完了報告の直後・または異常終了時（エラー発生時も）に必ず削除する。

<filename_hint> はフェーズ1のJSON出力で得た filename_hint の値（751行目の完了報告に使ったファイル名と同じ値）に置き換える。このファイルはフェーズ7.5（セッション横断総括の発火判定）で使用する。ユーザーへの表示・確認は不要。

フェーズ7: セッション終了確認（オプション）

フェーズ6の完了報告の直後に、ユーザーへセッション終了可否を1回だけ確認する。Default は No（記録して作業継続）。

🔁 このままセッションを終了して新セッションへ引き継ぎますか？[y/N]

• N（デフォルト）: 何もしない。記録だけ完了・同一セッションで作業継続
• y: フェーズ7.5（セッション横断総括の自動判定）を実行してから new-session スキルを呼び出す

設計意図（統合ではなく確認ステップにした理由）

• ssot-record（タスク毎・高頻度）と new-session（セッション区切り・低頻度）は粒度が違う。自動統合すると全タスク切り替えでセッションが切れる事故になる
• だから確認ステップのみ。ユーザーが「この記録でセッション終わり」と判断した時だけ new-session に繋ぐ
• 確認は1回・Default No・自動終了しない（N でも記録は残る）

注意

• new-session 呼び出し後は本スキルの役割終了。引き継ぎ処理は new-session 側で完結する
• 共通ファイルを触った場合のボード✅終了処理は、y で new-session を呼ぶとそちらで実施される（二重処理に注意）

フェーズ7.5: セッション横断総括（フェーズ7で y の場合のみ）

設計意図: 1トピック=1ファイルの個別記録だけでは、複数トピックを跨ぐセッションの「なぜ始まり・どう発展し・何ができたか」という横断的な文脈が失われる。セッション終了時（フェーズ7 y）のタイミングで、条件を満たす場合のみ自動的に補完する。

発火判定

# カウンタファイル名決定（セッションID分離・未設定時フォールバック・2026-07-06 改修）
SESSION_ID="${CLAUDE_CODE_SESSION_ID:-}"
if [ -n "$SESSION_ID" ]; then
  COUNTER_FILE="$HOME/.claude/state/ssot-record-session-count-${SESSION_ID}.txt"
else
  COUNTER_FILE="$HOME/.claude/state/ssot-record-session-count.txt"
fi
wc -l < "$COUNTER_FILE" 2>/dev/null || echo 0

• 行数が2以上: 以降のStep 1〜4を実行する
• 行数が0または1（ファイルが存在しない場合を含む）: フェーズ7.5をスキップし、そのまま new-session を呼び出す（このセクションの残りは実行しない）

会話の文脈だけでカウントしない（PreCompactでの圧縮により過去の完了報告が失われる可能性があるため、実ファイルの行数のみを判定根拠とする）。

Step 1: カウンタファイルの内容を確認

# カウンタファイル名決定（セッションID分離・未設定時フォールバック・2026-07-06 改修）
SESSION_ID="${CLAUDE_CODE_SESSION_ID:-}"
if [ -n "$SESSION_ID" ]; then
  COUNTER_FILE="$HOME/.claude/state/ssot-record-session-count-${SESSION_ID}.txt"
else
  COUNTER_FILE="$HOME/.claude/state/ssot-record-session-count.txt"
fi
cat "$COUNTER_FILE"

各行の filename_hint から、今セッションで記録した各 01_DECISIONS ファイルを特定する（該当日の 01_DECISIONS/<project>/YYYY-MM-DD_<filename_hint相当>.md をlsで確認、または会話文脈と突き合わせる）。

Step 2: 横断総括の下書きを生成

以下の固定テンプレートで下書きを作成する（ファイルにはまだ書き込まない、内容をメモリ上に保持するのみ）:

---
project: claude-code
date: YYYY-MM-DD
tags: [claude-code, セッション総括, <セッション内容に応じた追加タグ>]
---

# <セッションタイトル>

## 発端
（何がきっかけでこのセッションが始まったか。1〜3行）

## 気づき（転換点）（任意セクション）
（該当する気づきが実在する場合のみこのセクションを含める。無理に埋めない。
 該当なしの場合はこのセクション自体を書かない）

## 実施したトラック
| # | 内容 | 状態 | 詳細記録 |
|---|---|---|---|
| A | <内容> | <状態> | `01_DECISIONS/<project>/YYYY-MM-DD_<ファイル名>.md` |

状態は `✅完了・push済み` / `🔄継続中（次セッションへ引き継ぎ）` / `⏸保留` / `❌ボツ（理由: ...）` のいずれかを、各トピックの実態に応じて使い分ける。

## 00_SYSTEM反映状況
（CCガイド等00_SYSTEM側への反映があった場合のみ含める。無ければセクション自体省略）

## 未解決・次のタスク
（残タスクがあれば。無ければ「なし」）

ファイル名は 01_DECISIONS/claude-code/YYYY-MM-DD_<セッション内容を表す短い説明>.md とする（配置先は常に claude-code 固定。プロジェクト横断セッションでも同様）。

Step 3: 確認ステップ（1回のみ）

下書きのファイル名・タイトル・トラック件数のみを以下の形式で提示する:

📚 セッション横断総括の下書きができました
ファイル: 01_DECISIONS/claude-code/YYYY-MM-DD_<タイトル>.md
トラック数: N件（A, B, C...）
このまま記録してよいですか？[y/修正指示]

• y: Step 4へ進み確定保存
• 修正指示（1回目）: 指示に応じて下書きを修正し、再度同じ確認を1回だけ表示する
• 修正指示（2回目以降）: 3回目・4回目…と何度指示が来ても、以降は確認を挟まず指示をそのまま反映して確定保存する（無限ループ防止。確認が許されるのは最初の1回のみ）

Step 4: 確定保存

1. メインファイル作成: 01_DECISIONS/claude-code/YYYY-MM-DD_<タイトル>.md を下書き内容で作成
2. _INDEX.md追記: 01_DECISIONS/claude-code/_INDEX.md の末尾テーブルに1行追記（既存のssot-record フェーズ3-2と同じ手順）
3. 10_DAILY追記: 10_DAILY/YYYY-MM-DD.md に短い1エントリ追記（サマリー+リンクのみ、既存のフェーズ3-3と同じ手順）
4. commit & push:

   cd ~/projects/obsidian-ssot
   git add -A
   git commit -m "record: セッション横断総括 <タイトル>"
   git push
   

5. 完了報告に以下の1行を追加してから new-session を呼び出す:

   📚 セッション横断総括: 01_DECISIONS/claude-code/YYYY-MM-DD_<タイトル>.md
   

既存フェーズとの関係

• フェーズ0.8（関連パターンチェック）は日をまたぐ過去記録との根本原因照合が対象。本フェーズは同一セッション内のトピック間の関連性が対象で、スコープが異なるため独立実装とする（フェーズ0.8のロジックは流用しない）

制約・禁止事項

• APIキー・シークレットの値は絶対に書かない（キー名はOK）
• 日記に詳細を直書きしない（サマリー + リンクのみ）
• _INDEX.md に【要更新】マーカーを残さない
• ガイド転記はフェーズ2の yes 承認をもって承認済みとみなす（追加確認は不要）
• 1トピック = 1ファイル（複数の無関係な作業は別々のファイルに）
• also_daily: false の時は 10_DAILY に何も書かない
• タグマッピング設定は obsidian-ssot/00_SYSTEM/タグマッピング.md で管理（スキル内にハードコードしない）

このスキルのトリガーワード

以下のいずれかでトリガー（/ssot-record コマンドでも可）:

• 記録して / 書き留めて / 保存して / メモして
• 残しておいて / 忘れないようにして
• SSOTに入れて / SSOTに書いて
• ガイドに追加して / ガイドに書いて / ガイドに入れて
• 書いておいて / 記しておいて

record-decision スキルの上位互換。/record-decision が呼ばれた場合もこのスキルで処理する。