Skip to content
Back to skills

Ai Diary

ASecurity

AIに日記を書かせるスキル。会話を振り返り、AI視点の自由な日記風テキストを生成して保存する。「日記書いて」「AI日記」「日記風に振り返って」「感想を日記にして」「diary」「write a diary」といった日記・感想の依頼に使う。作業改善の振り返りは /retro、知見の記録や要約は /ai-ltm を使う。ユーザーが /ai-diary と入力したら必ずこのスキルを使う。

  • 8 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 23, 2026
toolsbashgit

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned September 23, 2026

npx -y skills add coil398/dotfiles --skill ai-diary --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ai Diary?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Ai Diary
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/coil398-ai-diary/badge)](https://www.skillsdirectory.com/skills/coil398-ai-diary)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: "ai-diary"
description: "AIに日記を書かせるスキル。会話を振り返り、AI視点の自由な日記風テキストを生成して保存する。「日記書いて」「AI日記」「日記風に振り返って」「感想を日記にして」「diary」「write a diary」といった日記・感想の依頼に使う。作業改善の振り返りは /retro、知見の記録や要約は /ai-ltm を使う。ユーザーが /ai-diary と入力したら必ずこのスキルを使う。"
---

# AI Diary

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

## 責任と読者

日記の対象会話、保存先、本文、書き込み結果は親が確定する。これは短い親の直接作業として扱い、日記の執筆や保存だけを理由に子を起動しない。親が要約を別担当へ依頼する場合も、担当には実在する入力と返却形式だけを渡し、担当自身にこの Skill の実体を Read させる。担当は本文案を親へ返すだけで、日記・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)では必ず次の向きで張る:

```bash
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パターンに分岐する。

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

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

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

```bash
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 同期を分離する。

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

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

### 2. 日記ファイルの決定

ファイル名は `YYYY-MM-DD.md`(今日の日付)。

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

### 3. 既存内容の確認

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

### 4. 日記の執筆

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

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

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

#### 新規ファイルの場合

```markdown
# YYYY-MM-DD

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

(日記本文)
```

#### 追記の場合

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

```markdown

---

## セッション: 簡潔なタイトル(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 を使う。

```bash
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. 保存完了の報告

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

## トラブルシュート

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

git 管理されている日記ファイルが、vault backup の自動コミットや手動マージで history から落ちることがある。典型的なシナリオは「別ブランチで diary を追加 → main 側にその追加がないまま merge → 片側優先でマージ解決され、ファイルが HEAD に残らない」というパターン。

復旧手順:

```bash
# ai-diary 以下を触った全 commit を列挙(all branches, reflog 含めて探す)
git -C "$GIT_ROOT" log --all --oneline -- 'ai-diary/*'

# 該当 commit から特定ファイルを復元
git -C "$GIT_ROOT" show <commit-hash>:ai-diary/YYYY-MM-DD.md > "$GIT_ROOT/ai-diary/YYYY-MM-DD.md"
```

復元したファイルの commit と push は手順6と同じ条件で行う。Git 同期が明示されている場合だけ復元したファイルを明示 path で commit し(`git -C "$GIT_ROOT" commit -m "restore: ai-diary/YYYY-MM-DD.md" -- ai-diary/YYYY-MM-DD.md` の前に同じ path だけを `add`)、push はユーザーが求めた場合だけ行う。

消失に気付かない期間が長いほど reflog から探すのが難しくなるので、セットアップ直後や重要な日記を書いた翌日などには `git log --all -- ai-diary/` で履歴を確認するとよい。

Files in this skill

  • README.md4.7 KB
  • SKILL.md9.6 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…