刃 — シングルバイナリで動作し、サーバーなしで即時P2P同期する Vim 風ガントチャート・ToDoプランナー

Vim のモーダル操作で高速に入力・編集でき、タスク間の依存関係も定義できるローカルファーストなガントチャート・ToDo管理ツール yaiba (刃) を Rust で作りました。

刃 — the blade. A vim-flavoured todo and gantt planner that runs as a single local binary and syncs directly between people.

GitHub - yukimemi/yaiba: 刃 — vim-flavoured todo & gantt planner. One local binary, embedded UI, peer-to-peer sync over iroh.

刃 — vim-flavoured todo & gantt planner. One local binary, embedded UI, peer-to-peer sync over iroh. - yukimemi/yaiba

github.com

なぜ作ったのか

タスク管理ツールを使う際、いつも以下のようなちょっとした不満がありました。

1. ターミナルツール：タイピングやキー操作は高速だが、全体のタイムラインや依存関係を直感的に俯瞰できるガントチャートを描くのが難しい。
2. Webベースのプランナー：美しいガントチャートを描画してくれるが、操作のたびにマウスに手を伸ばす必要があり、データも他人のサーバーに預けなければならない。
3. サーバー管理とアカウントの負担：チームでリアルタイム共有しようとすると、サーバーのセルフホストやアカウント作成・認証の手間が発生する。

「キーボード主体で快適に操作でき、タスクの依存関係とタイムラインが美しく描画され、かつサーバー不要でP2P同期できるツール」が欲しいという思いから開発したのが yaiba です。

yaiba の主な特徴

1. キーボードがそのままインターフェース（Vim モーダル操作）

yaiba は Vim の操作体系を全面的に採用しています。

• o / O で上下に新しいタスクを開いて即入力（Enter または Esc で確定）
• Space で完了（または s で todo → doing → done をトグル）
• dd でタスク削除、u / Ctrl+r で Undo / Redo
• J / K でタスクの上下移動（親の階層レベルに合わせて自動でインデント）
• >> / << でタスクの階層ネスト / 押し出し
• + / - で所要日数（duration）の増減、. / , で開始日の移動
• D で依存関係の追加（先行タスクを指定）、X で解除

キーボードから手を離さずに、プロジェクトのタスク追加・並び替え・スケジュール調整が完結します。

2. 依存関係とクリティカルパスの自動計算

単なるビジュアル的な矢印ではなく、Finish-to-Start（完了後開始）の DAG（有向非巡回グラフ）として依存関係を計算します。

• Forward/Backward pass により、各タスクの「最早開始日」「余裕日数（Slack）」を算出。
• クリティカルパス（Critical Path） を自動検出し、ハイライト表示。「このプロジェクトが実際にいつ終わるのか」を提示します。
• 後続タスクとのラグ日数指定（:dep 3 +5 で5日間の余裕を設定など）や、同日開始（:dep 3 +0）にも対応。

3. ひとつのアウトラインで、俯瞰から詳細まで（視点に応じた階層折りたたみ）

親タスクを持つタスクは自動的に サマリー（まとめタスク） となり、配下のタスクの期間や進捗率を自動で集計します。

• zm / zr で階層レベルを折りたたみ・展開。
• zM で全プロジェクトのサマリーのみを 1 画面に集約して表示（マネージャー視点の全体俯瞰）。
• zR で最も深い実装タスクまで一括展開（作業者視点での詳細確認）。
• zf で選択したサブツリーだけにズームイン、zF で戻る。

同じデータ構造のまま、表示する階層の深さ（視点）を切り替えるだけで、全体像の把握から具体的な作業まで柔軟に対応できます。

4. サーバー不要の P2P 同期 (iroh)

iroh を採用しており、中央サーバーを必要としない直接 P2P 同期を実現しています。

• 各レプリカ（環境）が独立して動作し、編集内容は CRDT（Hybrid Logical Clock を用いた Last-Writer-Wins）により競合なく自動マージされます。
• パブリックキーと UDP ホールパンチングにより、ポート開放やファイアウォール設定なしで相互接続。

同期の手順（ユーザー A がチケットを発行し、ユーザー B が参加する例）：

# 1. ユーザー A (共有元): アプリ内コマンド `:ticket` や起動ログからチケットを取得して B に共有
# チケット例: yaibaticket1abcdef1234567890abcdef1234567890...

# 2. ユーザー B (参加者): A から共有されたチケットを指定して参加（別プロジェクトとして独立保持）
yaiba join yaibaticket1abcdef1234567890... --as project-a

# (アプリを起動したまま UI から `:join yaibaticket1...` でも参加可能)

5. 画面モードと美しい UI（Neon / Office / Super Mode）

利用シーンに合わせて 3 種類のテーマモードを切り替えられます。

• Neon Mode（デフォルト）：サイバーパンク風のネオン HUD。クリティカルパスがマゼンタ色で流れるように強調されます。

• Office Mode (gt または :theme light)：ミーティングや画面共有、印刷向けの静かなデザイン。余計な発光や走査線をカットし、実用的な配色になります。

• Super Mode (gs または :super)：中二病全開・男のロマンを極限まで詰め込んだ覚醒モード。ネオンの発光倍率が解放され、背景に漆黒のオーロラが揺らめき、CRT走査線が走る超絶演出モードです。

  • タイピング即・斬撃：キーを1文字叩くたびにカーソルから閃光の如く斬撃エフェクトが放たれ、タイピングの連打に合わせて打撃音と反動（リコイル）が増幅！
  • 日本語変換は重打：日本語の変換確定（Enter）は、単なる1打鍵を超えた深みのある重厚な一撃として画面に刻み込まれます。
  • タスク完了は衝撃波（ショックウェーブ）：Space でタスクを完了した瞬間、画面全体に強烈な波紋と衝撃波が駆け巡る！
  • タスク削除は画面激震：dd で不要なタスクを滅ぼすと、画面全体がグラリと激しく振る動く！

  ※どんなにエフェクトを限界突破させても、「クリティカルパス＝マゼンタ色」のルールと視覚アクセシビリティ（prefers-reduced-motion 設定時の自動モーションオフ）は厳格に守られる硬派な仕様です。

• 日本語 UI 対応 (:lang ja)：UI全体（ヘルプ、ステータスライン、コマンド拒否メッセージ、列ヘッダー等）を日本語化できます。キー名やコマンド名は統一感を保つため英語のままとなっています。

6. マウス操作と右クリックメニュー

キーボード操作が基本ですが、画面共有時や他人に操作を譲る場合のためにマウス操作もサポートしています。

• タスクやバーのドラッグ＆ドロップ（開始日・期間の調整、並び替え、依存関係の接続）。
• 右クリックメニュー：キーボード操作のショートカットキー（dd, s, gp, zf など）が併記されており、「マウス操作をしながらキーボードショートカットを覚えられる」 ガイドの役割を果たします。

7. 計画 vs 実績 (Plan vs Actual) と イナズマ線 (Progress Line)

• 計画日付（start, duration）と実績日付（began, ended）を両方記録。
• gd で計画と実績の列表示（Date Columns）とコンパクト表示をトグル。
• 基準日（As-of date）を設定可能（:asof -3d や top バーの日付クリック）。
• ガントチャート上に イナズマ線 を描画。基準日に対して各タスクが予定通りか、遅れているか（左への折れ）、進んでいるか（右への膨らみ）が視覚的にひと目で把握できます。

8. 複数プロジェクト管理 (projects.toml)

ひとつの yaiba プロセスで複数のプロジェクト（データベースファイル）を登録・切り替え可能です。

• :proj またはトップバーのプロジェクト名クリックで曖昧検索（Fuzzy Picker）つきのプロジェクト切り替えダイアログを起動。
• P2P で参加した相手のタスク群は別プロジェクトとして孤立して保持されるため、自分のバックログと混ざる心配がありません。
• 完全に融合させたい場合は yaiba merge <ticket> を使用します。

9. AI エージェント連携 (yaiba mcp)

Model Context Protocol (MCP) に対応しており、Claude Code や Cursor などの AI エージェントから計画の参照・更新が可能です。

# バックグラウンドで起動中の yaiba に対して MCP サーバーを登録
claude mcp add yaiba -- yaiba mcp

エージェントは plan ツールで依存関係やクリティカルパス・遅延状況を把握し、add_task や link ツールでタスクの分解やリンク設定を自律的に行えます。

例えば、GitHub の Issue 群やロードマップのテキストを渡して 「この内容を元に、タスクを起こしてスケジュールを組んで」 と頼むだけで、適切な親子の階層構造や依存関係（クリティカルパス含む）が設定されたガントチャートがあっという間に組み上がります。

手動でタスクを1つずつ打ち込んで繋ぐ手間すらなくなり、AI と対話するだけでプロジェクト計画の初動が完了します。

インストールと使い方

インストール

crates.io からインストールするか、GitHub Releases からビルド済みバイナリ（Linux / macOS / Windows）をダウンロードします。

cargo install yaiba

クイックスタート

ターミナルで yaiba を実行すると、ローカルサーバーが起動し、自動的にブラウザで http://localhost:8188 が開きます。

# 起動（デフォルトでブラウザが開きます）
yaiba

# ポート変更やブラウザ起動なし
yaiba --port 9000 --no-open

# ネットワーク非接続（完全ローカルモード）
yaiba --no-sync

主なキーバインド・コマンド

おわりに

yaiba を作ったことで、「思考の速度でタスクを打ち込み、そのまま依存関係とタイムラインを組み上げ、必要に応じてP2PでチームやAIと共有する」という理想のタスク管理環境が手に入りました。

Webアプリケーションですがシングルバイナリとしてローカルで完結し、動作も非常に軽快です。打鍵感を極めた Super Mode でのタスク消化は癖になる爽快感があります。

「マウス中心のガントチャートツールにストレスを感じている方」「Vim のキーバインドでサクサク工程管理をしたい方」「サーバーなしでシンプルにタスクを同期したい方」は、ぜひ yaiba を試してみてください！

GitHub - yukimemi/yaiba: 刃 — vim-flavoured todo & gantt planner. One local binary, embedded UI, peer-to-peer sync over iroh.

刃 — vim-flavoured todo & gantt planner. One local binary, embedded UI, peer-to-peer sync over iroh. - yukimemi/yaiba

github.com

結 — ライブ設定を直接編集すれば、ソースリポジトリが自動で更新される

自作の dotfiles 管理ツール yui (結) を Rust で作りました。長年愛用してきた chezmoi から移行し、現在は自分の dotfiles リポジトリをこの yui で管理しています。

GitHub - yukimemi/yui: Target-as-truth dotfiles manager. Edit your live configs, source repo updates automatically via hardlink/junction/symlink.

Target-as-truth dotfiles manager. Edit your live configs, source repo updates automatically via hardlink/junction/symlink. - yukimemi/yui

github.com

なぜ作ったのか

dotfiles を長年 chezmoi などのツールで管理していて、どうしても拭いきれなかった 3 つの「気になる点」がありました。

1. 「編集して適用する」という 2 ステップの儀式 (edit-source-then-apply tax)
   • 設定ファイル（例えば target 側の ~/.config/nvim/init.lua など）をちょっといじりたいだけなのに、「リポジトリ内のソースファイルを編集 → chezmoi apply を実行して target 側に適用する」という 2 ステップの儀式が毎回発生し、テンポが悪かった。
2. ソースとターゲットのドリフト (Source ↔ Target drift)
   • アプリケーションが target 側の設定ファイルを直接上書き・編集した際、ソースリポジトリとの間に乖離（ドリフト）が発生し、次の chezmoi diff で初めて気づく。
3. 未追跡の新規ファイル (Untracked new files)
   • Neovim やその他のツールが管理対象ディレクトリ内に新しくファイルを作成しても、手動で chezmoi add をしない限り、リポジトリ側では未追跡のまま放置されてしまう。

これらを解決するために、「対象 (target/ホームディレクトリ) を Truth (真実) にする」という逆転の発想で設計したのが yui です。

yui のアプローチ: Target as Truth

yui は、chezmoi の流れを反転させるだけではありません。 yui apply を一度実行して、ソースリポジトリ（source）と target 側のファイルを物理的なリンクで接続してしまえば、それ以降は設定を変更するたびに yui apply を走らせる必要がなくなります。

物理リンクによって実体（inode）を共有しているため、エディタ等による target 側への書き込みが、そのまま自動的かつ即時に source 側の書き込みとして反映されます。

Windows でのデフォルト設定は意図的なものです。ハードリンクとジャンクションはどちらも管理者権限なしで作成可能で、多くのエディタの「アトミック保存」時にも壊れにくいためです。

このアプローチにより、エディタやアプリから target 側の設定ファイルへ書き込むだけで、リポジトリ側も自動で更新されます。もう「編集した後に apply を実行する」という手間はありません。

リンク接続のイメージ（ファイルツリー）

基本の配置ルールはリポジトリ直下の config.toml で定義します（例：home/ 配下を ~ にマウント）。yui apply を実行すると、その配下のファイルやフォルダが自動的にリンクされます。

OS別に異なるリンク先を設定したい場合や、デフォルトの配置ルールとは異なる特別な場所にリンクしたい場合は、[[link]] エントリを宣言します。宣言する場所は「対象ディレクトリ内の .yuilink マーカー」と「config.toml の中央 [[link]] テーブル」の 2 択で、どちらも書式は同じです（詳細は後述）。

[Source リポジトリ側] (~/.dotfiles/)
├── config.toml                     # マウント定義 (例: home/ -> ~/) とフック設定
├── home/                           # 基本的にこの配下が自動でリンクされる
│   ├── .gitconfig.tera             # テンプレートファイル
│   ├── .gitconfig                  # レンダリング結果 (gitignored) ━ [デフォルト: Hardlink/Symlink で自動リンク]
│   └── .config/
│       └── nvim/                   # 基本はそのまま ~/.config/nvim/ に自動マッピングされるが...
│           ├── init.lua
│           └── .yuilink            # 🌟Windows用に別の特別なパスを追加で指定するマーカー
└── .yui/
    ├── backup/                     # 自動バックアップ先
    └── state.json                  # マシンごとの状態管理

            │
            ▼ yui apply 実行 (Linux / macOS の場合)
            │

[Dest システム側 (Unix)] (~)
├── .gitconfig                      # (自動接続) home/.gitconfig とリンク共有
└── .config/
    └── nvim/                       # (自動接続) home/.config/nvim/ とリンク共有
        └── init.lua

            │
            ▼ yui apply 実行 (Windows の場合)
            │

[Dest システム側 (Windows)] (~)
├── .gitconfig                      # (自動接続) home/.gitconfig と物理リンクを共有
├── .config/
│   └── nvim/                       # (自動接続) home/.config/nvim/ と物理リンクを共有
│       └── init.lua
└── AppData/Local/nvim/             # 🌟(.yuilink の指定により、こちらにも追加でリンク共有)
    └── init.lua

アトミック保存対策と AutoAbsorb (吸い込み)

エディタによっては、ファイルを保存する際に「一時ファイルに書き出してから元のファイル名にリネームする」というアトミック保存を行います。これを行うと、せっかく張ったハードリンクやシンボリックリンクが切れてしまいます。

これを解決するために、yui は apply や status を実行した際、ファイルID (inode や file index) の一致をチェックします。リンクが切れてしまっている場合、yui の Absorb Classifier が以下のように状況を判定します。

エディタのアトミック保存でハードリンクが切れて内容が変更された場合、それは AutoAbsorb と判定されます。yui は自動的にリポジトリ側のファイルをバックアップした上で、実ファイル（target）の変更内容をリポジトリ（source）に吸い込み、再度リンクを張り直します。

これにより、リンク切れを気にする必要すらなくなります。

特別な配置やOSごとの振り分けを行う [[link]] 宣言

