Vibe Coding は準備が 9割

最近、コーディングエージェントを使いこなすために tmux に入門したんですが、セッションをいい感じに立ち上げてくれる tmuxinator が微妙にかゆいところに手が届かなかったので、せっかくだし作ってみようということで tumuxrs というツールを Rust で作ってみました

https://github.com/beijaflor/tmuxrs

なぜ作ったのか

tmuxinator でセッションを起動する方法は2つあります

1. 対象ディレクトリに .tmuxinator.yml を作成 → そのディレクトリで tmuxinator start を実行
2. ~/.config/tmuxinator/project.yml を作成 → どこからでも tmuxinator start project を実行

個人的には設定ファイルは一箇所に集約したい（各リポジトリに .tmuxinator.yml を散らかしたくない）のですが、かといって毎回プロジェクト名を指定するのも面倒です。

そこで tmuxrs では

• ~/.config/tmuxrs/project.yml に設定を集約
• プロジェクトディレクトリで単に tmuxrs start を実行するだけで、ディレクトリ名から自動的に設定を検出

という仕組みにしました。あと tmuxinator というコマンド名は長すぎる…

Vibe Documenting

Vibe Coding のアプローチはいろいろあると思いますが、今回は横道に逸れないように事前にしっかり設計する方法で進めました。

とはいえ tmux にも tmuxinator にも詳しくないので、まずは 名前だけ　ChatGPT と相談して決めて Claude Code 用のインストラクションを作ってもらい それを元にドキュメントを仕上げていきました

name = "myproject"
root = "~/projects/myproject"

[[windows]]
name = "editor"
commands = ["nvim"]

[[windows]]
name = "server"
commands = ["cargo run"]

[[windows]]
name = "logs"
commands = ["tail -f log/dev.log"]

最終的に出来上がったドキュメントは以下のような感じです

 docs/
  ├── README.md                         # 📖 ドキュメント全体のナビゲーション・ガイド
  ├── ROADMAP.md                        # 🗺️  開発ロードマップ（MVP→拡張→完全版）
  │
  ├── design/                           # 🏗️  アーキテクチャ設計ドキュメント
  │   ├── 01-feature-decisions.md       # ⚖️  全ての設計判断とトレードオフ分析
  │   └── 02-system-architecture.md     # 🏛️  モジュール構造・データフロー・実装詳細
  │
  ├── guides/                           # 📋 実装ガイド
  │   └── 01-implementation-guide.md    # 🛠️  段階的コーディング手順（10-14時間のMVP計画）
  │
  └── research/                         # 🔍 既存ツール調査・分析
      ├── 01-tmux-internals.md          # 🧠 tmuxのクライアント・サーバーモデル理解
      ├── 02-tmuxinator-analysis.md     # 💎 Ruby実装・ERBテンプレート・YAML処理分析
      ├── 03-tuxmux-analysis.md         # 🦀 Rust実装・KDL設定・Git統合パターン
      ├── 04-dmux-analysis.md           # 🎯 ディレクトリ非依存テンプレート手法
      └── 05-comparison-matrix.md       # 📊 機能比較マトリックス・哲学分析

とはいえ一発でこの形になったわけではありません。ほぼ何もないに等しいインストラクションを以下の手順で仕上げていきました

0. ドキュメンテーションのプランを立ててもらう

まずはどうやって仕様の明文化をするかのプランを立ててもらいました

今回のアプリケーションのコアとなる「コマンドで tmux を起動する」という部分の実装方法はアプリケーションが異なってもそこまで大きくは変わらないはずです。その部分をゼロから決める必要はないので、同じようなツールのリサーチをしてから設計をしてくださいと頼みました

1. リサーチ：
    - 競合アプリ（tuxmux、dmux）の実装を調査
2. 設計：
    - システムアーキテクチャを事前に設計
3. 実装計画：
    - ステップバイステップの実装ガイドを作成
4. コーディング：
    - 文書化された計画に従って実装

1. DeepWiki でリサーチ

競合アプリの調査には DeepWiki MCP を使います。最初は Rust 製の tmux ラッパーである tuxmux と dmux の調査だけをお願いしたんですが、Claude Code が気を利かせて tmux 本体と tmuxinator の調査も追加してくれました。

ちなみに tuxmux と dmux の DeepWiki エントリーはまだなかったので、作業時に作成しました

2. 競合ツールの機能比較

tuxmux と dmux の機能分析、そして tmuxinator の機能分析を眺めてみると結構異なる部分が多く、このまま実装計画に進むと迷走しそうだったのでまずは機能比較を作ってもらいました

### Configuration Loading Patterns

| Pattern | tuxmux | dmux | tmuxinator |
|---------|--------|------|------------|
| **Layered Config** | ✅ Global → Local | ✅ CLI → Env → File → Default | ❌ |
| **Multi-Format** | ❌ KDL only | ✅ 4 formats | ❌ YAML only |
| **Search Paths** | ✅ XDG paths | ✅ Multiple locations | ✅ Multiple locations |
| **Validation** | ✅ Compile-time | ✅ Serde | ✅ Runtime |

