jesseduffield

Vim沼: AIコーディング用Neovimセットアップ ! 本記事は devas.life の日本語訳です どうもTAKUYAです。本稿では、AIエージェント(Claude Code)を使用してNeovimをセットアップする手順について説明します。 動画版はこちら: youtube.com dotfilesはこちら: craftzdog/dotfiles 構成サマリー この記事で紹介するセットアップの全体像です。 スペックは9つのステップに分かれています。 ステップ 内容 主なプラグイン・機能 0. 前提条件 Neovim、CLIツール、フォント、Git Neovim 0.12、Nerd Font 1. 基盤 ファイル構成、オプション、メッセージ、基本のキーマップ vim.pack、ui2、tiny-cmdline.nvim 2. 見た目 カラースキーム、アイコン、タブライン、ステータスライン solarized-osaka、mini.icons、自作タブライン、lualine、incline.nvim、snacks.nvim 3. ナビゲーション ピッカー、ファイルエクスプローラー snacks.nvimのピッカー、oil.nvim 4. シンタックス 構文ハイライト、TODOと色の表示 nvim-treesitter、todo-comments.nvim、nvim-highlight-colors 5. コード支援 言語サーバー、補完、括弧、フォーマット Mason、nvim-lspconfig、blink.cmp、mini.pairs、conform.nvim 6. Git サイン、差分、lazygit、リンク gitsigns.nvim、mini.diff(フォーク)、codediff.nvim、lazygit、gitlinker.nvim 7. AI インラインの補完候補 copilot.lua 8. エージェントコーディング パスやコードブロックをエージェント用にコピー 自作のキーマップ ファイル構成: ~/.config/nvim ├── init.lua ├── after/lsp/<name>.lua # サーバーごとのLSP設定 └── lua/craftzdog/ ├── utils/ # 共通のヘルパー ├── config/ # options, keymaps, autocmds, commands, workarounds └── plugins/ # init.lua、グループごとの設定、keymaps.lua LazyVimを卒業した 2023年に紹介した前回のセットアップでは、プラグインのメンテナンスを避けるためにLazyVimを使っていて、とても快適でした。 LazyVimコミュニティのおかげで、プラグインを簡単に最新に保てて、設定も気軽にいじれました。 でも、カスタマイズすればするほど不安定になっていきました。 LazyVimを更新するたびにエラーを直すのが、ちょっと面倒だったんです。 一方で最近のNeovimでは、以前はプラグインが必要だった機能がたくさん組み込まれました: vim.pack: 組み込みのプラグインマネージャー vim.lsp.enableとafter/lsp/<name>.lua: ほぼボイラープレートなしでLSPを設定できる ui2: 新しいメッセージUI :restart: Neovimを再起動してセッションを復元する そこで、これらをベースに新しくセットアップを作ることにしました。 エージェントコーディングのためのNeovim Agentic Codingが普及し、僕もすっかりエージェント中心の開発ワークフローになりました。 最近はNeovimを、手でコードを書くためというより、主にコードレビューのために使っています。 正直、ワークフローの変化がとても速いので、いつまでこの構成でNeovimを使い続けるかはわかりません。しかしながら、現状のセットアップをシェアしてその変化を楽しむのも一興だと思いました。 設定を自然言語で書く 今はNeovimの設定をいじるのがとても簡単です。やりたいことをエージェントに伝えるだけだからです。 そこでLuaを書く代わりに、設定の スペック(仕様書) を英語でInkdropに書き、MCPサーバー経由でエージェントにステップごとに渡しました。 スペックノート スペックには「どうやるか」ではなく、「何がしたいか」と「なぜか」を書きます。 Luaのコードはエージェントが考えます。 ワークフロー スペックのステップを1つ書く。 そのステップだけを実装するようエージェントに頼む。 :restartでNeovimを再起動し、自分で動作を確認する。 差分をレビューしてコミットする。 エージェントへのプロンプト エージェントには次のルールを伝えました: スペックを読み、指定したステップだけを実装する。それ以外は何も足さない。 作業結果は軽くチェックする: Neovimがエラーなしで起動する: nvim --headless +qa 新しいキーマップが存在する: :verbose map <key> テスト用のプロジェクトを作ったり、UIを操作したりしない。動作は再起動後に自分で確認する。 設定のリロード ZRに:restartを割り当てています。 Neovimが同じターミナル内で再起動し、ウィンドウ、タブ、バッファを復元します。 先に:waで保存しておきます。未保存のバッファがあると再起動できません。 :restart +qall!なら未保存の変更を破棄して再起動します。 プラグインを追加するステップの後は、vim.packがインストールの確認を出すので承認します。 再起動で終了してしまうので、エージェントはNeovim内の:terminalではなく、別のターミナル分割で動かします。 以下が、ステップごとのスペック全体です。 自由にコピーして自分のエージェントに渡し、好みに合わせて調整してください。 0. 前提条件 0.1 Neovim Neovim 0.12以上。 この設定は0.12で入った組み込み機能(vim.pack、vim.lsp.enable、ui2メッセージUI)に依存しています。 0.2 CLIツール ツール 用途 git vim.packがプラグインのクローンに使う tree-sitter CLI + Cコンパイラ nvim-treesitterのmainブランチはパーサーをローカルでビルドする curlとtar パーサーとblink.cmpのバイナリのダウンロード Node.js + npm Masonはほとんどの言語サーバーをnpm経由でインストールする ripgrepとfd テキスト検索とファイル検索のバックエンド lazygitとgit-delta Git UIとその差分表示 0.3 フォント Nerd Font。僕はPlemolJP Console NFを使っています。 タブライン、ステータスライン、補完メニュー、ファイルエクスプローラーにアイコンが出るので、普通のフォントだと四角(豆腐)になります。 0.4 Git 設定フォルダはGitリポジトリにする。 .gitignoreにnvim-pack-lock.jsonを入れる。 1. 基盤 1.0 セッションを始める まず、スペックの場所をエージェントに伝えました: I'd like to make a neovim setup. I'm going to write a spec in this note: <link to the spec> When you are ready, say so エージェントの最初の返答 1.1 構成 ~/.config/nvim: 設定のルートフォルダ init.lua: 起動を速くするためvim.loaderを有効にし、次のファイルを順に直接requireする: craftzdog.utils(グローバル変数Craftzdogに代入) craftzdog.config.options、.keymaps、.autocmds、.commands、.workarounds craftzdog.plugins lua/craftzdog/: 自分の設定はここに置く utils/: 共通のヘルパー init.lua: ヘルパーモジュールのテーブルを返す。最初は空。 後のステップでutils/editor.luaのようなモジュールを追加し、editorとして公開する。 config/: Neovim本体の設定。上に挙げた名前ごとに1ファイル plugins/ init.lua: 1回のvim.pack.addですべてのプラグインをインストールし、各グループのファイルをrequireする プラグインのグループごとに隣にファイルを作り(例: ui.lua)、require("<plugin>").setup({ ... })で設定する。 keymaps.lua: プラグインを使うキーマップはすべてここ。すべてのプラグインの設定が終わってから読むよう、最後にrequireする。グループのファイルにはキーマップを書かない。 Luaファイルはタブでインデントし、stylua(デフォルト設定)で整形する。 生成されたファイルツリー 1.2 リーダーキーと基本設定 リーダーとローカルリーダーはSpace。 マウスはオフ。キーボードのみ。 クリップボードはunnamedplus。ヤンクとペーストがシステムのクリップボードを通る。 インデントはスペース2つ: tabstop、shiftwidth、softtabstopはすべて2 expandtabとsmartindentはオン -を単語の一部として扱うので、foo-barは1単語になる。 CSSのクラス名やケバブケースの名前に合う。 1.3 バッファの見た目 ハイブリッド行番号: number + relativenumberをオンにして、カーソル行には実際の行番号を表示する。 cursorlineはオン。折り返しなし、scrolloffは10、sidescrolloffは8。 signcolumnは常に表示。 Gitや診断のマークが出てもテキストがずれない。 cmdheightは0、ステータスラインはグローバルに1本(laststatus 3)。 縦のスペースを最大限使う。 すべてのフローティングウィンドウの枠を角丸に(winborder)。 ポップアップメニュー: 最大10行、少し透過(pumheight 10、pumblend 10)。 対応する括弧を一瞬ハイライト(showmatch オン、matchtime 2)。 titleをオンにして、ターミナルのタブにファイル名を表示する。 差分の空き領域を斜線╱で埋める。 ハイブリッド行番号 1.4 検索、ファイル、アンドゥ ignorecase + smartcaseをオン: 大文字を入力するまでは大文字・小文字を区別しない。 pathに**を追加して、:findがサブフォルダも検索するようにする。 :の補完: wildmodeはlongest:full,full wildignoreで/node_modules/、.o、.obj、.pyc、.class、*.jarを除外 swapfileとwritebackupはオフ。 永続アンドゥ(undofile オン)の保存先は~/.cache/nvim/undodir。 ファイルを閉じてもアンドゥできる。スワップファイルは邪魔なだけ。 タイミングをキビキビさせる: updatetime 300、timeoutlen 500、ttimeoutlen 0。 CursorHoldイベントが早くなり、キーシーケンスが遅延なく確定する。 試してみる: init.luaで/craftzdog、次に/Craftzdog :find opt<Tab> init.luaを編集して:wq、開き直してからu 1.5 分割と折りたたみ 新しい分割は下と右に開く。 折りたたみはTreesitterから作り、foldlevelは99。 最初はすべて展開された状態で、構文単位で折りたたむこともできる。 試してみる: :split、:vsplit :e $VIMRUNTIME/lua/vim/keymap.luaを開き、関数の中でzc / zo zM / zR 折りたたまれた関数 1.6 メッセージ メッセージはNeovim 0.12の実験的機能ui2で表示します。config/options.luaの最後で有効にします。 短いメッセージ: 画面の隅にポップアップ(最大で画面の高さの30%)し、5秒で消える。 長い出力(エラー、:ls、:verbose、シェルコマンド、進捗): 最大で画面の半分までのスクロールできるページャーに表示。 検索件数、検索パターン、補完、:の補完リスト、確認プロンプトはコマンドラインに残す。 自分で入力したコマンドの出力は、種類にかかわらずコマンドラインに表示する。 次のキーを押すまで、画面の下部に広がって表示される。 Enterでページャーに移る。 tiny-cmdline.nvimで、:のコマンドラインを左右中央・上から20%の位置にフローティングボックスとして表示します。設定はplugins/ui.luaに書きます。 cmdheightが0なのでコマンドラインを出す場所が必要で、視線がもともとある上の方が見やすい。 試してみる: :echo "hi" :lua print("hi") :foo :!ls :verbose set ts? フローティングのコマンドライン lsの出力 1.7 autocmd ヤンクしたテキストを一瞬ハイライトする。 アクティブなウィンドウにだけcursorlineを表示する。 ヤンクのハイライト 1.8 基本のキーマップ キー 動作 備考 x ヤンクせずに削除 <leader>d、<leader>c、<leader>p ヤンクレジスタを変えずに削除・変更・ペースト 周りを編集しても、ヤンクしたテキストが残る。 dw 単語を後方にヤンクせず削除 - / - 数値を増減 <C-a> 全選択 te 新しいタブを開く Tab / Shift-Tab タブを切り替える ss / sv 分割 ホームポジションで短くウィンドウを操作できる。 sh sj sk sl ウィンドウ間を移動 ホームポジションで短くウィンドウを操作できる。 <C-m> ジャンプリストを前に進む ターミナルでは<C-i>がTabと同じキーで、Tabはタブ切り替えに使っているため。 <leader>o / <leader>O コメントを継続せずに下/上に行を挿入(o<Esc>^Da) ssとsvで分割 1.9 隠れバッファを閉じる <leader>bdで、未保存のものを除くすべての隠れバッファを閉じる。 2. 見た目 2.1 カラースキーム solarized-osaka、vividスタイル、背景は透過。 ターミナルのブラーが透けて見え、配色がGhosttyのテーマと揃う。 カラースキーム適用前 カラースキーム適用後 2.2 アイコン mini.icons。nvim-web-deviconsのモックも兼ねる。 すべてのプラグインでアイコンの出どころを1つにする。 2.3 タブライン プラグインを使わず、utils/tabline.luaに自作のタブラインを書きます。 タブが2つ以上のときだけ表示する。 各タブには、アクティブなウィンドウのファイル名とアイコンを、左右3スペースずつの余白付きで、斜めの区切りの間に表示する。 両端が下に向かって外側に傾くので、各タブは下が広い台形になる: 色はsolarized-osakaのパレットから: アクティブなタブ: yellowの背景に太字のbase4の文字 非アクティブなタブ: base02の背景にbase0の文字 アイコンはタブの文字色に合わせる。 区切りは透過背景にタブの色。最後のタブの後ろの空き領域も同じ。 20文字より長い名前は、17文字に切って…を付ける。 未保存のタブはアイコンの前に[+]を表示する。 ターミナルは[Terminal]、空のバッファは[No Name]と表示し、アイコンは付けない。 タブライン 2.4 ステータスライン lualine。グローバルに1本、テーマはauto。 セクション 内容 a モード b Gitブランチ c プロジェクトルート名(cwdと違う場合のみ)、ファイルタイプのアイコン、整形したパス x マクロ記録中のレジスタ、診断、Gitの差分数 y 進捗 z 行:列 プロジェクトルートは、上の階層に向かって.git、lua、package.json、Makefile、Cargo.toml、go.mod、pyproject.tomlを探して決める。 カーソル移動時と、マクロの記録開始・終了時に更新する。 記録中の表示が、非表示のコマンドラインの代わりになる。 完成イメージ: 結果: ステータスライン 2.5 ウィンドウのラベル incline.nvimで、各ウィンドウの右上にアイコン付きのファイル名タグを表示する。未保存なら[+]も付ける。 ステータスラインがグローバルに1本なので、分割したそれぞれのウィンドウにどのファイルかを示す必要がある。 カーソルがタグの行に来たら、タグを隠す。 inclineのラベル 2.6 Snacks snacks.nvimで、通知、インデントガイド、statuscolumn、単語のハイライトを提供します。 後のステップで、ピッカーやlazygit連携など、さらに機能を有効にしていきます。 Words: カーソル下の単語をすべてハイライトする。]] / [[で出現箇所を移動。 言語サーバーが必要なので、ステップ5.1の後から動く。 スムーズスクロールはオフ。 スクロールは即座に反応してほしい。 vim.notify インデントガイド 3. ナビゲーション 3.1 ピッカー snacks.nvimのピッカー。 キー 動作 備考 ;f 隠しファイルも含めてファイルを検索 .github/や.env.exampleのようなドットファイルも、実際のプロジェクトの一部。 ;r 隠しファイルも含めてライブgrep ;; 最後のピッカーを開き直す \ 開いているバッファの一覧 すでにそのバッファを表示しているウィンドウがあれば、そこにジャンプする。 ;e 診断の一覧 ;n 通知の履歴 ;h Gitのハンクの一覧 ファイルピッカー ライブgrep 3.2 ファイルエクスプローラー oil.nvimでnetrwを置き換え、隠しファイルも表示します。 ディレクトリがバッファになっているので、ファイルの名前変更・移動・削除は、テキストを編集して:wするだけ。 列: アイコン、パーミッション、サイズ、更新日時。 ファイル名を変更すると、LSPにimportの更新を頼み、その編集を自動で保存する。 タブライン(2.3)では、oilのタブはディレクトリ(~/foo)をアイコンなしで表示する。 20文字より長いパスは左側を切り、…と末尾の17文字にする。 キー 動作 備考 sf ライブプレビュー付きの中央フローティングでoilを開く 最大200列幅、角丸。 h 親ディレクトリに移動 q oilを閉じる プレビュー付きのoilフローティング oilの列 4. シンタックス 4.1 Treesitter nvim-treesitterのmainブランチ。 38個のパーサーを入れる: astro, bash, c, cmake, cpp, css, diff, fish, gitignore, go, graphql, html, http, java, javascript, jsdoc, json, lua, luadoc, luap, markdown, markdown_inline, php, printf, python, query, regex, rust, scss, sql, svelte, toml, tsx, typescript, vim, vimdoc, xml, yaml FileTypeのautocmdで、パーサーがあればハイライトとTreesitterのインデントを開始する。 PackChangedイベントで:TSUpdateを実行する。 パーサーがプラグインのバージョンと同期した状態に保たれる。 PackChangedフック Inspect 4.2 ちょっとしたハイライト todo-comments.nvimでTODOやFIXMEなどをハイライト。設定はデフォルト。 nvim-highlight-colorsで、hex、rgb、hsl、ANSI、CSS変数の色を背景色として表示。Tailwindはオフ。 色が二重に塗られないよう、NeovimのLSPのdocument colorsはオフにする。 TODOとFIXME 色の表示 5. コード支援 5.1 言語サーバー Mason + mason-tool-installerで起動時にインストールし、自動更新はしません: サーバー: lua-language-server, vtsls, eslint-lsp, oxlint, tailwindcss-language-server, css-lsp, rust-analyzer, copilot-language-server フォーマッター: prettier, prettierd, oxfmt, stylua, shfmt デフォルト設定はnvim-lspconfigから。 vim.lsp.enableで有効にするサーバー: eslint, oxlint, lua_ls, cssls, vtsls, tailwindcss, rust_analyzer すべてのサーバーでファイル名変更(didRename / willRename)をサポートする。 Mason 単語のハイライト 5.2 診断の見た目 下線で表示し、入力中は更新せず、重大度順に並べる。 インラインのテキスト: ● メッセージ。ソースは複数あるときだけ表示する。 ガターのアイコンは共通のアイコンセットから。 たとえば、TSXファイルでconst x: number = 'a'と入力すると: エラーに下線が引かれ、インラインに● Type 'string' is not assignable…、ガターにアイコンが出る。 この行には「never read」のヒントもあるが、重大度順なのでガターにはエラーのアイコンが出る。 oxlintも未使用のxを指摘するので、各メッセージにソース(ts、oxc)が表示される。 診断 5.3 サーバーごとの設定 サーバーごとの設定はafter/lsp/<name>.luaに書きます。 Neovim 0.12が自動でマージしてくれるので、セットアップのボイラープレートは不要です。 vtsls: ワークスペースのTypeScriptを使い、ファイル移動時にimportを更新する。 サーバー側のあいまい検索と、関数呼び出しの補完。 インレイヒントは短く: 変数の型は出さず、最大30文字。 lua_ls: Neovimのランタイムを認識し、引数の型ヒントを表示し、うるさいチェックをいくつか黙らせる。 cssls: 空のルールを無視する。 oxlint: oxlint --lspで起動する。 lua_lsのチェックについて質問するClaude 5.4 補完 blink.cmp、バージョン^1、enterプリセット: Enterで確定。 5.1のすべての言語サーバーに、blink.cmpの補完のcapabilitiesも渡す。 関数の後に括弧を自動で付ける。ドキュメントは200ms後にポップアップ。 メニューの項目はTreesitterで色付けし、種類のアイコンは共通のアイコンセットから。 ゴーストテキストはオフ。 Copilotがすでにインラインで候補を出すので、ゴーストテキストが2つあるとぶつかる。 コマンドラインでは、:コマンドのときだけメニューが自動で開き、何も事前選択しない。 補完メニュー 5.5 括弧のペア mini.pairsをデフォルト設定で、挿入モードとコマンドモードで使う。 5.6 フォーマット conform.nvimで、保存時に1000msのタイムアウトでフォーマットし、なければLSPにフォールバックします。 ファイルタイプ フォーマッター js, ts, jsx, tsx, json, css, scss, less, html, markdown, mdx, yaml oxfmt、prettierd、prettierの順(最初に使えるもの) lua stylua sh shfmt fish fish_indent oxfmtは、プロジェクトに.oxfmtrc.jsonやVite+のvite.config.tsのようなoxfmtの設定があるときだけ動く。 prettierを使うプロジェクトは、そのままprettierでフォーマットされる。 :ToggleFormatterで、現在のバッファの保存時フォーマットをオフ/オンし、通知を出す。 このコマンドはconfig/commands.luaに置く。 ConformInfo 5.7 LSPのキーマップ キー 動作 備考 gd 定義へ移動 gD、gy、grと同じくピッカー経由。 gD 宣言へ移動 gy 型定義へ移動 gr 参照の一覧 gI TypeScriptではソース定義、他の言語では実装へ移動 .d.tsを飛ばして実際のコードに行ける。 ;c 呼び出し元の一覧 K ホバードキュメントを表示 gK / <C-k>(挿入モード) シグネチャヘルプを表示 <C-j> 次の診断へジャンプしてフローティング表示 <leader>ca コードアクションを表示 <leader>cr シンボル名を変更 <leader>cR importを更新しつつファイル名を変更 <leader>f 今すぐフォーマット <leader>cl LSPの情報を表示 参照のピッカー ホバードキュメント 6. Git 今は主にエージェントが書いたコードをレビューしているので、セットアップの中でここが一番よく使う部分です。 6.1 サインとblame gitsigns.nvimをデフォルト設定で。 キー 動作 備考 <leader>gb 行のblame <leader>gB バッファのblame <leader>go その行を最後に変更したコミット時点のファイルを新しいタブで開く エディタを離れずに、昔の変更の文脈を確認できる。 <leader>gs バッファをステージ。ステージするものがなければアンステージ <leader>gh ハンクをステージ/アンステージ Gitのサイン blameのフローティング 6.2 差分のオーバーレイ mini.diffを自分のフォーク(craftzdog/mini.diff、feat/groupingブランチ)から使います。 このフォークでは、git diffの表示と同じように、変更をハンク単位でまとめる。 キー 動作 <leader>gd オーバーレイの切り替え ]c / [c ハンク間を移動 mini.diffのオーバーレイ 6.3 差分ビュー codediff.nvimで、左右に並べた差分と履歴を見ます。 エージェントがコードベースに大量の変更を入れたときに使います。 エクスプローラー: ツリー表示、幅50列、カーソル移動に合わせてファイルを開き、行の増減(+/-)を表示。 コンパクトモード: 変更箇所と前後8行だけを表示し、折りたたみを左右のペインで同期。 キー 動作 <leader>dv 差分ビューの切り替え <leader>dh 現在のファイルの履歴を表示 <leader>dH リポジトリの履歴を表示 codediffのエクスプローラー 6.4 Lazygit ;gで、snacks.nvim経由でlazygitをフローティングで開きます。テーマを同期し、アクティブな枠線はWarningMsgの色にします。 ファイル上でeを押すと、lazygitを閉じ、起動元のウィンドウでファイルを開きます。$NVIMとnvim --server --remoteを使います。 ;gは現在のウィンドウを覚えておく。 eはlazygitを終了し、--remote-sendでそのウィンドウにフォーカスしてからファイルを開くので、カーソルがファイルに移る。 新しいタブでも、入れ子のNeovimでもない。Neovimの外では、単にnvim <file>を実行する。 編集コマンドはfishの構文で書く。 lazygit自体の設定はNeovimの設定の外、~/.config/lazygit/config.ymlにあります。snacks.nvimが同期したテーマと一緒に読み込みます。内容は: 差分はdelta --dark --paging=never --syntax-theme="Solarized (dark)"で表示。 マウスイベントと自動fetchはオフ。 ファイルパネルのCで、commitizen(git cz)でコミット。 lazygitのフローティング 6.5 リンク gitlinker.nvim: :GitLinkで、現在の行(または選択範囲)のGitHubのURLをコピー。 7. AI 7.1 Copilot copilot.lua。自動トリガーをオンにし、Markdownとhelpでも有効にします。 メモやドキュメントでも、コードと同じくらい候補が役に立つ。 最初に一度:Copilot authが必要。 macOSでは、ターミナルでOptionをAltとして扱う設定が必要。 キーは挿入モードで使います: キー 動作 <C-l> 候補を確定 Alt-l 1単語だけ確定 Alt-Shift-l 1行だけ確定 Alt-] / Alt-[ 候補を切り替え <C-]> 候補を消す 8. エージェントコーディング Neovimからエージェントにコンテキストを渡すための、小さなヘルパーです。 8.1 エージェント用にパスをコピー キー 動作 備考 <leader>yf 現在のファイルのcwdからの相対パスを#L<行番号>付きでコピー 例: lua/craftzdog/config/options.lua#L12 <leader>yp 同じ形式で絶対パスをコピー どちらも、コピーしたテキストを通知で表示する。 パスをエージェントのプロンプトに貼れば、該当する行を正確に指せる。 パスをコピーした通知 8.2 ヘルパーのキーマップ キー 動作 備考 <leader>cc(ビジュアル) 選択範囲を、filename="…"とline=…属性付きのMarkdownコードブロックとしてコピー Inkdropのコードブロック属性と同じ形式。言語名は短縮形(tsx、jsx、ts、js)。 <leader>j プロジェクトのpackage.jsonを中央の80%のフローティングで開く。qかEscで閉じる。 Inkdropに貼り付けたコードブロック 実践例: 新しいセットアップで小さなアプリを作る このセットアップを普段どう使っているかを見せるために、小さなアプリを作りました。この設定のキーマップをすべて載せた、1ページのチートシートです。 Inkdropのノート駆動エージェントコーディングのワークフローに沿って進めました。 タスクごとにノートを1つ作り、自分とエージェントの共有の場所として使います。 僕が要件を書き、残りの計画はエージェントが埋めます。 1. アプリの雛形を作る ~/Developments/devaslife/keymap-cheatsheetにWakuのアプリを作りました: npm create waku@latest Wakuアプリの雛形作成 2. 計画ノートに要件を書く 新しいノートを作り、Cmd+Tで組み込みのImplementation planノートテンプレートを適用しました。 テンプレートの最初には、自分で書くRequirements(要件)とRelated notes(関連ノート)のセクションがある。 残りはエージェント用の骨組み: 要件の言い換え、現状、決定事項、フェーズ、リスク、ステータス、結果。 エージェントへの指示は> # !Instructionsと> # !Exampleのブロックに書かれている。 Inkdropは作成したノートからこれらを取り除き、エージェントは元のテンプレートから読む。 テンプレートから作った新しいノート 要件はたった2行と、スペックのノートへのリンクだけです: Requirements - Build a one-page keymap cheatsheet for my neovim setup - It renders a simple table for each keymap Related notes - [Set up Neovim](inkdrop://note/…) 要件と関連ノート 3. エージェントに計画を埋めてもらう ノートのリンクをコピーして、Claude Codeに渡しました: fill out [Create a keymap cheatsheet for Neovim setup](inkdrop://note/eOuwoieG) Claude Codeはfill-out-templateスキルを使い、InkdropのMCPサーバー経由でノートを読んで更新します。 計画を埋めるClaude 計画を書く前に、スペックのノートと実際のLuaの設定の両方を読んでいました。 すべてのキーマップの定義場所をfile:lineの形で一覧にした。 スペックと設定の食い違いを見つけた。 例: ファイル検索のキーが、スペックでは;fではなく:fと誤記されていた。 スペックより設定の方を信頼すると判断した。 そのうえで、僕にしか決められないことを質問してきました: 決定事項 質問 僕の答え データの出どころ ページはキーマップをどこから取得する? 手で整理した、型付きのTSデータファイル 対象範囲 スペックの表だけか、設定でマップしているキーすべてか? マップしているキーすべて スターターのUI スターターのヘッダーとフッターを残す? 削除して、/の1ページだけにする 質問するClaude 僕の答えをDecisions Needed(決定事項)に記録し、作業を3つのフェーズに分けました: キーマップのデータ ページと表のコンポーネント スターターの残骸を削除 埋まった計画 コードをレビューするより、計画をレビューする方がずっと楽なので、注意力はここに注ぎます。 4. 実装する Claude Codeに実装を頼むと、3つのフェーズすべてを1分18秒で実装しました。 進むにつれて、ノートのStatusセクションで各フェーズにチェックを付けていきます。 実装完了 チートシートは7セクション・59キーで、ダークモードにも対応しています。 キーマップのチートシート 5. Neovimでコードをレビューする ここでセットアップのGitの部分が活躍します: ;g: lazygitで、差分全体にざっと目を通す <leader>dv: codediffで、変更されたファイルを1つずつ左右に並べて見る <leader>gd: mini.diffのオーバーレイで、ファイル内の変更を見る lazygitで差分をレビュー mini.diffでレビュー レビューの後、プロジェクトをpnpmに切り替えてコミットしました。 6. 結果を記録する 最後に、動いているページのスクリーンショットをClaude Codeに貼りました。 するとノートのOutcome(結果)とFollow-up(フォローアップ)のセクションを埋めてくれます。 結果を記録したノート これでノートには、何をなぜ作ったのかが残ります。スペックの誤記を直すというフォローアップも含めてです。完成したノートはこちら: Create a keymap cheatsheet for Neovim setup まとめ 今やコードを書くコストはほぼゼロなので、設定を自然言語のスペックとして書くのはとても自然に感じました。僕の場合は英語と日本語です。 スペックは読みやすく、各設定の横に「なぜ」が残ります。そして、やりたいことをエージェントに伝えるだけで、いつでもセットアップを作り直したり調整したりできます。 スペックは全部上に載せたので、ぜひコピーして自分好みにしてみてください。皆さんのNeovimセットアップの参考になれば嬉しいです。読んで・観てくれてありがとうございました!

