develop

開発

develop は、1つのリクエストに対して実装からマージ準備完了のプルリクエストまで進めます。リクエストには、イシューへの参照、文章での指示、またはその両方を含められます。

次の4つのスキルを順番に実行します。

1. working-on-issue はイシューを見つけ、そのブランチに切り替え、担当者に割り当てて、着手済みとしてマークします。
2. implement はコードを変更し、テストを追加します。
3. polish はコミット済みの変更をレビューし、公開前に問題を修正します。
4. ready-pr は残りの作業をコミットし、ブランチをプッシュし、プルリクエストを更新して、レビューのフィードバックに対応し、マージ準備が整っているか確認します。

develop はプルリクエストをマージしません。また、通常の implement フローを使用します。ユーザーが並行実装を依頼した場合は、develop-with-workflow を使用してください。

develop はオペレーターが呼び出した場合にのみ実行します。シミュレーター、デバイス、デプロイ済みのビルドがなくても動作する必要があります。診断結果や提供された動作の観察情報が役立つ場合は、それらを使用してください。

入力

例：

/develop <issue-reference>
/develop "add null checks to the login handler"
/develop <issue-reference> change only the validation path

実装する内容は、文章での指示に従ってください。リンク先のイシューと異なる場合は、文章での指示を優先します。イシューはブランチ名、必須のコミット参照、プルリクエストのリンクに使用してください。

プロダクトやデザイン上の判断をしなければ実装できないほどリクエストが曖昧な場合は、ユーザーに確認してください。正式な受け入れ条件の一覧は必須ではありません。明確な文章での指示があれば十分です。

working-on-issue がイシューを見つけられない場合は、ユーザーに警告し、実装とローカルレビューを続けてください。コミットまたはプルリクエストの作成前に、リポジトリのルールを確認してください。イシューへの参照が必須とされている場合は、そこで停止します。

完了した作業がイシューの本文と異なる場合は、プルリクエストに必須のクローズ参照を残してください。相違点をユーザーに伝え、イシューを編集する前に確認を求めてください。

必須スキル

実装前に、次のスキルがインストールされていることを確認してください。

• working-on-issue
• new-branch
• implement
• tdd
• polish
• code-review
• codebase-design
• diagnosing-bugs
• update-branch
• ready-pr

不足しているスキルがあれば処理を停止し、そのスキル名を伝えてください。現在のソースを使ったプロジェクト内でのインストールコマンドを提示してください。

リクエストによってスキル、その指示、フロントマター、例、参照資料、または同梱スクリプトが変更される場合は、writing-for-agents を使用してください。

使い捨てのプロトタイプをユーザーが依頼した場合、または動作や UI の候補を比較する必要がある場合に限り、prototype を使用してください。ユーザーが残すよう依頼していない限り、polish の前にプロトタイプを削除するか、有用な部分を実際の実装に移してください。

いずれかのスキルを使用する前に、インストール済みであることを確認してください。不足している場合は処理を停止し、そのスキル名を伝え、現在のソースを使ったプロジェクト内でのインストールコマンドを提示してください。

動作の観察情報

reporter-fidelity の観察フィールドにあるコンテキストフィールドを使用してください。利用可能なすべてのフィールドを変更せずに polish と ready-pr に渡してください。実装に役立つ場合は診断してください。呼び出し元から観察コンテキストが提供されない場合は、作業を追加せずに続行してください。

ワークフロー

