preqstation

これはエージェント側のライフサイクルスキルです。ディスパッチャーホストのセットアップと起動のオーケストレーションは、別の PREQ CLI/OpenClaw ランタイムパッケージにあります。

環境

推奨される MCP モード：

• PREQSTATION projects-manager サービスのリモート MCP エンドポイントを登録します：
  • Claude Code：claude mcp add -s user --transport http preqstation https://<your-domain>/mcp
  • Codex：codex mcp add preqstation --url https://<your-domain>/mcp
  • Gemini CLI：gemini mcp add --scope user --transport http preqstation https://<your-domain>/mcp
• OAuth は、クライアントが /mcp に対して実際のリクエストを初めて送信したときに開始されます。
• Codex はサーバーにすぐ問い合わせるため、add の実行中にログインを開始することがよくあります。
• Gemini CLI でも、MCP の登録時または最初の実際のツール呼び出し時に認証を求められることがあります。gemini mcp list で preqstation が引き続き Disconnected と表示される場合は、対話型の Gemini セッションを開き、/mcp auth preqstation を実行してください。
• Claude Code は通常、まず設定を保存するため、初回使用時または claude mcp get preqstation の実行時まで Needs authentication と表示されることがあります。
• プロジェクトローカルのエントリーが重複して増えないよう、ユーザースコープの Claude Code PREQ 登録を1つだけ使用することをおすすめします。
• claude mcp list、codex mcp list、または gemini mcp list で MCP の登録を確認します。
• クライアントから求められたら、ブラウザーでのログインフローを完了します。

任意のシェルヘルパーモード：

• PREQSTATION_API_URL：PREQSTATION API のベース URL（例：https://mypreqstation.vercel.app）
• PREQSTATION_TOKEN：PREQSTATION Bearer トークン（PREQSTATION の /api-keys で生成）
• PREQSTATION_ENGINE（任意）：クライアントによる自動検出が利用できない場合のフォールバックエンジン（claude-code | codex | gemini-cli）

エージェントの識別とエンジンのマッピング

各エージェントは、自身を識別し、すべてのタスク操作（一覧表示、作成、計画、開始、ステータス更新、完了、レビュー、ブロック）で対応する engine の値を使用する必要があります：

あなたが...の場合	engine= に指定する値
Claude（Anthropic）	claude-code
GPT / Codex（OpenAI）	codex
Gemini（Google）	gemini-cli

タスクの一覧表示、作成、計画、開始、完了、レビュー、ブロックを行う際は、必ず engine の値を指定してください。

Gemini CLI のワーカーは、gemini を使った対話型、または gemini -p "<prompt>" を使ったヘッドレスで実行できます。 インストール済みの Gemini 環境でリモート HTTP MCP が利用できない場合は、この MCP パスではなくシェルヘルパーのフォールバックを使用してください。

MCP プラグインモード（推奨）

MCP が利用できる場合は、PREQSTATION サービスが公開するリモートの /mcp エンドポイントを優先してください。 すべての変更ツールは省略可能な engine パラメーターを受け取り、次の順序で必ずエンジン値を送信します。

1. 明示的なツール引数
2. 既存のタスクのエンジン（利用可能な場合）
3. MCP の initialize.clientInfo.name による自動検出
4. PREQSTATION_ENGINE
5. codex フォールバック