AI 一口气改了几个文件，别急着全提交。Lazygit 能在终端逐行选改动，拆成几次提交，方便检查。 MIT 开源。注意它的撤销靠 Git reflog，不能恢复工作区或 stash 的改动，别把撤销键当万能后悔药。 jesseduffield/lazygit t.co

Review Agent Code in a GitHub PR, lazygit or Hermes? What Each One Can't See - Book: Ship It — the pragmatic startup tech stack - Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- The agent runs for forty minutes and reports back: done. You open the diff. Fourteen files changed, one commit at the end, and somewhere in the middle a lockfile moved and a CI workflow gained a step. Which of the agent's replies did that? Was it the one where you said "fix the test", or the one where it decided the test runner needed upgrading? The diff can't tell you. A diff knows files and lines. It doesn't know about turns. Where you read an agent's work decides what you catch. This post compares three places: GitHub's pull request view, lazygit in your terminal, and the Review Desk in Hermes IDE. I build Hermes, so weigh the third section with that in mind. The PR view wins more of the comparison than you might expect from me. Four questions for any review surface Every review tool answers the same four questions, with different amounts of detail. 1. Granularity. What is the smallest unit you can look at on its own: the branch, a commit, a hunk, or the agent turn that produced the change? 2. Feedback. When you find a problem, how does your comment get back to whoever wrote the code, and is that an agent or a person? 3. Risk signals. Does the tool point at the changes that deserve a second look, like a lockfile, a CI workflow or a secret? 4. Review to merged. How many steps between "this looks right" and the change sitting on your main branch? With a human author, question 1 barely matters. A person commits in chunks that mean something. An agent often doesn't commit until the end, or commits whatever is on disk, so a single commit can hold a dozen turns of trial and error. !Three lenses over one long diff: a wide lens covering the whole branch, a magnifier over a single hunk, and a row of numbered beads marking each agent turn Branch, hunk or turn: the unit you review in sets what you can isolate. GitHub's PR view: built for teams and CI The pull request page is where team review happens, and nothing else in this comparison replaces it. Granularity. Since a December 2025 public preview, the new "Files changed" page lets you "review all commits, a subset of commits, or a single commit" without leaving the page, with C opening the commit filter if single-key shortcuts are on. Inside that, GitHub's review guide has you go file by file and tick Viewed. If the file changes after you tick it, it is unmarked again, which matters when an agent keeps pushing. The floor is the commit. If the agent squashed ten turns into one commit, the PR shows one commit. Feedback. You can comment on a line or a range, propose a suggested change, and submit the review as Comment, Approve or Request changes. Agents that live on GitHub read those comments. GitHub's Copilot coding agent responds when you mention @copilot on a pull request, and from the Files changed tab you can use Fix with Copilot on one comment or Add to batch for several. It "only responds to comments from people who have write access to the repository." Claude Code GitHub Actions does the same for @claude in PR comments and reviews, once the workflow is installed. If your agent runs on your laptop instead, the comment sits on GitHub and you carry it back to the terminal yourself. Risk signals. This is where the PR view is hard to beat for a team. Protected branches can require a number of approvals, a review from code owners, and passing status checks, and can dismiss stale approvals when new commits arrive. For dependencies, dependency review adds a rich diff of manifest and lockfile changes to Files changed, with vulnerability and license data. The dependency review action that enforces it works on all public repositories; private ones need GitHub Code Security or Advanced Security. One trap is worth checking in your repo. Files marked linguist-generated in .gitattributes are, per GitHub's docs, "hidden by default in diffs": # .gitattributes package-lock.json linguist-generated That line is reasonable for humans, who rarely edit a lockfile on purpose. For an agent that might bump a dependency on its way to fixing a test, it folds away the line you most wanted to see. Review to merged. It is slow next to a local merge, and on purpose: push, wait for CI, wait for a reviewer. That wait is the point when other people depend on the branch. lazygit: hunks and lines, at terminal speed lazygit is a terminal UI for git, and it is very good at the part of review that is about shaping changes. Granularity. Its unit is the hunk and the line. Version 0.66.0, released October 5, moved staging into the main view: "press space to stage a hunk or range of lines." The same release added "Build custom patches directly from a commit's diff." You can also mark a commit "so that any other commit you select will be diffed against it" (README). The current release is 0.66.1, from October 11. For agent work, that means you can pull a bad hunk out of a commit, stage the good half of a file, and split one huge commit into three that make sense. Neither of the other two tools edits history this directly. Feedback. lazygit has no review comments. You read, you decide, and you type the feedback into the agent yourself. One bridge arrived in 0.66.0: "Open the selected diff line in the branch's pull request," so you can jump from a line in your terminal to the same line on GitHub and comment there. Risk signals. None built in. It shows you everything at the same weight, so the lockfile looks like any other file. Its custom command system lets you add your own checks, but you write them. Review to merged. Fast. Merge, rebase, squash, all on your machine with a few keys. Press z to undo the last action, but note the README's caveat: undo "uses the reflog," so it can't bring back working tree or stash changes. Hermes Review Desk: by turn, before a PR exists Hermes is a desktop app that runs coding agents such as Claude Code and Codex, each in its own terminal and its own git worktree (README). Its Review Desk works from a different unit: the agent's turn. Granularity. Hermes saves every agent turn, so you can diff or restore any single turn, with undo (README). A strip under each session, labelled "Agent replies" since 2.3.1 (October 13, 2026), shows one chip per reply with the lines it changed; click one to see its changes or restore your files to that point. The Review Desk (⌘G, or Ctrl+Shift+G on Windows and Linux) shows changes by turn or by file. So you can find the reply that moved the lockfile and restore your files to the point before it. Feedback. You leave line comments in the Review Desk, and Hermes sends a line comment "back to the agent that wrote it" (README). For an agent running on your own machine, neither of the other tools closes that loop for you. Risk signals. The Review Desk shows changes with risk flags (README). That gives you a pointer to where to look first. Review to merged. Land "commits, opens a pull request or merges locally in one step, into the branch the task started from, and can be undone" (README). Undo data for a landed task is kept for 14 days (release notes). Your own checks can decide when a task is done. !Three small terminal windows, each with a robot silhouette, and a folded note flying back along an orange thread to the one terminal whose robot wrote the marked line Each line comment is routed to the agent session that wrote that line. The Review Desk is a single-person, local review. It has no approvals, no code owners, no required checks on a shared branch, and no CI history. Turn history exists only for sessions run in Hermes; a branch an agent pushed from somewhere else is just commits. In a task with extra folders, the replies strip tracks changes in the main project only (2.3.1 notes). And the turn view tells you which reply changed a line, not why the agent did it; you still read the transcript for that. Side by side | | GitHub PR view | lazygit | Hermes Review Desk | |---|---|---|---| | Smallest unit | Commit, then file | Hunk and line | Agent turn, then file | | Comments | Line, range, suggestions | None | Line comments | | Feedback to agent | @copilot, @claude (GitHub-hosted) | You type it | Sent to the agent that wrote the line | | Risk signals | Code owners, required checks, dependency review | None built in | Risk flags on changes | | Team review | Yes | No | No | | Undo | Revert PR | z via reflog | Restore a turn, undo a landing | | Where it runs | GitHub | Your terminal | Desktop app, your machine | Use them in order They don't compete as much as the table suggests. They sit at different points in the life of a change. 1. While the agent is still working, review by turn. That is when "restore to before turn 7 and tell the agent why" is cheap, and the comment reaches the right agent without a copy-paste. Hermes does this; so does reading git diff after every turn, if you have the patience. 2. Before you push, shape the history. If the result is one blob of a commit, lazygit's hunk staging and custom patches turn it into commits a teammate can follow. 3. Once others are involved, open the PR. Approvals, code owners, required checks and dependency review belong there, and they protect the branch from you as much as from the agent. If you work alone on a side project, step 3 may be a formality. On a team, it isn't optional, and no local tool should pretend otherwise. Hermes's Land step can open the pull request for you. Where do you review agent code today, and what slipped past you because of it? Tell me in the comments. --- If this was useful I build Hermes IDE: it is free to download, source-available under BSL 1.1, runs on macOS, Windows and Linux, and isn't affiliated with Nous Research, Anthropic, OpenAI or any agent vendor. If reviewing by turn sounds useful, try it on your next agent task and star it on GitHub or open an issue when something doesn't match what I wrote here. If the PR-and-CI step is where your small team still improvises, Ship It covers the road from localhost to production: CI/CD, hosting, auth, payments and monitoring, picked for a team without a platform department. 

