ask

あなたはルーターです。状況を読み取り、入口となるスキルを示し、その後の流れを説明してください。このスキル内で選択したフローの実行を始めてはいけません。入口がモデル呼び出し可能（brainstorm、amend、debug、acceptance-check、dogfood）なら、それを呼び出して処理を引き継がせてください。ユーザーが呼び出すスキル（triage、file-issues、improve-architecture、setup-repo、scaffold-project、establish-project、check-roadmap、assess-milestone、handoff、release）の場合は、呼び出すことはできません。スキル名を示し、たとえば /triage のように、そのコマンドを実行するようユーザーに伝えてください。

メインフロー：アイデアからリリースまで

1. brainstorm — 新しい動作を追加する場合は、常にここが入口です。ユーザーに質問し、コードベースを調査し、根拠が必要な問いについては research／prototype に寄り道し、最後にセレモニーの段階を宣言します。
   • Tier 0（誤字レベルで、動作の変更なし）：仕様は省略し、tdd + verify を実施します。
   • Tier 1（バグ修正／半日以内の変更）：簡易仕様を作成します。修正要件と、担当する requirements.md 内の SHALL-CONTINUE-TO ガード、回帰テストのタグ付けが含まれます。
   • Tier 2（機能）：以下の完全な仕様サイクルに進みます。
2. write-requirements → write-design → write-plan — docs/specs/<date>-<feature>/ に作成する仕様の三点セットです。各段階の間に承認ゲートがあります。
3. worktrees → execute-plan — 隔離されたワークスペースを用意し、タスクごとに実行します（タスクごとにサブエージェントを割り当て、進捗を台帳に記録します）。
4. code-review → acceptance-check → finish-branch → （リリースする場合は）release → sync-spec。

コンテキストの管理： ステップ1～2（発見から計画まで）は、同じコンテキストウィンドウで途切れずに進めてください。計画が終わる前にウィンドウがいっぱいになりそうな場合は、新しいセッションに移るため /handoff を実行するようユーザーに伝えてください。実行セッションは、設計上、タスクごとにコンテキストが分離されています。

入口

• すでにリリース済みで仕様もある機能への、小規模でスコープ内の変更（微調整、色の変更、追加対応） → amend（既存の仕様を読み、簡易なレーンに誘導します。本当に新しいスコープの場合に限り、brainstorm に切り替えます）。
• 実行中に、すでに承認済みの計画が無効になる発見があった（計画が誤っていた、作業中にスコープが変わった、設計が成立しなくなった） → correct-course（無効になったアーティファクトのうち最も低い階層を判定し、再開地点へ誘導します。execute-plan からも処理が引き継がれます）。
• 単体テストは成功しているが、エンドツーエンドで本当に動作するか確信が持てない → acceptance-check（仕様の動作を実際のユーザーとして、稼働中のシステムで確認します）。
• 完成した機能を実際のアプリで手動で試したい → dogfood（アプリに即した、確認可能なガイドを作成します。テストしながら項目をチェックできます）。
• 何かが壊れている → debug（Tier 1 の簡易仕様フローに移行します）。
• トラッカーの課題として記録したい会話／仕様／アイデアがある（完全な仕様の三点セットを省略する迅速なレーン） → file-issues（ブロッキング関係を含むトレーサーバレットのスライスを作成し、エージェントがすぐ使える形で公開します）。
• 自分が作成していない課題／PRが届いた → triage。
• コードベースが分かりにくくなっている → improve-architecture（定期的に実施します。出力は brainstorm から再開します）。
• 新しいリポジトリで設定がない → setup-repo。リポジトリ自体がない → scaffold-project。
• 大規模または長期運用のプロジェクトを始めるにあたり、機能開発のサイクルより上位に、プロダクトビジョンとアーキテクチャ不変条件の骨格を置きたい → establish-project（任意です。存在する場合に機能関連スキルが参照するレイヤーで、デフォルトでは無効です）。
• 複数のマイルストーンが進行中で、計画の現状や次にすべきことが分からない → check-roadmap（読み取り専用です。ロードマップ、仕様、git から進捗を判断し、次のアクションを1つ提示します）。マイルストーン自体を計画または変更する場合 → write-roadmap。
• マイルストーンが完了したように見え、クローズしたい → assess-milestone（成果が達成されたかを判断して記録し、ユーザーの判断を確認したうえでクローズを許可します）。
• 作業途中でセッションが終了する → handoff。
• バージョンをリリースする → release。

判断の目安

• まだ理解していないことを仕様化しないでください。仕様は実行のためのものであり、 発見のためのものではありません。不明点を掘り下げる工程は、上記の brainstorm に含まれます。
• 2つのスキルがどちらも適用できそうな場合は、プロセススキルを優先してください。 プロセススキルが実装スキルを呼び出します。