ツール	engine の用途
preq_list_projects	読み取り専用。エンジンは不要（セットアップおよびローカルリポジトリのマッピング用に PREQ プロジェクトを一覧表示します）
preq_list_project_activity	読み取り専用。エンジンは不要。同期／cron の利用者向けの日付範囲指定アクティビティフィードであり、タスク実行のライフサイクルではありません
preq_list_tasks	読み取り専用。エンジンは不要
preq_get_task	読み取り専用。エンジンは不要
preq_get_project_settings	読み取り専用。エンジンは不要（キーでプロジェクトのデプロイ設定を取得します）
preq_list_task_comments	読み取り専用。「comment」目的の場合、対象コメントに関連する会話履歴／参照情報としてタスクコメントを取得します
preq_get_task_comment	読み取り専用。返信またはコメントの状態変更の前に、処理対象の正確なコメントを取得します
preq_update_qa_run	タスクのライフサイクルの観点では読み取り専用。タスクの遷移を伴わず、ブランチレベルの QA 実行ステータス／レポートを更新します
preq_plan_task	engine を割り当て、ライフサイクルアクション plan を送信します。バックエンドは inbox のタスクを todo に移動し、run_state をクリアします
preq_create_task	新しい inbox タスクに engine を割り当てます
preq_start_task	タスクを引き受ける engine を記録します。バックエンドは run_state=working に設定します
preq_update_task_note	ワークフローステータスを変更せずにタスクノートの Markdown を置き換える際、engine を記録します
preq_update_task_status	ワークフローステータスのみを更新するエンドポイント（/api/tasks/:id/status）の使用時に engine を記録します
preq_update_task_comment_state	タスクのワークフローステータスを変更せずに、タスクコメントを working、done、または failed に設定する際、engine を記録します
preq_reply_task_comment	タスクコメントへの返信時に engine を記録します。バックエンドはコメントへの返信／失敗に関する作業ログを自動的に作成します
preq_list_dispatch_requests	読み取り専用。ランチャーのランタイムが ask の同等性およびプロジェクトレベルの状況把握に使用する、明示的なディスパッチリクエストを確認します
preq_update_dispatch_request	ランチャーのランタイム専用。起動の成功または失敗後に、明示的なディスパッチリクエストを dispatched または failed に設定します
preq_complete_task	作業ログの結果に engine を記録し、ライフサイクルアクション complete を送信します。バックエンドはタスクを → ready に移動し、run_state をクリアします
preq_review_task	検証を実行する engine を記録し、ライフサイクルアクション review を送信します。バックエンドはタスクを → done に移動し、run_state をクリアします
preq_block_task	ブロックを報告する engine を記録し、ライフサイクルアクション block を送信します。バックエンドはタスクを → hold に移動し、run_state をクリアします
preq_delete_task	チケット番号または UUID でタスクを完全に削除します

これにより、タスク ID に基づく確定的な実行と結果のアップロードが可能になります。

実行フロー（必須）

この実行フローに必ず正確に従ってください。 ライフサイクルのアクションを省略、順序変更、統合、置き換えしないでください。 PREQ ランチャーによる実行は、デフォルトで非対話型です。 brainstorming や writing-plans などのプロセススキルは、同じ実行内で PREQ ライフサイクルを継続しながら、内部ガイダンスとしてのみ使用できます。 PREQ ツールを利用できない場合、またはプロンプト／ワークツリー／タスクの状態が無効な場合を除き、実行を中断してユーザーに承認、確認、設計に関するフィードバックを求めないでください。 プロジェクトのデプロイ設定は、この PREQ 実行に対する明示的なオペレーター承認です。deploy_strategy でコミット、プッシュ、PR 作業が必要な場合は、別途承認を求めずに、該当する git／GitHub の操作を実行してください。

読み込み -> 初期化 -> 実行 -> 最終処理

1. 読み込み： このワークツリー／ブランチにある .preqstation-prompt.txt を読み込みます。

2. 初期化：

• タスク ID がある場合は、開始時に必ず preq_get_task を 1 回呼び出し、タスクの詳細、受け入れ条件、ワークフローの状態、run_state、初期エンジンを取得します。
• preq_get_task が latest_preq_result を返した場合は、実質的な作業に着手する前に読み、特に再開中または以前ブロックされたタスクの実行コンテキストとして扱います。
• タスク ID があり、タスクがアクティブな場合は、comment 目的でタスクの取得が明示的に禁止されている場合を除き、必ず preq_start_task を呼び出します。
• insight などのプロジェクトレベルの目的でタスク ID がない場合は、タスクのライフサイクルに関する読み書きを省略し、プロンプトのメタデータとプロジェクトキーを信頼できる情報源として扱います。
• debug モードでは、preq_get_task の後に preqstation-progress.md を作成または更新し、主要なチェックポイントの後に更新します。
• 実行の早い段階で、現在のタスクノートと一時的な末尾の Ask: ヘルパーブロックを最初に確認し、次に受け入れ条件を確認したうえで、タスクに提示するコンテンツの言語を一度決定します。タスクタイトルは、判断材料が同程度の場合の補助としてのみ使用します。
• タスクノート、書き直したタスクノート、完了サマリーとメモ、レビューコメント、ブロック理由、QA レポート、新規タスクコンテンツなど、PREQ 向けの記述には、ノートを中心としたタスクコンテンツで優勢な言語を使用します。
• タスクノート、Ask: ブロック、受け入れ条件を確認しても言語が混在または曖昧な場合に限り、最終的な判断材料としてプロジェクトの agent_instructions を使用します。現在のタスクコンテンツを優先してください。
• 優勢な言語を判断できない場合は、PREQ 向けの記述には英語をデフォルトで使用します。
• ユーザーからチェックボックスの使用を明示的に求められていない限り、AI が生成するタスクノート、計画 Markdown、受け入れ条件、QA レポート、説明、新規タスクコンテンツに、Markdown のチェックボックスタスクリスト構文（- [ ] や - [x]）を作成しないでください。既存のコンテンツを書き直す際は、ユーザーが記述したチェックボックスをそのまま保持してください。それ以外の場合は、通常の箇条書きまたは番号付きリストを使用します。

