Imported from fukukei23/claude-config (skills/ssot-record/SKILL.md). Install upstream with npx skills add fukukei23/claude-config --skill ssot-record. Copyright stays with the author.

ssot-record スキル

概要

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

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

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

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

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

手順

該当タスクを特定: バックログ.md から会話文脈・ふくけい指示で該当タスク行を探す。未登録なら新規タスク行を追加してから。

📝WIPメモ追記: 該当タスク行の直下にインデントブロックで追記:

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

日記サマリー: 10_DAILY/YYYY-MM-DD.md に1行追記（バックログ更新への言及のみ・技術詳細直書き禁止）。
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ハブファイルのマッピング定義（新設・監査⑩見逃し防止）

検出手順（両表で共通）

設定ファイル読込: タグマッピング.md と ハブマッピング.md をRead
タグ照合: 分類判定で決まった tags と両マッピングテーブルの「必須タグ」を照合
追加タグ照合: マッチした行の「追加タグ」と tags を照合（OR条件）
ファイル存在確認: 更新対象ファイルが存在するか ls で確認
結果をフェーズ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の各行（日付ファイルパス）について、以下を取得する:

各ファイルをReadし、frontmatterのtags・root_cause（あれば）を取得
対応する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と判断した場合のみ）

内容カテゴリ	対象ガイドページ
スキル自作・登録・既存スキルの機能拡張・仕様変更	`03_スキルシステム.md`
MCP追加・設定変更	`04_MCPサーバー.md`
フック追加・変更	`05_フック.md`
メモリ設定変更	`06_メモリ.md`
エージェント設定	`07_エージェント.md`
settings.json変更	`08_設定ファイル.md`

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の場合）:

🚨 2026-08-23 改訂: ふくけいに [y/N] を聞かない。 下の3値ルールで LLM が自動判定し、結果と理由を完了報告に1行出す（事後にふくけいが違うと言えば戻せる・可逆）。

改訂理由: 旧版は「構造的な文書への追記も検討しますか？[y/N]」と聞き、y なら「どこに書くのが適切だと思いますか？」と置き場所までふくけいに聞いていた。しかし ①判断材料（同型が過去何件あるか・どのハブに入るか）はすべて機械的に数えられる ②ふくけい側にその材料は無い ③将来この知見を探すのも LLM である。つまりふくけいに判断負担だけ渡して判断の質は上がっていなかった（2026-08-23 ふくけい申告)。

判定軸（唯一これだけ）

「個別記録への逆リンクだけで、将来の LLM がこの知見に辿り着けるか？」

辿り着けるなら何もしない。辿り着けないなら、辿り着ける場所に1行だけ置く。「重要そうだから」「もったいないから」で書かない（真実のソースを増やさない）。

3値ルール（上から順に評価・最初に当たったもので確定）

判定	条件（すべて機械的に確認できる）	動作
R: バックログに自動起票	踏む前に読んでいないと避けられない性質、かつ踏む前には検索キーワードを思いつけない（＝事後の grep では手遅れ）。例: 「0件を根拠に結論を出すな」型	P2でバックログに自動起票（層1 `rules/_shared/` へは書かない・毎回読込の肥大化コストが高いため）。~~完了報告に1行提案するのみ~~ ← 2026-08-23 B案改訂: 「提案」は確認要求と等価で当初目的（ふくけいに判断を投げない）に反するため起票に変更
H: ハブに1行追記	同じ `root_cause.category` かつ共通タグ2つ以上の過去記録が 2件以上（今回で通算3回目以上）、かつそれらが今回と異なる project に属すること（プロジェクト跨ぎ必須・2026-08-23 B案追加）	`ハブマッピング.md` で決まるハブに1行追記。別プロジェクトでの再発は「パターン」であり、個別記録を全部読まないと見えない。同一プロジェクト内の再発は `_INDEX.md` に並んで見えるため対象外
N: 逆リンクのみ（既定）	上記いずれにも当たらない（通算2回目まで・同一プロジェクト内のみの再発を含む）。`root_cause` 未記入の記録も N 確定（判定不能を FAIL に倒さない・2026-08-23 B案追加）	フェーズ3-1-α の逆リンクのみ。2点は線を引けば辿れるので第3の文書は不要

