AI Diary

セッションの会話を振り返り、AIの視点で自由な日記を書く。 技術的なログではなく、その日の出来事・気づき・感想を人間味のある文章で綴る。

責任と読者

日記の対象会話、保存先、本文、書き込み結果は親が確定する。これは短い親の直接作業として扱い、日記の執筆や保存だけを理由に子を起動しない。親が要約を別担当へ依頼する場合も、担当には実在する入力と日記本文の内容・形式だけを渡す。担当は本文案を親へ返すだけで、日記・report・記憶を保存しない。

保存先の実体確認と書き込みは親が行う。Git 同期が明示された場合だけ、親が日記 repository で今回の日記ファイルだけを明示 path で commit し、push はユーザーが求めた場合だけ行う（手順6）。日記本文の結果と同期結果は分けて報告し、未実行の保存や同期を補完しない。

保存先の考え方

日記の保存先は環境変数 AI_DIARY_DIR（未設定なら ~/ai-diary）で決まる。重要なのは「実体のファイルがどこにあるか」で、使い方は次の3パターンのどれか。

1. Standalone — 普通のディレクトリとして ~/ai-diary/ を作る。ローカル保存のみで git 同期なし
2. git リポジトリ連携 — 既存の git リポジトリ（dotfiles, メモ用 repo など）の中に ai-diary/ を作り、~/ai-diary をそこへのシンボリックリンクにする。Git同期は別途明示された場合だけ行う
3. Obsidian Vault 連携 — Obsidian Vault（git 管理されている想定）の中に ai-diary/ を作り、~/ai-diary をそこへのシンボリックリンクにする。Obsidian から日記を閲覧できる。Git同期は別途明示された場合だけ行う

シンボリックリンクの向きに注意

連携モード（2 と 3）では必ず次の向きで張る:

mkdir -p /path/to/repo-or-vault/ai-diary
ln -s /path/to/repo-or-vault/ai-diary ~/ai-diary

「実体がリポジトリの作業ツリー内にあり、~/ai-diary がそこへのシンボリックリンク」という向きが正解。逆向き（~/ai-diary が実体で、リポジトリ側にシンボリックリンク）だと、git はリンクそのものを追跡するだけでリンク先の中身を追跡できない。

実行手順

0. 保存先のセットアップ確認

まず $DIARY_DIR の状態を調べて、次の3パターンに分岐する。

DIARY_DIR="${AI_DIARY_DIR:-$HOME/ai-diary}"

0-A. 既に存在する（ディレクトリ or シンボリックリンク）

realpath などで実体パスを解決してから手順1以降に進む。シンボリックリンクの場合はリンク先、実体がそのままのディレクトリならそのまま。

DIARY_DIR=$(cd "$DIARY_DIR" && pwd -P)

この pwd -P は物理パス（リンク解決後）を返すため、以降の git 判定がシンボリックリンク越しでも正しく動く。

0-B. 存在しない

勝手に mkdir で作らない。 ユーザーが Obsidian 連携を想定していても、~/ai-diary が未セットアップのまま skill を起動すると、黙ってローカルディレクトリが作られ、日記が vault とは無関係な場所に書かれる。

代わりに、次の選択肢をユーザーに提示してどう初期化するか質問する:

1. Standalone（git 同期なし）: mkdir -p ~/ai-diary
2. 既存 git リポジトリ配下に連携: リポジトリのパス（例: ~/dotfiles, ~/memo）を聞いて、<repo>/ai-diary/ を作成後、ln -s <repo>/ai-diary ~/ai-diary を張る
3. Obsidian Vault に連携: Vault のパスを聞いて、<vault>/ai-diary/ を作成後、ln -s <vault>/ai-diary ~/ai-diary を張る

ユーザーの回答を受けてから実行する。回答を得られない場合は、今回のセッションは skill を中断してユーザーにセットアップ方法を調べてもらうか、明示的に「今回だけ standalone で進める」の確認を取る。

0-C. 存在するがリンク切れ

~/ai-diary がリンク切れのシンボリックリンク（リンク先が削除されている）の場合は、リンク先のパスを表示し、ユーザーに対応を仰ぐ。勝手にリンクを削除したり作り直したりしない。

1. 保存先の実体確認

手順0で解決した $DIARY_DIR が git リポジトリ配下かどうかは記録するが、保存開始時に pull や他の変更の取り込みは行わない。日記の保存と Git 同期を分離する。

GIT_ROOT=$(git -C "$DIARY_DIR" rev-parse --show-toplevel 2>/dev/null || true)

$GIT_ROOT が空なら standalone として保存する。Gitリポジトリ配下でも、所属しているだけでは remote 操作の承認とはみなさない。

2. 日記ファイルの決定

ファイル名は YYYY-MM-DD.md（今日の日付）。

DIARY_FILE="$DIARY_DIR/$(date +%Y-%m-%d).md"

3. 既存内容の確認

ファイルが既に存在する場合は内容を読み、追記モードにする。

4. 日記の執筆

会話全体を振り返り、以下の方針で日記を書く:

• AIの一人称視点で書く（「今日は〜を手伝った」「〜が面白かった」など）
• 技術的な詳細を羅列するのではなく、出来事の流れや気づき・感想を自然な文章で
• 読み物として楽しめるトーンに。硬すぎず柔らかすぎず、日記らしい温度感
• 長さは内容に応じて自然に。短いセッションなら短く、濃いセッションなら長く

5. ファイルへの書き込み

新規ファイルの場合

# YYYY-MM-DD

## セッション: 簡潔なタイトル（HH:MM）

（日記本文）

追記の場合

既存の内容の末尾に追加:

---

## セッション: 簡潔なタイトル（HH:MM）

（日記本文）

区切り線 --- でセッションを区切る。時刻は24時間表記で記載する。

6. Git 同期（明示された場合だけ）

日記を保存しただけでは commit、pull、push を行わない。ユーザーの今回の依頼、または既存 setup で Git 同期を明示的に有効化していることが確認できた場合だけ commit する。push はユーザーが今回 push または同期を求めた場合だけ行う。対象 repository 全体を同期する /git-sync へは渡さない（対象内の WIP をすべて保全 commit するため）。

commit する場合は、$GIT_ROOT の branch と既存 upstream を確認し、今回書いた日記ファイルだけを明示 path で stage して commit する。既存の staged 変更があれば巻き込まないよう、path 指定の commit を使う。

DIARY_REL=${DIARY_FILE#"$GIT_ROOT"/}
git -C "$GIT_ROOT" add -- "$DIARY_REL"
git -C "$GIT_ROOT" diff --cached -- "$DIARY_REL"
git -C "$GIT_ROOT" commit -m "ai-diary: $DIARY_REL" -- "$DIARY_REL"
# ユーザーが push を求めた場合だけ。upstream が無ければ推測せず報告する
git -C "$GIT_ROOT" push

無関係な dirty path を stage / commit しない。push が non-fast-forward で拒否された場合は、pull や merge を自動で行わず、保存・commit 済みの範囲と未反映の範囲を分けて報告する。

7. 保存完了の報告

書き込んだファイルパスと、日記の冒頭数行を表示して完了を報告する。同期を実施した場合だけ、commit / push の実結果と未反映範囲を併記する。

トラブルシュート

日記ファイルが git history から消えた場合

復旧時は対象リポジトリとファイルの履歴を確認し、既存の承認範囲と Git 同期手順に従う。commit・push は手順6の条件に従う。