基本的には config.toml に home/ を ~（ホーム）へマウントする定義を 1 つ書くだけで、配下のディレクトリ（例：home/.config/nvim）も自然にターゲット（~/.config/nvim）へとマッピングされます。

しかし、「OS別にマッピング先を変えたい」「デフォルトの配置ルールから外れる特定の場所へ個別リンクしたい」「ディレクトリを丸ごと 1 本のリンクにしたい」といった場合には、[[link]] エントリを宣言します。書く場所は 2 つあり、スキーマは共通です。

1つのソースから複数のターゲットへのリンク振り分け

例えば、Neovim の設定を Unix ではデフォルトの ~/.config/nvim に配置しつつ、Windows では LOCALAPPDATA/nvim にもマッピングしたいとします。マーカーで書く場合は、home/.config/nvim/.yuilink に以下のように記述します。

# $DOTFILES/home/.config/nvim/.yuilink
[[link]]
dst = "{{ env(name='LOCALAPPDATA') }}/nvim"
when = "yui.os == 'windows'"

config.toml に集約する場合は、対象を src で指定します。

# $DOTFILES/config.toml
[[link]]
src = "home/.config/nvim"
dst = "{{ env(name='LOCALAPPDATA') }}/nvim"
when = "yui.os == 'windows'"

これによって、yui apply は環境（OS）の判定を評価し、Windows の場合であれば通常の ~/.config/nvim へのマッピングに加え、追加で AppData/Local/nvim にも物理リンクをマッピングしてくれます。

ディレクトリ丸ごとのリンクと、マーカーの「見え方」

[[link]] で ディレクトリを指定すると、そのディレクトリ自体が 1 本のリンク（Windows ならジャンクション）になります。中のファイルを 1 つずつリンクするわけではないので、アプリがそのディレクトリに新しく作ったファイルもそのまま source 側に現れます。冒頭に挙げた「未追跡の新規ファイル」問題がそもそも発生しない状態です。

加えて、アプリが設定ファイルをアトミック保存（一時ファイルを書いて rename）する場合、ファイル単位のハードリンクは切れて毎回ドリフト扱いになりますが、ディレクトリのジャンクションはこの経路では壊れません。

注意点として、この「ディレクトリ丸ごと」を .yuilink で宣言すると、target 側から見たディレクトリの中にマーカー自身も見えます（例：~/.omp/.yuilink）。アプリの設定ディレクトリにツール固有のファイルを置きたくない場合は、中央テーブルで宣言すると綺麗に収まります。

その他の特徴

• テンプレート (*.tera) と teravars による柔軟な出し分け

  • Tera テンプレートエンジンをサポートしています。.tera サフィックスの付いたテンプレートファイルはレンダリングされ、出力される実ファイル（.tera サフィックスを落とした実設定ファイル）は自動的に .gitignore の専用セクション（# >>> yui rendered ～ <<< の間）へ追記され、コミット対象から除外されます。 手動で .gitignore を編集する必要がなく、レンダリング後の中間ファイルを誤ってコミットしてしまう心配がありません。
  • yui は内部で teravars ライブラリを採用しており、環境変数やシステムコンテキスト（OS、アーキテクチャ等）に加え、config.toml の [vars] テーブルで定義した任意の変数にアクセスできます。
  • さらに、Git管理から除外される config.local.toml を各マシンに配置し、その中で [vars] の上書き定義（オーバーライド）を行うことで、マシンごとの微調整をシームレスに行えます。

  具体例：AutoHotkey の設定切り分け

  自宅の個人PCと、会社の仕事用PCで AutoHotkey (.ahk) のキー割り当てや起動アプリを切り分けたい場合の実例です。

  リポジトリでコミットする config.toml には、共通のデフォルト定義を書いておきます。

  # $DOTFILES/config.toml (共通設定)
  [vars.autohotkey]
  purpose = "home"
  use_new_outlook = true
  use_excel = false
  use_neovide = true
  

  仕事用PCには、Git管理外の config.local.toml を作成して仕事用の変数で上書きします。

  # $DOTFILES/config.local.toml (仕事用PCのローカルのみ、gitignored)
  [vars.autohotkey]
  purpose = "work"
  use_excel = true         # 仕事用PCでは Excel ショートカットを有効にする
  use_new_outlook = false  # Classic Outlook を使う
  

  そして、設定ファイル AutoHotkey.ahk.tera では、これらの変数を使って条件分岐を記述します。

  ; Outlook (New か Classic か)
  ^F9::
  {
  {%- if vars.autohotkey.use_new_outlook %}
    Activate(EnvGet("LOCALAPPDATA") . "\Microsoft\WindowsApps\olk.exe")
  {%- elif vars.autohotkey.purpose == "home" %}
    Activate(EnvGet("LOCALAPPDATA") . "\Microsoft\WindowsApps\olk.exe")
  {%- else %}
    Activate("C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE")
  {%- endif %}
  }
  
  ; Excel (必要な場合のみキー割り当てを有効化)
  {%- if vars.autohotkey.use_excel %}
  F9::
  {
    Activate("C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE")
  }
  {%- endif %}
  

  このように記述しておくことで、yui apply を叩いた時にそれぞれのマシン固有の設定（自宅PCなら New Outlook の起動、仕事用PCなら Classic Outlook 起動や Excel ホットキー有効化）が施された AutoHotkey.ahk が自動生成されます。

• 秘密情報の暗号化 (*.age)

  • age による暗号化をサポートしています。Bitwarden や 1Password といった Vault ツールと連携し、新しいマシンで yui secret unlock を実行するだけで秘密鍵を復元できるセキュアな仕組みも用意されています（※セットアップ方法や Vault 連携などの詳細な手順は、yui の README (Secrets) をご参照ください）。

• フック (hooks)

  • apply の前後に走らせるフックを設定可能。スクリプトファイルの SHA-256 が変化したときだけ走る when_run = "onchange" など、きめ細かい制御ができます。
  • Deno で書いたスクリプトを走らせることも簡単です。

--git-hooks による安全策

yui init --git-hooks を実行すると、リポジトリの .git/hooks/ に pre-commit と pre-push のフックがインストールされます。

これらのフックの中身は、いずれも yui render --check を実行するシンプルなものです。

• pre-commit: コミット時に、もしテンプレート（*.tera）からレンダリングされた結果と、実際にステージされているファイルに乖離（ドリフト）がある場合、コミットを拒否します。これにより「適用（yui apply や yui render）を忘れたままコミットしてしまった」というイージーミスを防げます。
• pre-push: プッシュ時にも同様のチェックを行います。--no-verify などでコミット時のチェックをバイパスした場合のセーフティネットとして機能し、乖離した状態のままリモートにプッシュされるのを防ぎます。

インストールとクイックスタート

インストール

cargo install yui-cli

クイックスタート

# リポジトリの初期化と git hooks の設定
yui init --git-hooks

# $DOTFILES/config.toml を編集してマウントを定義

config.toml の最小構成例：

[[mount.entry]]
src = "home"
dst = "~"

[[mount.entry]]
src  = "appdata"
dst  = "{{ env(name='APPDATA') }}"
when = "yui.os == 'windows'"

あとは以下のコマンドで操作します：

yui apply   # テンプレート描画 + リンク作成 + ドリフトの自動吸い込み
yui status  # ドリフト状態のチェック
yui list    # マッピング一覧の表示
yui diff    # 乖離しているファイルの差分表示
yui doctor  # 環境チェック

おわりに

yui を導入したことで、dotfiles 編集の心理的摩擦がほぼゼロになりました。 「あ、Neovim の設定ファイルちょっと書き換えよう」と思った瞬間にいつものエディタで直接開き、保存するだけで、自動的にリポジトリ側のソースが更新されます。あとは必要に応じてリポジトリでコミットするだけです。

「chezmoi の 2ステップの儀式がめんどくさい」「実機設定とリポジトリの同期をシームレスに行いたい」という方は、ぜひ yui を試してみてください。

GitHub - yukimemi/yui: Target-as-truth dotfiles manager. Edit your live configs, source repo updates automatically via hardlink/junction/symlink.

Target-as-truth dotfiles manager. Edit your live configs, source repo updates automatically via hardlink/junction/symlink. - yukimemi/yui

github.com

Claude Code と一緒に Rust 製の CLI を作るのが楽しくて、ここ最近で shun / rvpm / todoke / yui / renri といった CLI がどんどん増えていきました。これらにまったく同じボイラープレートを適用しつづけるためのメタテンプレート CLI、kata (型) を作りました。

型 — the woodblock pattern. 各プロジェクトに同じ型を押し当てる、版木のイメージです。

GitHub - yukimemi/kata: Multi-project template applier with AI-delegated merge

Multi-project template applier with AI-delegated merge - yukimemi/kata

github.com

なぜ作ったのか

同じような CLI が増えてくると、共通ボイラープレートのメンテがどんどんしんどくなります。具体的にしんどかったのはこのあたりです。

• Makefile.toml の check / clippy / test タスクの並び
• .github/workflows/ci.yml の OS マトリクスと action のバージョン pin
• .github/workflows/release.yml の cross-compile + cargo publish のテンプレ
• rustfmt.toml / clippy.toml / rust-toolchain.toml の方針
• apm.yml で APM 経由の AI エージェント用 skill (renri など) を入れる定型
• renovate.json の auto-merge ルール
• そして極めつけに AGENTS.md / CLAUDE.md / GEMINI.md

最後の AGENTS.md がいちばんやっかいでした。Claude / Gemini / Codex に渡している「PR レビューはこう回す」「worktree workflow はこう」「Rust の lint/format ポリシーはこう」みたいな会話で蓄積されたノウハウを、新しいプロジェクトを生やすたびに、あるいは規約を 1 行直すたびに、N 個のリポジトリにぜんぶ手でコピペする必要があったのです。

「Gemini Code Assist と CodeRabbit 両方のレビュー待つようにしよう」と気付いたら 7 個のリポジトリの AGENTS.md を全部開いて編集する、というのを何度かやりました。1 回ならいいんですけど、規約は一度決めて終わりじゃなくて、運用しながら何度も微調整したくなる。

copier / cookiecutter / cruft といった既存ツールは「最初のプロジェクト生成」と「機械的な再適用」までは面倒を見てくれるんですが、AGENTS.md のように

• リポジトリ共通のセクション (PR レビュー規約、worktree workflow)
• プロジェクト固有のセクション (このプロジェクトのアーキ概要、特殊な事情)

が1 枚のファイルに同居しているようなものを update し続ける機能はありませんでした。AI に判定を委譲するモードもありません。

そこで作ったのが kata です。「型 (テンプレート) を版木のように押し当てて、押し当てきれないところだけ AI に判断させる」 という発想で設計しました。

kata の特徴

• layered template — pj-base + pj-rust + pj-rust-cli を順に重ねて、後勝ち。言語非依存な部分を pj-base に集約できる
• how × when の二軸 — how (overwrite / merge-section / merge-toml / merge-yaml / ai / script) と when (once / always / manual) が独立。how="ai", when="once" と how="script", when="always" がどちらも自然に書ける
• marker-bracketed merge-section — AGENTS.md の <!-- kata:agents:base:begin --> ～ <!-- kata:agents:base:end --> の間だけを kata が管理。プロジェクト固有の節は外側にいくらでも書ける
• path-based merge-toml — Makefile.toml の tasks.check / tasks.clippy / tasks.test だけを kata が所有して、tasks.install-local のような独自タスクは触らない
• AI 委譲 — how = "ai" なファイルは、インストール済みの claude / gemini / codex CLI に template の diff と現在の中身を投げて、chezmoi 風の [a]ccept / [e]dit / [s]kip / [d]efer で確認
• truth は PJ 側 — どのテンプレートをどの rev で適用したかは各 PJ の .kata/applied.toml に記録される。グローバル設定は単なる PJ パスのレジストリ
• 並列実行 — tokio で PJ をファンアウト、AI 呼び出しは semaphore で抑制してエージェント CLI の同時起動が爆発しないようにする
• CI 同期 — kata-apply.yml を pj-base が配布。daily で kata update + kata apply を回して、テンプレ上流の変更を PR として自動取り込み

インストール

cargo install kata

kata --version で動作確認できれば OK です。

クイックスタート

# 新しい Rust CLI プロジェクトに rust-cli プリセットを適用
mkdir my-rust-cli && cd my-rust-cli
kata init github.com/yukimemi/pj-presets:rust-cli --non-interactive

# テンプレが進化したら再適用 (idempotent)
kata apply --non-interactive

# 適用前のドライラン
kata status

# 何が tracked か確認
kata list

これで Makefile.toml / apm.yml / renri.toml / .github/workflows/ci.yml / release.yml / AGENTS.md / CLAUDE.md / GEMINI.md / rustfmt.toml / clippy.toml / rust-toolchain.toml / renovate.json などがまとめてプロジェクトに落ちてきます。

preset = テンプレートの束

pj-presets:rust-cli は単に「どのテンプレートを、どの順に重ねるか」を書いた小さなファイルです。

# pj-presets/rust-cli.toml
name = "rust-cli"

[[templates]]
source = "github.com/yukimemi/pj-base"

[[templates]]
source = "github.com/yukimemi/pj-rust"

[[templates]]
source = "github.com/yukimemi/pj-rust-cli"

順に書かれた順番で適用され、同じファイルが衝突したら後勝ちです。これによって

• pj-base — 言語非依存 (LICENSE, .gitignore, AGENTS.md の共通節, apm.yml, renri.toml の base, kata-apply.yml ……)
• pj-rust — Rust 共通 (Makefile.toml, CI matrix, rust-toolchain.toml, rustfmt.toml, clippy.toml)
• pj-rust-cli — CLI 用追加 (release.yml の cross-compile + cargo publish)

という役割分担ができて、たとえば「Rust ライブラリだから CLI 用 release は要らない」というケースには pj-rust-lib を組み合わせた別 preset を用意するだけで済みます。

ライブラリ向けに rust-lib、Web フロント向けに web-react、Firebase まで含む web-react-firebase も用意していて、preset 単位で気軽に「型」を切り替えられます。

how と when を独立に持つということ

kata の設計でいちばんこだわったのが how (適用方法) と when (タイミング) を別の軸として持つことです。

この 2 軸が独立なので、たとえば

• release.yml は overwrite, when=once — 初回だけ配って、以降はプロジェクト側で自由に編集
• ci.yml は overwrite, when=always — CI は常に上流追従
• Makefile.toml は merge-toml, when=always — kata 所有のタスクだけ追従
• AGENTS.md は merge-section, when=always — マーカーの中だけ追従
• apm.yml は overwrite, when=once — 初回テンプレ、以降はプロジェクト側
• LICENSE は overwrite, when=once — 初回だけ

という細かいポリシーを 1 つの manifest で表現できます。「mode」として 1 つの enum にまとめなかったのは、how="ai", when="once" (ROADMAP.md の初期生成だけ AI に任せる) のような組み合わせを潰したくなかったからです。

AGENTS.md の merge-section が刺さるところ

kata を入れて一番恩恵を感じているのが AGENTS.md の扱いなので、ここは少し詳しく書きます。

pj-base 側の AGENTS.md.base (テンプレ) には共通規約だけが書かれています。

## Shared conventions