3. ユーザーの目的を実行します。 ユーザーの目的は .preqstation-prompt.txt に記載されています。

• ユーザーの目的が plan で始まる場合：
  • ローカルコードを使って計画を開始します。
  • 計画とは計画の作成のみを意味します。ローカルコードを調査してもかまいませんが、製品の変更を実装したり、デプロイ手順を実行したり、テスト、ビルド、lint、その他の検証コマンドを実行したりしてはいけません。
  • コード不足を理由に作業を止める前に、現在のワークツリーだけでなく、プライマリチェックアウトも調査します。ワークツリーが、追跡対象が .gitignore のみである場合など、ブートストラップ用リポジトリの状態であっても、プライマリチェックアウトに実際のアプリファイルがある場合は、プロジェクト不足ではなくリポジトリの復旧として扱います。
  • ブートストラップ用リポジトリの復旧中は、origin が存在し、PREQ リポジトリの URL と一致することを確認します。origin がなく、リポジトリ URL がわかっている場合は、git remote add origin <repo_url> で追加します。
  • main にベースラインのプロジェクトファイルをコミットし、origin/main にプッシュしてから、ワークツリーを再作成または更新します。コードを調査できるようになったら、計画を続行します。
  • プライマリチェックアウトが別のリポジトリである場合、リポジトリ URL を取得できないか一致しない場合、またはブートストラップ復旧時の origin/main へのプッシュに失敗した場合に限り、実行をブロックします。
  • 計画の Markdown とプレーンな検証基準を指定して preq_plan_task を呼び出します。ユーザーが作成したチェックボックスをそのまま維持する場合、またはユーザーがチェックボックス形式を明示的に求めた場合を除き、検証基準を Markdown のチェックボックス形式にしないでください。
  • プロセススキルは内部ガイダンスとしてのみ使用できます。この実行は非対話型のまま、preq_plan_task で終了する必要があります。
