cli-forge

cli-forge ルーター

cli-forge ワークフロー全体への安定したエントリーポイントとして、この親スキルを使用します。

このスキル自体は、設計、計画、実装の作業を行いません。現在の段階を特定し、リポジトリの状態から最も早く未完了のフェーズを把握し、必要な入力をまとめ、適切な子スキルに作業を振り分けます。

目的

受付レイヤーおよびトラフィックコントローラーとして機能します。

• リクエストを、設計、引き継ぎ、計画、スキャフォールド、拡張、検証、公開の7つの下流ステージに分類します。
• 現在のファイルシステムの状態（ディレクトリ、基本ファイル、検証レポートの有無）を確認します。
• 入力をまとめ、handoff.yml の契約を生成します。
• ユーザーが一部のコンテキストを提示した場合、中断したワークフローを再開します。

基準となる参照資料

• ./contracts/handoff.yml.tpl
• ./planning-brief.md

開始条件

#	確認項目	参照元
1	ユーザーのリクエストがある	ユーザー

必須入力

• ユーザーのリクエスト（明示的または曖昧なもの）
• 対象ディレクトリのパス。重要：ユーザーがプロジェクトのパスを提示していない場合は、アクティブなプロジェクトを特定するために、ワークスペース内の .cli-forge/ ディレクトリを必ず積極的に検索してください。リクエストの対象が、まだ cli-forge を導入していない既存の Rust CLI プロジェクトと思われる場合は、Cargo.toml と src/main.rs の組み合わせなど、プロジェクトのルートと思われる場所を検索するか、ユーザーにパスを明示的に尋ねてください。ルートディレクトリが対象プロジェクトだと決めつけないでください。

ワークフロー

1. ユーザーのリクエストを読み、期待される結果を分類します。
2. ファイルシステムを調べて、段階を特定します。
   • 対象ディレクトリが存在せず、新規リクエストの場合 → 設計
   • design-contract.yml が存在し、cli-plan.yml が存在しない場合 → 計画
   • ソースファイルがすでに存在する既存プロジェクトで、.cli-forge/design-contract.yml が存在しない場合 → 引き継ぎ
   • ソースファイルがすでに存在する既存プロジェクトで、.cli-forge/design-contract.yml と .cli-forge/cli-plan.yml の両方が存在しない場合 → 引き継ぎ
   • cli-plan.yml が存在し、ソースファイルが存在しない場合 → スキャフォールド
   • 既存プロジェクトで、機能リクエスト（stream または repl）があり、ベースラインがスキャフォールドと互換性がある場合 → 拡張
   • 既存プロジェクトで、デーモン機能のリクエストがある場合 → 計画
   • 既存プロジェクトで、監査リクエスト（または編集後の検証）がある場合 → 検証
   • 検証に合格し、リリースリクエスト（npm への公開を含む）がある場合 → 公開
3. 選択した経路に必要な入力を確認します。
   • スキャフォールド：skill_name
   • 引き継ぎ：project_path、post_adoption_objective、takeover_mode
   • 拡張：project_path と feature（stream または repl）
   • 計画：デーモン機能のリクエスト、デーモン契約の変更、またはデーモン範囲の更新
   • 検証：project_path
   • 公開：publish_mode
4. ルーター成果物を書き込む前に、対象プロジェクトの .cli-forge/ ディレクトリが存在することを確認します。この最初の書き込みに関する制約は、パイプラインファイルがまだない初回導入リポジトリにも適用されます。
5. contracts/handoff.yml.tpl のテンプレートを使用して、対象プロジェクトディレクトリに .cli-forge/handoff.yml を生成します。これにより、後続処理で利用する分類と入力が明示的に記録されます。
6. 次に呼び出す子スキルを明記した、わかりやすい引き継ぎメッセージを提示します。有効な次の段階が2つまたは3つある場合は、利用可能であればランタイムのダイアログ形式の選択機能（例：AskUserQuestion）を使い、該当する選択肢を提示します（推奨経路を先頭にします）。ダイアログ形式の選択機能を利用できない場合、または有効な次の段階が1つだけの場合は、現在のファイルシステムの状態で有効な段階のみから、次の段階を1～3個明示した番号付きテキストメニューを提示します。有効な選択肢のうち最小の集合を使い、有効な次の段階が1つだけの場合は、その段階だけを 1. の選択肢として表示します。推奨経路を先頭にし、回避策として Other: explain a routing concern を追加します。実際に表示された番号付き選択肢に対応する数字、または Other: ... のみを受け付けます。通常の文章による返答を番号付き選択肢に自動的に対応付けてはいけません。数字の返答に追加の文章が含まれている場合や、Other: の返答でパイプラインのガードレールに反する段階が求められた場合は、確認を求め、引き継ぎ先を有効な段階の範囲内に保ちます。ユーザーに特定のフレーズやスキル名を正確に入力するよう求めてはいけません。

