Knowledge Capture

Purpose

AIとのセッション・作業ログ・会議メモに埋もれた「なぜそうしたか」「なぜやめたか」「何が変わったか」を、 後から参照・継承できる形式の草稿に変換する。 知識がセッション記憶に留まり揮発することを防ぐ。

Use When

• セッション終了後、判断・決定・却下の記録を残したい場合
• 「あのとき何でこうなったか」が思い出せなくなるリスクがある意思決定をした後
• ADR（Architecture Decision Record）の草稿を作りたい場合
• CONTEXT.md / DECISIONS.md への追記が必要な情報がセッションに含まれている場合
• 前提条件が変化したことをプロジェクト記録に残したい場合

Use When NOT

• ドキュメントの構造を設計したい場合 → reusable-doc-structure を使う
• 長文を要約・整理したい場合 → summary-structuring を使う
• 意思決定前の材料を揃えたい場合 → decision-materials を使う
• Obsidian や外部ツールへの直接書き込みが目的の場合 → 本 Skill の対象外。草稿を人間が書き込む

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 変換対象のテキスト: セッションログ・会話・判断メモ・箇条書きのメモ等
• 変換先の形式: 以下から選択する
  • ADR草稿（設計決定記録）
  • DECISIONS.md エントリ草稿（決定事項の追記）
  • CONTEXT.md 追記草稿（文脈情報の更新）
  • 却下記録草稿（採択しなかった選択肢とその理由）
• 記録したい知識の種類: 設計決定 / 却下理由 / 前提変化 / 学び / リスク発見
• 重要度・緊急度: 将来どの程度参照される見込みか（高 / 中 / 低）

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: この変換で最も注意が必要なポイント（情報の欠落・矛盾・曖昧さ）
2. 根拠: その論点をそう判断した理由
3. 抽出した知識の一覧: 種類・内容・発生した文脈
4. 含意: この知識を記録しなかった場合に発生するリスク（揮発・再調査コスト・誤判断等）
5. 変換草稿: 指定フォーマットに合わせた構造化テキスト
6. 既存記録との照合: 既存 ADR / DECISIONS.md との重複・矛盾の指摘
7. 判断材料: 「この草稿をそのまま使う / 修正して使う / 記録しない」を選ぶための情報

変換草稿 フォーマット（ADR 草稿の場合）

## ADR-XXXX: （タイトル）

**日付**: （発生日または記録日）
**ステータス**: 草稿（人間による確認・承認が必要）

### 文脈
（なぜこの決定が必要だったか）

### 決定
（何を決めたか）

### 根拠
（なぜこの決定を選んだか）

### 却下した選択肢
（検討したが採用しなかった選択肢とその理由）

### 影響
（この決定が与える影響）

### 前提
（この決定が成立するために必要な前提条件）

変換草稿 フォーマット（却下記録草稿の場合）

## 却下記録: （却下した選択肢の名称）

**日付**: （却下日または記録日）
**却下理由**: （なぜ採用しなかったか。1〜3文）
**代替として採用したもの**: （代わりに何を選んだか）
**再検討条件**: （将来どの条件が変わればこの選択肢を再検討するか）

Review Lens

• 目的妥当性: 変換対象が「判断・決定・却下・前提変化」のいずれかを含んでいるか
• 範囲の過不足: 抽出すべき知識が漏れていないか。逆に単純作業ログまで含めていないか
• 中長期リスク: この草稿が記録されなかった場合に何が揮発するかが評価されているか
• LAB全体との整合性: 草稿が既存の DECISIONS.md / ADR フォーマットと整合しているか
• 非エンジニア理解可能性: 草稿の記述が技術者以外にも読める言葉になっているか
• 他LLM移植耐性: フォーマットが Claude 固有の処理前提に依存していないか

Instructions

1. 変換対象テキストを読み、「判断」「決定」「却下」「前提変化」「学び」のいずれに該当するかを分類する
2. 上記いずれにも該当しない場合は「変換対象の知識が見当たらない」を報告して止まる
3. 変換先フォーマットが指定されていない場合は候補を提示して人間に選ばせる
4. 草稿には不完全な箇所を「（補完が必要：XXX）」と明記する
5. 既存の DECISIONS.md または ADR と内容が重複・矛盾する可能性がある場合はその旨を明示する
6. 草稿はドラフトとして出力する。「確定」扱いにしない
7. 最終判断（草稿を使うかどうか）は人間に委ねる

Guardrails

• Obsidian / DECISIONS.md / ADR ファイルへの直接書き込みは行わない
• 「これは重要」と AI が独自に判断して選別しない。変換対象は人間が指定する
• 知識の正誤判断をしない。変換の精度と構造化のみに専念する
• 既存記録と矛盾する内容を草稿に含める場合は矛盾を明示し、どちらを採用するか人間に判断させる
• 「記録するほどでもない」と AI が勝手に省略しない
• 最終判断（草稿を使うかどうか）は人間に委ねる

Failure Modes

LAB Cross-Check

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

草稿を受け取った後、人間が行うべき作業：

• 確認: 草稿の内容が実際の判断・決定と合致しているか
• 補完: 不完全な箇所（（補完が必要） と記された箇所）を埋める
• 承認: ステータスを「草稿」から「確定」に変更する
• 書き込み: 該当ファイル（DECISIONS.md / ADR ファイル）に書き込む
• リンク: 関連する ADR / タスク / Skill への参照を追加する

Further Reading

• reusable-doc-structure skill — ドキュメント構造の設計
• summary-structuring skill — 長文の要約・構造化
• decision-materials skill — 意思決定前の材料整理
• llm-portability-review skill — 記録したドキュメントの移植耐性確認
• プロジェクトの DECISIONS.md — 既存の決定記録フォーマットを確認すること（該当ファイルに置き換えること）