プロジェクト跨ぎ必須の根拠（実測・2026-08-23）: 旧条件（跨ぎなし）では H が 411件中 67% で発火し機能不全。閾値をどう振っても 67%→49% 止まりで、効いたのは「プロジェクト跨ぎ」という別軸。跨ぎ必須で 7%、既存のハブマッピングガード込みの実効発火率は 3%（411記録中14件）。設計: 00_SYSTEM/マルチLLMレビュー/2026-08-23_ssot-record関連パターン判定の3値ルール/revised_proposal.md

N へ降格するガード（H より優先）

ハブマッピング.md に該当ハブが無い → N。新規ハブを作ってまで残さない（実測: 跨ぎ条件を満たす29件のうち15件がこれで落ちる）
追記先候補が 01_DECISIONS/ 配下の個別記録 → N（記録間の関係は逆リンクで表す）
同じ root_cause.category の行が既にそのハブにある → N（既存行の日付と参照リンクだけ更新してよい）← 2026-08-23 B案変更: 旧「既に同趣旨の行がある」は判定が曖昧で「Hが実質停止しBがCと等価になる」懸念があったため機械判定可能な形へ置換

通算件数の数え方

まずフェーズ0.8の候補リスト（追加I/Oなし）で、今回と root_cause.category が一致し tags が2つ以上重なるものを数える。候補は「過去7日 ∪ 直近5件」なので取りこぼしうるため、 H の条件に当たりそうな時だけ全期間を1回走査して確定させる。

プロジェクト跨ぎ判定が必要なのでシェルパイプでは書けない。python で数う （2026-08-23 B案。旧実装 grep | xargs grep | xargs grep | wc -l は xargs -r が無く0件時に stdinを読んで停止するバグがあり、機械的基準の実装として成立していなかった）:

python3 - <<'PY'
import glob, os, re
root = os.path.expanduser("~/projects/obsidian-ssot/01_DECISIONS")
CAT, TAGS, ME = "<今回のroot_cause.category>", {"<タグ1>", "<タグ2>"}, "<今回のproject>"
peers = []
for p in glob.glob(os.path.join(root, "*", "2*.md")):
    proj = os.path.relpath(p, root).split(os.sep)[0]
    if proj == ME:            # ← プロジェクト跨ぎ必須（同一prj内の再発は _INDEX.md で見える）
        continue
    h = open(p, encoding="utf-8").read(3000)
    if not re.search(rf"^\s*category: *{CAT}\b", h, re.M):
        continue
    t = re.search(r"^tags: *\[(.*?)\]", h, re.M)
    if t and len({x.strip() for x in t.group(1).split(",")} & TAGS) >= 2:
        peers.append(os.path.relpath(p, root))
print(len(peers), "件"); [print(" ", x) for x in peers]
PY

⚠️ この件数を根拠にする前に必ず出力の中身を目視する（@rules/_shared/LLMサボりバイアス防止.md 「検索結果を事実として使う前の確認」）。0件・N件をそのまま信じない。上の実装は件数と ファイル名の両方を出すので、目視を省く言い訳を作らない。

追記時のガードレール（H の場合）

末尾への1行追加のみ。既存の見出し・本文・他セクションは一切編集・削除しない。対象ファイルの構造を壊さないことを最優先する。

非対話実行時

自律ループ等でふくけい応答を待てない場合も同じルールで判定してよい（元々ふくけいに聞かないため分岐が不要になった）。related_pattern 自体はフェーズ3-1の related_entries として frontmatter に記録する。

プロジェクトドキュメント更新対象ありの場合（フェーズ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: ファイル作成・更新

呼称チェック（2026-08-29 spec）

記録本文に「私」「ユーザー（人間を指す文脈）」が無いか生成後に確認すること:

人間の行動・発言 → 「ふくけい」
LLMの実装・判断 → 「CC」（一人称禁止）
変換は主体判定方式（「私→ふくけい」単純置換禁止）
人間の発言の直接引用ブロック内の「私」は例外として残す
詳細: ~/.claude/rules/_shared/呼称.md（層1・「ユーザー」主体判定フローチャート含む）
writer_modelは補助情報: 記録主体の主キーは本文の主体判定（ふくけい/CC）。writer_modelは「どの実行エンジンが書いたか」の追跡用（r2レビューOR#3採用）。writer_modelから主体を推定しない（r3レビューMiniMax#5）。対象は01_DECISIONS新規作成ファイルのみ（10_DAILY等の追記型ファイルはエントリ単位のセッションログで追跡・r3レビューGemini#4）