This file is the agent-agnostic source of truth (per the
[agents.md](https://agents.md) convention)...

### Git workflow
- **No direct push to `main`.** Open a PR.
- Branch names: `feat/...`, `fix/...`, `chore/...`.
- **PR titles + bodies in English.**
...

### PR review cycle
- Every PR runs reviews from **Gemini Code Assist** and **CodeRabbit**...
- **After opening a PR, immediately enter the review-monitoring loop...**
...

### Worktree workflow
Use [`renri`](https://github.com/yukimemi/renri) for any commit-bound change...

これを pj-base/template.toml でこう宣言しています。

[[file]]
src = "AGENTS.md.base"
dst = "AGENTS.md"
how = "merge-section"
when = "always"
marker = { begin = "<!-- kata:agents:base:begin -->", end = "<!-- kata:agents:base:end -->" }

kata apply を実行すると、各プロジェクトの AGENTS.md の対応マーカーの中だけがテンプレ内容で置き換わります。マーカーの外にはそのプロジェクトの固有の事情 (アーキテクチャ、設計判断、ドメイン用語、Phase n の状況……) をいくらでも書いておけて、それは kata apply で一切触られません。

さらに layered なので、pj-rust は <!-- kata:agents:rust:* -->、pj-rust-cli は <!-- kata:agents:rust-cli:* --> とそれぞれ自分のマーカーブロックを所有します。これによって 1 枚の AGENTS.md の中に「言語非依存 / Rust 共通 / Rust CLI 専用 / プロジェクト固有」の 4 層が綺麗に同居する、という構造になります。

Makefile.toml の merge-toml で「kata 所有タスク」だけ追従させる

AGENTS.md の marker と並んでよく使うのが、Makefile.toml の merge-toml です。pj-rust/template.toml ではこう宣言しています。

[[file]]
src = "Makefile.toml"
how = "merge-toml"
when = "always"
# kata owns these specific tasks; everything else is left untouched
paths = [
    "tasks.default",
    "tasks.check",
    "tasks.fmt",
    "tasks.fmt-check",
    "tasks.clippy",
    "tasks.test",
    "tasks.lock-check",
    "tasks.publish-dry",
    "tasks.hook-install",
    "tasks.apm-install",
    "tasks.setup",
    "tasks.on-add",
]

paths で「kata が所有する TOML のパス」を明示します。tasks.check / tasks.clippy / tasks.test のような kata-managed task は毎回上流から上書きされますが、consumer 側で勝手に追加した tasks.install-local とか tasks.deploy のような独自タスクは paths に含まれないので一切触られない という挙動になります。

merge-toml は toml_edit で paths で指定した key だけを replace していくので、

• 同じ key の値は更新される (例: tasks.check.script の中身が変わる)
• paths に出てこない key は consumer の手書きが完全に保持
• インデント / コメント / 順序も toml_edit レベルで保持

という、overwrite だと潰してしまう手書き内容を尊重した同期ができます。

GHA の action バージョンは .kata/vars.toml に切り出して Renovate に任せる

merge-toml × when = "once" のもう 1 つの実用例が、GitHub Actions の version pin を .kata/vars.toml (Tera 変数ファイル) に切り出す パターンです。

考えたい問題はこうです。

• ci.yml / release.yml / kata-apply.yml の version pin (actions/checkout@v6.0.2 等) を Renovate に自動 bump させたい
• しかし workflow 本体は overwrite, when=always で kata-managed なので、Renovate が直接 ci.yml を編集しても次の kata apply で潰されてしまう

解決策は、pin だけを .kata/vars.toml に切り出して、workflow 本体は Tera テンプレでそれを参照 することです。

pj-base/vars.toml (universal pin):

[actions]
checkout = "actions/checkout@v6.0.2"
create_pull_request = "peter-evans/create-pull-request@v8.1.1"

pj-rust/vars.rust.toml で Rust 専用の pin を追加マージ:

[actions]
swatinem_rust_cache = "Swatinem/rust-cache@v2"

template.toml 側で .kata/vars.toml の所有関係を宣言:

# pj-base — universal pin を初回だけ seed
[[file]]
src = "vars.toml"
dst = ".kata/vars.toml"
how = "overwrite"
when = "once"

# pj-rust — Rust 専用 pin を merge-toml で重ねる (初回だけ)
[[file]]
src = "vars.rust.toml"
dst = ".kata/vars.toml"
how = "merge-toml"
when = "once"
paths = ["actions.swatinem_rust_cache"]

両方とも when = "once" なので、初回 apply で seed したあとは consumer の .kata/vars.toml を kata は一切触らない、という所有関係になります。ci.yml.tera の中では:

- uses: {{ vars.actions.checkout }}
- uses: {{ vars.actions.swatinem_rust_cache }}

として参照されているので、.kata/vars.toml の pin が変われば次の kata apply で ci.yml 全体が新しい version で再レンダリングされる、という流れになります。

その上で consumer 側の .kata/vars.toml を Renovate の customManager が scan していて、新しい action リリースが出たら .kata/vars.toml の pin 値を bump する PR を作ってくれます。Renovate が触るのは .kata/vars.toml の 1 行だけ、workflow 本体は kata-apply の再レンダリングで反映、という分業になります。

まとめると、

• workflow の構造変更 (新ステップ追加、jobs の整理など) → 上流テンプレへの push → daily kata-apply で降りてくる
• action の version bump → consumer の .kata/vars.toml を Renovate が自走で書き換える → 次の kata apply で ci.yml が再レンダリング

という、役割分担の明快な並列同期が merge-toml と when = "once" の組み合わせだけで組めます。

ところで、上の ci.yml.tera で {{ vars.actions.checkout }} のように書けているのは Rust 製のテンプレートエンジン Tera のおかげです。.tera サフィックスの付いたファイルが apply 時に Tera で render されて、suffix を落とした名前で consumer に書き出される、というシンプルな仕組み。{% if is_windows() %} のような分岐も {{ env.HOME }} のような環境変数参照も全部 Tera の機能で、kata 側はほぼ何も再発明していません。

実はこの「設定を Tera で書ける」感覚は、rvpm や todoke といった他の Rust 製 CLI でも同じスタックで提供していて、内部では teravars (Tera + vars + include + system context を統一した薄いラッパー) を共有しています。rvpm で見慣れた {% if is_windows() %} がそのまま kata の template でも通る、というのが地味に効いていて、Rust で「設定が宣言的に書ける小さな CLI」を作るときの定番スタックとして teravars はかなりおすすめです。

ここが本題: pj-base を直せば全プロジェクトに反映される

これが kata を作って一番うれしかったところです。

「あ、AGENTS.md のこの一節、ちょっと書き方が悪かったな。Claude が誤解しがちだから直したい」 「PR review cycle の節、CodeRabbit の rate-limit notice の扱いを追記したい」 「Worktree workflow の節に新しい renri prune の説明を入れたい」

こういう気付きは規約を運用してるとめちゃくちゃ頻繁にあります。kata を入れる前は N 個の AGENTS.md を全部開いて同じ編集を N 回繰り返す ことになっていました。

kata を入れた今はこうなっています。

# pj-base 側でだけ直す
cd ~/src/github.com/yukimemi/pj-base
$EDITOR AGENTS.md.base
git commit -am "docs(agents): clarify PR review cycle"
git push

# あとは何もしなくていい — 翌日になれば、
# kata-apply ワークフローが全 PJ に PR を作って auto-merge する

具体的には、各プロジェクトの .github/workflows/kata-apply.yml (これも pj-base 配布) が毎日 03:17 UTC に走って、

1. 上流テンプレ (pj-base / pj-rust / pj-rust-cli) の最新 rev を取得
2. kata update で applied.toml の rev を更新
3. kata apply --non-interactive --no-ai で再レンダリング
4. 差分が出たら kata-apply/auto ブランチに PR を作成
5. CI が緑なら auto-merge

を全リポジトリで自動的に回します。規約や設定の更新が該当するテンプレレイヤへの 1 push だけで N プロジェクトに伝播していくわけです。AGENTS.md の共通節なら pj-base、Makefile.toml / rustfmt.toml / clippy.toml / ci.yml といった Rust 共通の規約なら pj-rust、release.yml の cross-compile + cargo publish なら pj-rust-cli、というレイヤ分担そのままに、それぞれの上流に 1 push すれば全 consumer PJ が翌日には追従します。

ワークフロー本体もテンプレ管理なので、ワークフロー自体の改善 (新しい action バージョン、ステップの追加) も同じ仕組みで自動的に各プロジェクトに降りていきます。テンプレが自分自身のメンテも見るかたち。

CI で kata-apply を回す

このフローの肝は CI で kata apply を回せることです。設計時点でここを最優先に考えていて、

• --non-interactive でプロンプトを完全にスキップできる
• --no-ai で AI ファイルを丸ごとスキップ (= 機械的なテンプレ同期だけ自動で回せる)
• --non-interactive --yes で「全部 accept」モードもあり (= 信頼できるテンプレなら AI も自動 accept)

という 3 つのフラグで CI 適性が担保されています。

pj-base が配布する kata-apply.yml.tera の中身は essentially こんな感じです (一部抜粋)。

name: kata-apply

on:
  schedule:
    - cron: "17 3 * * *"     # 03:17 UTC daily
  workflow_dispatch:

permissions:
  contents: write
  pull-requests: write

concurrency:
  group: kata-apply
  cancel-in-progress: false

jobs:
  apply:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6.0.2
        with:
          token: ${{ secrets.KATA_APPLY_TOKEN }}    # ← PAT 必須

      - name: Install kata
        run: |
          KATA_VERSION="$(curl -fsSL https://api.github.com/repos/yukimemi/kata/releases/latest | jq -r .tag_name)"
          curl -fsSL "https://github.com/yukimemi/kata/releases/download/${KATA_VERSION}/kata-x86_64-unknown-linux-gnu.tar.gz" \
            | tar xz -C /tmp
          sudo mv /tmp/kata /usr/local/bin/kata

      - name: kata update + apply
        run: |
          kata update
          kata apply --non-interactive --no-ai

      - name: Open / update PR if there are changes
        id: cpr
        uses: peter-evans/create-pull-request@v8.1.1
        with:
          token: ${{ secrets.KATA_APPLY_TOKEN }}
          branch: kata-apply/auto
          title: "chore(kata): auto-apply"

      - name: Enable auto-merge
        if: steps.cpr.outputs.pull-request-number != ''
        env:
          GH_TOKEN: ${{ secrets.KATA_APPLY_TOKEN }}
        run: |
          gh pr merge --auto --squash ${{ steps.cpr.outputs.pull-request-number }}

要点だけハイライトしておきます。

• KATA_APPLY_TOKEN は GITHUB_TOKEN じゃダメ。GITHUB_TOKEN 経由で開いた PR は GitHub のループ防止仕様で下流ワークフロー (CI) を triggers しません。auto-merge の前提が CI 緑判定なので、CI が走らないと永遠にマージされません。適切な権限 (contents: write + pull-requests: write) を付けた PAT (fine-grained でも classic でも可) を KATA_APPLY_TOKEN リポジトリシークレットとして設定する、というのが consumer 側の唯一のセットアップ作業です
• ブランチは kata-apply/auto 固定。create-pull-request の delete-branch: true と組み合わせると、毎日新しい差分を同じブランチに rolling で上書きしていく動きになるので、PR が大量にスタックしません
• CI が落ちたら PR は open のまま残る。auto-merge は CI 緑になったときだけ発火するので、何か壊れたら人間が見るタイミングが自然に生まれます
• cron: "17 3 * * *" は意図的な off-peak かつ off-the-hour pin。0 0 * * * や 0 9 * * * みたいに :00 ちょうどでスケジュールする人が地球上に多すぎて、GitHub Actions の runner プールが :00 / :30 で枯渇する (cron-storm) という現象があります。:17 のような半端な分にずらすと runner 確保がスムーズ。さらに 3 UTC は日本時間 12:00 / 米西海岸の夜 / 欧州早朝で、runner 自体も比較的空いている時間帯なので、daily な機械的同期にはちょうどいい枠です

「全プロジェクトに同じワークフローが入っている」という事実が、全プロジェクトに同じ自動同期がかかっている という安心感に繋がっていて、これは入れた価値が大きかったです。

AI 委譲モード

how = "ai" を指定したファイルは、インストール済みの AI CLI に判断を投げます。

template.toml にこう書くと:

[[file]]
src = "ROADMAP.md.tera"
dst = "ROADMAP.md"
how = "ai"
when = "always"
agent = "auto"                # claude > codex > gemini で最初に見つかったやつ
prompt = """
Merge the template's structural changes into the project's
ROADMAP.md. Preserve project-specific phases and dated entries.
"""

kata は template の diff、現在の dst の中身、prompt をまとめて指定エージェントの CLI (claude -p, gemini -p, codex exec のいずれか) に投げます。返ってきた full body または patch に対して、chezmoi 風の対話プロンプトが出ます。

proposed change for ROADMAP.md:
  + Phase 5 — opencode adapter
  + ## Crate structure (regenerated section)
  ...

[a]ccept / [e]dit / [s]kip / [d]efer ?

• a = そのまま採用
• e = $EDITOR で開いて手で直してから採用
• s = この回はスキップ (次回 kata apply でもう一度提案される)
• d = defer (今回は見送り、ただし「次回必ず再提案」を applied.toml に記録)

--non-interactive だけだと安全側に倒れて AI ファイルはスキップ、--non-interactive --yes だと全部 accept という CI 完全自動モードになります。

backend は trait で抽象化されていて、claude / gemini / codex の 3 つを実装済みです。agent = "auto" は PATH を見て上から順にフォールバックしていく挙動。MockAiAgent も組み込まれていて、テストでは決定的な応答が返せます。

並列度の制御もあって、AI 呼び出しはグローバル semaphore (default 4) で絞られます。kata apply --all で 10 個のプロジェクトを並列で回したときに、エージェント CLI の同時起動が爆発しないようにするためです。

.kata/applied.toml が source of truth

kata の状態は全部 PJ 側の .kata/applied.toml に書かれます。グローバル設定 (~/.config/kata/config.toml) は単なる PJ パスのレジストリで、何が適用されているかは知りません。

applied.toml はだいたいこんな感じです。

preset = "github.com/yukimemi/pj-presets:rust-cli"
applied_at = "2026-05-17T04:40:43Z"

[[templates]]
source = "github.com/yukimemi/pj-base"
rev = "f04151faf4f0678be9621bb724c8f3120a5e4d8b"
version = "0.10.0"

[[templates]]
source = "github.com/yukimemi/pj-rust"
rev = "9f103ca5aaf39e1dcf1a4d84b11685821aabc62f"
version = "0.5.0"

[[templates]]
source = "github.com/yukimemi/pj-rust-cli"
rev = "9263751c3f94f3415147e546db33170157fb1503"
version = "0.2.0"

[files."AGENTS.md"]
content_hash = "e4f146a1c66d11e6b6c707f52507b3e37da2fe52d8d7cf13f75edcf9ad5d3a7f"

[files."Makefile.toml"]
content_hash = "27e3f57b9efd6c177843d9b0d248f40af5843739bcde6ceaf985f2ce518ecfcf"

[files."LICENSE"]
once_applied = true

これを git に commit しておくと、

• teammate が clone → kata apply で同じ状態が再現できる
• CI が applied.toml を見るので、ローカル設定なしで CI が完結する
• rev が pin されている ので、上流の HEAD が動いても勝手に当たらない (kata update で明示的に上げる)

という運用になります。「状態は対象 (PJ) 側に置く、グローバル設定は単なるレジストリに留める」という設計を kata でも採用しました。

kata apply が冪等であること

設計でずっと気をつけたのが「何度走らせても結果が変わらない」ことです。apply が走るたびに差分が出るようなツールは CI で回せないので、

• content_hash を applied.toml に記録して、変化がないファイルはそもそも書き換えない
• once_applied = true のファイルは 2 回目以降は完全 skip
• merge-section / merge-toml のマージはべき等なように実装 (同じ入力で何度マージしても同じ出力)
• AI モードも --non-interactive --no-ai で完全に固定動作 (= AI モードを除いて再現可能)

という不変条件を守るようにしてあります。

おかげで kata apply --non-interactive --no-ai を毎日 CI で回すと、変更が必要なときだけ PR が立ち、なければ何も起きないという静かな動きになります。

関連プロジェクト

kata の周りに必要な template repo は以下です。すべて単体で意味があるので、好きな組み合わせで preset を組めます。

kata 自身も dogfood で pj-presets:rust-cli を適用しています — README の表が示す通り、Makefile.toml も CI も AGENTS.md も全部 kata-apply 経由で同期されています。

おわりに

kata を入れる前は、AGENTS.md を 1 行書き換えるのに 7 リポジトリの編集が必要でした。今は pj-base に 1 push すれば、翌日には全プロジェクトに PR が立って auto-merge されています。Claude / Gemini / Codex に渡しているノウハウが全プロジェクトで瞬時に揃う、というのが体験として相当よかったです。

「規約を更新する心理的コストが下がると、規約をもっと細かく洗練させたくなる」というポジティブフィードバックが回り始めていて、Claude Code との PR レビューサイクル運用 (/loop での 60s ポーリング、CodeRabbit の rate-limit notice の扱い、version-bump-only PR の特例……) みたいな細かい知見が、書いた次の日には全 PJ の Claude に届くようになりました。

Rust + Tera + tokio + AI CLI 委譲という shun / rvpm / todoke のときから使い倒している組み合わせに、teravars (Tera engine + vars + include の共通エンジン) を載せた構成で、いつもの定番スタックの延長で書けたのも開発体験として良かったところです。

複数のリポジトリのボイラープレートに疲れている方、特に AGENTS.md などの AI への指示書 を複数プロジェクトに散らかしてしまっている方は、ぜひ kata を試してみてください — 型を押して、版木を当てて、揃えていきましょう。

GitHub - yukimemi/kata: Multi-project template applier with AI-delegated merge

Multi-project template applier with AI-delegated merge - yukimemi/kata

github.com

自作のファイル・URL ディスパッチャ todoke (届け) を Claude Code と一緒に作りました。Rust 製で、入力された引数（ファイルパス・URL・任意の文字列）を TOML で書いたルールに照らして、対応するエディタ・ブラウザ・スクリプトに引き渡す CLI です。名前のとおり、引数を然るべき相手に**「届け」**ます。

ちなみに、漫画『君に届け』が好きです。

GitHub - yukimemi/todoke: A rule-driven file and URL dispatcher: hands incoming paths (or URLs) to the right handler based on TOML-defined rules.

A rule-driven file and URL dispatcher: hands incoming paths (or URLs) to the right handler based on TOML-defined rules. - yukimemi/todoke

github.com

なぜ作ったのか

きっかけは Neovim を $EDITOR にしたときの、ちょっとした困りごとが積み重なっていたことです。

• git commit のように呼び出し元をブロックしないと動かないものは、新しい nvim を起動して終了を待ちたい
• 一方、ファイルマネージャからファイルをダブルクリックしたときは、起動済みの nvim に :edit で送り込みたい
• プロジェクトによっては Neovim ではなく VSCode で開きたいものもある
• 開く URL によってブラウザを使い分けたい（Gmail は Chrome、GitHub は Edge、みたいに）

エディタ側の振り分けについては、以前は自作の hitori.vim を使っていました。$EDITOR=nvim で起動した Neovim 内から「これは別の起動済み nvim に転送すべきか / このまま開くべきか」を判定して、必要なら起動済み nvim にバッファを送り直す、という仕組みです。動作自体はちゃんとしていたのですが、

• 判定のためにいったん Neovim を起動して denops.vim を立ち上げる必要があり、毎回 Deno のコールドスタートが入って体感が重かった
• 判定ロジックが Vim プラグイン内に閉じているので、Neovim 以外のターゲット（VSCode に流したい / URL はブラウザに渡したい / 独自スキームを処理したい）にスケールしない
• Windows のファイル関連付けに置きづらい（Neovim を起動してから判定、という順序がそもそも噛み合わない）

要するに、判定は Neovim の外でやらないと、速度面でも対応範囲の面でも厳しい、というのが結論でした。

そこで、「入力を受け取って、ルールに従って正しい相手に届けるだけ」 の単機能ツールを Neovim の外側に切り出すことにしました。それが todoke です。判定が CLI 側で完結するので、$EDITOR 呼び出しはミリ秒で終わるし、Neovim 以外のターゲットにも横展開できます。

todoke の特徴

• ルールベースのルーティング — TOML の正規表現で各入力を届ける。ファイル / URL / 任意文字列のすべてに対応
• Neovim インスタンスの再利用 — kind = "neovim" のターゲットは msgpack-RPC で起動中の nvim にぶら下がり、:edit を送る。Windows でも \\.\pipe\... 名前付きパイプで動く
• 同期 / 非同期をルールごとに指定 — sync = true ならハンドラ終了までブロック（git commit 用）、sync = false なら投げて即終了（OS の関連付け用）
• Tera テンプレート対応 — command / listen / args / group などすべての値で {% if is_windows() %} や {{ env.HOME }} が使える
• 任意の CLI に対応 — code / helix / subl / emacsclient / firefox / bat …いずれもプラグイン不要
• $EDITOR 互換 — git、crontab、visudo、fc、mutt などの $EDITOR 呼び出し側との互換性を最優先で設計
• Windows の OS 既定プログラム にも設定可能。GUI ターゲットは cmd ウィンドウを点滅させずに起動できる
• 静的バイナリ — Rust 製でコールドスタートはミリ秒オーダー

インストール

cargo install todoke

~/.cargo/bin/todoke にバイナリが置かれるので、PATH に追加しておきます。

クイックスタート

todoke は設定ファイルがなくても動きます。バンドルされたデフォルト設定が、COMMIT_EDITMSG などの $EDITOR コールバックは新しい nvim で sync = true 起動、それ以外はすべてひとつの共有 nvim にルーティングする、というルールを最初から持っています。

$EDITOR を todoke にしてみるだけでも体験できます。

export EDITOR=todoke
git commit              # → COMMIT_EDITMSG を nvim mode=new sync=true で開く
todoke notes.md         # → 起動中の nvim に :edit notes.md を送り込む

カスタマイズしたければ todoke config init で ~/.config/todoke/todoke.toml に内蔵 default 設定を書き出してくれるので、そこから編集するのが手っ取り早いです (一度書き出したファイルは todoke 側からは絶対に上書きされません)。todoke config edit なら書き出し + $EDITOR での起動を一発でやってくれます。

設定例

ここでは複数のターゲットとルールを組み合わせた、実用的な todoke.toml の例を紹介します。

# ============================================================
# ターゲット定義 (届ける相手)
# ============================================================

# kind = "neovim" にすると msgpack-RPC で起動中の nvim を再利用する
[todoke.nvim]
kind = "neovim"
command = "nvim"
listen = '{% if is_windows() %}\\.\pipe\nvim-todoke-{{ group }}{% else %}/tmp/nvim-todoke-{{ group }}.sock{% endif %}'

[todoke.code]
command = "code"
[todoke.code.args]
remote = ["--reuse-window"]
new    = ["--new-window"]

# Chrome / Edge を別ターゲットとして登録
[todoke.chrome]
command = "chrome"
gui = true                # Windows: cmd ウィンドウを出さずに起動

[todoke.edge]
command = "msedge"
gui = true

# ============================================================
# ルール (どの入力をどのターゲットに届けるか)
# ============================================================

# git commit / rebase / merge は常に新規 nvim をブロック起動
[[rules]]
name = "editor-callback"
match = '(?i)/(COMMIT_EDITMSG|MERGE_MSG|git-rebase-todo)$'
to = "nvim"
mode = "new"
sync = true

# Gmail は Chrome で開く
[[rules]]
name = "gmail"
match = '^https?://mail\.google\.com/'
to = "chrome"

# GitHub は Edge で開く
[[rules]]
name = "github"
match = '^https?://(www\.)?github\.com/'
to = "edge"

# 仕事のリポジトリだけ VSCode で開く
[[rules]]
name = "work"
match = '/src/company/'
to = "code"
mode = "remote"

# それ以外の URL は Edge にフォールバック
[[rules]]
name = "url-default"
match = '^https?://'
input_type = "url"
to = "edge"

# 残り (主にファイル) は共有 nvim にすべて流す
[[rules]]
name = "default"
match = '.*'
to = "nvim"
group = "default"
mode = "remote"

これでこういう使い分けができます。

todoke notes.md                              # → 共有 nvim に :edit
todoke ~/src/company/foo.py                  # → VSCode で開く
todoke https://mail.google.com/mail/u/0/     # → Chrome
todoke https://github.com/yukimemi/todoke    # → Edge
todoke https://example.com                   # → Edge (URL fallback)
git commit                                   # → 新規 nvim (sync) で COMMIT_EDITMSG

Neovim の再利用: kind = "neovim"

todoke の中でいちばん力を入れた機能です。

kind = "neovim" のターゲットは、設定された listen パスにある msgpack-RPC ソケット / 名前付きパイプ越しに起動中の nvim にぶら下がって :edit を送るだけです。重要なのは、

• Windows でも \\.\pipe\nvim-todoke-default のような名前付きパイプでそのまま動く
• 起動済みの nvim がいなければ todoke が nvim --listen <path> で自動的に起動する
• group で nvim インスタンスを論理的に分けられる（group = "work" と group = "private" で別 nvim になる）

つまり、OS のファイルマネージャからダブルクリックしたファイルが、いま開いている nvim のバッファとして開く という体験が、追加の Vim プラグイン無しで実現します。

さらに group を使えば、ひとつの nvim にすべて流すのではなく、用途別に複数の nvim インスタンスを使い分けることもできます。listen の中に {{ group }} を埋め込んでおけば、group が変わるたびに別の pipe / socket になって、別の nvim プロセスとして起動・再利用される、という仕組みです。

[todoke.nvim]
kind = "neovim"
command = "nvim"
# listen に {{ group }} を入れておくのが鍵 — group ごとに別 pipe / socket になる
listen = '{% if is_windows() %}\\.\pipe\nvim-todoke-{{ group }}{% else %}/tmp/nvim-todoke-{{ group }}.sock{% endif %}'

# 仕事のリポジトリは "work" グループ
[[rules]]
match = '/src/company/'
to = "nvim"
group = "work"
mode = "remote"

# プライベートは "personal" グループ
[[rules]]
match = '/src/yukimemi/'
to = "nvim"
group = "personal"
mode = "remote"

# その他は共有の "default"
[[rules]]
match = '.*'
to = "nvim"
group = "default"
mode = "remote"

仕事のファイルは仕事用 nvim、プライベートは別 nvim、それ以外は共有 nvim — どこに届くかは match で決まります。

入力の 3 種類: file / url / raw

todoke は引数を 3 つの種類に分類します。

ファイル / URL は形から自動判定されます。ファイルとして存在しない Makefile や newfile.txt も、ファイルらしい形であれば file として扱われるので、vim Makefile と同じ感覚で todoke Makefile が動きます。

HEAD や main のような曖昧な文字列は、--todoke-as raw で明示するか、ルール側で input_type = "raw" に固定すれば「git ref を GitHub のツリービューで開く」みたいな運用ができます。

[[rules]]
name = "gh-ref"
match = '^(HEAD|main|master|develop|v?\d+\.\d+\.\d+|[0-9a-f]{7,40})$'
to = "gh-ref"
input_type = "raw"      # ← ローカルの "main" ファイルと衝突しないよう raw に固定

エディタ系フラグの取り回し: passthrough

$EDITOR=todoke でいざ運用してみると、+42 file.txt のような vim スタイルのフラグを渡してくる呼び出し元が出てきます。todoke は何もしないと +42 を「ファイルパス」と誤認識してしまうので、「これはフラグなのでファイルや URL のような入力としては扱わず、引数としてターゲットに forward する」 と書く仕組みが必要になります。それが passthrough です。

# どのフラグもターゲット非依存で素通しする
[[rules]]
name = "any-flag"
match = '^[-+]'
passthrough = true        # to は不要 — 同じ batch で他のルールが選んだターゲットに合流する

[[rules]]
name = "nvim-file"
match = '.*'
to = "nvim-term"
sync = true

これで todoke +42 foo.txt は nvim +42 foo.txt として起動します。-c :set ft=md のような 値が次の argv にあるフラグには consumes、-p a.txt b.txt c.txt のような 可変長 には consumes_until、-- で分けるタイプには consumes_rest を使います。

[[rules]]
name = "nvim-c"
match = '^-c$'
to = "nvim-term"
sync = true
passthrough = true
consumes = 1                     # -c とその次の argv を 1 セットで素通し

[[rules]]
name = "nvim-p"
match = '^-[pOo]$'
to = "nvim-term"
sync = true
passthrough = true
consumes_until = '^[-+]'         # 次のフラグが来るまで argv を吸い続ける

{{ passthrough }} を args の中で参照すると、フラグを 任意の位置に挿入できます。gvim のように --remote-silent <file> の前にフラグを置きたい、というケースに便利です。

[todoke.gvim]
command = "gvim"
gui = true
[todoke.gvim.args]
default = [
  "--servername", "{{ group | upper }}",
  "{{ passthrough }}",                       # ← ここで素通しフラグを並べる
  "--remote-silent", "{{ input }}",
]

{{ passthrough }} を単独の args 要素として書いた場合は inline 展開されるので、-c :set ft=md のような複数 argv のフラグも 1 つの "" にまとめられず、ちゃんと argv 単位で渡ります。

ちなみに passthrough と並んで、引数を空白で連結した全体を 1 つの正規表現でマッチさせる joined = true というモードもあります。+42 file.txt のような「フラグとファイルを 1 ルールで丸ごと拾いたい」といった用途向けです。詳細は README を参照してください。

[vars] で GUI を切り替える

Neovim の GUI フロントエンドには neovide、nvim-qt、素の nvim (ターミナル) などの選択肢があって、気分で切り替えたいことがあります。todoke の [vars] セクションと Tera テンプレートを組み合わせると、1 行書き換えるだけでフロントエンドを差し替えられる構成になります。

[vars]
# ここを書き換えるだけで全部追従する
gui = "neovide"
# CLI 引数を embedded nvim に渡すために `--` 区切りが必要なラッパー型 GUI 一覧
wrapper_guis = ["neovide", "nvim-qt"]

[todoke.gui]
kind = "neovim"
command = "{{ vars.gui }}"
listen = '{% if is_windows() %}\\.\pipe\nvim-todoke-{{ group }}{% else %}/tmp/nvim-todoke-{{ group }}.sock{% endif %}'
# ラッパー GUI のときだけ gui = true (Windows の cmd ウィンドウを抑止)
# 素の nvim はターミナルが必要なので false にする
gui = {{ vars.gui in vars.wrapper_guis }}

{% if vars.gui in vars.wrapper_guis %}
# ラッパー型は本体 nvim への引数の前に `--` を挟む必要がある
[todoke.gui.args]
remote = ["--"]
{% endif %}

[[rules]]
match = '.*'
to = "gui"
mode = "remote"

vars.gui を変えるだけで、

• "nvim" → nvim FILE --listen PIPE (ターミナルで起動)
• "neovide" → neovide FILE -- --listen PIPE (GUI、-- 区切りあり)
• "nvim-qt" → nvim-qt FILE -- --listen PIPE (GUI、-- 区切りあり)

の 3 通りに切り替わります。{% if %} の中で [todoke.gui.args] テーブルそのものを条件包含できるのは、todoke が TOML パース前に全文を Tera に通している (= TOML 構造ごと条件分岐できる) ことの利点です。

新しいラッパー GUI を試したくなったら wrapper_guis に追加するだけで対応できる、というのも気に入っています。

CLI

todoke 自身のフラグはすべて --todoke- プレフィックスで、ロングオプションのみです。これは todoke が $EDITOR の代わりに呼ばれたときに、呼び出し元（nvim・vim・helix）のフラグと絶対に衝突しないようにするための設計です。

todoke [INPUTS]...                 # ルールに従ってディスパッチ (デフォルト)
todoke check [INPUTS]...           # ドライラン: 実行せずに dispatch plan を表示
todoke doctor                      # 設定の健康診断
todoke list [--alive-only]         # 起動中のインスタンス一覧 (※ v2.0.0 時点で未実装)
todoke kill <GROUP> | --all        # インスタンスを終了        (※ v2.0.0 時点で未実装)
todoke config path                 # 設定ファイルパスを表示
todoke config init                 # 無ければ default を書き出す (idempotent)
todoke config edit                 # $EDITOR で開く
todoke config show [--rendered]    # 中身を表示 (--rendered で Tera 展開後)
todoke completion <shell>          # シェル補完スクリプト
todoke --todoke-config <PATH>      # 設定ファイルを上書き
todoke --todoke-to <NAME>          # ルールを無視してターゲット強制
todoke --todoke-group <NAME>       # ルールを無視してグループ強制
todoke --todoke-as <KIND>          # 入力種別を file / url / raw に強制
todoke --todoke-verbose            # ログレベルを上げる (繰り返し可)

check と doctor を用意したのは、ルールが増えるとどれが当たるか分からなくなる、というのが個人的な経験で確実だったからです。todoke check ~/notes.md https://mail.google.com https://github.com/yukimemi と打てば、それぞれどのルールが当たってどのターゲットに飛ぶかが実行抜きで確認できます。

想定する使いどころ

$EDITOR として

export EDITOR=todoke
git commit                         # editor-callback ルール → 新規 nvim sync
git rebase -i HEAD~3               # 同上
crontab -e                         # 同上 (CRONTAB 系のファイル名は default config で拾う)

Windows のファイル関連付けとして

.txt を右クリック → プログラムから開く → todoke.exe を選ぶだけです。gui = true のターゲットは cmd /c start を経由せずに起動するので、コンソールウィンドウが点滅しません。GUI な Neovim フロントエンド（neovide / nvim-qt）や VSCode をターゲットにするときに気持ちのよい体験になります。

URL / 独自 ID のディスパッチャとして

firefox や chrome の代わりに todoke を渡しておくと、ホストごとにブラウザを使い分けたり (Gmail は Chrome、GitHub は Edge、など)、URL のパスから別プロファイルに届けたり、というのが設定だけで作れます。

設計のポイント

batch という単位

todoke 内部では、入力をルール照合した結果、「同じターゲット × 同じグループに行く入力」が 1 つの batch にまとめられます。これによって todoke a.md b.md c.md を渡したときに、3 回別々に nvim へ RPC が飛ぶのではなく、1 回の :args a.md b.md c.md 相当でまとめて開く、という挙動が実現します。

passthrough ルールがフラグを集めて、その batch にマージするのもこの単位です。+42 a.txt b.txt で +42 は a.txt の batch に入るし、a.txt b.txt 全体に対して +42 を効かせる挙動になります。

Tera を全箇所で使う

command / listen / args / group / to といったルール側のあらゆる文字列が Tera で展開されます。これによって、

• listen = '{% if is_windows() %}\\.\pipe\...{% else %}/tmp/...{% endif %}' のような OS 分岐
• command = "{{ vars.gui }}" のような変数経由の参照 ([vars] セクションで一括切り替え)
• group = "{{ env.PROJECT_GROUP | default(value='default') }}" のような環境変数経由の動的グループ

がすべて宣言的な設定だけで書けます。

それに加えて、入力種別ごとに使える変数も用意されています。

• file 入力: {{ file_path }} (正規化された絶対パス) / {{ file_dir }} / {{ file_name }} / {{ file_stem }} / {{ file_ext }} (拡張子、ドットなし)
• URL 入力: {{ url_scheme }} / {{ url_host }} / {{ url_port }} / {{ url_path }} / {{ url_query }} / {{ url_fragment }}
• 共通: {{ input }} (生の入力文字列) と {{ input_type }}、ルールの match で取った正規表現キャプチャの {{ cap.1 }} / {{ cap.<name> }}

たとえば「.xlsx ファイルは Excel.exe に渡す」はこれだけで書けます。

[todoke.excel]
command = "C:/Program Files/Microsoft Office/root/Office16/EXCEL.EXE"
gui = true
args.default = ["{{ file_path }}"]    # 絶対パスに正規化済み

[[rules]]
match = '\.xlsx?$'
to = "excel"

URL 側も同じで、たとえば Edge を URL のホストごとに別プロファイルに分けたければ:

[todoke.edge-per-host]
command = "msedge"
gui = true
args.default = [
  "--profile-directory={{ url_host }}",   # github.com / mail.google.com / ... ごとに別プロファイル
  "{{ input }}",
]

[[rules]]
match = '^https?://'
input_type = "url"
to = "edge-per-host"

shun / rvpm でやっていたのと同じ思想で、「設定は宣言的に、でもちょっとしたロジックも書けるように」という落としどころを TOML × Tera に求めた形です。

append_inputs / append_passthrough の auto

exec ターゲットの args に {{ input }} や {{ file_path }} が出てくると、todoke はそれを検知して末尾への自動 append を抑制します。{{ passthrough }} についても同様です。これは設定が直感的に書けるようにするための小さな仕掛けで、たとえば

args.default = ["--new-window", "{{ input }}"]

と書くだけで、URL が末尾に二重に付かなくなります。明示的に append_inputs = false を書くこともできますが、9 割のケースでは auto 検知だけで済みます。

ロードマップ

リリース済み (v2.0.0):

• コアディスパッチ、neovim / 汎用 exec バックエンド、$EDITOR 互換、Windows のファイル関連付け対応、カラー出力
• check (dispatch plan のドライラン)、doctor (設定の静的解析)、completion
• config サブコマンド一式 — path / init / edit / show

予定:

• list / kill — 現状はスタブ (bail!("not implemented yet"))。起動中の nvim インスタンス一覧 / グループ単位での終了
• neovim での remote + sync (nvim_buf_attach 経由) — 再利用 nvim のバッファが閉じるまでブロックする (現状は fresh-spawn の nvim でしか sync = true が効かない)
• script ターゲット kind — 任意のシェルコマンドをハンドラにできるようにして、todoke を「ファイル種別ごとの汎用 open-with」ツールとして使えるようにする

おわりに

$EDITOR=todoke にしてからは、git commit でも、ファイルマネージャからのダブルクリックでも、URL を渡しても、すべて 1 個の todoke コマンドが然るべき相手に届けてくれるので、エディタまわりの取り回しがだいぶ楽になりました。

rvpm のときに使った Rust + Tera + Tokio の組み合わせに今回も助けられていて、設定が宣言的に書ける CLI ツールを少ないコードで作れる構成として、自分の中で定番化しつつあります。

Neovim を $EDITOR にしているけど git commit の体験が微妙、ファイルマネージャから開いたファイルが新しい nvim を立ち上げてしまうのが嫌、URL や独自 ID をシェルから直接ブラウザに飛ばしたい、といった嗜好に合う方は、ぜひ試してみてください — 君に届け！

GitHub - yukimemi/todoke: A rule-driven file and URL dispatcher: hands incoming paths (or URLs) to the right handler based on TOML-defined rules.

A rule-driven file and URL dispatcher: hands incoming paths (or URLs) to the right handler based on TOML-defined rules. - yukimemi/todoke

github.com

GitHub - yukimemi/rvpm: Fast Neovim plugin manager with pre-compiled loader and merge optimization

Fast Neovim plugin manager with pre-compiled loader and merge optimization - yukimemi/rvpm

github.com

rvpm profile でプラグイン単位の Neovim 起動時間を phase ごとに可視化する TUI も付いています。

なぜ新しく作ったのか

以前、Deno + denops ベースの dvpm を作り、愛用していました（過去の記事・キャッシュ機能の記事）。dvpm は denops との親和性も高く気に入っていたのですが、使い続けるうちにいくつか気になる点が出てきました。

• 設定を TypeScript で書く前提なので、素の Neovim 設定と混ぜるときに壁がある
• denops 起動前には遅延ロードが効かず、キャッシュ機能でカバーしていた
• AI 時代、プラグインの追加・更新・削除といった管理操作はエディタの外からコマンドで叩けたほうが何かと都合が良い

ちょうど別プロジェクトで Rust を触っていたので、「設定は TOML、管理は CLI、Neovim 側はただ loader.lua を読むだけ」 という形を Rust で作ってみることにしました。

rvpm の特徴

• CLI ファースト — プラグインの追加・更新・削除はすべてターミナルで完結
• TOML 設定 — 宣言的で、Tera テンプレート対応
• 事前コンパイルされた loader.lua — rvpm generate 時にプラグインディレクトリを walk してファイルリストを焼き込む。Neovim は固定の dofile() / source を並べるだけ
• 豊富な遅延ロードトリガー — on_cmd, on_ft, on_map, on_event, on_path, on_source, ColorSchemePre 自動検知、depends の解決まで実施
• merge 最適化 — merge = true のプラグインは単一の runtimepath エントリに集約
• プラグインブラウザ TUI — rvpm browse で GitHub の neovim-plugin トピックを眺めながらインストール
• AI CLI 連携 — rvpm add / rvpm tune で Claude / Gemini / Codex に [[plugins]] ブロックとフックファイル一式を設計させられる
• エディタ起動への影響を抑える — CLI で管理する別プロセスなので、循環依存・存在しないプラグイン・設定ミスがあっても Neovim の起動を巻き添えにしにくい（rvpm 側は警告で止めない）

インストール

# crates.io から
cargo install rvpm

# または最新 main から
cargo install --git https://github.com/yukimemi/rvpm

Releases ページに Linux (x86_64) / macOS (Intel / Apple Silicon) / Windows (x86_64) のビルド済みバイナリも置いてあります。

クイックスタート

# 1. 初期化 (config.toml を作り、init.lua に loader の読み込みを書き込む)
rvpm init --write

# 2. プラグインを追加
rvpm add folke/snacks.nvim
rvpm add nvim-telescope/telescope.nvim

# 3. GitHub の "neovim-plugin" トピックを TUI で探してインストール
rvpm browse

# 4. インストール済みプラグインを TUI で管理
rvpm list

# 5. config.toml を開いて細かい設定を書く
rvpm config

既存の Neovim 設定を壊さずに試す

rvpm は Neovim の $NVIM_APPNAME に対応しているので、既存の ~/.config/nvim/ をそのまま残した状態で、別の appname で試せます。

# Bash / Zsh
NVIM_APPNAME=nvim-rvpm rvpm init --write
NVIM_APPNAME=nvim-rvpm rvpm add folke/snacks.nvim
NVIM_APPNAME=nvim-rvpm nvim

# PowerShell
$env:NVIM_APPNAME = "nvim-rvpm"
rvpm init --write
rvpm add folke/snacks.nvim
nvim

関係ファイルは次の 3 つのディレクトリに隔離されるので、気に入らなければこれらを削除するだけで跡形もなく消せます。

• ~/.config/nvim-rvpm/ — Neovim 側の設定ディレクトリ（rvpm init --write が init.lua をここに書き込む）
• ~/.config/rvpm/nvim-rvpm/ — rvpm の config_root（config.toml、グローバル before.lua / after.lua）
• ~/.cache/rvpm/nvim-rvpm/ — rvpm の cache_root（plugin の clone と loader.lua）

設定例

~/.config/rvpm/<appname>/config.toml:

[options]
concurrency = 10       # git 並列数 (デフォルト 8)
auto_clean  = true     # sync / generate で未参照プラグインを自動削除
url_style   = "full"   # config.toml に書くときは full URL で

# 即時ロード (on_* トリガーなし)
[[plugins]]
url = "folke/snacks.nvim"

# on_cmd があるので lazy = true が自動推論される
# depends は "このプラグインより先に読み込む" 依存関係
[[plugins]]
url     = "nvim-telescope/telescope.nvim"
depends = ["plenary.nvim"]
on_cmd  = ["Telescope"]

# ファイルタイプ + イベントで遅延ロード
[[plugins]]
url      = "neovim/nvim-lspconfig"
on_ft    = ["rust", "toml", "lua"]
on_event = ["BufReadPre"]

# キーマップで遅延ロード (mode と desc も指定可)
[[plugins]]
url  = "folke/which-key.nvim"
on_map = [
  "<leader>?",
  { lhs = "<leader>v", mode = ["n", "x"], desc = "Visual leader" },
]

# "他のプラグインの読み込み完了" を遅延トリガーに使う (on_source)
# snacks.nvim がロードされて rvpm_loaded_snacks.nvim が発火したら読み込む
[[plugins]]
url       = "folke/todo-comments.nvim"
on_source = ["snacks.nvim"]

on_* のどれか一つでも指定されていれば lazy は自動で true になります。

遅延ロードトリガー

lazy.nvim など主要なプラグインマネージャーが持っている遅延ロードトリガーには概ね対応しています。

Colorscheme の遅延ロード

lazy = true なプラグインが colors/*.vim や colors/*.lua を持っていると、ColorSchemePre のハンドラを rvpm generate 時に自動で登録します。設定で明示する必要はありません。

[[plugins]]
url  = "folke/tokyonight.nvim"
lazy = true  # colors/ を持っているので ColorSchemePre が自動登録される

[[plugins]]
url  = "catppuccin/nvim"
name = "catppuccin"
lazy = true

複数のカラースキームを入れていても、起動コストはゼロで :colorscheme tokyonight のタイミングで初めて読み込まれます。

Tera テンプレート

config.toml 全体が TOML パース前に Tera で処理されるので、条件分岐や環境変数の参照ができます。

[vars]
use_blink = true
use_cmp   = false

{% if vars.use_blink %}
[[plugins]]
url = "saghen/blink.cmp"
on_event = ["InsertEnter", "CmdlineEnter"]
{% endif %}

{% if vars.use_cmp %}
[[plugins]]
url = "hrsh7th/nvim-cmp"
on_event = "InsertEnter"
{% endif %}

{% if is_windows %}
[[plugins]]
url = "thinca/vim-winenv"
{% endif %}

{% if %} は「そもそも loader.lua に含めない」、cond = "..." は「含めるが実行時に Lua で判定」、という使い分けになっています。

コマンド一覧

rvpm list — 管理 TUI

インストール済みプラグインの一覧表示と、そこからの操作を担う TUI です。

詳細は README を参照してください。

rvpm browse — プラグイン探索 TUI

GitHub API から neovim-plugin topic のリポジトリ（最大 ~300 件）を取得して、plugin 一覧と README プレビューの 2 ペインで表示します。端末の横幅が広ければ左右に、狭ければ上下にレイアウトが自動で切り替わります。

既にインストール済みのプラグインには緑の ✓ が付き、Enter してもインストール済みである旨の警告だけが出て重複追加を防ぎます。検索結果は一定期間キャッシュされるので、同じ画面を何度も往復してもレスポンスは軽快です。

README プレビューは内蔵の markdown レンダラ（tui-markdown）で描画していますが、オプションで mdcat / glow / bat など外部レンダラにパイプすることもできます。

[options.browse]
readme_command = ["mdcat"]
# readme_command = ["glow", "-s", "dark", "-w", "{{ width }}", "{{ file_path }}"]

ディレクトリ構成とユーザー設定

rvpm のファイル配置は次のようになっています。<appname> は $RVPM_APPNAME → $NVIM_APPNAME → "nvim" の順で解決されるので、Neovim の appname 切り替えとそのまま揃います。

~/.config/rvpm/<appname>/                    ← config_root
├── config.toml                              ← プラグイン宣言と [options]
├── before.lua                               ← グローバル before (ユーザー設定前半)
├── after.lua                                ← グローバル after  (ユーザー設定後半)
└── plugins/<host>/<owner>/<repo>/           ← プラグイン固有のフック
    ├── init.lua                             ← rtp 追加前
    ├── before.lua                           ← rtp 追加後、plugin/* ソース前
    └── after.lua                            ← plugin/* ソース後

~/.cache/rvpm/<appname>/                     ← cache_root
├── plugins/
│   ├── repos/<host>/<owner>/<repo>/         ← plugin の clone 先
│   ├── merged/                              ← merge=true の共通 rtp
│   └── loader.lua                           ← 生成されるローダー
└── browse/                                  ← `rvpm browse` のキャッシュ

Windows でも %APPDATA% ではなく %USERPROFILE%\.config\... / %USERPROFILE%\.cache\... に配置されます。dotfiles をそのまま持ち運べる構造にしたかったのでこうしています。

ユーザー自身の設定も rvpm に任せられる

rvpm の考え方としてユーザーの Neovim 設定そのものも rvpm の管理下に置く、という使い方にしています。init.lua にはローダーの読み込み一行だけを書き、それ以外のユーザー設定は config_root/ 直下の before.lua / after.lua に分けて置く形です。

これらは設定エントリなしで rvpm generate 時に自動検出されます。同じ仕組みでプラグイン固有のフックも plugins/<host>/<owner>/<repo>/ に init.lua / before.lua / after.lua を置くだけで拾われます。

-- ~/.config/rvpm/nvim/plugins/github.com/nvim-telescope/telescope.nvim/after.lua
require("telescope").setup({
  defaults = { layout_strategy = "vertical" },
})
vim.keymap.set("n", "<leader>ff", "<cmd>Telescope find_files<cr>")

config.toml・グローバルフック・プラグイン固有フックを全部同じツリーの下に置けるので、dotfiles として ~/.config/rvpm/ ごと管理すれば Neovim 設定一式が rvpm にまとまります。

AI による rvpm add — Claude / Gemini / Codex 連携

rvpm add には、追加するプラグインの [[plugins]] ブロックの設計まるごと AI CLI に任せるモードがあります。options.ai = "claude" と書く（または --ai claude を都度指定する）だけで、プラグインの README / doc/ を読み込んだ AI が [[plugins]] エントリと per-plugin の init.lua / before.lua / after.lua までセットで提案してきます。

[options]
ai = "claude"           # "off" (default) | "claude" | "gemini" | "codex"
ai_language = "ja"      # 説明文を日本語で返してもらう

rvpm add owner/repo 実行時の流れはこんな感じです。

1. プラグインを clone（通常の add と同じ）
2. 「rvpm の TOML スキーマ」「プラグインの README + doc/」「現在の config.toml と plugins/ ツリー」「既存の per-plugin フックファイル」をプロンプトに組み立てる
3. 設定された AI CLI を claude -p / gemini -p / codex exec で one-shot 起動
4. 返ってきた XML（<rvpm:plugin_entry> / <rvpm:init_lua> / <rvpm:before_lua> / <rvpm:after_lua> / <rvpm:explanation>）をパース
5. 提案を表示して Apply / Chat / Hand off / Skip を選ばせる

Chat を選ぶと「depends に plenary を追加して」「これは eager で読み込みたい」のような要望をワンラインで投げて再提案させられます。Hand off を選ぶとここまでのやり取りを一時ファイルに保存して、その CLI のインタラクティブセッションに制御を渡します。AI CLI 側のファイル編集ツール（Claude Code なら Edit / Write）でそのまま続きを進められます。

rvpm add は新規追加時にしか動かないので、既に config.toml に登録済みのプラグインを AI に再設計させたい場合は rvpm tune <query> を使います。tune ではセクション単位で Use FRESH（クリーンな再設計で上書き）/ Use MERGED（既存の編集を残しつつ提案を取り込む）/ Keep existing（変更しない）が選べます。

なぜこの機能が AI と相性良く成立するのか

これがこの記事で一番書きたかった話です。AI add を雑な思いつきで載せたわけではなく、rvpm のディレクトリ構造とフックのルールが固定化されているからこそ成立しています。

• プラグイン側の設定は [[plugins]] ブロックという単一のスキーマに集約されている。on_* トリガーや lazy / merge の意味は TOML 上で完結していて、Lua をどこに書くべきかで悩む余地がない
• per-plugin のフックは {config_root}/plugins/<host>/<owner>/<repo>/ 以下の init.lua / before.lua / after.lua の 3 ファイルだけ。それぞれが走るタイミング（rtp 追加前 / plugin/* ソース前 / plugin/* ソース後）も 9 フェーズのローダーモデル上で固定
• グローバルフックも {config_root}/before.lua / after.lua の 2 つに限定

この「置き場所と意味が一意に決まっている」ことのおかげで、

• AI に渡すプロンプトをテンプレ化できる（スキーマと既存ファイルの内容をそのまま埋め込めば過不足ない）
• AI 側も「どのフックに何を書けば、いつ走るか」を曖昧さなく出力できる
• Apply 時に「[[plugins]] だけ FRESH を採用、after.lua は MERGED、before.lua は Keep」のような per-section の選択肢が成立する

逆にここがフリーフォーム（init.lua 一枚に何でも書く方式）だと、AI の出力もコンテキストに強く依存して再現性が下がりますし、ユーザーの既存設定との突き合わせも難しくなります。「リポジトリパスでフックファイルを分離する」という構造的な制約が、AI 時代になって思いがけず効いてきた、という話でした。

設計のポイント

9 フェーズのローダーモデル

rvpm generate が吐く loader.lua は次の 9 フェーズで構成されています。

Phase 1: vim.go.loadplugins = false            -- Neovim の自動 source を抑止
Phase 2: load_lazy ヘルパ                       -- 遅延プラグインを実行時に読み込む関数
Phase 3: global before.lua                     -- ユーザーの before フック
Phase 4: 全プラグインの init.lua                 -- 依存順 / rtp 追加前
Phase 5: rtp:append(merged_dir)                -- merge=true 用の単一 rtp
Phase 6: eager プラグイン (依存順):
            rtp 追加 → before.lua
            plugin/**/*.{vim,lua} を source
            ftdetect/** を source
            after/plugin/** を source
            after.lua
            User autocmd "rvpm_loaded_<name>" 発火   -- on_source の待ち受け先
Phase 7: 遅延トリガー登録                        -- on_cmd / on_ft / on_map / ...
Phase 8: ColorSchemePre ハンドラ                 -- colors/ がある lazy プラグイン用
Phase 9: global after.lua

plugin/ / ftdetect/ / after/plugin/ のファイルリストは rvpm generate のタイミングで glob して loader.lua に焼き込んでいます。 そのため Neovim 起動時は glob が走らず、固定の dofile() / source を順次読み込むだけです。 I/O コストは CLI 側で払っておいて、エディタ起動側はそれを静的に消費するだけ、という分業にしたかったのがこの設計の出発点でした。

各フェーズが実測でどれくらいかかっているかは、冒頭で紹介した rvpm profile の TUI で phase ごと・プラグイン単位に可視化できます。

merge 最適化

merge = true のプラグインは、{cache_root}/plugins/merged/ に集約されて単一の vim.opt.rtp:append(merged_dir) になります。eager なプラグインをどれだけ積んでも &runtimepath が膨らまないのが利点です。

chezmoi 統合

自分は dotfiles を chezmoi で管理しているので、専用のオプションも追加しました。 options.chezmoi = true にするとすべての書き込み（config.toml、グローバルフック、プラグイン固有フック）を chezmoi の source 側に行い、その後 chezmoi apply --force <target> で target に反映するフローに切り替わります。

[options]
chezmoi = true

技術的なポイント

Rust

Rust のエコシステムに乗せたことで得られたものが二つあります。

一つは Tera テンプレートエンジンです。 TOML という宣言的なフォーマットに寄せつつ、{% if %} による条件分岐や {{ vars.xxx }} / {{ env.XXX }} / {{ is_windows }} での変数展開が挟めるので、「設定は宣言的に、でもちょっとしたロジックは書きたい」という欲張りな要求を満たせています。dvpm 時代に TypeScript だから自由にできていた部分を、TOML に落としても失わずに済んだ形です。

もう一つは ratatui による TUI の表現力の部分です。 rvpm sync の進捗表示や rvpm list / rvpm browse のペイン分割、リアルタイムに更新される clone 状態など、ターミナル上でそれなりに見栄えのする画面が作れました。CLI ファーストを掲げるなら画面もちゃんと作り込みたかったので、ratatui の表現力に助けられています。

前身 dvpm との関係

rvpm は dvpm の後継プロジェクトという位置付けです。dvpm は denops ベースで「TypeScript で Vim/Neovim の設定を書く」という尖った方向性でしたが、rvpm は 「Neovim の標準的な Lua 設定に CLI で補助輪を付ける」 という立ち位置を取っています。

設計面では、volt から影響を受けています。(けっこう好きでした) volt は Go 製の CLI プラグインマネージャーで、$VOLTPATH/plugconf/<host>/<owner>/<repo>.vim というリポジトリ URL そのままのパスに各プラグインの設定ファイルを置く、という発想を持っていました。 rvpm の {config_root}/plugins/<host>/<owner>/<repo>/ 以下に init.lua / before.lua / after.lua を配置する仕組みは、ここから直接影響を受けています。 「プラグインごとの設定を vimrc (init.lua) から切り離して、リポジトリパスに対応したファイルとして独立管理する」という思想そのものが volt 由来です。 lazy.nvim からも影響を受けていて、遅延ロードトリガーの命名（on_cmd / on_ft / on_event / on_map）はそちらに寄せました。

volt の「CLI で完結」「リポジトリパスで plugin 設定を分離」「ユーザーの 設定自体もマネージャ管理下に置く」という哲学と、lazy.nvim の遅延ロード API 設計、そして dvpm で積んできた自前のプラグインマネージャー実装の経験 — この三つが rvpm のベースになっています。

おわりに

自分で使うためのツールなのでドッグフーディングは毎日しています。自分の dotfiles も ~/.config/rvpm/nvim/ に移行済みで、200 個近いプラグインを rvpm で管理しています。

Neovim プラグインマネージャー自体は世の中に優秀なものが既にたくさんありますが、「CLI でプラグイン管理を完結させたい」といった嗜好に合う方がいれば、ぜひ試してみてください！

GitHub - yukimemi/rvpm: Fast Neovim plugin manager with pre-compiled loader and merge optimization

Fast Neovim plugin manager with pre-compiled loader and merge optimization - yukimemi/rvpm

github.com

[!NOTE] Update (2026-04-04) shun の大幅なバージョンアップ（v5.0.1）に伴い、履歴スキーマ（バージョン 2）の変更や、新しい設定項目、プレビューパネルの追加などを反映しました。

Alfred や Raycast が好きで、Windows でも同じような体験がしたくて、Claude Code と一緒にランチャーを作りました。

GitHub - yukimemi/shun: A minimal keyboard-driven cross-platform launcher

A minimal keyboard-driven cross-platform launcher. Contribute to yukimemi/shun development by creating an account on GitHub.

github.com

shun とは

shun (瞬) は、グローバルホットキーで呼び出せるキーボードドリブンのミニマルランチャーです。

• バックエンド: Rust + Tauri v2
• フロントエンド: Svelte 5
• 検索エンジン: nucleo-matcher（Helix エディタと同じファジー検索エンジン）

主な機能

ファジー / 完全一致 / migemo 検索

nucleo-matcher によるファジー検索と完全一致検索を設定で切り替えられます。インストール済みアプリ、設定したアプリ、スキャンしたディレクトリのファイルが瞬時に絞り込まれます。

search_mode には以下の5モードがあります。

設定ファイルで固定するほか、Ctrl+Shift+m でその場でサイクル切り替えできます。ソート順（回数優先 / 最近優先）も Ctrl+Shift+o で切り替え可能です。切り替えた状態は /save コマンドで config.local.toml に永続化できます。

migemo 系モードでは、ローマ字で日本語のファイル名や候補を検索できます。たとえば hajime と入力すると 初めてのRust や はじめに にマッチします。fuzzy_migemo は「ローマ字でも日本語でもどちらでも引っかかる」ので、混在した候補リストを扱う場合に特に便利です。

rustmigemo と jsmigemo（oguna 氏作）を使用。辞書（yet-another-migemo-dict、BSD-3-Clause）はアプリに同梱しているので別途インストール不要です。

起動履歴 & よく使う順 / 最近使った順ソート

起動したアプリを自動的に記録し、実行回数と最終使用日時の組み合わせでソートされます。設定の sort_order でどちらを優先するか切り替え可能です。

• count_first: 実行回数を優先し、同じ回数なら新しい順に表示。
• recent_first: 最終使用日時を優先し、同じ日時なら回数が多い順に表示。

Args モード（Tab キー）

Tab キーを押すと Args モードに入り、追加の引数を渡して起動できます。バージョンアップにより、「どのアプリを、どの引数で実行したか」 が個別に履歴として記憶されるようになりました。

edge   →  Tab  →  https://bing.com     →  Enter
chrome →  Tab  →  https://google.co.jp →  Enter

ブラウザごとに開く URL を使い分けるのが特に便利です。一度使った組み合わせは引数込みで履歴に残るので、次回からは edbi と入力するだけで「Edge で Bing を開く」が候補に出てきます。

以前使った引数の組み合わせが履歴として記憶されていて、次回はゴーストテキストとして表示されます。Ctrl+f で1単語、Ctrl+e で行全体を確定できます。History アイテムで Tab を押すと、その引数を引き継いで Args モードに入れます。

パス & URL を直接開く

• ~/Documents や /usr/bin のような絶対パスを入力 → エクスプローラーや Finder で開く
• %APPDATA% や $HOME, ${XDG_CONFIG_HOME} などの環境変数を含むパスを直接入力 → 展開して開く
• shell:startup などの Windows 特殊フォルダを入力 → 直接開く
• https://... を入力 → ブラウザで開く
• Tab で補完候補がドロップダウン表示

プレビューパネル

Ctrl+Shift+p でプレビューパネルを表示できます。

• Args モード: ファイルパス補完中に、選択しているファイルの中身を表示。
• 検索結果: 実行ファイルやスクリプト、テキストファイルなどの内容を表示。

プレビューには Shiki による構文強調（シンタックスハイライト）が適用され、テーマに合わせた色で見やすく表示されます。Ctrl+j / Ctrl+k でパネル内のスクロールも可能です。

ウィンドウの移動

ウィンドウ上部の ⠿ マーク（ドラッグハンドル）をマウスで掴んで、好きな位置にウィンドウを移動できます。移動した位置は /save position コマンドで config.local.toml に保存し、次回起動時にも維持することが可能です。

スラッシュコマンド

/save や /config などのコマンドは、Tab キーを押すことで引数の候補（設定項目やファイル名）がドロップダウン表示されます。

その他の便利な操作

• Shift + Enter: 履歴の候補を無視して、現在入力しているクエリを直接コマンドとして実行します。
• Ctrl + w / Ctrl + u: カーソル前の 1 単語削除、または行頭までの削除。
• Ctrl + d: 選択した履歴アイテム（特定の引数セットを含む）を削除。

アップデート検知

バックグラウンドで定期的に新バージョンをチェックします（デフォルト1時間ごと、設定変更可能）。新バージョンが見つかると、検索欄のプレースホルダーが Update available: vX.X.X — /update に変わって通知してくれます。

実際のアップデートは手動で、/update を実行すると起動します。ダウンロードの進捗がリアルタイムで表示され、完了後に自動再起動します。

Scoop や Homebrew でインストールした場合は、それぞれ scoop update shun / brew upgrade --cask shun を代わりに実行してくれます。

インストール

ワンライナー

Windows (PowerShell、管理者権限不要):

irm https://yukimemi.github.io/shun/install.ps1 | iex

macOS / Linux:

curl -fsSL https://yukimemi.github.io/shun/install.sh | sh

パッケージマネージャー

WinGet (Windows):

winget install yukimemi.shun

Scoop (Windows):

scoop bucket add yukimemi https://github.com/yukimemi/scoop-bucket
scoop install yukimemi/shun

Homebrew (macOS):

brew tap yukimemi/tap
brew install --cask yukimemi/tap/shun

設定

初回起動時に自動生成されます。

設定できる項目は多岐にわたります。詳細は README を参照してください。ここでは代表的な例を紹介します。

# 検索モードとソート順
search_mode = "fuzzy_migemo"  # "fuzzy" | "exact" | "migemo" | "fuzzy_migemo" | "exact_migemo"
sort_order  = "count_first"   # "count_first" | "recent_first"
history_max_items = 1000      # 保持する履歴の最大数

# ウィンドウ・表示設定
max_items    = 8              # 候補の最大表示数
hide_on_blur = true           # フォーカスが外れたら自動的に閉じる
monitor      = "cursor"       # 起動モニター ("cursor" | "primary" | インデックス番号)
font_size    = 14             # フォントサイズ
opacity      = 1.0            # ウィンドウの不透明度 (0.0 - 1.0)
icon_style   = "unicode"      # ステータスバッジのスタイル ("unicode" | "svg")

# プレビュー・その他
preview_args   = true         # 引数モードでのプレビュー (デフォルト: true)
preview_search = true         # 検索結果のプレビュー (デフォルト: true)
auto_start     = true         # ログイン時に自動起動 (デフォルト: true)

[keybindings]
launch      = "Ctrl+Space"    # グローバルホットキー
next        = "Ctrl+n"
prev        = "Ctrl+p"
confirm     = "Enter"
arg_mode    = "Tab"
accept_line = "Ctrl+e"        # ゴーストテキストを全確定
accept_word = "Ctrl+f"        # ゴーストテキストを 1 単語確定
delete_word = "Ctrl+w"        # カーソル前の 1 単語削除
delete_line = "Ctrl+u"        # 行頭まで削除
run_query   = "Shift+Enter"   # 履歴を無視して直接実行
delete_item       = "Ctrl+d"        # 選択した履歴アイテムを削除
cycle_search_mode = "Ctrl+Shift+m"  # 検索モードをサイクル切り替え
cycle_sort_order  = "Ctrl+Shift+o"  # ソート順をトグル
toggle_preview    = "Ctrl+Shift+p"  # プレビューパネルの表示/非表示
preview_scroll_down = "Ctrl+j"      # プレビューパネルをスクロール
preview_scroll_up   = "Ctrl+k"      # プレビューパネルをスクロール
close             = "Escape"

# 自動で見つかったアイテム（scan_dirs やシステムアプリ）の挙動を上書き
[[overrides]]
name       = "scoop"          # アプリ名（ファイル名）でマッチ
completion = "list"           # スキャンで見つかったコマンドに補完を追加できる
completion_list = ["install", "update", "search", "list", "status", "info"]

[[overrides]]
ext        = "xlsx"           # 拡張子でマッチ
path       = "C:/Program Files/Microsoft Office/root/Office16/EXCEL.EXE"
args       = ["{{ file_path }}"] # 本来のパス（Excel ファイル自体のパス）を引数で渡す

# ファイルパス補完付きでエディタを開く
[[apps]]
name       = "Neovide"
path       = "neovide"
completion = "path"

# docker exec の補完をコマンド出力から生成
[[apps]]
name               = "docker exec"
path               = "docker"
args               = ["exec", "-it"]
completion         = "command"
completion_command = "docker ps --format '{{.Names}}'"

# git checkout のブランチ補完
[[apps]]
name               = "git checkout"
path               = "git"
args               = ["checkout"]
completion         = "command"
completion_command = "git branch --format='%(refname:short)'"
workdir            = "~/src/myproject"

# ディレクトリをまとめてスキャン
[[scan_dirs]]
path       = "~/.local/bin"
recursive  = false
extensions = ["sh", "py", "ps1"]

テンプレートプレースホルダー

path や args には Tera テンプレート構文が使えます。Tab で Args モードに入って入力した内容が {{ args }}（文字列全体）や {{ args_list }}（スペース区切りの配列）に展開されます。

利用可能な変数・関数：

• {{ args }}: 入力内容全体（文字列）
• {{ args_list.0 }}: スペース区切りの第1引数（0番目）
• {{ env.VAR_NAME }}: 環境変数
• {{ vars.my_var }}: [vars] セクションで定義した変数
• {{ file_path }}: overrides で差し替えられた元のファイルパス（フルパス）
• {{ now() | date(format="%Y%m%d") }}: 現在の日時
• {{ args | urlencode }}: URL エンコードフィルタ

Web 検索をランチャーから

| urlencode フィルタを使うと日本語もそのまま検索できます。

# Google 検索
[[apps]]
name = "Google"
path = "https://www.google.com/search?q={{ args | urlencode }}"

# 第1引数、第2引数を個別に使いたい場合
[[apps]]
name = "Multi Search"
path = "https://example.com/search?q1={{ args_list.0 }}&q2={{ args_list.1 }}"

[[apps]]
name = "Perplexity"
path = "https://www.perplexity.ai/search?q={{ args | urlencode }}"

[[apps]]
name = "GitHub Search"
path = "https://github.com/search?q={{ args | urlencode }}"

使い方: perp → Tab → rust の所有権とは → Enter で Perplexity が開きます。一度使った検索クエリは履歴に残るので、次回は候補として出てきます。

環境変数

{{ env.VAR_NAME }} または Tera 標準の {{ get_env(name="VAR") }} で環境変数を参照できます。

# プロジェクトを引数で指定してエディタで開く（src/ 以下の相対パスで補完される）
[[apps]]
name = "Open Project"
path = "neovide"
args = ["{{ env.USERPROFILE }}/src/{{ args }}"]
completion = "path"

# default 指定（Tera 標準関数）
[[apps]]
name = "Work Dir"
path = '{{ get_env(name="WORK_DIR", default="~/work") }}/{{ args }}'

日付プレフィックス付きメモ

now() 関数と date フィルターで今日の日付を埋め込めます（Tera 標準機能）。

# MemoNew: Tab → タイトル入力 → Enter で "20260321-タイトル.md" を作成して開く
[[apps]]
name       = "MemoNew"
path       = "nvim"
args       = ['~/memo/{{ now() | date(format="%Y%m%d") }}-{{ args }}.md']
completion = "none"

# MemoList: Tab → ~/memo/ 以下のファイルを migemo パス補完で選択 → Enter
# "hajime" で "初めて.md" がヒット
[[apps]]
name                   = "MemoList"
path                   = "nvim"
args                   = ["~/memo/{{ args }}"]
completion             = "path"
completion_search_mode = "migemo"

date(format="%Y-%m-%d") のようにフォーマットを変えるのも自由です。設定だけで完結する、ちょっとしたメモ管理フローが作れます。

履歴ファイル

履歴は以下のパスにシンプルな JSON として保存されています。バージョン 2 以降、構造が配列形式になり、各エントリが key と args（配列）を個別に持つようになりました。これにより、以前の形式（文字列結合）では失われがちだった「スペースを含む引数」なども正確（lossless）に保持・復元できるようになっています。

{
  "version": 2,
  "entries": [
    {
      "key": "msedge.exe",
      "args": ["https://bing.com"],
      "count": 12,
      "last_used": 1742478231
    },
    {
      "key": "Google",
      "args": ["shun", "launcher"],
      "count": 5,
      "last_used": 1775302627
    }
  ]
}

普通の JSON なので、テキストエディタで直接編集できます。/history コマンドで即座に開けます。

不要な履歴アイテムを1件ずつ消したいだけなら、ランチャー上で候補を選んで Ctrl+d を押すだけで削除できます。

マシン固有の設定は config.local.toml に

config.toml と同じディレクトリに config.local.toml を置くと、その内容がマージされます。config.toml を dotfiles などで複数マシン共通に管理しつつ、マシンごとに異なるスキャン対象パスや追加アプリは config.local.toml に書く、という運用が便利です。

# config.local.toml（このマシンだけのスキャン追加）
[[scan_dirs]]
path = "C:/work/projects"
recursive = true
extensions = ["exe", "bat", "ps1"]

ユーザー定義変数 [vars]

[vars] セクションに任意のキーを定義すると、path や args の Tera テンプレートから {{ vars.キー名 }} で参照できます。config.toml と config.local.toml はマージしてから展開されるので、config.local.toml 側の [vars] に書いた値を config.toml の [[apps]] で使うことができます。マシンごとに異なるパスなどを config.local.toml にだけ書いておく運用が便利です。

# config.local.toml
[vars]
work_dir = "C:/work/myproject"
editor   = "neovide"

# config.toml（config.local.toml の vars を参照できる）
[[apps]]
name = "Open Work"
path = "{{ vars.editor }}"
args = ["{{ vars.work_dir }}"]

技術的なポイント

Rust + Tauri v2

ネイティブアプリとして軽量・高速。バックエンドは Rust で書かれており、グローバルショートカットの登録、アプリスキャン、検索、履歴管理などをすべて Rust で処理しています。

nucleo-matcher

Helix エディタが採用しているファジーマッチャーで、精度と速度のバランスが良いです。

rustmigemo / jsmigemo

oguna 氏による Pure Rust / Pure JS の migemo 実装。辞書（yet-another-migemo-dict、Mozc + UniDic ベースの BSD-3-Clause ライセンス）をバイナリに同梱し、インストール不要で日本語ローマ字検索を実現しています。

Svelte 5 (Runes)

フロントエンドは Svelte 5 の Runes ($state, $derived, $effect) で記述。シンプルな UI ながら補完ドロップダウンやゴーストテキストなど複数の状態を管理しています。

おわりに

このランチャーは Claude Code と一緒に開発しました。自分でアーキテクチャや機能の方向性を決めつつ、Rust の細かい実装や CI/CD の設定などは Claude Code に大きく助けてもらっています。「こういう動きにしたい」という意図を伝えるだけでコードに落としてくれるので、アイデアを素早く形にできました。

Tauri v2 を使っているので Windows / macOS / Linux すべてでビルド・リリースしていますが、動作確認は Windows のみで行っています。macOS・Linux で試してみた方がいれば、フィードバックいただけると嬉しいです！

ぜひ試してみてください！

GitHub - yukimemi/shun: A minimal keyboard-driven cross-platform launcher

A minimal keyboard-driven cross-platform launcher. Contribute to yukimemi/shun development by creating an account on GitHub.

github.com

1. シェルの挿入モードからノーマルモードに戻りたい（シェルの操作）。
2. Neovim 自体のノーマルモードに戻って、ウィンドウ移動やバッファ切り替えをしたい（Neovim の操作）。

これをスムーズに行うための「二段階 Esc」設定が非常に快適だったので紹介します。

課題：Esc 一発で Neovim モードに戻ってしまう問題

通常、ターミナルモードで Esc を Neovim の <C-\><C-n>（モード抜け）にマッピングしてしまうと、シェルの vi モードとしての Esc が効かなくなります。これではシェルのコマンド履歴検索や行編集の恩恵を受けられません。

かといって、シェルの vi モードを活かすためにマッピングを外すと、Neovim 自体の操作に移るために毎回 <C-\><C-n> を打つ必要があり、これが地味にストレスです。

解決策：PowerShell 側での「二段階 Esc」実装

この問題は、PowerShell の PSReadLine で「現在のモード」を判定して Esc の挙動を変えることで解決できました。

具体的には、PowerShell のプロファイル（$PROFILE）に以下のような設定を追加しています。

# PSReadLine の ViMode を利用
if ($env:NVIM) {
  # シェルがすでに Command (Normal) モードの時に Esc を押すと、
  # Neovim 本体のサーバに対してモード変更のリモート命令を送る
  Set-PSReadLineKeyHandler -Chord Escape -ViMode Command -ScriptBlock {
    & nvim --server $env:NVIM --remote-send "<C-\><C-n>"
  }
}

この設定により、以下のような流れるような操作が可能になります。

• 1回目の Esc: シェルが Insert → Command モードに移行。シェルの vi 操作が可能になる。
• 2回目の Esc: シェルがすでに Command モードなら、Neovim 本体が Terminal-Normal モードに移行。

今回は PowerShell での設定を紹介しましたが、nvim --server を利用したリモート送信自体は Neovim の標準的な機能です。そのため、zsh や bash など、他のシェルでも bindkey などを利用して「ノーマルモード中に Esc を押した時の挙動」をカスタマイズすれば、同様の「二段階 Esc」が実現可能と思われます。

視覚的なモード管理（Neovim 側）

二段階に分けたことで、「今どちらのノーマルモード（シェル or Neovim）にいるのか」を判別する必要があります。これを Neovim 側の autocmd で視覚的にサポートします。

-- Terminal-Normal モード（Neovim 制御下）になった時だけ枠線を赤く光らせる
vim.api.nvim_create_autocmd("TermLeave", {
  callback = function()
    if vim.bo.buftype == "terminal" then
      -- モードを抜けた（Terminal-Normal になった）時に ErrorMsg ハイライトを適用
      vim.wo.winhighlight = "FloatBorder:ErrorMsg"
    end
  end,
})

vim.api.nvim_create_autocmd("TermEnter", {
  callback = function()
    if vim.bo.buftype == "terminal" then
      -- 再びターミナル操作に戻った時にハイライトをクリア
      vim.wo.winhighlight = ""
    end
  end,
})

この設定（ここでは浮動ウィンドウの FloatBorder を想定）により、「枠線が赤く光っていれば Neovim 操作モード」「そうでなければシェル操作モード」 と一目で判別できるようになります。

※ハイライトグループや適用先（FloatBorder や StatusLine など）は、自身のターミナルの開き方や好みに合わせて適宜調整してください。

まとめ

この「二段階 Esc」と「視覚的なフィードバック」を組み合わせることで、ターミナル内での vi キーバインドの利便性を最大化しつつ、Neovim 本体の操作への復帰もストレスなく行えるようになりました。

ターミナル作業が多い Vimmer の方、特に PowerShell をメインに使っている方には非常におすすめのセットアップです。

参考設定（dotfiles）

実際の私の設定は、以下のリポジトリで公開しています。

PowerShell (PSReadLine の Esc 制御)

  if ($env:NVIM) {
    Set-PSReadLineKeyHandler -Chord Escape -ViMode Command -ScriptBlock { & nvim --server $env:NVIM --remote-send "<C-\><C-n>" }
  }

Neovim (autocmd による枠線の可視化)

vim.api.nvim_create_autocmd("TermLeave", {
  callback = function()
    if vim.bo.buftype == "terminal" then
      vim.wo.winhighlight = "FloatBorder:ErrorMsg"
    end
  end,
})

vim.api.nvim_create_autocmd("TermEnter", {
  callback = function()
    if vim.bo.buftype == "terminal" then
      vim.wo.winhighlight = ""
    end
  end,
})

OpenClaw とは

OpenClaw は、自律的な AI エージェントをローカルで動かし、WhatsApp や Discord などのメッセージングアプリと連携させることができるツールです。 シェルコマンドの実行やファイル操作などのスキルを持たせることができ、AI が「思考」するだけでなく「実行」まで担ってくれます。

セットアップ手順

1. Discord Bot の作成

まずは Discord 側で Bot アカウントを作成します。

1. Discord Developer Portal で New Application を作成。
2. Bot セクションでトークンを取得。
3. Privileged Gateway Intents ですべての項目（特に Message Content Intent）を ON にして保存。
4. OAuth2 -> URL Generator で bot スコープと Administrator 権限を選択し、生成された URL をブラウザに貼り付け、自分のサーバーに Bot を招待。

注意: Intents を変更した後は、一度サーバーから Bot をキックして招待し直さないと権限変更が反映されない場合があるので注意が必要です。

2. OpenClaw の初期化

mkdir ~/.openclaw
cd ~/.openclaw
npx openclaw onboard

onboard コマンドを実行すると、対話形式でセットアップが始まります。 主な質問と設定内容は以下の通りです。

1. Risk Acknowledgement: リスクについての確認。y で承諾。
2. Onboarding mode: QuickStart を選択。
3. Model/auth provider: 使用する AI モデルを選択。Google (Gemini) や OpenAI などから選べます。
   • API キーの入力や、OAuth によるブラウザ認証（Google Antigravity OAuth など）を行います。
4. Channel Setup: ここで Discord を選択。
   • 取得した Discord Bot Token を入力します。
5. Skills/Hooks: 依存関係（スキル）のインストールに使用するパッケージマネージャ（Bunなど）の選択や、自動化のための Hooks（session-memory, command-logger など）を有効にするかを選択します。

設定が完了すると Gateway が起動し、Discord Bot がオンラインになります。

3. systemd による自動起動

セットアップの最後で、OpenClaw が「gateway サービスを systemd としてインストールし、有効化するか？」と聞いてくるので、Yes と答えるだけで自動的にバックグラウンドサービスとして常駐します。

AI の記憶と設定ファイルについて

OpenClaw の最大の特徴は、AI の記憶や設定がすべてローカルの Markdown ファイルとして管理されている点です。 ~/.openclaw/workspace ディレクトリには以下のようなファイルが生成されます。

• IDENTITY.md: AI 自身のアイデンティティ（名前、性格、口調など）。ここを編集すると AI のキャラ付けを変更できます。
• USER.md: ユーザー（自分）に関する情報。名前や好みなどが記録されます。
• MEMORY.md: 長期記憶。重要な事実や文脈がここに蓄積されます。
• SOUL.md: AI の行動原理や「魂」にあたる部分。
  • このファイルは非常にユニークで、対話を通じて「実行前には必ず確認してほしい」とか「定期的にリポジトリを同期して」といったルールが追記されていきます。git log で履歴を見ると、AI が指導を受けて成長していく様子が分かります。
• AGENTS.md, TOOLS.md: エージェントの構成や使用可能なツールの定義。

Discord で会話しながら「私の名前は yukimemi だよ」と教えたり、「〜については覚えておいて」と頼んだりすると、AI が自律的にこれらのファイルを更新します。 記憶がテキストファイルとして可視化され、さらに Git でバージョン管理できるため、「いつ何を覚えたか」が履歴として残るのが非常に面白いです。

遭遇したトラブルと解決策

Failed to resolve Discord application id エラー

Discord Bot のトークンからアプリケーション ID が正しく解決できない場合に発生します。 これは設定ファイル (openclaw.json) の不整合が原因でしたが、npx openclaw doctor --fix を実行することで、設定ファイルを自動的に修復して解決できました。

記憶（workspace）の管理

前述の通り、OpenClaw のワークスペース（~/.openclaw/workspace）はそれ自体が Git リポジトリとして管理されています。 そのため、自分の dotfiles リポジトリなどでまとめて管理しようとするとサブモジュール扱いになってしまい、中身（AI の記憶）が保存されません。

今回はワークスペースを dotfiles の管理対象外（.gitignore）とし、エージェント自身に自分の記憶を Git 管理させる という運用スタイルにしました。 AI に「記憶をコミットして GitHub にプッシュしておいて」と頼むと、自分で git commit して、GitHub CLI (gh) を使ってリポジトリ作成からプッシュまで完遂してくれました。これは感動的です。

まとめ

これで、Discord を通じていつでも自律エージェントと対話できる環境が整いました。 自分だけの AI アシスタント、これから育てていくのが楽しみです。

これを実現するために、PSReadLine のキーハンドラ機能を使って実装してみました。

実装方法

$PROFILE や、そこから読み込まれるモジュールファイルに以下のコードを追加します。

  # --- Abbreviation Expansion ---
  $abbrs = @{
    "b"     = "cd .."
    "g"     = "git"
    "s"     = "jj status"
    "d"     = "jj diff"
    "o"     = "Start-Process"
    "a"     = "git add"
    "t"     = "exit"
    "which" = "Get-Command"
    "l"     = "Get-ChildItem"
    "la"    = "Get-ChildItem -Force"
    "c"     = "Clear-Host"
    "e"     = "nvim"
  }

  $expandAbbrLogic = {
    $line = $null
    $cursor = $null
    [Microsoft.PowerShell.PSConsoleReadLine]::GetBufferState([ref]$line, [ref]$cursor)

    if ($cursor -gt 0) {
      $sub = $line.Substring(0, $cursor)
      if ($sub -match '(?<Word>\S+)$') {
        $word = $Matches['Word']
        if ($abbrs.ContainsKey($word)) {
          [Microsoft.PowerShell.PSConsoleReadLine]::Delete($cursor - $word.Length, $word.Length)
          [Microsoft.PowerShell.PSConsoleReadLine]::Insert($abbrs[$word])
        }
      }
    }
  }

  Set-PSReadLineKeyHandler -Key Spacebar -ViMode Insert -ScriptBlock {
    . $expandAbbrLogic
    [Microsoft.PowerShell.PSConsoleReadLine]::Insert(' ')
  }.GetNewClosure()

  Set-PSReadLineKeyHandler -Key Enter -ViMode Insert -ScriptBlock {
    . $expandAbbrLogic
    [Microsoft.PowerShell.PSConsoleReadLine]::AcceptLine()
  }.GetNewClosure()

解説

略語辞書の定義

$abbrs ハッシュテーブルに、略語と展開後のコマンドを定義しています。 例えば "g" = "git" と定義しておくと、g と入力してスペースを押すと git に置き換わります。

自分は一文字コマンドをけっこうたくさん定義しています。 一文字でできるとすごい早くて便利！

展開ロジック

$expandAbbrLogic スクリプトブロックで実際の置換処理を行っています。

1. GetBufferState で現在の入力行とカーソル位置を取得。
2. カーソル直前の単語を正規表現 (?<Word>\S+)$ で抽出。
3. その単語が $abbrs に存在すれば、Delete で削除し Insert で展開後の文字列を挿入。

キーハンドラの設定

Set-PSReadLineKeyHandler を使い、Spacebar (スペースキー) と Enter キーをフックしています。

• Spacebar: 略語を展開してから、スペースを挿入します。これにより、g -> Space -> git となり、続けて引数を入力できます。
• Enter: コマンドの末尾で略語を使って即実行する場合（例: exit を t に割り当てて t -> Enter）のために、Enter キーでも展開処理を走らせてから AcceptLine (実行) しています。

まとめ

エイリアスとは異なり、実際に実行されるコマンドが入力中に明示され、そのまま履歴に残るのがメリットです。 コマンドの打ち間違いにも気づきやすくなるため、よく使うコマンドを登録しておくと重宝します。

それが、キャッシュ機能 と 遅延ロード機能 です。

起動直後からプラグインを使いたい！ (キャッシュ機能)

前回の記事で、 dvpm の特徴として「どれだけプラグインを入れても起動速度が劣化しない」という点を挙げました。 しかし、これには「起動直後はプラグインがまだ読み込まれておらず、バックグラウンドで denops が立ち上がってから順次読み込まれる」というトレードオフがありました。

「爆速で起動してほしいけど、起動した直後から Telescope などのプラグインをすぐに使いたい……」

そんなわがままを叶えるのが キャッシュ機能 です。

仕組み

dvpm のキャッシュ機能は、各プラグインの runtimepath への追加処理や、 before / after で指定した Vim script / Lua の設定を、一つの .vim ファイルに書き出します。

次回以降の Vim / Neovim 起動時に、このキャッシュファイルを source するように設定しておけば、 denops の起動を待たずして、通常のプラグインマネージャーと同じように起動時からプラグインが有効になります。

設定方法

Dvpm.begin でキャッシュファイルの出力先を指定し、各プラグインで cache.enabled: true を設定するだけです。

export async function main(denops: Denops): Promise<void> {
  const base_path = (await fn.has(denops, "nvim")) ? "~/.cache/nvim/dvpm" : "~/.cache/vim/dvpm";
  const base = (await fn.expand(denops, base_path)) as string;

  // キャッシュファイルの出力先を指定
  const cache_path = (await fn.has(denops, "nvim"))
    ? "~/.config/nvim/plugin/dvpm_plugin_cache.vim"
    : "~/.config/vim/plugin/dvpm_plugin_cache.vim";
  const cache = (await fn.expand(denops, cache_path)) as string;

  const dvpm = await Dvpm.begin(denops, { base, cache });

  // キャッシュを有効にする
  await dvpm.add({
    url: "tani/vim-artemis",
    cache: { enabled: true },
  });

  // 起動時にすぐ表示されてほしいダッシュボードなどはキャッシュに最適
  await dvpm.add({
    url: "goolord/alpha-nvim",
    enabled: async ({ denops }) => await fn.has(denops, "nvim"),
    cache: {
      after: `
        lua << EOB
          require("alpha").setup(require("alpha.themes.startify").config)
        EOB
      `,
    },
  });

  await dvpm.end();
}

このように設定しておくと、 dvpm がキャッシュファイルを自動生成してくれます。 ダッシュボードのような「起動した瞬間に見えていてほしい」プラグインでも、ストレスなく利用できるようになります。

キャッシュの詳細オプション

キャッシュ機能にも、通常ロードと同様に、以下の設定オプションが用意されています。

• before: プラグインが runtimepath に追加される 前 に実行する Vim script / Lua を記述します。
• after: プラグインが runtimepath に追加された 後 に実行する Vim script / Lua を記述します。
• beforeFile: before と同様ですが、文字列ではなく外部ファイル（ .vim や .lua ）のパスを指定して読み込ませます。
• afterFile: after と同様に、外部ファイルのパスを指定します。

before, after, beforeFile, afterFile のいずれかが設定されている場合、 cache.enabled: true は省略できます

必要な時だけ読み込みたい！ (遅延ロード機能)

最近のプラグインマネージャー（ lazy.nvim など）では当たり前となっている 遅延ロード (Lazy Load) にも対応しました。

「特定のファイルタイプを開いた時だけ」「特定のコマンドを叩いた時だけ」といった条件でプラグインをロードできます。

設定例

dvpm.add の lazy オプションで指定します。

  // コマンド実行時にロード
  await dvpm.add({
    url: "tweekmonster/startuptime.vim",
    lazy: { cmd: "StartupTime" },
  });

  // 特定のイベント発生時にロード (例: インサートモードに入った時)
  await dvpm.add({
    url: "cohama/lexima.vim",
    lazy: { event: "InsertEnter" },
  });

  // ファイルタイプに応じてロード
  await dvpm.add({
    url: "OXY2DEV/markview.nvim",
    lazy: { ft: "markdown" },
    dependencies: ["nvim-treesitter/nvim-treesitter"],
  });

  // キー入力でロード
  await dvpm.add({
    url: "mbbill/undotree",
    lazy: {
      keys: {
        lhs: "<leader>u",
        rhs: "<cmd>UndotreeToggle<cr>",
        mode: "n",
        desc: "Undo Tree",
      },
    },
  });

  // ライブラリとそれを使用するプラグインの遅延ロード
  await dvpm.add({
    url: "kana/vim-textobj-user",
    lazy: { enabled: true },
  });
  await dvpm.add({
    url: "kana/vim-textobj-entire",
    dependencies: ["kana/vim-textobj-user"],
    lazy: {
      keys: [
        { lhs: "ie", mode: ["x", "o"] },
        { lhs: "ae", mode: ["x", "o"] },
      ],
    },
  });

keys の指定では、プロキシマッピングを自動で作成し、キーが押された瞬間にプラグインをロードして、本来の機能を実行するようになっています。 mode や desc を指定することで、 which-key.nvim などのプラグインとも相性良く設定できます。

遅延ロードの詳細オプション

遅延ロード設定は配列指定など、いくつかのパターンで設定できます。

• 配列での指定: cmd, event, ft, keys はいずれも配列を受け取れます。複数のコマンドやファイルタイプをきっかけにロードしたい場合に便利です。
• keys の lhs のみ指定: rhs を省略して lhs だけを指定することも可能です。この場合、ロード後に dvpm が作成した暫定的なマッピングを解除（unmap）し、プラグイン側が本来定義しているマッピングが有効になるように振る舞います。
• 依存関係の自動ロード: lazy 設定されたプラグインが読み込まれる際、 dependencies に指定されたプラグインも（それらが lazyであっても）自動的にロードされます。

ライフサイクルと User イベント

dvpm はプラグインの登録からロードまでの各工程で、詳細に制御するためのフックと User イベントを提供しています。 フックの実行順序は以下の通りです。

1. add / addFile: Dvpm.end() 実行時に常に実行（ロードの有無に関わらず実行）。
2. before / beforeFile: runtimepath に追加される直前に実行（遅延ロード時はロード発生時）。
3. after / afterFile: runtimepath に追加され、 plugin/*.vim や plugin/*.lua がソースされた直後に実行。

また、これらに合わせて詳細な User イベントも発火します。

システムライフサイクルイベント

• DvpmBeginPre / DvpmBeginPost: Dvpm.begin() の前後。
• DvpmEndPre / DvpmEndPost: Dvpm.end() の前後。
• DvpmInstallPre / DvpmInstallPost: プラグイン全体のインストール前後。
• DvpmUpdatePre / DvpmUpdatePost: プラグイン全体のアップデート前後。
• DvpmCacheUpdated: キャッシュファイルが更新された時。

プラグイン個別イベント

• DvpmPluginLoadPre:{pluginName} / DvpmPluginLoadPost:{pluginName}: 個別ロードの前後。
• DvpmPluginInstallPre:{pluginName} / DvpmPluginInstallPost:{pluginName}: 個別インストールの前後。
• DvpmPluginUpdatePre:{pluginName} / DvpmPluginUpdatePost:{pluginName}: 個別アップデートの前後。

※ {pluginName} は dvpm で管理されているプラグイン名です。通常はリポジトリ URL の末尾（例: cohama/lexima.vim なら lexima.vim）になりますが、 dvpm.add の際に name プロパティで任意の名前を指定することも可能です。

このように、Vim script / Lua 側からも autocmd User DvpmPluginLoadPost:lexima.vim ... といった形で、特定のプラグインがロードされたタイミングをフックすることができます。 また、ワイルドカードを使って、各プラグインがロードされるたびに共通の処理を一括でフックすることも可能です。

// 各プラグインがロードされるたびに、そのプラグイン名をログに出す例
await autocmd.define(
  denops,
  "User",
  "DvpmPluginLoadPost:*",
  `echom "Loaded plugin: " . substitute(expand("<amatch>"), "^DvpmPluginLoadPost:", "", "")`,
);

他にも DvpmBeginPre/Post, DvpmEndPre/Post, DvpmCacheUpdated といったシステム全体のライフサイクルに合わせたイベントも用意されています。

まとめ

キャッシュ機能と遅延ロード機能が加わったことで、 dvpm は「TypeScript で Vim / Neovim の設定が書ける」という変態的なメリットを維持したまま、現代的なプラグインマネージャーとしての利便性と、圧倒的な起動速度の両立を手に入れました。

「やっぱり設定は型安全に TypeScript で書きたい！」という方は、ぜひ試してみてください。

yukimemi/dvpm: dvpm - Denops Vim/Neovim Plugin Manager