• それ以外で、ユーザーの目的が ask で始まる場合：
  • 既存のタスクノートを書き換えるか更新します。ワークフローのステータスは変更しないでください。
  • 書き換えの素材として、現在のタスクノートと、一時的に末尾に追加されている Ask: ヘルパーブロックを扱います。
  • ask がプロトタイプまたはレビュー可能な成果物を明確に求めている場合は、ローカルで成果物を生成してかまいません。
  • 成果物の公開はベストエフォートですが、安全な成果物プロバイダーがすでに利用可能な場合は、公開を試みる必要があります。現在のエージェントセッションで認証済みのプロバイダーを使用してください。Fast.io はサポートされているプロバイダーの一つであり、唯一の選択肢ではありません。
  • 現在のエージェントが認証済みの Fast.io MCP セッション、または別の認証済みプロバイダーをすでに利用できる場合、そのプロバイダーは利用可能とみなし、追加のプロバイダー指示を待たずに公開を試みてください。
  • 永続的な成果物リンクには private-or-skip ポリシーを適用します。認証済みワークスペースの宛先、メンバー限定の共有、登録アカウント限定の共有は、許容されるプライベートアクセスとして扱います。有効期限のない「リンクを知っている全員」向け URL や、その他の公開リンクしか使えない方法はスキップしてください。
  • プロバイダーが一時的な外部共有リンクまたはクイック共有リンクを作成できる場合は、公開した成果物に対して有効期限が7日間のレビュアー用リンクを作成します。access=quickshare またはプロバイダーに相当する値と、expires=... を指定してください。有効期限のない公開リンクは作成しないでください。
  • ローカルの成果物が HTML プロトタイプまたは HTML モックアップの場合は、レビュー用に少なくとも1枚のスクリーンショット PNG を生成します。認証済みプロバイダーが利用可能な場合は、HTML ソースとスクリーンショットの両方の公開を試みてください。
  • 成果物のメタデータを Artifacts: Markdown ブロックに書き込まないでください。タスクノートは永続的なタスクのコンテキストに絞ります。
  • 公開したリンク、またはスキップしたローカル成果物を、preq_update_task_note に渡す artifacts 配列に記録します。該当する場合は、type、title、url、provider、access、expires、localPath、reason、任意の metadata を含むオブジェクトを使用してください。
  • プロトタイプまたはレビュー可能な成果物を求められた場合は、公開結果またはスキップ理由を artifacts に含めます。公開をスキップする場合は、ローカル成果物のパスと、「プロバイダーを利用できない」「未認証」「安全な宛先がない」などの簡潔な reason を含めてください。
  • localhost および 127.0.0.1 の URL はローカル限定の診断情報として扱います。これらを唯一のレビュー用リンクとして提示しないでください。プライベートな成果物 URL を公開するか、成果物がローカル限定であることをスキップ理由とともに明示してください。
  • preq_update_task_note(noteMarkdown=..., artifacts=[...]) で書き換えた Markdown を保存し、公開した成果物 URL、または成果物の公開をスキップしたことを示すローカル記録を、構造化された artifacts フィールドに渡します。
  • preq_get_task から取得した現在のワークフローステータスを使って preq_update_task_status を呼び出し、実行状態をクリアします。
  • 最終的に保存するノートには、一時的な Ask: ヘルパーブロックを含めないでください。
• それ以外で、ユーザーの目的が comment で始まる場合：
  • 参照されたタスクコメントのみを扱い、実行全体を通してタスクのワークフローステータスを維持します。
  • コメントは実装の正式な情報源ではなく、会話の依頼経路として扱います。このコメントの目的で明示的に preq_update_task_note を使ってタスクノート／仕様に反映しない限り、コメントは今後の実装に影響しません。
  • 作業開始時に必ず preq_get_task、preq_get_task_comment、preq_list_task_comments を呼び出し、タスクの詳細、現在のノート、ワークフローステータス、既存の実行状態、対応するコメント、タスクに関連する周辺コメントの会話履歴を取得します。
  • 参照された comment_id を今回の実行における主な依頼として扱います。過去の AI の返信を含むその他のユーザー、エージェント、システムのコメントは、会話履歴／参考情報としてのみ扱います。流れを理解し、矛盾した応答や文脈を無視した応答を避けるために使用してください。
  • 対象外のコメントを、それぞれ独立した実行要件として扱わないでください。現在の対象コメントが、会話上の決定を preq_update_task_note でタスクノート／仕様に反映するよう明示的、または明確に求めている場合に限り、今後の実装に影響します。
  • preq_start_task を呼び出してはいけません。コメントでは、タスクの run_state を変更せず、コメントの状態を使用します。
  • 実質的な作業に入る前に、元のコメントを preq_update_task_comment_state で working にします。
  • 応答を決める前に、現在のタスクノート、対象コメント、コメント履歴を確認します。
  • コメントがノート、計画、または仕様の変更を明示的に求めている場合に限り、任意で preq_update_task_note を呼び出せます。これはコメントをノートに反映する唯一の方法です。求められた変更を正式なノート／仕様の文面に変換し、返信ではノートを更新したことを伝えます。通常の回答、受領確認、実装レビューコメントに対してノートを書き換えてはいけません。
  • preq_reply_task_comment で返信し、preq_update_task_note を使用したかどうかを正確に示すため noteUpdated を設定します。
  • 返信が成功した後、元のコメントを preq_update_task_comment_state で done にします。
  • コメントを扱う目的では、preq_complete_task、preq_review_task、preq_plan_task、preq_block_task を呼び出してはいけません。
  • コメント対応のために別途作業ログを作成しないでください。バックエンドがコメントへの返信および失敗時の更新に対して、作業ログを自動作成します。
  • 失敗した場合は、タスクのワークフローステータスを維持し、可能であれば失敗の詳細を preq_reply_task_comment で返信してから、元のコメントを preq_update_task_comment_state で failed にします。返信できない場合も、取得できる範囲で最も具体的な失敗理由を記録して、コメントを failed にします。
