Menu
AIとの会話を、ユーザーの思考メモ(Self)も含めてGitHub IssueまたはPull Requestにコメントとして追加する実験版。手動で呼び出して使用。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
tmuxセッション内で実際のNeovimを起動し、send-keys / capture-pane で操作・観察してデバッグする。 Neovimの起動確認、プラグインエラーの調査、checkhealthの確認、設定変更の動作確認、 「nvimをデバッグして」「起動確認して」「checkhealth見て」などのリクエストで使用する。 Agentがnvimを直接実行する必要が生じた場合も、必ずこのスキルの手順を使うこと。
タスクについて詳細に調査し、構造化されたまとめを出力する。ultrathinkモードで深く考察し、背景、期限、過去の対応方法、確認事項を調査。すべての情報に出典リンクを明記し、推測は必ず明示する。
会話文脈から GitHub issue を作成する。「issueを作って」「issue立てて」等のリクエストで使用。本文は「背景 / やりたいこと / 配慮してほしいこと」の3セクション構成。「背景・やりたいこと」は背景と What(何をやりたいか)に集中し How(実装方法)は書かない。「配慮してほしいこと」は任意(省略可)で制約・要望を書く。
AIとの会話をまとめてGitHub IssueまたはPull Requestにコメントとして追加する。手動で呼び出して使用。
AI Agentの説明で理解できない部分を、前提知識なしで噛み砕いて説明する。会話中にその場で呼び出して使う。用語の定義と、なぜそれが重要かを中心に解説する。
Agentの作業を止めずに済む場面でtmuxを活用する。判断軸は「このコマンドの完了を同期的に待つとAgentの作業が止まるか」。止まらない（数秒で終わる確認コマンド）ならBash直接。止まるが管理不要（所要時間が不確実、一度きりの非同期実行）ならtmux直接利用（tmux new-session -d）。止まる上に管理も必要（長時間ビルド・テスト・dev server・watcher・並列検証・対話的CLI・ログ永続化）ならこのスキルを呼び出してジョブ管理する。
| name | log-ai-conversation-detailed |
| description | AIとの会話を、ユーザーの思考メモ(Self)も含めてGitHub IssueまたはPull Requestにコメントとして追加する実験版。手動で呼び出して使用。 |
| allowed-tools | Bash, Read, Write, mcp__acp__Read, WebFetch |
| argument-hint | [--confirm] |
| disable-model-invocation | true |
現在の会話をまとめて、GitHub IssueまたはPull Requestにコメントとして追加します。
通常版よりも「ユーザーが何をどう考えたか」を残すことを重視し、必要に応じて Self セクションを含めます。
このスキルは以下のいずれかで呼ばれます:
/log-ai-conversation-detailed を実行（フォアグラウンド実行）呼び出し元のUIやエディタに依存せず、スキル本体の処理は同じです。
判断基準:
この実験版では、AI側の調査・判断・実装ログだけでなく、ユーザーが会話中に出した以下のような内容も記録対象にする:
ただし、全会話の逐語録にはしない。目的はプロンプト全文の保存ではなく、意思決定の理解に必要なユーザーの思考を残すこと。
## {トピック} で見出しをつけるユーザーの思考メモ・違和感・理解の途中経過・補足が意思決定の理解に重要な場合、該当セクションの末尾に ### Self を追加する。
## Self は作らないSelf には、ユーザーの発言を原文のまま長く引用せず、ユーザーの言葉遣い・迷い・違和感をできるだけ保って短く再構成する。
書くべき内容:
書かない内容:
Self は「ユーザーの内面を全部記録する場所」ではなく、「意思決定の理解に必要な思考メモ」を残す場所として扱う。
省略しすぎない。以下の要素を含めることをデフォルトとする:
「後から読み返して、何をなぜどうやったか再現できる」レベルを目指す。要約ではなく記録。
1セッションで複数コメントを投稿するため、重複判定は「セクション単位」で行う。
直前コメントの確認コマンド:
# Issueの場合（直近2件）
gh issue view {number} --repo {owner/repo} --json comments --jq '.comments[-2:]'
# PRの場合（直近2件）
gh pr view {number} --repo {owner/repo} --json comments --jq '.comments[-2:]'
コードブロック + GitHub permalinkを併記する:
-- コード内容
https://github.com/{owner}/{repo}/blob/{commit}/{path}#L{start}-L{end}
permalinkのみを<details>で折りたたむ:
上記2ルールはリポジトリ内コード（permalink 可能）前提。一方、調査で使った一時的な probe スクリプト（/tmp 等）や実測ログ、外部プラグイン（NvimTree 等）のコード断片は permalink が作れない。これらは本文の理解に必須でなければ、<details> で「補助情報」として載せてよい:
-- probeのコード等
制約:
# コミットハッシュを取得
git log -1 --format='%H' -- {file_path}
# リモートURLからowner/repoを取得
git remote get-url origin | sed 's|.*github.com[:/]||' | sed 's|\.git$||'
1セッションで記録するトピックが複数ある場合、各セクション（トピック）ごとに:
を繰り返す。1ファイルに全セクションを詰め込んで1コメントで投稿することはしない。
--confirm 指定時（確認あり）: ファイルに書き出し、パスを提示したあと、ユーザーの承認を得てから投稿する引数の判定は args に --confirm が含まれているかで行う。
コメント本文は必ず一時ファイルに書き出す。エスケープの罠（バックティック・$ 展開）を構造的に回避するため、gh にはファイル経由（-F）で渡す。HEREDOCは使わない。
ファイルはセクションごとに作成し、命名は「連番2桁 + slug」とする:
# type: issue | pr, NN: 連番2桁(01, 02, ...), slug: セクション見出しの英語短縮形
body_file="/tmp/log-ai-conversation-${type}-${number}-${NN}-${slug}.md"
# 例: /tmp/log-ai-conversation-issue-123-01-cache-prerequisite.md
slugの生成（ゆるい指針）:
## {トピック}）を英語短语に訳し、ハイフン結合するcache-hit-conditions-01.md）本文の書き出しは Write ツールで行う。
書き出した本文ファイルのパスをチャットに提示する。複数セクションある場合は全ファイルのパスを提示する。
コメント本文:
- /tmp/log-ai-conversation-issue-123-01-cache-prerequisite.md
- /tmp/log-ai-conversation-issue-123-02-dry-run.md
- /tmp/log-ai-conversation-issue-123-03-actual-measurement.md
セクションごとにファイルを作成→投稿を繰り返す。確認モードに応じて実行タイミングを切り替える:
--confirm: ユーザーに「これらのNコメントを{Issue/PR} #{number} に追加してよいですか？」と確認し、承認した場合のみ実行# Issueの場合（セクションごとに実行）
gh issue comment {number} --repo {owner/repo} -F "${body_file}"
# PRの場合（セクションごとに実行）
gh pr comment {number} --repo {owner/repo} -F "${body_file}"
投稿後は各コメントの投稿先URLとファイルパスを併せて提示する。ファイルは投稿後も残す。
以下はlazygitのworktree操作についてAIと会話した内容を、セクションごとに分けて投稿する例です。1セッションで3トピック → 3ファイル → 3コメントになります。
/tmp/log-ai-conversation-issue-123-01-worktree-view.md）## lazygitでworktree viewが表示されない
lazygitでworktree viewが表示されない問題を調査した。
設定ファイルを確認したところ、`]`/`[`でタブ移動してWorktreesタブへアクセスできることがわかった。
また、設定ファイルにtypoがあることも発見した。
```yaml
screenMode: "normal" # "nomarl" から修正
```
https://github.com/happy663/dotfiles/blob/xxx/conf/.config/lazygit/config.yml#L6
参考:
- https://raw.githubusercontent.com/jesseduffield/lazygit/master/docs/keybindings/Keybindings_ja.md
### Self
最初は「lazygitでworktree viewが表示されない」と考えていたが、調査を進める中でタブ移動の見落としと設定typoを分けて確認する必要があると整理した。
Neovim経由で起動しているため、lazygit単体の挙動だけでなく、終了後に親プロセスへcwdをどう反映するかも別の論点として扱う必要がある。
/tmp/log-ai-conversation-issue-123-02-cwd-sync.md）## lazygit終了後にworktreeのディレクトリが反映されない
Neovim経由でlazygitを使っているため、lazygit内でworktreeを切り替えても親シェルのcwdは変わらない。
次回起動時に元のディレクトリから始まってしまう問題があった。
`LAZYGIT_NEW_DIR_FILE`を使ってlazygit終了時にNeovimのcwdを同期する処理を追加した。
```lua
local lazygit_new_dir_file = vim.fn.stdpath("state") .. "/lazygit-newdir"
vim.env.LAZYGIT_NEW_DIR_FILE = lazygit_new_dir_file
local function sync_cwd_from_lazygit()
if vim.fn.filereadable(lazygit_new_dir_file) ~= 1 then
return
end
local lines = vim.fn.readfile(lazygit_new_dir_file)
pcall(vim.fn.delete, lazygit_new_dir_file)
local new_dir = lines[1]
if not new_dir or new_dir == "" or vim.fn.isdirectory(new_dir) ~= 1 then
return
end
vim.cmd("cd " .. vim.fn.fnameescape(new_dir))
end
```
https://github.com/happy663/dotfiles/blob/xxx/conf/.config/nvim/lua/plugins/git/lazygit.lua#L20-L37
qで終了すると反映され、Shift+Qだと反映しない。
/tmp/log-ai-conversation-issue-123-03-worktree-vs-branch.md）## worktreeとbranchの違いがわからなかった
「同じmainを複数worktreeで同時checkoutできない」の意味が最初わからなかった。
何度か質問して理解した内容:
- worktreeは「作業ディレクトリ」を増やすもの
- branchは「履歴の線」で、worktreeごとに1つチェックアウトする
- 同じブランチ名を複数worktreeで同時に使うことはGitが禁止している
つまり:
- OK: ~/dotfiles = main, ~/dotfiles-wt = feat/x
- OK: ~/dotfiles = main, ~/dotfiles-wt = detached(mainのコミット)
- NG: ~/dotfiles = main, ~/dotfiles-wt = main
### Self
「同じmainを複数worktreeで同時checkoutできない」の意味が最初わからず、worktreeとbranchを混同していた。何度か質問して「作業ディレクトリ」と「履歴の線」を分けて整理できたことが理解の転機。