出力

• .cli-forge/handoff.yml — 明示的なルーティング契約

終了条件

#	チェック
1	リクエストの意図が正しく分類されている
2	後続段階に必要な入力が揃っている
3	handoff.yml が生成されている
4	正しい子段階への引き継ぎが明示されている

ガードレール

• アシスタントへの重大な指示：段階的なパイプラインを必ず守ってください。この段階では、自分でコードを記述、生成、またはスキャフォールドしてはいけません。
• アシスタントへの重大な指示：handoff.ymlを生成して次のステップを説明したら、必ず停止してユーザーに制御を戻してください。次の段階を自律的に呼び出してはいけません。利用可能な次の段階が2つまたは3つある場合は、ランタイムのダイアログ形式の選択機能（例：AskUserQuestion）を使って引き継いでください。ダイアログ形式の選択機能が利用できない場合、または有効な次の段階が1つだけの場合は、Other: explain a routing concernを含む、標準化された番号付きテキストの代替形式を使ってください。ユーザーに次のスキル名を明示的に入力させてはいけません。また、代替形式の入力によって、リポジトリの状態に基づいて算出された有効な段階の集合を迂回できるようにしてはいけません。
• ルーターは簡潔に保ってください。ここでテンプレートを実行したり、コンパイル手順を実行したり、CLI コントラクトを定義したりしてはいけません。
• それ以前の段階が未完了の場合、ワークフローを無理に先へ進めてはいけません。たとえば、ユーザーが「検証」を依頼しても、プロジェクトが使用可能なコントラクトのベースラインを持たない既存リポジトリであれば、Validate の前に Takeover に誘導してください。design-contract.ymlがすでに存在し、cli-plan.ymlがない場合は、実装からコントラクトを再構築するのではなく、Plan を再開してください。承認済みのcli-plan.ymlがあるものの、生成済みのソースツリーがまだない場合は、Scaffold に誘導してください。
• ユーザーがリリースを依頼しており、検証が未実施または古い場合は、まず Validate に誘導してください。
• ユーザーが既存プロジェクトへのデーモンサポート追加を依頼した場合は、デーモン機能のコントラクトを明示的に更新できるよう、まず Plan に誘導してください。専用のデーモン実装サポートが追加されるまでは、デーモン関連の依頼を Extend に送ってはいけません。
• ソースファイルがすでに存在する既存の Rust CLI プロジェクトに、使用可能なコントラクトのベースラインがない場合、Design、Scaffold、Extend、Validate に直接送ってはいけません。リポジトリに.cli-forge/design-contract.ymlがない場合、ユーザーが採用済みコントラクトの更新を明示的に依頼した場合、または下流の段階で必要となるものの、コントラクトが存在しても使用可能なベースラインの受領証がないためにベースラインの確立が必要な場合に限り、Takeover に誘導してください。design-contract.ymlがすでに承認済みの場合は、ユーザーが明示的に Takeover による更新またはベースラインの確立を依頼していない限り、Takeover に戻さず、Design -> Plan の再開経路を維持してください。
• Takeover によって任意のプロジェクトを採用した場合、Extend に誘導してはいけません。Extend が有効なのは、現在のプロジェクト構成が、機能テンプレートが直接パッチを適用するスキャフォールド互換ファイルにすでに一致している場合のみです。
• 新しい作業をcli-forge-distributeに誘導してはいけません。npm の公開は Publish に含まれます。cli-forge-distributeモジュールはデーモン実装コミットでアーカイブされており、現在は存在しません。
• 対象プロジェクトのディレクトリが不明な場合は、必ずユーザーに確認するか、.cli-forge/フォルダーを検索してください。Takeover が有力な場合は、Rust CLI プロジェクトのルートと思われる場所も検索してください。現在の作業ディレクトリが対象だと決めつけてはいけません。

次のステップ

次のいずれかに進みます。

• ../cli-forge-design/SKILL.md
• ../cli-forge-takeover/SKILL.md
• ../cli-forge-plan/SKILL.md
• ../cli-forge-scaffold/SKILL.md
• ../cli-forge-extend/SKILL.md
• ../cli-forge-validate/SKILL.md
• ../cli-forge-publish/SKILL.md