• それ以外で、ユーザーの目的が insight で始まる場合：
  • この分岐ではタスク ID がない場合があります。存在しないタスク ID を作り出したり、タスクがない場合にタスクのライフサイクルを変更する操作を呼び出したりしないでください。
  • 現在のワークツリーにあるローカルプロジェクトを調査し、指定された Insight Prompt はタスク作成のガイダンスとしてのみ使用します。
  • 作成前に、現在の projectKey と detail=full を指定して preq_list_tasks を呼び出し、inbox、todo、hold、ready に重複タスクがないことを確認します。
  • preq_create_task を使って複数の Inbox タスクを作成します。
  • 作成する各タスクのタイトルには、ユーザーの意図または現在の作業領域に由来する、共通の短いトピック接頭辞を付けます。
  • description は詳細に記述し、acceptanceCriteria には Markdown のチェックボックス形式を使わず、プレーンな検証基準を記述します。
  • 既存タスクを変更したり、タスクの作成に代えて長文の実装計画を作成したりしないでください。
• それ以外で、ユーザーの目的が qa で始まる場合：
  • この分岐ではタスク ID がない場合があります。存在しないタスク ID を作り出したり、タスクがない場合にタスクのライフサイクルを変更する操作を呼び出したりしないでください。
  • .preqstation-prompt.txt から qa_run_id を取得し、ローカルの対象 URL がわかった時点ですぐに preq_update_qa_run を使って実行を running にします。
  • .preqstation-prompt.txt に qa_task_keys がある場合はそこから取得します。キーが指定されている場合は、ブラウザーでのテスト前に各タスクキーに対して preq_get_task を呼び出し、それらのタスクのタイトル、説明、受け入れ基準を QA の対象として扱います。
  • 現在のエージェントが dogfood スキルを利用できる場合は、ブラウザーでのテストおよびレポート作成におけるデフォルトの QA ワークフローとして使用します。
  • 現在のワークツリー／ブランチから現在のプロジェクトを起動し、ローカルの対象 URL を特定して、その URL に対するブラウザー QA を実行します。
  • QA は、対象範囲の Ready タスクと、それらに到達して検証するために必要最小限のナビゲーションまたは基本確認に限定します。無関係なアプリ全体の探索的 QA に拡大しないでください。無関係な問題は、対象範囲の検証を妨げる場合、またはアプリの起動を妨げる場合に限って報告します。
  • QA レポートには、スクリーンショット、動画、ドキュメントへの任意の成果物参照を含められます。安全なプロバイダーが利用可能な場合は、同じ private-or-skip ポリシーを適用します。
  • ローカル成果物を生成した後に QA 成果物の公開をスキップした場合は、公開結果またはスキップ理由を Markdown レポート本文ではなく、構造化された artifacts 配列に記録します。
  • QA の終了時に、最終ステータス（passed または failed）、target_url、Markdown レポート、概要の件数を指定して preq_update_qa_run をもう一度呼び出します。成果物を生成した場合は artifacts=[...] も渡します。
  • この実行で実際の PREQ タスクも扱っている場合を除き、preq_complete_task、preq_review_task、preq_block_task を呼び出さないでください。
