最初のタスクを実行する

作業内容を記述し、計画を承認すれば、Coroidがそれを構築・検証するのを確認できます。

1件のタスクは、1つのpull requestとして完了する作業単位です。新規に開始するには新規作業.

適切な初回タスクを選択する

最適な初回タスクは、規模が小さく実際のもので、既存のテストに近いものです。「エクスポートコマンドに」のようなものが良い例です。--jsonフラグを追加し、インポートコマンドがすでに対応している出力形式に合わせることで、Coroidに明確な目標が与えられ、結果も明確に把握できます。

初回利用時には以下を避けてください：

実装内容ではなく、最終的な成果物を記述しましょう。作業完了時に満たされるべき条件や、重要なファイル、準拠すべき規約、変更を加えてはならない箇所など、明確にしておくべき事項を記載してください。

計画を自ら作成する必要はありません。それは Coroid が最初に生成するものであり、あなたが承認を行うのです。

コード上に記載されていない背景情報 — ADR、スタイルガイド、チケットなど — がある場合は、それらを添付してください。詳しくはプロジェクトの背景情報を参照してください。これらは Coroid が明示的に指示されなくても把握している情報です。

Coroid はあなたの記述内容を仕様書に変換します。そこには構築対象、対象外の範囲、成功を判断するための受け入れ基準が記載されており、タスクの仕様書タブで確認できます。

構築を開始する前に必ず確認してください。受け入れ基準が実際の要望と一致しない場合は、今すぐ修正してください。これらは後続の検証段階でテスト対象となるからです。詳細は仕様書をご覧ください。仕様書.

些細な変更を除き、仕様書は計画となります。計画：順序付けられた手順の集合です。コードを記述する前にこれを承認します。

ここが介入するのに最もコストがかからないタイミングです。計画を却下するのにかかる時間はわずか1分ですが、完成した pull request を却下すると、全体の処理が無駄になってしまいます。

承認されると、タスクは新規作業に入ります。PENDINGエージェントの空きが出るまで待機し、その後実行されます。IN_PROGRESSリアルタイムで実行状況を追跡できます。実行された手順、呼び出されたツール、操作されたファイル、および蓄積されるテスト結果を確認可能です。

常に監視する必要はありません。必要な時や完了した時には通知が届きます。

所要時間所要時間は変更の規模やテストスイートの実行時間によって決まり、所有するエージェントスロット数には依存しません。スロット数は同時に実行できるタスク数を制御します。
**NEEDS_HUMAN_REVIEWこれはエラーではありません。**これは Coroid があなたのみが下せる判断を求めていることを意味します。回答すればタスクは続行されます。
**再作業は通常のことです。**レビュー担当者が問題を発見した場合、あなたが確認する前に開発者に戻されます。

結果をレビューしてマージする— 届くものと確認すべき点について