ask-skills

Ask Skills

担当範囲：ルーティングのみ。解析、ステージポリシー、スケジューリング、実装、最終処理、承認は担当しません。

ルーティングやスキルの構成を行う前に、セキュリティと委任範囲についての運用上の既定値を読みます。

ルーティングマップ

まず提供レーンを選び、明示します。デフォルトはスキルのみで、スキルのみの契約に沿って to-spec -> to-tickets -> execute-ticket をインラインで実行します。ランナー、スケジューラー、代替ドライバーは決して起動しません。直接レーン：小規模な変更（テストを含めておよそ3ファイル、100行。契約、スキーマ、マイグレーション、依存関係、ポリシー、金銭、認証、データ削除に関わらないもの）、または明示的なクイック変更の依頼：編集、テスト、リント、再読込を行い、コミット前に規模を測定し、変更が大きくなった場合はエスカレーションします。オートパイロットは明示的な依頼がある場合のみ使用します。AFK、継続、コンパクションによってオートパイロットを選択することはなく、以下のオートパイロットのルートが一時停止を覆すこともありません。オートパイロットが利用できなくても、他のレーンは妨げられません。

• 既知の1つのリポジトリで、曖昧さのない肯定的な「すべてマージ」「全部マージ」「mergia tutto」：ticket-autopilot。これは運用上のリポジトリ全体に対する権限付与トランザクションであり、成果物の納品依頼ではありません。repository-autonomous-merge-statusを確認します。権限がない場合は、人間の実行者と永続化された肯定メッセージを使ってgrant-repository-autonomous-merge --scope current-and-future-runsを実行します。正確な有効な権限付与とその来歴を保持し、取り消し済み、レガシー形式、不正な形式、または矛盾した状態の場合は安全側に倒して処理を中止します。その後、merge-allを実行します。呼び出し元にPRのhead SHAを指定させたり、意図を1つのPRに絞ったりしてはいけません。ランナーが稼働中のすべての正確なheadを検出し、再検証します。リポジトリの識別が曖昧な場合は、その識別情報だけを尋ねます。
• 既知の1つのリポジトリで、曖昧さのない肯定的な「すべてを許可」「authorize everything」「autorizo todo」：ticket-autopilot。これは運用上のリポジトリ全体に対する権限付与トランザクションです。repository-authority-statusを読み、権限がないものだけを付与します。その際、grant-repository-autonomous-operations --scope current-and-future-runsを追加します。マージと調整には、それぞれ独自の権限付与と取り消しがあります。マージと調整に記載された対象リストと制限を適用し、対象となる内容と取り消し方法を報告します。
• マージ全体や包括的な権限付与に関する引用文、例、質問、否定、取り消し、ポリシーの依頼、回帰レポートは、権限付与ではありません。実際の議論や変更の意図に応じて通常のルートに振り分け、プロバイダーの変更は一切行いません。
• 1つの正確なチケットについて、保留、キャンセル、再開、または管理上の処理状態をopen、on-hold、canceledに設定する明示的な依頼：change-status-ticket。このルートが実装より優先されるのは、その処理状態を明示的に指定する意図がある場合に限ります。また、「open」は再開または処理状態の設定を意味し、ファイル、Issue、PRを開くことではありません。
• 機能、意思決定、診断、アーキテクチャ、バグ分析に関する曖昧な依頼：to-spec。実行可能なスライスが必要な場合に限り、to-ticketsも追加します。
• 実行可能なスライスが必要な既存の仕様：to-tickets。
• 1つの正規チケットMarkdownファイル：正規チケット契約に従って正規化します。skills-onlyの場合は、skills-only契約に記載された純粋関数を使用します。それ以外の場合は、絶対パスで指定したticket-autopilotスキルのルートからticket-parseを使用します。正規化されたTicket Envelope、ソース成果物の参照、現在のCandidateRefをexecute-ticketに渡します。この単一チケットのルートをフォルダースケジューラーに通したり、オーケストレーションを再構築したりしてはいけません。
• すでに正規化されたTicket Envelopeと現在のCandidateRefの組み合わせ：直接execute-ticketを実行します。
• レガシー形式のチケットMarkdown：明示的なmigrateコマンドのみで変換できます。その後、上記の正規ルートを使用します。
• Autopilotによるオーケストレーションの明示的な依頼があるチケットフォルダー：ticket-autopilot。skills-onlyの場合は、永続化された依存関係の証拠を使って、依存関係が解決済みのチケットを一度に1件ずつ直列で処理します。スケジューラーの状態を再構築したり、依存関係が完了したと推測したりしてはいけません。
• 1つのリポジトリですでに複数のエージェント（Crewまたは複数のPiセッション）が、PM、開発者、レビュー担当者など、どの役割でも設定されている場合：crew-delivery。この処理が委任を作成することはありません。
• 巨大で不明瞭な複数セッションにまたがる作業、または次に取り組むべき領域が不明確な場合：wayfinder。調査チケットには、状況に応じてresearch、prototype、grillingを使用します。
• 独立した相互検証が必要な難しいバグ：triangulate-diagnosis。証拠に基づく単一の診断にはdiagnoseを使用します。
• ランナー候補、または単独のPR、コミット、ローカル差分、ユーザー指定の範囲：レビューにはcode-review、QA計画にはqa-test-planを使用します。
• ランタイム／リリースの主張に関する監査：verification-audit。
• 検証済みバンドルに基づくPRの説明：explain-pr。
• GREEN候補の対象を絞ったクリーンアップ：code-simplification。 チケットのパスだけが示されている場合や、実装・完了の依頼は、処理ではなく納品を意味します。 ブロック、停止・再開、中断、待機、ゲート、準備状況、ライフサイクルに関する質問は、 管理上の処理ではありません。実行時の制御には Autopilot を、読み取り専用の質問には 調査・診断を使用してください。一般的なドキュメントのみの変更や小規模変更を迂回させる目的で、 change-status-ticketを使用してはいけません。

実行時のデフォルト

重要な作業のルーティング後は、次のようにします。

• update_plan（Pi Plan）が利用可能な場合は、ルート選択後に初期化し、in_progressの ステップを常にちょうど1つにして、引き継ぎ時に完了するかクリアしてください。 計画レビューのチェックポイントに記載されたイベントで、内容を調整してください。
• 互換性のあるプロジェクトに紐づいたllm-wikiを調査に利用できる場合は、まずインデックスとして 照会してください。そのRAG可用性契約を適用し、選択したクエリモードまたはフォールバックを明示して、 重要な主張を正規ページおよび一次ソースで検証してください。推測に基づいてWikiを構築してはいけません。
• pi-code-toolのcodeが利用可能な場合は、ループ、フィルタリング、集計、反復的な調査、 派生変換、プログラムによるチェックに優先して使用してください。作成する編集には、直接edit／writeを使用してください。

軽微な作業では、Pi Planとコードモードを省略できます。ツールが利用できない場合は、 根拠を捏造せず、明示的にフォールバックしてください。ツールの利用可能性や自動承認は、 リポジトリやプロバイダーに対する権限を与えるものではありません。

回答

適したスキル／組み合わせ、その適合理由、不足している入力を示してください。入力が十分な場合は、 再確認を求めずに実行してください。