先頭作業（必須）: 本フェーズ開始時にフラグを作成すること。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
writer_model: <実行中バックエンドモデル名（GLM/MiniMax等・2026-08-29 spec §6）>
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>
falsification: <この判断が誤りと分かるのは何が起きた時か・観測可能な具体指標1文>  # 判断収束ループ・2026-08-18
falsification_keywords: [キーワード1, キーワード2]  # 逆引きgrep用・3語以内
outcome: pending  # pending/confirmed/falsified — フェーズ3.7の逆引き1問で更新
---

> **falsification の質基準（判断収束ループ・2026-08-18）**: 良い例「テスト赤が再発した時」「cronが2回連続発火した時」／悪い例「予期せぬ動作」「期待通りでない場合」（抽象語禁止・抽象語を検知したら具体指標へ書き直させる）

# 📖 <タイトル> — 議論の経緯
> 📅 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
- 未解決: <あれば>  ← なければ省略

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

⚠️ 機械ゲート補強（2026-09-05・効果: 低（人間向け）・機械防御は hook 層）: 日記への Write ツール使用は厳禁（diary-write-guard hook が deny）。日記への書込は 直前 Read 後の Edit（短い old_string での末尾挿入） 限定。全体上書きは 2026-09-05 02:15 に実際に事故が発生（過去同型 5 件・バックログ P2）。

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

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

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

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

Hook追加・変更時: 「SessionStart / PostToolUse / PreToolUse / Stop / Notification」の該当テーブルに1行追加
Cron追加・変更時: 「Cron」テーブルに1行追加
スクリプト追加時: 「スクリプト一覧」の該当セクションに1行追加
変更履歴: テーブル末尾に | 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ガイド/

追記先の判定

内容カテゴリ	追記先ファイル	追記箇所
新機能・新コマンド	`00_早見表.md`	該当セクションのテーブル末尾
新用語・新概念	`10_用語集.md`	該当するアルファベットセクション
スキル自作・登録	`03_スキルシステム.md`	カスタムスキルテーブル末尾
MCP追加・設定変更	`04_MCPサーバー.md`	現在の構成テーブル末尾
フック追加・変更	`05_フック.md`	該当フック種別テーブル末尾
設定ファイル変更	`08_設定ファイル.md`	該当セクション末尾
その他Claude Code情報	`10_用語集.md`	該当するアルファベットセクション

実行手順

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

判定基準

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

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

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

更新手順

設定ファイル参照: obsidian-ssot/00_SYSTEM/タグマッピング.md の「更新の種類詳細」に従う
各ファイルの更新: 検出されたファイルごとに 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）を触った場合、自分のボードエントリを更新する。

手順:

obsidian-ssot/00_SYSTEM/active-sessions.md を読み、自分のセッション(環境+トピック)のエントリを特定
- エントリが無い場合（resume-sessionで追加し忘れた等）: 先頭行に追加（セッション/触る共通ファイル/方針/開始/🟢進行）
「触る共通ファイル」欄に今回触ったファイルを追記（既存なら重複回避）

即commit+push（フェーズ5のcommitとは別に、ボードは時間感度高め）:

cd ~/projects/obsidian-ssot && git commit-scoped -m "chore: active-sessions 更新(<セッション名>: <触ったファイル>)" -- 00_SYSTEM/active-sessions.md && 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ハブ）。

実行手順

検出リスト確認: フェーズ0.5で検出された 00_SYSTEMハブ（セキュリティ設定ハブ・MCPガイド・リポジトリ索引・リンク運用方針・全体マップ_MOC 等）
重要度判定:
- 必須: フェーズ2で承認済みなら自動追記
- 任意: フェーズ2で「追記するか[y/N]」が y の場合のみ
各ハブを更新: Read → 既存フォーマット確認 → Edit/Write で追記（テーブル行追加/セクション追記）
ε重複回避: 自動化.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へ）。

手順

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

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

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

