opentui

OpenTUI で端末の画面（TUI）を作るときに使います。説明文は、部品・配置・キー入力とキーの割り当て・動き・試験を含む、どんな TUI の作業にも使え、と書いています。

OpenTUI は anomalyco/opentui で開発されている TUI の枠組みです。このスキルはその使い方を、本体とは別の作者がまとめた参照の資料です。

同梱の資料（2026-10-23 時点）

26 件

同梱の資料の合計（2026-10-23 時点）

約 230 KB

本文の分かれ道（決定木）

9 本

必ず守る決まり

4 つ

本文は道案内で、中身は資料にある

本文（10,003 バイト、2026-10-23 時点）は、やりたいことから読むべき資料を引く道案内です。資料の側は合計で約 230 KB あり、必要なものだけを開く作りになっています。

枠組みごとの資料は、どれも 5 本の同じ並びです。

• REFERENCE.md概要と始め方。最初に必ず読む
• api.md部品とフック。コードを書くとき
• configuration.mdtsconfig や組み立ての設定
• patterns.mdよくある形と勧められる書き方
• gotchas.md落とし穴と不調の切り分け

これが Core・React・Solid の 3 つにあり、ほかに部品（5 本）、配置（2 本）、キー入力・キーの割り当て・動き・試験（各 1 本）が並びます。

枠組みを選ぶ分かれ道

本文の最初の分かれ道は、どの枠組みで書くかです。

Core の資料は、ふつうのアプリや手早い試作なら React か Solid を勧めています。残りの分かれ道は、表示・入力・配置・動き・キー操作・試験・端末の機能（音・画像・クリップボード・通知・SSH）・不調の切り分けです。

必ず守る 4 つの決まり

本文の冒頭に、OpenTUI のどのコードでも守れ、という決まりが 4 つあります。

• 新しいプロジェクトは create-tui で作る
• create-tui の旗は引数の前に書く。bunx create-tui -t react my-app は動き、bunx create-tui my-app -t react は動かない
• process.exit() を直に呼ばない。renderer.destroy() を使う
• React と Solid では、文字の飾りは属性ではなく入れ子のタグで付ける

Core の資料は、エージェントは必ず -t <雛形> を付けた自動の形で使え、とも書いています。旗の無い対話の形は人の入力を待つので、エージェントは答えられません。作るディレクトリは、まだ存在してはいけません。

• OpenTUI 以外の TUI の枠組み本文は OpenTUI の API だけを扱う
• ブラウザの画面部品は端末用。<div> や <button> は使えないと React の資料にある
• Bun も新しい Node.js も使えない基準は Bun。Node.js は 26.4.0 以降で、ネイティブの描画に FFI が要る

Ink など別の枠組みで作っているなら、このスキルの部品の名前や API は当てはまりません。React の資料は、OpenTUI の JSX の要素は HTML の要素ではないと、はっきり書いています。

Bun と Node.js の扱いが資料によって違う

Core の資料によると、ネイティブの描画を作らずに @opentui/core を読み込むだけなら、FFI 無しの Node.js でも動きます。Node の権限の仕組みの下では、--allow-ffi とファイルの権限も要ります。

process.exit() の扱い

決まりは「直に呼ぶな」ですが、Core の資料の例には、renderer.destroy() を待ったあとで process.exit(1) を呼ぶ形も「正しい」として載っています。要は、端末の状態を戻す destroy() を先に通すことです。

process.exit() だけで抜けると、代わりの画面の状態や生の入力の状態が残り、端末が壊れたように見えます。React の資料は、これをいちばん多い間違いとしています。

console.log が見えない

OpenTUI は画面の上に重ねる表示のために console の出力を取り込むので、動かしている間は端末にログが出ません。資料は、重ねた表示を renderer.console.show() で出す、ファイルに書く、OTUI_USE_CONSOLE=false で取り込みを止める、といった手を挙げています。

書かれているコマンドと通信

SKILL.md と資料に書かれているのは、bunx create-tui・bun install・bun run・bun test などのシェルコマンドの実行です。create-tui と bun install は、パッケージを取りに外と通信します。

Core の資料の SSH の例は、@opentui/ssh で TUI を SSH の上に出し、2222 番で待ち受けます。例の認証の設定は publicKey: "any" です。名前どおりに受け取れば鍵を選ばない設定なので、外から届く場所で動かすなら認証の設定を先に確かめてください。

同梱の命令と導入の台本は、このスキルの外にある

リポジトリには、OpenCode 用の /opentui の命令と導入の台本 install.sh もあります。README は、curl で取った台本を bash に流す入れ方を案内しています。npx skills add で入るのはスキルの資料だけで、この 2 つは含まれません。

資料はある時点の本体に合わせたもの

README の末尾に、本体 anomalyco/opentui のどのコミットに合わせたかが書かれています（fbd584b2、2026-08-27）。パッケージの置き場所が移ることもあり、本文の表にも @opentui/three は元 core/src/3d、のような注記があります。資料より新しい版を使うなら、本体の文書と照らしてください。

ライセンスは MIT です。

React と Solid で部品の名前は同じですか

ほぼ同じですが、複数の語からなる名前の書き方が違います。React は <tab-select> のようにハイフン、Solid は <tab_select> のように下線です。Solid でハイフンの名前を使うと、資料によるとエラーになります。表やスライダーなど、Core でしか使えない部品もあります。

試験はどう書きますか

資料の testing/REFERENCE.md に、Bun の試験の仕組みと、試験用の描画の用意（createTestRenderer、React と Solid は testRender）が載っています。描いたあとに renderOnce() を呼んでから画面を取り込むこと、試験ごとに描画を destroy() すること、スナップショットの大きさをそろえることが落とし穴として挙がっています。

Zig は必ず入れる必要がありますか

いいえ。TypeScript の変更は Bun がそのまま動かすので、組み立ては要りません。Zig が要るのは、OpenTUI のネイティブの部分（Zig のコード）を変えて作り直すときだけだと、Core の資料に書かれています。

どのエージェントで使えますか

README は、npx skills add msmps/opentui-skill の入れ方が Claude Code・Codex・Cursor・Gemini CLI・GitHub Copilot・Goose・OpenCode・Windsurf で動くと書いています。OpenCode には、命令の /opentui を一緒に入れる別の導入の台本もあります。