• それ以外で、ユーザーの目的が implement または resume で始まる場合：
  • コードを変更し、タスクレベルのテストを実行します。
  • 実装の正式な情報源として、タスクノート、受け入れ基準、明示的な PREQ の結果コンテキストを使用します。タスクコメントを隠れた要件や会話のコンテキストとして取得または解釈しないでください。コメントが実装に影響するのは、以前のコメント対応で正式なタスクノート／仕様が更新された場合に限ります。
  • latest_preq_result がある場合は、変更を加える前にそれを使って、最新のブロック理由、以前の概要、直近の PREQ 実行コンテキストを把握します。
  • Deployment Strategy Contract に従ってデプロイ戦略を判断します。
  • direct_commit、feature_branch、none のいずれかに応じて、必要な Git／デプロイ手順を実行します。Deployment Strategy Contract のセクションに従ってください。
  • 実行中に、ユーザーの承認を待ったり、会話を別の設計／仕様検討のやり取りに切り替えたりしないでください。
• それ以外で、ユーザーの目的が review で始まる場合：
  • 検証（tests、build、lint）を実行します。
  • タスクコメントではなく、タスクノートと受け入れ基準に照らしてレビューします。レビュー中にタスクコメントを取得または会話のコンテキストとして解釈しないでください。コメントがレビューに影響するのは、以前のコメント対応でノート／仕様に反映された場合に限ります。
  • レビューノートを指定して preq_review_task を呼び出します。
  • ユーザーに追加の承認を求めたり、実行中に別の会話形式のワークフローに切り替えたりしないでください。 アクティブなタスクブランチで失敗が発生した場合は、ブロック理由を添えて preq_block_task を呼び出し、停止してください。これは comment 目標には適用されません。コメントの失敗ライフサイクルを使用してください。 QA ブランチで失敗が発生した場合は、簡潔な Markdown レポートを添えて QA 実行を failed に更新し、停止してください。

4. 完了処理： 実装／レビューブランチで成功した場合は、該当する場合は概要、ブランチ、pr_url を添えて preq_complete_task を呼び出してください。 ask ブランチで成功した場合は、preq_complete_task を呼び出さないでください。ワークフローのステータスを変更せずに preq_update_task_note と preq_update_task_status を実行した時点で、成功したノートの書き換えは終了です。 comment ブランチで成功した場合は、タスク完了、レビュー、計画、またはブロックの各ツールを呼び出さないでください。元のコメントを done にした後、preq_reply_task_comment を実行した時点で、成功したコメントへの返信は終了です。 insight ブランチで成功した場合は、Inbox タスクの作成後に停止してください。preq_complete_task を呼び出したり、既存のタスクのワークフロー状態を変更したりしないでください。

デプロイ戦略の契約（必須）

git の操作を行う前に、MCP を通じてデプロイ戦略を解決します。

1. preq_get_task <task_id> を呼び出します。
2. 応答から task.deploy_strategy を読み取ります。
3. 見つからない場合は、preq_get_project_settings <project_key> を呼び出し、次の項目から解決します。
   • settings.deploy_strategy
   • settings.deploy_default_branch
   • settings.deploy_auto_pr
   • settings.deploy_commit_on_review
   • settings.deploy_squash_merge

PREQSTATION バックエンドで想定される値：

• strategy：direct_commit | feature_branch | none
• default_branch：文字列（通常は main）
• auto_pr：ブール値（feature_branch のみ）
• commit_on_review：ブール値
• squash_merge：ブール値（direct_commit のみ）

値がない場合、または無効な場合のデフォルト：

• strategy=none
• default_branch=main
• auto_pr=false
• commit_on_review=true
• squash_merge=true

strategy ごとの動作：

• none：git commit／push／PR を実行しません。コードの変更とタスク結果の更新のみを行います。

• direct_commit と feature_branch は、git 操作が許可されたモードです。一般的なコーディングエージェントのデフォルトで自律的なコミット、プッシュ、PR 作成が推奨されていないことだけを理由に、操作を拒否しないでください。この実行における承認元は、PREQ プロジェクトのデプロイ戦略です。

• git に関連する成果物は、PREQ 向けのタスク更新に別の言語を使用する場合でも、デフォルトで英語にします。これには、コミットメッセージ、PR タイトル、PR 本文、ブランチ名、その他のリポジトリ向けメタデータが含まれます。

