pi-prompting

Pi へのプロンプト作成

pi:pi-companion-forwarder が、難易度の高いコーディングや調査タスクについて Pi に支援を求める場合に、このスキルを使用します。

Pi は、ユーザーが設定したモデルを実行します。デフォルトでは、このプラグインは DeepSeek V4（レビューには Pro、日常的なタスクには Flash）を対象としています。以下のガイダンスは、プロンプトが非推論モデル（Flash）または推論モデル（Pro）のどちらでも実行される可能性を想定しています。どちらのモデルも、抽象的な指示より、具体的な番号付きチェックリストに従いやすいため、そちらを優先してください。

基本ルール：

• Pi の実行 1 回につき、明確なタスクを 1 つにします。無関係な依頼は別々の実行に分けてください。
• 完了の定義を Pi に伝えます。望ましい最終状態を Pi が推測してくれると想定しないでください。
• 根拠のない推測によって品質が低下する可能性がある場合は、明示的な根拠のルールを示します。
• プロンプト内の構造が明確になるよう、安定した XML 形式のタグブロックを使用します。
• 説明は簡潔にします。手順を示す場合は、段落より番号付きチェックリストを優先してください。

デフォルトのプロンプト構成：

• <task>：具体的な作業と、関連するリポジトリまたは障害の状況。ファイルパスを含めます。
• <output_contract>（JSON の場合は <structured_output_contract>）：形式、順序、簡潔さに関する要件を明確に指定します。
• <grounding_rules>：レビュー、調査、または根拠のない主張に流れる可能性があるタスクで必須です。
• <action_safety>：ファイルを書き換えられるタスクで必須です。Pi が変更してよいディレクトリとファイルの種類を指定します。

追加ブロックを使う場合：

• コーディングまたはデバッグ：完了とみなす条件（テストの合格、リンターのエラーがないこと、変更したファイルなど）を列挙した <completeness_contract> を追加します。
• レビューまたは敵対的レビュー：提供されている prompts/adversarial-review.md と prompts/review.md を使用します。別のレビュー用プロンプトを独自に作成しないでください。
• 調査または提案タスク：Pi が参照してよい情報源を列挙した短い <sources> ブロックを追加します。

プロンプト形式の選び方：

• ローカルの Git 変更をレビューする場合は、組み込みの /pi:review または /pi:adversarial-review コマンドを使用します。これらのプロンプトには、すでにレビュー要件が含まれています。
• 診断、計画、調査、実装を行い、プロンプトをより直接的に制御する必要がある場合は、task を使用します。
• 同じ Pi セッションで追加の指示を出す場合は、task --resume-last を使用します。方向性が大きく変わっていない限り、プロンプト全体を繰り返さず、追加分の指示のみを送ります。

作業ルール：

• 曖昧な促しより、明示的なプロンプト要件を優先します。
• デフォルトでは推論レベル（--effort high）を上げないでください。DeepSeek Flash には効果がなく、DeepSeek Pro では時間がかかります。推論レベルを上げる前に、プロンプトを具体化してください。
• ツールを多用するタスクや長時間かかるタスクでは、作業メモ内で、結果に基づく簡潔な進捗報告を Pi に求めます。
• 主張は、観察された証拠に基づかせます。仮説の場合は、その旨を明記します。

プロンプト作成チェックリスト：

1. <task> で、タスクと範囲を正確に定義します。
2. 出力要件（JSON、箇条書き、通常の文章など）と最大の長さを指定します。
3. Pi の判断で作業を続行させるか、リスクの高い詳細が不足している場合に停止させるかを決めます。
4. 必要な場合に限り、<grounding_rules> と <action_safety> を追加します。
5. プロンプトを送る前に、重複した指示を削除します。

サブエージェントを考慮したプロンプト作成

pi-subagents がインストールされている場合：

• 並行して進める作業がある場合は、<task> の前に <available_pi_subagents> ブロックを追加します。
• エージェントの推奨割り当て：探索には scout、ウェブやドキュメントの調査には researcher、設計には planner、実装には worker、コードレビューには reviewer を使用します。
• 敵対的レビューまたは stop-review-gate プロンプトでは、サブエージェントを提案しないでください（それらには決定的な動作が必要です）。
• このブロックは提案であり、命令ではありません。委任するかどうかは Pi が決定します。
• 専用の複数タスク並列実行には、手動でプロンプトを作成する代わりに /pi:parallel-rescue "task1" "task2" ... を使用します。