3. feature-decisions.md の作成

機能比較を作ってもらったんですがこれを読んで理解するのは労力がかかるなと思ったので「実装に進む前にいくつか設計上の意思決定をしないといけないと思うんだけど一緒に考えてくれない？」的な事を頼んだところ、各機能について「概要とメリットデメリット、オプション」を列挙したドキュメントを作ってくれました。神すぎる

## 1. Configuration System

### A. Configuration Format Support

**Options:**

1. **YAML-only** (tmuxinator compatibility)
   - ✅ Perfect tmuxinator migration
   - ✅ Single format simplicity
   - ❌ Limited user choice
2. **Multi-format** (YAML + JSON + TOML)
   - ✅ User preference flexibility
   - ✅ Better tooling integration
   - ❌ More complexity
   - ❌ Testing multiple formats

**Decision:** [ ] Option 1: YAML-only [ ] Option 2: Multi-format

4. 差別化ポイントを Claude と壁打ち

feature-decisions.md の中でいくつか決めきれない項目があったので、それに関してはチェックを入れずに「わからないから一緒に考えて」みたいなお願いをして一緒に考えてもらいました。特に Configuration Loading Strategy に関しては今回一番解決したかった事だったので、そのほかのツールとの比較なんかをしながら決めていきました

### The Problem with tmuxinator
tmuxinator requires either:
- Manual project specification: `tmuxinator start webapp`
- Scattered config files: `.tmuxinator.yml` in every project directory

This creates friction - you either lose convenience or end up with config files scattered across projects.

### tmuxrs Solution: Best of Both Worlds

**Centralized Configuration:**

~/.config/tmuxrs/
├── webapp.yml
├── api-server.yml
└── mobile-app.yml

**Directory-Aware Execution:**

cd /path/to/webapp/
tmuxrs start                    # Auto-detects webapp.yml

cd /different/path/to/webapp/   
tmuxrs start                    # Still finds webapp.yml (same project)

cd /path/to/api-server/
tmuxrs start                    # Auto-detects api-server.yml

この部分の言語化を自分一人でやっていたら多分諦めていたかも

5. 実装ドキュメントの作成

これは特に何もなくデファクトに従ってもらいました。注意点としてはデファクトを勝手に察する場合が多いので「公式やウェブを検索して一般的な方法に従ってください」と明示するのだけ大事ですね

Rust ということもあってツールチェインがほぼ固定されていたのもよかったのかも

6. 作成されたドキュメントを整理

この時点でドキュメントはルートディレクトリにまとめて置いてあり、また内容にも重複がありました。レポジトリを公開するにあたっても邪魔なので「重複を排除して整理してね」とお願いしました。 Claude Code にドキュメントを作り散らかしてもらってあとで整理させるというのは結構使いやすいテクニックなのでおすすめです

ちなみに最初にお願いしたところ DOCUMENTS.md というドキュメントの説明をまとめたファイルを作ってきたので「そうじゃなくてディレクトリ階層とファイル名で整理して」とダメ出し。これも頻出するので変なドキュメント作っていないかたまにチェックするといいかも

7. CLAUDE.md を作ってもらう

ここまでくると具体的な実装に入れるようになったので直前に CLAUDE.md を作り直してもらいました（実は一番最初に作ってもらっていた）。これもアプリケーションのコンセプトとか余計な内容が入ってしまったので「公式とほかの Rust プロジェクトを参考にしてね」とお願いしたらいい感じのものが出てきます

実装フェーズはオートパイロット

ここまでで全体の作業時間の半分くらいを使っているんですが、ここからは完全に Vibe Coding です。コミットも任せて実装を進めてもらいつつ、各フェイズの合間に成果物の確認をする感じ。確認方法も Claude Code に聞くと教えてくれます

もう Vibe Coding というよりは実装が進むのを外から眺めている感じで、どんどん機能が実装されていくのが気持ちよかったです。同じ技術スタックの既存のレポジトリを複数参考にしているため Vibe Coding にありがちな横道に逸れることもほぼなく、細かい微調整のみで最後まで作り切ってくれました

まとめ

今回はドキュメントを Vibe で作って、実装はほぼノータッチという感じでした。 Claude Code は結構気軽にドキュメントを作ってくれるので最初はあまり細かいことは考えずに量産してもらって、適当なタイミングで整理をしてもらうのが良さそうです。その際には「ドキュメントを見直して重複をチェックして正しいドキュメントに整理してね」的なプロンプトを渡すとやってくれます

シンプルなツールですが結構堅牢で Production Ready なクオリティのコードベースになった気がしています。今回の DeepWiki に競合調査してもらって比較表と意思決定のドキュメントを作ってから実装ドキュメントを作るという方法は再現性が高そうなので今後も活用していきたいな、と思いました