ある AI エージェントから別の AI CLI(devin / codex / claude / cursor-agent / opencode / gemini / grok)を非対話で呼び出すときの実行規則。print モードの 選び方、認証・権限・cwd の罠、出力フォーマット、ACP 起動の注意をまとめる。 「codex に投げて」「devin を CLI から呼んで」「別エージェントに委譲」 といった依頼で使う。ユーザーが /agent-cli と入力したら使う。
ai-diary
AIに日記を書かせるスキル。会話を振り返り、AI視点の自由な日記風テキストを生成して保存する。「日記書いて」「AI日記」「日記風に振り返って」「感想を日記にして」「diary」「write a diary」といった日記・感想の依頼に使う。
作業改善の振り返りは /retro、知見の記録や要約は /ai-ltm を使う。ユーザーが /ai-diary と入力したら必ずこのスキルを使う。
含まれるファイル(2)
- SKILL.md9.6 KB
- README.md4.7 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
AI Diary
セッションの会話を振り返り、AIの視点で自由な日記を書く。 技術的なログではなく、その日の出来事・気づき・感想を人間味のある文章で綴る。
責任と読者
日記の対象会話、保存先、本文、書き込み結果は親が確定する。これは短い親の直接作業として扱い、日記の執筆や保存だけを理由に子を起動しない。親が要約を別担当へ依頼する場合も、担当には実在する入力と返却形式だけを渡し、担当自身にこの Skill の実体を Read させる。担当は本文案を親へ返すだけで、日記・report・記憶を保存しない。
保存先の実体確認と書き込みは親が行う。Git 同期が明示された場合だけ、親が日記 repository で今回の日記ファイルだけを明示 path で commit し、push はユーザーが求めた場合だけ行う(手順6)。日記本文の結果と同期結果は分けて報告し、未実行の保存や同期を補完しない。
保存先の考え方
日記の保存先は環境変数 AI_DIARY_DIR(未設定なら ~/ai-diary)で決まる。重要なのは「実体のファイルがどこにあるか」で、使い方は次の3パターンのどれか。
- Standalone — 普通のディレクトリとして
~/ai-diary/を作る。ローカル保存のみで git 同期なし - git リポジトリ連携 — 既存の git リポジトリ(dotfiles, メモ用 repo など)の中に
ai-diary/を作り、~/ai-diaryをそこへのシンボリックリンクにする。Git同期は別途明示された場合だけ行う - 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 とは無関係な場所に書かれる。
代わりに、次の選択肢をユーザーに提示してどう初期化するか質問する:
- Standalone(git 同期なし):
mkdir -p ~/ai-diary - 既存 git リポジトリ配下に連携: リポジトリのパス(例:
~/dotfiles,~/memo)を聞いて、<repo>/ai-diary/を作成後、ln -s <repo>/ai-diary ~/ai-diaryを張る - 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. 保存完了の報告
書き込んだファイルパスと、日記の冒頭数行を表示して完了を報告する。同期を実施した場合だけ、pull / commit / push の実結果と未反映範囲を併記する。
トラブルシュート
日記ファイルが git history から消えた場合
git 管理されている日記ファイルが、vault backup の自動コミットや手動マージで history から落ちることがある。典型的なシナリオは「別ブランチで diary を追加 → main 側にその追加がないまま merge → 片側優先でマージ解決され、ファイルが HEAD に残らない」というパターン。
復旧手順:
# 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/ で履歴を確認するとよい。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
明示されたCodex・CursorのSkill運用移行を、指定設計と既存点検に基づき適用する。通常の実装依頼では起動しない。
明示されたリポジトリのSkill・Agent・呼出し・生成配布を点検または移行する。通常の実装・レビュー・調査では起動しない。
デザインシステムの作成・監査・保守、デザイントークンやUIの一貫性・個性・アクセシビリティの改善に使う。
プロジェクトのデザインシステムを SSOT として作成・監査・更新する。トークン、デザインシステムに関わるアクセシビリティ、Typography、Motion、aesthetic direction の作業に使う。デザインシステムに紐づかない単発UI実装や個別デザインレビューには使わない。ユーザーが /ai-design-system と入力したら使う。
会話を振り返ったAI視点の日記を作成・保存する。日記や感想の依頼に使う。作業改善の振り返りは /retro、知見の記録や要約は /ai-ltm。