task-to-pr

タスクからPRへ

各タスクを、証拠を添えた1つの焦点を絞ったプルリクエストとして提出します。仕様はチケットとして扱います。Markdownの仕様書、GitHubのIssue、または受け入れ条件が定められたタスクを使用できます。作業定義を別途作成しないでください。

このワークフローでは、必要なスキルを SKILL.md ファイルから直接読み、手順として使用してください。クライアントがブロックするスキルコマンドを使って実行しないでください。

準備

1. ソース、リポジトリの指示、関連する要件とアーキテクチャ、コード、テストを確認します。作業を続ける場合は、既存のブランチ、ワークツリー、プルリクエストを再利用します。
2. 成果、範囲、決定事項、チェックが十分か確認します。重要な選択が未決定の場合は、実装前に /spec に戻るか、必要な決定事項を報告します。範囲が小さく、内容が決定済みの作業については、仕様書を作成しないでください。
3. 大きな仕様では、必要に応じて /plan を使って分割します。各タスクで、動作する成果を1つ提出します。依存関係を特定し、必要に応じて独立した作業を同時に開始します。

提出と修正

1. 隔離されたブランチとワークツリーを作成するか、再利用します。独立した作業は、最新のリモート既定ブランチから開始します。リポジトリのブランチ命名規則とワークツリー規則に従います。
2. タスクを実装し、変更した動作と影響を受ける不具合に対する有意義なテストを追加します。変更が影響する場合は、要件、アーキテクチャ、仕様を更新します。意図したアーキテクチャと実装状況を正確に保ちます。
3. /test を使い、受け入れ条件と影響を受けるルールを検証します。コミット前に失敗を修正します。
4. Conventional Commit を作成し、プッシュして、プルリクエストを作成または更新します。リポジトリのPRテンプレートに従います。問題と成果を冒頭に記載し、検証結果とソースへのリンクを含めます。レビュー可能な状態にし、対応している場合はトラッカーチケットを「Review」に移動します。
5. 実装に関わっていない、新しいサブエージェントを使って /review を実施します。現在のコミットに対する設定済みのCIと自動レビューが完了するまで待ちます。
6. 妥当な指摘と、変更によって生じた失敗を修正します。レビューの指摘には、修正内容または対応しない根拠を返信します。スレッドを解決済みにするのは、完全に対応した場合のみです。
7. 実装を変更した後は、影響を受ける /test チェックと、新しい独立した /review を再実行し、コミット、プッシュして、CIと自動レビューが再度完了するまで待ちます。PRの検証結果を更新します。利用可能なすべてのチェックが通り、対応が必要な指摘がなくなるまで続けます。
8. 進行に必要な決定、権限、利用できないチェック、または外部での修正が不足している場合は、ブロッカーとして報告します。テストを弱めたり、リポジトリのルールを回避したり、実行していないチェックに合格したと主張したりしないでください。
9. 最終的な検証結果とPRのリンクを、ソースの仕様書またはタスクに記録します。PRがオープンかマージ済みかを含め、実際の結果に合わせて提出状況を更新します。元のトラッカー項目がある場合は、それも更新します。人によるレビューのため、合格したPRは通常オープンのままにします。人による承認待ちはマージのブロッカーであり、実装チェックの失敗ではありません。

依存関係

依存する作業は、各前提作業にオープンなPRがあり、新しい Approve レビューを受け、既知のブロッキング指摘がない場合にのみ開始します。レビュー済みの前提作業を基点としてブランチを積み重ねます。前提作業が複数ある場合は、依存関係の順にまとめます。各PRの差分は、そのタスクに絞ってください。

前提作業が変更またはマージされたら、依存するブランチとPRのベースを更新します。新しいベースに対して、影響を受けるテスト、独立したレビュー、CIを再実行します。

権限がある場合にのみマージする

明示的に /factory または /codex-issue-coordinator を使用すると、そのスコープ内でのマージ権限が付与されます。それ以外の場合は、ユーザーから依頼された場合にのみマージします。スキルが自動選択されても、権限は付与されません。マージする前に、次の条件を満たしていることを確認してください。

• 最終コミットで、スコープが完了しており、受け入れ条件を満たしていることを証明できること。
• テストと必須の CI が成功し、最新の /review の判定が Approve であること。
• 未解決の、対応が必要なレビュー指摘や重大な決定事項がないこと。
• リポジトリで必須とされるすべての承認を得ていること。
• PR の準備が整っており、マージ可能で、必須のベースブランチと同期していること。

リポジトリで推奨される方法を使い、依存関係の順にマージしてください。ブランチ保護を決して回避しないでください。GitHub でマージが報告されたことを確認してから、元の仕様またはタスクのデリバリーステータスと、元のイシューおよびプロジェクトの状態を更新してください。手動で作成したワークツリーは、マージまたはクローズ後に削除してください。管理対象のワークツリーには、ホストのライフサイクルツールを使用してください。オープン中の PR のワークツリーは保持してください。 マージ権限は、デプロイやリリースの公開を許可するものではありません。

報告

各 PR、テスト、レビュー判定、CI の状態、およびブロッカーを報告してください。スコープ内のマージ権限が付与されていない場合は、テストに合格した PR をオープンのままにして終了してください。マージモードでは、確認済みのマージと、人による対応が必要な作業を報告してください。