Lazygit-ல் Git வேலைகள் எல்லாம் ஒரே திரையில் தெரிகின்றன. Stage, commit, rebase ஆகியவை விசைப்பலகையிலேயே முடிகின்றன. முதலில் எதை முயற்சி செய்வீர்கள்? jesseduffield/lazygit Instagram-லும் பின்தொடருங்கள்: instagram.com

⌨️ GitHub 好项目｜Lazygit 把 Git 常用操作放进终端界面：查看差异、按行暂存、整理提交，还支持交互式 rebase 和 worktree。 适合习惯键盘的开发者；需先安装 Git、理解提交与分支。MIT 许可，支持 Windows/macOS/Linux。 jesseduffield/lazygit 图：官方 README 演示截图 t.co

I run a dozen Claude Code sessions at once. This tmux console tells me which one needs me !15 seconds: status bar → picker → jump to the session waiting on you → switch account from the sidebar TL;DR — claude-tmux-sessions is a small set of tmux tools for running many Claude Code sessions in parallel. It answers three questions I kept asking myself: which session is waiting on me, what is everyone doing, and what do I do when one account runs out of quota? MIT, tmux + bash + python3, driven by Claude Code hooks. How I use Claude Code Some context first, or the design will look odd. I use two Claude accounts to push several projects forward at the same time: - One account per project. Each account has a 5-hour and a 7-day usage window. If one busy project shares an account with the others, it stalls them too. With an account per project, each has its own quota. - One session per role inside an account. Algorithms, backend, frontend, testing: one session each, so each context holds only its own part of the work and doesn't drift. - I only make decisions. I don't watch any one terminal. I go over when a session needs a yes/no, or when it has finished and I should look at the result. - Memory lives in files. Project rules, hand-off notes and a dev log are in the repository, so switching accounts or sessions loses nothing. That adds up to a lot of sessions open at once, more than one person can watch. tmux only manages windows; it has no idea what the Claude inside each window is doing. Hence this. Four pieces !The whole screen: Claude on the left, its sidebar on the right, the status bar at the bottom Status bar: who is waiting on you !Status bar: four counts on the left, the window list with a state per window, CPU/memory/swap/disk on the right Each session reports its state through Claude Code hooks, and the status bar counts them: - ⏸ waiting for your confirmation (a permission prompt is open and Claude is idle) — the only state that rings and sends a notification; - ✔ finished, and you haven't looked yet; - ▶ running, nothing to do; - ✓ finished, and you've seen it. The four counts never move: a zero turns grey but keeps its place, so you can click from muscle memory. Click ⏸ to jump to the session that has waited longest; click ✔ to get a list of just the finished-but-unread ones: !Clicking ✔: a picker with only the done-unread sessions floats up from the bottom That list is a tmux 3.7 floating pane, not display-popup, which is why clicking anywhere outside closes it — display-popup swallows clicks outside its box. Picker: what is everyone doing !Picker: grouped by project, numbered rows, live preview of the highlighted session prefix + g lists every session, grouped by tmux session (for me, one per project), with a live view of the one under the cursor. Every row is numbered; type the number to jump. It behaves like an inbox: visiting a session marks it read, and quiet ones fold away by default, so the list shows only what needs you. Sidebar: everything about this one session Every Claude gets a sidebar on its right that is about this session only: - Every turn. What you said and the start of the reply. Click a turn and the main pane scrolls to that turn's final answer. Turns before a /compact fold into one line. It reads the transcript file, not the screen. - Quota. Context, 5-hour and 7-day bars. Grey until something runs well ahead of an even pace. - Buttons. git (with the count of uncommitted files), files, refresh quota, switch account, close. The git and files buttons open lazygit and yazi floating over the right 60 % of the window, so the Claude on the left doesn't re-wrap; click outside and they're gone: !lazygit floating on the right, showing the diff of what Claude just changed Rule of thumb: global things go on the status bar, things about the current session go on the sidebar. The status bar is short on space, and this keeps both uncluttered. Switch accounts: keep going when one runs out Click ⇄ on the sidebar and the session exits, then comes back as claude --resume of the same session id under the other account. Same conversation, same context. There are guard rails: a session that is working is left alone; one with unsent text in its prompt is left alone (exiting would lose it); a window with agent-team teammates first gets a line typed to the lead asking it to wind the team down, and switches once they've exited. Trade-offs I made on purpose - Hooks, not screen scraping, for state. Sessions report their own state when it changes: accurate, no polling, no CPU. The screen is read only where there is no other way ("which turn is where", "is there unsent text"). - An inbox, not a dashboard. Things you've seen turn ✓ on their own and come back when that session does something new. Nobody maintains the list. - Everything is clickable. I work mostly by voice and trackpad, so every segment and button takes a click. Keyboard shortcuts are there too. - When in doubt, don't switch accounts. It skips and tells you why rather than risk losing anything. The rest of my setup The tmux console is one of four pieces. I also dictate almost every prompt with a push-to-talk voice tool (an LLM proofreads each transcript, and Claude adds the words it sees misheard to the vocabulary itself), and look back at usage and configuration in a local web dashboard. That's written up in docs/workbench.md. Try it git clone https://github.com/threedaycat/claude-tmux-sessions.git ~/projects/claude-tmux-sessions ~/projects/claude-tmux-sessions/install.sh --lang en Then add one line to your tmux config, source-file ~/projects/claude-tmux-sessions/tmux/claude-tmux.conf, and put the status-bar segments into your own status line; the README walks through it. Known limits, up front: I use it daily on macOS only (Linux is untested); you need a Nerd Font for the icons; and a few features read Claude Code's screen, so a Claude Code UI change may need a follow-up fix. Issues and PRs welcome.

