Menu
AIとの会話を、ユーザーの思考メモ(Self)も含めてGitHub IssueまたはPull Requestにコメントとして追加する実験版。手動で呼び出して使用。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
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を混同していた。何度か質問して「作業ディレクトリ」と「履歴の線」を分けて整理できたことが理解の転機。