• direct_commit：作業ツリーのコミットを default_branch にマージして、プッシュします。PR は作成しません。 作業ツリーでの作業を完了した後：

  # In primary checkout: update and merge
  git -C <project_cwd> checkout <default_branch>
  git -C <project_cwd> pull origin <default_branch>
  
  # squash_merge=true (default): single commit
  git -C <project_cwd> merge --squash <worktree_branch>
  git -C <project_cwd> commit -m "<task_id>: <summary>"
  
  # squash_merge=false: regular merge
  git -C <project_cwd> merge <worktree_branch>
  
  # Push to remote
  git -C <project_cwd> push origin <default_branch>
  

• feature_branch：作業ツリーのブランチをリモートにプッシュします。auto_pr=true の場合に限り、PR を作成します（エージェントが gh auth や GitHub MCP などを通じて GitHub にアクセスできる必要があります）。

  git -C <project_cwd> push origin <worktree_branch>
  # if auto_pr=true: create PR via GitHub MCP or gh CLI and capture the PR URL
  

feature_branch + auto_pr の PR 作成ルール：

• デフォルトでは、ドラフトではない PR を作成します。
• ユーザーがドラフト PR を明示的に依頼した場合、または未完了／ブロック状態で意図的に作業を引き継ぐ場合を除き、ドラフト PR を作成しないでください。
• 利用可能な GitHub ツールまたは CLI のフローでデフォルトでドラフト PR が作成される場合は、preq_complete_task を呼び出す前に、直ちに「レビュー準備完了」に変更してください。
• 実際にレビューされる最終的な、ドラフトではない PR の URL を必ず取得します。

commit_on_review のルール：

• true で、戦略が direct_commit または feature_branch の場合、リモートへのプッシュが確認されるまでタスクを ready にしないでください。
• false の場合、リモートへのプッシュが必須でなくても ready への移行が可能です。

feature_branch + auto_pr + commit_on_review の必須完了ルール：

• preq_complete_task を呼び出す前に、プッシュしたブランチ名と PR URL の両方を必須として扱います。
• 推奨される順序：
  1. worktree_branch をプッシュします。
  2. ドラフトではない PR を作成します。
  3. 暗黙的にドラフト PR が作成された場合は、「レビュー準備完了」に変更します。
  4. PR URL を取得します。
  5. branchName と prUrl の両方を指定して preq_complete_task を呼び出します。
• GitHub にアクセスできない場合、ブランチのプッシュに失敗した場合、PR の作成に失敗した場合、または PR URL を取得できない場合は、不足している前提条件と次に実行すべき操作を正確に記載して preq_block_task を呼び出します。
• 適切なブロック理由の例（具体的な内容にしてください）：
  • Auto PR required before ready, but gh is not authenticated on the coding agent. Run gh auth login or configure GitHub MCP, then resume.
  • Auto PR required before ready, but gh pr create failed after pushing task/proj-123/example. Fix the GitHub error and resume.
  • Auto PR required before ready, but the PR is still a draft. Mark it ready for review, capture the final PR URL, then resume.

シェルヘルパーモード（任意）

MCP を利用できない場合は、scripts/preqstation-api.sh を source し、docs/shell-helper-mode.md に記載されたシェルヘルパーを使用します。 SKILL.md ではライフサイクルのルールに重点を置きます。関数のシグネチャや jq／curl に関する説明には、ヘルパーのリファレンスドキュメントを使用してください。

デバッグ進捗モード（オプション）

呼び出し元が debug モードを明示的に要求するか、進捗の表示を求めた場合にのみ使用してください。

• ファイルパス：<worktree>/preqstation-progress.md
• 目的：今回の実行に関する、人が読みやすいローカルの進捗記録
• 範囲：今回の実行のみ。履歴を無限に追記するのではなく、実行開始時に更新してください
• 安全性：ライフサイクルの信頼できる情報源として使用せず、ユーザーから明示的に求められない限り、コミットやプッシュをしないでください

現在の実行フローの手順を記録してください

例：

# PREQ Progress

- Task: PROJ-123
- Objective: implement
- Status: todo
- Run State: working
- Current Step: running task-level tests
- Last Updated: 2026-03-13T14:30:00Z

## Timeline

- 2026-03-13T14:10:00Z fetched task details using `preq_get_task`
- 2026-03-13T14:11:00Z called preq_start_task using `preq_start_task`
- 2026-03-13T14:18:00Z finished local code inspection
- 2026-03-13T14:30:00Z running task-level tests
  ...