Coroidは処理完了後、独自のブランチ上でpull requestを作成しますが、マージは行いません。その判断はあなたが下します。
同時に届く内容
- コードの変更内容
- それに合わせて記述または更新されたテスト
- 既存のテストスイートを実行した結果
- 組織で設定された品質チェックの結果
- 差分に対するレビュー結果。修正済みのものも、未修正の指摘も含まれます。
目的はレビューを置き換えることではありません。あなたのレビューが最初のものになるべきではないということです。
実際に確認すべき点
機械的な検証はすでに完了しています。あなただけが判断できる点に注意を向けてください：
- **目的の問題を正しく解決しているか？**仕様書に記載された受け入れ基準と照らし合わせて確認してください。自分の記憶に頼るのではなく。
- **コードベースに適合しているか？**コーディング規約、命名規則、抽象化の構造などです。Coroidはコードを読み取ってこれらを推測しますが、ほぼ正しい程度で完全とは限りません。
- **予期しなかった箇所に変更が及んでいないか？**差分を確認する前にファイル一覧をご覧ください。
- **新しいテストは有意義か？**何も保証しないパスするテストは、テストがないよりも悪い場合があります。
作業を差し戻す方法
段階的にコストが高くなる3つの選択肢があります：
- コメントを付けて再作業を依頼する— タスクがあなたの指摘内容とともに開発者エージェントに戻り、コンテキストは保持されます。「正しいが不完全」な場合に最適です。
- 計画を拒否して再実行する— 実行方法は間違っているが、内容自体は妥当な場合に適用します。
- タスクをキャンセルする— その作業が不要な場合に適用します。キャンセルすると実行が停止し、エージェントのスロットが解放されます。
再作業のコメントは、同僚に伝えるのと同じように具体的に記述してください。「これは空のケースを処理していない」parseRange「〜により修正される」と記述すれば修正につながりますが、「改善が必要」とだけ記述すると推測に頼ることになります。
マージ方法
通常のブランチ保護、必須チェック、承認ルールを利用して、ご自身のプロバイダー経由でマージしてください。Coroidが作成したpull requestは、既存のプロセスに従って処理されます。
マージに関して特別な仕組みはありません。これは意図的な設計です。pull requestは通常のプルリクエストなので、既に信頼しているレビューやCIプロセスを通じて処理されます。
次へ
次に進む先— あなたの目的に応じてドキュメントの他のセクションへ移動できます。