القائمة
UI モード・状態遷移・ガード条件の追加・変更時、または計画レビュー時に使用。既存モードとの直交性・リセット経路・入力分岐・SPEC §8.6 整合を検証する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
workspace/plan.md の完成後、実装着手前に使用。計画の影響範囲・不変条件・スコープの漏れを検証する。
GitHub issue から作業を開始するときに使用。実装の前段階（ブランチ作成・調査・計画・計画レビュー）までを行う。
コード変更を伴うタスク（機能追加・バグ修正・リファクタリング）の実装時に使用。実装からコミット作成まで自律的に行う（計画が要る変更は /start-issue へ）。
大きなサイクル完了後や定期メンテナンス時に使用。governance:check（決定的検査）を実行し、機械化できない意味的整合（コマンド直書き grep・npm ラッパー等価・メモリ整合）を検証して報告する（修正はしない）。
開発サイクル完了時（実装・レビュー・追加修正まで済んだ後）に使用。教訓の抽出・残タスクの振り分け・RETROSPECTIVE.md 更新を行う。
worker スレッド・channel・フレーム drain・Tauri listener・スレッド/窓をまたぐ共有状態・フレーム内 live-read を追加/変更したとき、または async 関数を追加/変更したとき、あるいは計画レビュー時に使用。送信から適用までの窓での状態競合リスクを検証する。
| name | state-check |
| description | UI モード・状態遷移・ガード条件の追加・変更時、または計画レビュー時に使用。既存モードとの直交性・リセット経路・入力分岐・SPEC §8.6 整合を検証する。 |
| argument-hint | [変更内容, 例: 'InstantCommandMode 追加' / 'indexing ガードを handleInput に追加'] |
| allowed-tools | ["Read","Grep","Glob"] |
$ARGUMENTS のモード・状態遷移・ガード条件について、既存の状態モデルとの整合を検証する。 $ARGUMENTS が空の場合は、会話の直近の変更内容から対象を推定する。
実装後のコードレビューだけでなく、workspace/plan.md の計画レビューにも使える。計画段階で「このモード追加は既存モデルと整合するか？」を検証し、見落としがあれば計画を更新してから実装に進む。
このプロダクトの UI 状態は複数の直交・排他モードの組み合わせで動く（SPEC.md §8.6 / §18.5 / §19.7）:
folderState（フォルダ展開）と toolSelectionState（ツール選択）は直交interpKind() の instant は plain（NormalMode）/ command（CommandMode）と排他（入力解釈は単一の判別子値。query+prefix から純粋導出）toolSelectionState !== null > folderState !== null > 通常モードモードやガードを1つ追加・変更すると、既存の全モードとの組み合わせそれぞれについて「排他か・直交か・どちらが優先か」の明示的な判断が必要になる。判断されなかった組み合わせは「たまたま動く」状態で残り、別の変更で壊れる。
典型的なバグパターン:
resetForShow() でクリアされず、ホットキー再表示時に前回の状態が残るif (indexing()) return 等）が、初回起動・エラーリカバリ・別モードの特殊パスを意図せず塞ぐ（AGENTS.md「初回フローとガードの相互作用」）$ARGUMENTS から以下を抽出する:
対象コードを読む。主な置き場所: src-tauri/src/egui_shell/search_state.rs（モード・view stack・reset-on-show の純粋核）、src-tauri/src/egui_shell/view.rs（キー入力分岐・driver）、src-tauri/src/egui_shell/lifecycle.rs（show/hide・blur 判定）。
新規・変更モードと既存の各状態の組み合わせを全列挙し、それぞれ明示的に判定する:
組み合わせ: <新モード> × <既存状態>
同時成立: [排他（同時に true にならない）/ 直交（同時成立しうる）]
直交の場合の優先度: <どちらの挙動が勝つか> — 根拠: <SPEC 該当節 / コード箇所>
判定: [整合 / 未定義 — 要対処: <内容>]
最低限確認する既存状態: folderState、toolSelectionState、interpKind()（plain/command/instant。command=/ プレフィックス、instant=コマンドプレフィックス）、indexing、launching。
「未定義だが現状動いている」はレッドフラグ。偶然の動作として記録し、明示化を提案する。
新規・変更される状態シグナルについて、全リセット経路を確認する:
| リセット経路 | トリガー | 確認内容 |
|---|---|---|
resetForShow() | ホットキー再表示（window-shown） | 新シグナルがクリアされるか |
| Escape 連鎖 | Escape キー | 連鎖のどの位置で復帰するか（内側優先） |
| 実行完了 | Enter / クリックによる起動成功 | クエリクリア・非表示と同時に状態が片付くか |
| モード離脱 | プレフィックス削除・フォルダ離脱等 | デバウンス/RAF のキャンセルを伴うか（ui ルール） |
各経路について「リセットされる / 意図的に保持 — 理由」を明示する。理由なしの保持はレッドフラグ。
新モード中（またはガード変更後）の各入力イベントについて、挙動を明示的に判定する:
イベント: <Enter / Shift+Enter / ArrowRight / ArrowLeft / Escape / 文字入力 / クリック / ダブルクリック>
新モード中の挙動: <実行する / 無効化 / 別モードへ委譲>
実装箇所: <file:line>（計画レビュー時: plan.md に記述があるか）
判定: [明示済み / 未定義 — 既存分岐 <どれ> が偶然マッチしている]
ガードを追加・変更した場合は、そのガードが true になる全コンテキストを列挙し、初回起動・インデックス構築中・エラーリカバリの特殊パスを阻害しないか確認する。
SPEC.md §8.6 の mermaid 状態遷移図を読む[...]）乖離があれば SPEC.md の更新内容を具体的に提案する（仕様変更なら SPEC 先行、AGENTS.md「バグか仕様変更かを判定する」）。
根拠の規律: 全判定に根拠（file:line・SPEC 該当節・grep 結果のいずれか）を付ける。コードを確認せずに下した判定は [整合] とせず [未定義] として報告する。
直交性マトリクス・リセット経路・入力分岐の判定を根拠付きで列挙する。 問題が見つかった場合は修正案（ガード追加 / リセット追加 / SPEC 更新）を提示する。 全項目が整合する場合は「状態モデルとの不整合なし」と明示する。