Git without memorizing commands — LazyGit Git without memorizing commands — LazyGit LazyGit is a free, open-source terminal UI for git. Run one command inside any repo and you get panels for files, branches, commits and stash. Stage a hunk with space, drop to a single line when you only want part of it, and step through merge conflicts with the arrow keys — pick a side with space, take both with b, undo with z. Press c to commit with a message. Interactive rebase, cherry-pick, bisect, amend, worktrees, a commit graph and an undo command, all on keys. Free and open source (MIT), written in Go — 83,108 stars on GitHub. jesseduffield/lazygit #lazygit #git #terminal

Bilgisayarınızda Terminal Varsa Bunları Bilmelisiniz 🖥️ Tier 3 veri merkezinde VDS ve VPS için Netverim'i ziyaret edin 👉🏻 go.yusufipek.me (YUSUFIPEK20 koduyla %20 İNDİRİM) Bu video sponsorumuz Netverim'in reklamını içermektedir. #reklam Orhun Parmaksız ve Ratatui github.com/orhun youtube.com ratatui/ratatui 👉🏻 YouTube'un Metasını Öğrettiğim Kursum: go.yusufipek.me 🔗 Beni bulabileceğiniz diğer platformlar için - go.yusufipek.me 🤝 İşbirlikleri için: go.yusufipek.me 💬 Forum: go.yusufipek.me ━━━━━━━━━━━━━━━━━━━━━━━━ KAYNAKLAR ━━━━━━━━━━━━━━━━━━━━━━━━ 1) Orhun Parmaksız ve Ratatui orhun.dev ratatui/ratatui 2) Swaggerfall holonaut64.itch.io 3) ADS-B TUI j4v3l/ADS-B_TUI 4) Metropolis 5c0/metropolis 5) Textual Paint 1j01/textual-paint 6) Inertia aclfe/inertia 7) Ratty orhun/ratty 8) Zoetrope furkankly/zoetrope 9) llmfit AlexsJones/llmfit 10) btop aristocratos/btop 11) bandwhich imsnif/bandwhich 12) cloudflare-speed-cli kavehtehrani/cloudflare-speed-cli 13) Bufferbloat videom youtube.com 14) Trippy fujiapple852/trippy 15) DNS Globe 514-labs/dnsglobe 16) gdu dundee/gdu 17) lazydocker jesseduffield/lazydocker 18) Patent r14dd/patent 00:00 Giriş 00:39 Orhun Parmaksız ve Ratatui 01:00 Swaggerfall: Terminalde Açık Dünya Oyunu 01:28 ADS-B TUI ile Uçak Takibi 01:48 Metropolis: Sistem Ölçümleri Şehre Dönüşüyor 02:17 Textual Paint ile Terminalde Çizim 02:43 Inertia ile Terminalde Fizik Deneyleri 03:03 Orhun Anlatıyor: 3 Boyutlu Terminal Ratty 05:52 Zoetrope ile Ajan Oturumlarını İzleme 06:27 llmfit: Donanıma Sığan Yerel Modeller 07:00 btop ile Sistem ve Sunucu İzleme 08:29 bandwhich: İnterneti Hangi Program Kullanıyor 08:52 Cloudflare Speed CLI ve Bufferbloat Puanı 09:37 Trippy ile Bağlantının Yolunu İzleme 10:04 DNS Globe ile DNS Yayılımını Kontrol 10:33 gdu: Diskinizi Ne Dolduruyor 10:54 lazydocker ile Docker Hatalarını Bulma 11:21 Patent ile Benzer Projeleri Arama 11:58 Terminal Uygulamaları Daha mı Güvenli?

🔥 [1 Repo Every Developer Should Know] lazygit: The Free Tool Taking Over GitHub! #shorts Discover jesseduffield/lazygit: simple terminal UI for git commands 💬 Comment "LAZYGIT" below for the direct link, or grab it from the links below: 👉 Interactive Star History & Live Analysis: githubrepo.cloud ⭐ Embed Live Verified Badges in your README: githubrepo.cloud 🔗 Direct GitHub Repository: jesseduffield/lazygit 📊 Repository Specs: ⭐ Stars: 82,912 🍴 Forks: 3,063 💻 Language: Go 📜 License: MIT #shorts #lazygit #cli #git #terminal #linux #devops #commandline #sysadmin

Repo link: jesseduffield/lazygit Runs 100% locally — nothing uploads. What paid tool should I replace next?