tui-fundamentals について
ターミナルユーザーインターフェースを計画する開発者向けの設計・アーキテクチャガイドです。TUIの適否、フレームワーク選定、状態管理、端末互換性を扱います。
主な機能
- 01TUIの適否の判断
- 02モデル・更新・ビューの分離
- 03端末サイズに応じたレイアウト
- 04端末ライフサイクルの一元管理
- 05フレームワーク選定ガイド
活用シーン
- 01フルスクリーンTUIまたはCLIの計画
- 02ターミナルアプリのフレームワーク選定
- 03端末サイズ変更に対応するレイアウト設計
- 04自動化と対話操作の両立
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/tui-fundamentalsを入力して読み込まれたか確認します。
同梱ファイルreferences/framework-selection.mdreferences/tui-architecture.md
詳細
TUI の基礎、アーキテクチャ、フレームワークの選定
ターミナル製品の設計、つまりどのような TUI を構築するか、どの抽象化を使うか、状態をどう整理するか、フルスクリーンのターミナル UI が適切かどうかを検討するタスクで、このスキルを使用します。
最初の判断：TUI は適切ですか？
ユーザーが継続的な視覚的フィードバック、複数ステップのナビゲーション、キーボードによる探索、多数の項目からの選択、ダッシュボードのような操作画面を必要とする場合は、リッチな TUI を優先します。フローが短く、スクリプト化しやすく、主に自動化を目的としている場合や、スクリーンリーダーや CI システムで使われる可能性が高い場合は、行指向の CLI、プロンプト、またはプレーンな出力を優先します。
本番環境向けのターミナル製品では、多くの場合、次の両方を提供します。
- 自動化、アクセシビリティ、ログ、非 TTY での使用に対応する、スクリプト化可能な CLI。
- 探索、監視、一括選択、ガイド付きワークフローに対応する、任意で使用できる TUI。
アーキテクチャのルール
- モデル、更新、ビューを分離します。 ビジネス状態をターミナルに直接出力してはいけません。描画は状態を参照し、入力はイベントを生成し、更新ロジックは状態を変換します。
- ターミナルサイズを入力として扱います。 レイアウトは、サイズ変更のたびに幅と高さに基づいて再計算する必要があります。特定のターミナルサイズを前提にしてはいけません。
- ターミナルのライフサイクルは一箇所で管理します。 raw モード、代替画面、マウス、フォーカス、キーボードプロトコル、クリーンアップは、一元管理する必要があります。
- すべての操作をキーボードで実行できるようにします。 マウス対応は拡張機能であり、主要なナビゲーション手段ではありません。
- 機能低下時の動作を設計します。
TERM=dumb、非 TTY 出力、カラー非対応、Windows コンソールの差異、tmux/screen、SSH、CI に対して、明確な動作を用意する必要があります。 - 隠れたグローバルターミナル出力を避けます。 ログ、進捗状況、バックグラウンドタスクの出力によって画面が乱れないようにする必要があります。
フレームワーク選定の簡易マトリクス
| 必要なもの | 有力な選択肢 |
|---|---|
| 正確な描画を行う Rust のフルスクリーンアプリ | Ratatui + Crossterm |
| ウィジェット、CSS、非同期ワーカーを備えた本番品質の Python アプリ | Textual |
| リッチな出力、進捗状況、テーブル、Markdown、ログに対応する Python アプリ | Rich |
| REPL、シェル、補完、複雑なプロンプト入力に対応する Python アプリ | prompt_toolkit |
| 依存関係を抑えた従来型の Unix TUI | curses/ncurses |
| 合成可能なコマンドを備えた Go の Elm 風アプリ | Bubble Tea + Bubbles + Lip Gloss |
| フォーム、テーブル、ツリービューを標準で備えた Go アプリ | tcell 上の tview |
| Go のポータブルな低レベルセルエンジン | tcell |
| Node で React 風のターミナルコンポーネントを使うアプリ | Ink |
| Node の DOM のようなフルスクリーンウィジェット | Blessed |
| .NET のフルスクリーンビュー | Terminal.Gui |
| .NET のリッチな CLI 出力とプロンプト | Spectre.Console |
新しいプロジェクトでフレームワークを決定する前に、references/framework-selection.md をお読みください。
製品設計チェックリスト
- 主要なユーザージャーニーを一文で定義します。
- アプリをフルスクリーン、インライン、プロンプトベース、またはハイブリッドのどれにするか決めます。
- 対応が必要な環境を列挙します：Windows Terminal、従来型 conhost、macOS Terminal、iTerm2、GNOME Terminal、Alacritty、SSH、tmux/screen、CI、ログ。
- ターミナルの最小サイズと、小さい画面での代替表示を定義します。
- 終了キー、破壊的操作の確認ルール、復旧手順を定義します。
- 必須の操作すべてについて、非対話型の代替手段を定義します。
- ヘルプの表示方法を決めます：フッターのヒント、
?、コマンドパレット、--help、ドキュメント。
失敗しやすいポイント
- スクリプト化すべきワークフローにフルスクリーン UI を構築する。
- フレームワークでレイアウト、入力、クリーンアップ、テストをすでに解決できるのに、低レベルのエスケープシーケンス方式を選ぶ。
- ビジネスロジックとターミナルへの出力を混在させ、テストが不安定になり、描画に一貫性がなくなる。
- スクリーンリーダーの利用者、CI、パイプ、
TERM=dumbへの対応を後回しにする。 - カラー、Unicode アイコン、Nerd Fonts、マウス対応が常に利用できると想定する。
参考ファイル
references/framework-selection.md- エコシステムの詳細な比較と判断ツリー。references/tui-architecture.md- 状態、イベント、ライフサイクル、ログ、配布のパターン。
コメント
Markdown 対応