CLI UX レビュー は何をしますか？
開発者以外の、そのCLIを初めて使用するユーザーの視点に立ち、固定評価項目に基づいてCLIを監査します。
呼び出すタイミング
- 「CLI UX監査」/ 「CLIレビュー」/ 「このCLIは直感的か」
- すべてのCLIリリース前
- CLIコマンドの追加または変更後
基本方針
すべてのコマンド出力は、次の3つの質問に答えなければなりません。 「状況は何か？ · 次のステップは何か？ · 何ができるか？」
品質基準：コマンドの終了は、Codexがセッションを終了する方法と同じく、プレーンなステータス行の後に、正確な次のコマンドを、一目で「これを入力する」と分かるように、明確な色で表示すること。
評価項目（各コマンドを7項目すべてで評価）
- 次のステップの表示。 すべての成功／終了状態は、次のコマンドか、「完了しました」という明示的なメッセージで終わること。コマンドが静かに停止してはいけない。
- コマンドの色分け。 実行可能なコマンドは、一貫したアクセントカラー（シアン＋太字）で表示すること。生のテキストやリテラルなバッククォートで表示してはいけない。
- 内部実装の露出なし。 列挙値、状態コード、専門用語をユーザー出力に使わないこと。人間の言葉と、必要なら1行の説明を付ける（例：「dirty」ではなく「ローカル編集」）。
- 無反応ハングの防止。 長時間実行されるコマンドやstdioコマンドは、TTY上で自身の動作を明示し、ターミナルがフリーズして見えないようにすること。
- 一貫したプリミティブ。 1つのグリフセット、1つの行/テーブルヘルパー、1つの次のステップブロックを、全コマンドで共有し、コマンドごとに再発明しないこと。
- エラーに修正方法を埋め込む。 すべてのエラーメッセージは、それを解決する正確なコマンドを明記すること。
- 初回起動ガイド。 引数なしの起動やログインしていない状態で、番号付きのクイックスタートを表示すること。
実行方法
- すべてのコマンドとすべての出力パスを洗い出す。
--helpだけでなくソースコードを読むこと。 - 各コマンドについて、成功パス、エラーパス、空の状態を一つずつ確認する。
- 7つの評価項目に基づいてスコアを付ける。発見事項には
ファイル:行数を引用すること。 - 不合格の場合、具体的な before / after を実際の文字列で記述する。
- 出力：横断的な問題、コマンド別の表、優先順位付けされた before/after 修正、実行計画。
出力形式
発見ドキュメント：要約と核心的問題、横断的問題の表、コマンド別の発見事項、各修正の before/after、実行計画。実際の出力パスを確認せずに「問題なし」と記載してはいけない。