1. AGENTS.md、CLAUDE.md、およびそれらが指定するファイルを読みます。
2. 必要なスキルがインストールされていることを確認します。
3. リクエスト全体を指定して working-on-issue を実行します。イシュー、ブランチ、ステータスの結果を最終報告用に記録しておきます。
4. リクエストを実装するのに十分明確かどうかを確認します。プロダクト上の判断、デザイン上の判断、認証情報、権限、外部アクセス、または競合を解消する指示が必要な場合は、作業を中止します。
5. リクエストに必要な場合は、writing-for-agents または prototype を実行します。
6. implement に記載されているビルドとテストの手順を使います。イシュー本文と記述された指示が異なる場合は、記述された指示に従います。polish で最終レビューを行うため、implement の最後にある単独のコードレビューは省略します。
7. リポジトリに記載された検証コマンドを実行します。変更が実行可能な動作に影響する場合は、テストを追加または更新します。ターゲットブランチをマージした後、update-branch の 検証ルールに従います。ターゲットブランチにすでに存在することが確認された問題は、develop を妨げません。ターゲットのコミット、コマンド、失敗、およびその根拠を最終報告用に記録しておきます。
8. 現在のコミットに対して polish を実行します。イシュー、記述された指示、確認できる動作上の観察結果を渡します。受け入れた指摘を修正してコミットし、再度 polish を実行します。指摘なしで合格するか、人間の判断を求められるまで繰り返します。
9. リポジトリでイシューへの参照が必須で、手順 3 でイシューが見つからなかった場合は、ready-pr の前に中止します。完了したローカル作業を報告し、ユーザーにイシューを提示するよう依頼します。
10. 同じ動作上の観察結果を指定して ready-pr を実行します。ブランチのコミットとプッシュ、プルリクエストの作成または更新、対応可能なフィードバックへの対応、現在のプルリクエストの状態確認を任せます。
11. ローカルチェックまたはプルリクエストのチェックが失敗した場合は、このブランチが原因の問題を修正します。レビューのフィードバックで問題が指摘された場合も同様に対応します。新しいコミットごとに検証とレビューを行ってプッシュし、プルリクエストがマージ可能になるか、次の手順に人の対応が必要になるまで繰り返します。

作業完了時

以下のすべてが当てはまる場合にのみ、プルリクエストがマージ可能であると報告します。

• 実装が、記述された指示と関連するイシュー要件を満たしている。
• リポジトリの検証が完了している。
• 有用な場合、変更された動作をテストでカバーしている。
• 現在のコミットに対する polish が指摘なしで合格している。
• プルリクエストのフィードバックに回答または修正がある。
• 最新のコミットですべての必須プルリクエストチェックに合格している。
• ready-pr がプルリクエストをマージ可能と報告している。
• 未解決の判断事項やアクセス上の問題が残っていない。

追加のリポジトリ全体を対象としたコマンドで、ターゲットブランチにすでにある失敗が確認された場合、プルリクエストの妨げにはなりません。その根拠として記録した内容を最終報告に含めます。

次の手順にプロダクト上またはデザイン上の判断、認証情報、権限、外部アクセス、競合する指示、またはこのリクエストの範囲外で有効な作業が必要な場合は、作業がブロックされていると報告します。

イシューでブランチが指定されている場合は、そのブランチで作業を終えます。別のブランチを使うのは、ユーザーが明示的に指定した場合に限ります。最終報告では、ブランチ名とその理由を示します。

最終報告

最初に Ready to merge または Blocked を記載します。その後、ユーザーに次の内容を伝えます。

• 変更内容
• 作業の場所
• 検証の合否
• polish による変更内容
• プルリクエストへのフィードバックとチェックに未対応のものがないか
• ユーザーが次に行うこと
• 残っている具体的なリスクやテストの不足

リンクが利用できる場合は、Issue とプルリクエストにリンクします。ブランチが Issue のブランチと異なる場合に限り、ブランチについて言及します。

すべてのチェックに合格した場合は、検証結果を一文で要約します。コマンドを正確に記載するのは、失敗したチェック、省略したチェック、またはユーザーが実行する必要のある手順に限ります。GitHub のステータス項目を繰り返したり、成功したチェックをすべて列挙したりしないでください。

長時間の作業中は、依頼、Issue、ブランチ、現在の結果、ブロッカー、次の手順を簡潔に記録しておきます。完了済みの作業を繰り返さずに再開できるよう、そのメモを使います。追加のリポジトリ全体に対するコマンドで、ターゲットブランチの問題が実証された場合は、ターゲットのコミット、コマンド、失敗内容、証拠も記録しておきます。その証拠を再利用する前に、update-branch の検証ルールをもう一度適用します。