表現ゆれ対策（2026-07-05実証）: バックログ行の抽象語（「恒久対応」「根本対応」等）と記録内容の具体語（「運用リトリア」「スキル組込」等）が表現ゆれを起こし、照合漏れが発生した事例あり（Gemini空応答恒久対応 vs multi-llm-review空応答対策組込）。対象ファイル名・関数名・プロジェクト名等の「実体キーワード」でも照合すること。タスク名の字面一致だけに頼らない。
候補提示と承認ゲート:
```
✅ バックログ完了チェック
今回の記録「<記録サマリー>」に対応するバックログ候補:
  1. [ ] <候補1のタスク名>（P0/P1/P2）
  2. [ ] <候補2> ...
どれを [x]（完了）にしますか？[番号 / 違う / なし]
```
- 承認: 指定された行を [x] 化（必要なら完了日付を追記）
- 「違う」: 手動で行番号を指定させる（フォールバック）
- 「なし」: バックログに該当タスクなし → 「バックログ未登録タスクです。追加しますか？[y/N]」（y なら [x] 済みとして該当P区分に新規追加）
該当なし（候補0件）: ステップ3の「なし」と同様に「バックログ未登録タスク。追加しますか？」を確認。

安全設計

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

⚡ 軽残作業の先回り実行（2026-08-20追加）

完了候補の対応の中に**「[S]サイズ＋単発＋可逆（git巻き戻し可能）」の残作業**が含まれる場合（例: 1コマンド足すだけの検知追加・1行修正）、ふくけい承認を待たずに実行してしまい、完了報告に「実行済み＋巻き戻し方法（commit hash）」を添えてよい。その上で該当バックログ行を [x] 化して報告する（ふくけいが巻き戻しを希望すれば戻す）。

適用条件: ①5分以内で完了できる ②失敗してもgit/バックアップで元に戻せる ③破壊的操作を含まない
適用外: 設計判断が要るもの・他セッション占有中のファイル・不可逆操作（削除・外部送信）
根拠: 2026-08-20の指摘「判断するまでもない軽タスクを残して聞くのは無駄——やってから全部終わったと報告すればよい」。承認ゲートは誤[x]化防止のためのものだが、可逆な軽作業は「実行→報告→(必要なら)巻き戻し」で同程度の安全をより低い対話コストで達成できる

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

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

実行条件

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

手順

「未解決」セクションの内容を抽出: 記録した 01_DECISIONS ファイルの「## 未解決」以下の行を取得
バックログ重複チェック: 既存の [ ] 行と内容が被らないか確認（被れば追加不要）

確認ゲート:

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

承認: 指定されたものをバックログの該当 P 区分（P0/P1/P2）に [ ] 行で追加。P 区分は内容から推断（即効性高=P0・近いうち=P1・いつか=P2）
「なし」: 追加せず（一時的/memo的・次セッションで自然解決想定と判断）

安全設計

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

フェーズ3.7: 穴発見時の答え合わせ（outcome逆引き・2026-08-18追加）

記録対象のトピックに穴・不具合・予想外の事象が含まれる場合（バグ報告・事故・方針転換のきっかけ等）:

grep -rl "falsification_keywords" 01_DECISIONS/ で由来判断を逆引き（自然言語一致に頼らない・キーワードタグで照合）
疑わしき由来判断（通常0-3件）があれば、観測された事実を3つ以内で箇条書き提示してから1問だけ質問:

「この事象は <ファイル名> の判断の falsification（<その文>）に該当しますか？（Yes→outcome: falsified として更新 / No→そのまま）」
Yes の場合: 該当ファイルの outcome: を falsified に更新し、本記録に「由来: <ファイル名>」リンクを付ける
逆引き0件・またはふくけい不在（非対話）の場合: 質問せずスキップ（形骸化防止・毎回聞かない）

フェーズ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"）

ファイルをReadして「カスタムスキル」テーブルの末尾を確認

テーブル末尾に1行追加:

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

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

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

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

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

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

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

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

共通ルール

追記前に必ず既存行を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

source/XX_<章名>.md に内容を追記（Markdownで書く）
テスト実行: python3 -m pytest test_convert.py -q
ビルド: python3 convert.py
ガイドリポジトリで git commit-scoped -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 commit-scoped -m "record: <内容の1行説明>" -- <今回触ったファイルを明示>
git push

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

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

cd /home/yn4416/projects/<project>
git commit-scoped -m "docs: <内容の1行説明>" -- <今回更新したdocsを明示>
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 #バグ修正
📖 ガイド転記: なし（または「あり → <章名>」）
🔗 関連パターン: <N|H|R> — <理由1行>（通算<n>回目・別prj: <projA>,<projB>）  ← **related_patternが非nullなら省略不可**。
   N=逆リンクのみ / H=<ハブ名> に1行追記済み / R=バックログにP2自動起票済み
   related_pattern が null の場合は行ごと省略してよい
