subtask4llm-pi

Pi 用 Subtask4LLM

現在の Pi セッションをプランナーおよびレビュアーとして使用します。scripts/run_workflow.py のスタンドアロンランナーは、対象のワークスペースで Pi ワーカーを順次起動します。

ワークフロー

1. 要求された実装に具体的な手順が複数あり、順序立てた引き継ぎによって個別の作業コンテキストが有用になる場合は、このワークフローを選択してください。ランナーを使うためだけに、小さな変更を分割しないでください。

2. リポジトリを調査し、順序付きの手順を1～10件含む、完全なバージョン1のJSON計画を準備してください。各手順には、一意のID、範囲を限定したタスク、空でない受け入れ条件、先行する手順のみを対象とする依存関係を設定してください。プランナーとの会話を参照しなくても作業者が済むよう、リポジトリの共通調査結果、ユーザー要件、制約、関連パス、設計上の決定、エッジケースを計画に含めてください。

3. references/plan-format.md を読み、計画を一時的なJSONファイルに書き込み、実行前に --dry-run で検証してください。

4. 作業者を開始する前に、目標と順序付きの手順タイトルをユーザーに提示し、それぞれに短い説明と依存関係を記載してください。その後、ユーザーが先に計画の確認または変更を求めている場合を除き、ワークフローを開始してください。

5. 対象のリポジトリからランナーを実行してください。

   macOS または Linux の場合：

   python3 <skill-path>/scripts/run_workflow.py <plan.json> --workspace <repository>
   

   Windows PowerShell の場合：

   py -3 <skill-path>\scripts\run_workflow.py <plan.json> --workspace <repository>
   

   --model <model-id> は、モデルIDが判明していて、設定済みのモデルを上書きする必要がある場合にのみ追加してください。それ以外の場合、ランナーは PI_WORKFLOW_MODEL が設定されていればその値を使用し、そうでなければPiの設定済みのデフォルトを使用します。--timeout-seconds、--timeout-checkpoint-seconds、--retries 0|1、--max-summary-chars、--pi-bin、--artifacts-dir は、タスクでそれらの制御が必要な場合にのみ使用してください。先行する手順が失敗した後も後続の手順を実行するようユーザーが求めている場合にのみ、--continue-on-error を追加してください。いずれかの手順が失敗した場合、最終的なワークフローのステータスには失敗が報告されます。成果物の作成は任意であり、ランナーは既存の成果物保存先への上書きを拒否します。

6. 作業者は、--mode json --no-session --no-skills を指定した、1回限りのJSONイベント形式のPiプロセスとして実行されます。プロンプトは標準入力で送信され、ランナーは最終的なアシスタントのテキストを抽出します。このテキストは、文書化された結果スキーマに一致する生のJSONでなければなりません。ランナーは、すべてのサブタスクとオーケストレーターから読みやすい要約をストリーミングし、ワークフロー全体のライブログにまとめます。試行ごとの進捗ログファイルは作成しません。実行開始時にログのパスと、そのままコピーして使える tail -f コマンドを表示します。別のパスを指定する場合は --live-log <path> を使用してください。デフォルトのライブログは、システムの一時ディレクトリ内のワークスペース外に作成されます。ログにはツールのコマンドと、その短い出力またはアシスタント応答の要約が含まれるため、機密情報が含まれる可能性があるものとして扱ってください。ランナーは10分ごとに進捗を確認し、10分間更新がないシェルコマンドを停止します。それ以外の場合は、30分のハードリミットまで続行します。タイムアウト時の診断には直近のアクティビティが含まれ、再試行は行われません。作業者は通常どおり AGENTS.md のコンテキスト検出を行います。ランナーはコンテキストファイルを無効にしません。各作業者には共通コンテキスト、ワークフロー全体のマップ、割り当てられたタスクと受け入れ条件、および宣言された依存関係の詳細な結果のみが渡されます。 ライブログは、ユーザーが進行状況を確認するためのものです。ランナーの開始後、ログのパスと tail -f コマンドをユーザーに提示し、ランナープロセスが終了するまで待ってください。プロセスを繰り返しポーリングしたり、別途 sleep や tail による確認を実行したり、ライブログを読み直したり、時間を指定した進捗報告を送ったりしないでください。ユーザーから求められた場合、またはトラブルシューティングに必要な場合にのみ、進捗を再確認してください。待機中もランナー独自のプロセス監視とログへの書き込みは続行されます。

7. タイムアウト以外の失敗では、設定された再試行回数を上限として再試行できます。タイムアウトや、停止したと検出されたコマンドは再試行されません。デフォルトでは、ある手順が失敗したままになるとランナーは停止します。--continue-on-error を指定した場合、ランナー自身が計画の残りの手順を実行します。ランナー終了後に、独自判断で追加の作業者を実行しないでください。

8. ランナーの最終レポートと実際のワークスペース差分を確認してください。要求された変更を適切な範囲で検証し、変更したファイル、実施したチェック、未解決のリスクを報告してください。

前提条件と権限

このワークフローを実行する前に、Pi CLI と Pi 用に設定されたプロバイダーがインストールされ、使用できる状態になっている必要があります。このスキルが Pi、プロバイダー、その他のツールを自動的にインストールすることはありません。

Pi のワーカーコマンドは、現在のユーザーの権限でファイルを変更できます。Pi CLI はサンドボックスではありません。依頼されたリポジトリ作業にその権限が適切な場合にのみランナーを使用し、無関係な変更を保持し、ワーカーに無関係な外部操作を許可しないでください。

リファレンス

• バージョン 1 の計画と結果の形式、CLI の制御、例
• 単独で実行できる順次処理の Pi ランナー