🔗 コミット: <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: 確定保存

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

commit & push:

cd ~/projects/obsidian-ssot
git commit-scoped -m "record: セッション横断総括 <タイトル>" -- <今回作成した記録ファイルを明示>
git push

完了報告に以下の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 が呼ばれた場合もこのスキルで処理する。

変動可能性のある外部情報の記録ルール（2026-08-23追加）

外部APIの仕様・料金・モデル名・エラーコード・プラン対応は予告なしに変更される。「恒久情報」として書くと、LLMが古い情報を真実として扱い判断を誤る。

SSOT役割の再定義: 30_RESEARCH/ 配下の情報は「普遍的な真実」ではなく「特定時点における検証済みスナップショット」である。LLMはこれを読む際、「これは過去の事実であり、現在の真実とは限らない」を前提に扱わなければならない。

必須メタ情報（frontmatter）:

recorded_at: 記録日時（ISO 8601・タイムゾーン明記）
source_verified_at: 公式情報を確認した日時
change_likelihood: high | medium | low（判断基準は後述）
verify_after_days: 相対日数（既定90日・経過でLLMは警告）。next_verify_recommendedより形骸化しにくい

change_likelihood 判断基準（記録者の主観を排すためガイドライン規定）:

high: 料金プラン・ベータ機能・モデルバージョン名・マーケティングキャンペーン
medium: APIパラメータ・エラーコード詳細
low: コアなAPIエンドポイント・認証方式

本文構造ルール:

「現時点で判明している事実」と「公式情報源URL」を分離
検証コマンド1行を併記（curl https://api... | jq で再現可能）
「モデルXXが対応アカウントYで利用可能」記述はアカウント種別/残高/プラン依存を必ず明示
重要情報ブロックごとに (最終確認: YYYY-MM-DD) をインライン記述（粒度別確認日の明示）

LLMの読み方ヒント:

記録日が verify_after_days 経過 → 自動的に change_likelihood=high 扱い
「現時点では」「〜時点の確認では」と書かれた箇所は古い可能性大
自動更新は厳禁。情報の鮮度低下を検知したら人間のオペレーターに再検証を提案する
frontmatter change_likelihood を見て自己判断

省略のコスト（記録者への注意）:

必須メタを省略するとLLMが情報の鮮度を機械評価できず、全情報を「等しく疑わしい」としか扱えない
結果として、まだ有効な情報（基本APIエンドポイント）の利用を過度に避けたり、逆に変動の激しい情報（料金プラン）を無警戒に扱う事故が起きる

配置先: 30_RESEARCH/（特性カタログ準拠・外部サービス調査が時系列で陳腐化する情報の正典）

About

ssot-record スキル

概要

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

手順

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

ライフサイクル

フェーズ0: 情報収集

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

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

検出手順（両表で共通）

検出結果の例

タグがマッチしない場合

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

候補収集パイプライン

候補情報の整形

候補が0件の場合

後片付け

フェーズ1: 分類判定

環境別の判定方法

判定に使うプロンプト

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

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

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

判定軸（唯一これだけ）

3値ルール（上から順に評価・最初に当たったもので確定）

N へ降格するガード（H より優先）

通算件数の数え方

追記時のガードレール（H の場合）

非対話実行時

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

呼称チェック（2026-08-29 spec）

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

3-2. _INDEX.md への追記

3-3. 10_DAILY への追記

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

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

追記先の判定

実行手順

判定基準

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

更新手順

更新の種類別の実装

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

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

実行手順

判定基準

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

実行条件

手順

安全設計

⚡ 軽残作業の先回り実行（2026-08-20追加）

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

実行条件

手順

安全設計

フェーズ3.7: 穴発見時の答え合わせ（outcome逆引き・2026-08-18追加）

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

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

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

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

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

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

共通ルール

4-1. 追記先の特定

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

フェーズ5: git commit & push

5-1. SSOT（必須）

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

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

フェーズ6: 完了報告

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

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

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

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

注意

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

発火判定

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

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

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

フェーズ4: ガイド転記（`guide_needed: true` かつふくけい承認済みの場合のみ）

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

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