implement-issue

イシューを実装する

現在のリポジトリを対象に、イシューを最初から最後まで解決するか、実装が不要であることを根拠とともに示してください。

ゲート

• 判断する前に、イシュー、プロジェクトの指示、ビジョン、コントリビューションガイド、Definition of Ready、Definition of Done、関連するドメインスキル、実際のプロジェクトコマンド、影響を受けるコードパス、テスト、再現手順を確認してください。
• 選択肢を提示する前に、必ずウェブ検索を実施し、現在の根拠を記録してください。公式情報や一次情報を優先し、チェックアウト内のバージョンと照合してください。記憶しているリンクは検索の手がかりとしてのみ扱います。判断に関連する最新の根拠を検索で得られない場合は、そこで中止してください。
• 自動モード以外では、登録済みの grilling と render-html のスキル、および Python 3 が必要です。いずれかの依存関係が利用できない場合は中止してください。実際の grilling 意思決定ループを使用し、場当たり的な質問で模倣しないでください。
• 選択肢を提案する前に、イシュー、リポジトリ、再現手順、プロジェクトの契約、最新のウェブ調査、共有された最新状況の成果物から、中立的な根拠資料をひとつ作成してください。すべての選択肢は、この同じ資料に基づいて導き出してください。
• 採点前に、イシューの成果、制約、要件に基づく比較基準をひとつ定義してください。実行可能なすべての選択肢に、意思決定に関係する検証を同等に行ってください。
  • UI／UX に違いがある場合は、実質的に異なる体験をそれぞれ提示してください。
  • アーキテクチャやワークフローに違いがある場合は、関連する各フローを提示してください。
  • インタラクションが多い場合や技術的な主張について、静的な根拠だけでは判断できない場合は、比較可能な短期間のプロトタイプまたは測定結果を用いてください。
  • 同等の検証とは、実装にかける労力が同じであることではありません。観測された事実、提案する動作、プロトタイプ限定の簡略化を明示してください。
• ある選択肢によって根拠の不足が判明した場合、影響を受けるすべての選択肢について同じ関連検証を行ってください。それが不可能な場合は、検証の不均衡を明らかにし、比較時の確信度を下げてください。
• プロトタイプはローカルで使い捨てにし、レビュー可能なキャプチャと調査結果のみを保持し、grill の終了時に削除してください。デプロイや公開はしないでください。プロトタイプを保持または昇格させるのは、ユーザーが明示的に承認した場合に限ります。承認済みのプロトタイプ素材は、git-workflow の同期ゲートを通過するまで、選択したワークツリーの外に置いてください。
• 宣言した比較基準に照らし、実質的に異なる実行可能な選択肢を 2〜4 件比較し、その中からひとつを推奨してください。自動モードでない限り、ユーザーが選ぶまで待ってください。関連性の高い出典リンク、確認したプロジェクトのバージョン、スコア、残っている不確実性を含む、簡潔な根拠の要約を提示してください。
• 自動モード以外では、grilling の意思決定ループに入る前に、render-html を使って比較内容を一時的なインタラクティブ影響レポートとして提示してください。共有された構造化根拠、宣言した比較基準、各選択肢の影響、長所、短所、スコア、不確実性、コピー可能な議論用プロンプトを含めてください。すべての中立的な選択肢を提示した後、締めくくりのセクションで推奨を示してください。
• 最新の根拠により、必須のプロトタイプや準備条件が満たされないことが決定的に示された場合は、ゲートを迂回するか尋ねずに、その時点での中止を報告してください。
• 選択肢の選択後、または自動モードでの開始後は、状況確認、診断、修正、ゲート失敗の対応中も、承認された実装作業を継続してください。結果が完成した場合、安全に範囲内で進められる作業を外部要因で続行できなくなった場合、または新たな権限や重要な未解決の判断が必要になった場合に限り、制御を返してください。既知の修正案や推奨案があるだけでは終了条件になりません。
• コードまたはテストを変更した場合は、変更のない同一の実装に対して /code-review fix-all とブラックボックステストをイシューに照らして再度実施し、両方が合格するまで続けてください。その後、プロジェクトのゲートを完了し、/create-pr を実行してください。

プロジェクトの定義

最も近くにある適用可能な DEFINITION_OF_READY.md と DEFINITION_OF_DONE.md を正式な基準として扱います。実際に検索してもどちらかが見つからない場合は、 そのことを一度だけ明記し、その不足を計画と PR に引き継いで、ワークフローに組み込まれたチェックと リポジトリで実際に定義されているコマンドのみを使用します。

自動モード

自動モードは、元のプロンプトに automatic と記載されている場合、または明示的に要求されている場合にのみ適用されます。インタラクティブな HTML レポートと grilling のループは省略しますが、ほかのゲートはすべて適用されます。共有パケット、事前定義された評価基準、および同等のチェックが完了するまで、選択肢を選ばないでください。比較が未完了のままの場合は、最初の好みが検証済みであるかのように扱うのではなく、不足している内容と確信度への影響を報告します。プロダクト、アーキテクチャ、セキュリティ、スコープ、またはビジョンに関する重大な判断が必要な場合は、自動モードを無効にします。

ワークフロー

1. コメントとラベルを含めて Issue を取得し、オープン状態であり、実装に着手できる状態で、PR、重複、ブロック中、または却下済みの項目ではないことを確認します。
2. 適用されるプロジェクトの契約と専門スキルを読み込みます。
3. エントリーポイントから症状までの動作全体をたどり、可能であれば記載された再現手順または成果物を実行します。実際のレイヤーを特定できるまで、呼び出し元、関連箇所、テスト、設定、履歴を調べます。必ず最新のウェブ検索を行い、その結果をチェックアウト済みの内容と照合します。
4. 動作が再現しなくなっている場合は、以下を区別します。
   • すでに修正され、テストでカバー済み：修正コード／コミットとテストの証拠を添えて、クローズを推奨します。 未カバーの
   • 修正済みで、回帰テストがない：不足しているテストのみを追加します。
   • 共通の根本原因に起因する関連パスにも影響が残っている：該当するパスのみを含めます。
5. 中立的な証拠パケットと比較基準を作成し、選択肢を導き出して、それぞれを意思決定に関係する同等のチェックで検証します。まず比較し、その後でのみ推奨します。
6. 自動モード以外では、ワークツリーの外に一時ディレクトリを作成します。render-html のスキーマに従い、そこで選択肢の比較をレンダリングします。レポートを開いて確認します。ホストのインラインプレビューが利用できない場合は、絶対パスを提示して続行します。レポートと共有証拠を使って、grilling を一度に1つの判断事項について実行し、チャットでユーザーの選択を待ちます。ユーザーから保持を明示的に求められない限り、選択後に一時レポートとその入力を削除します。
7. 選択後、専用ブランチ／ワークツリーを再利用または作成し、編集前に git-workflow のリモートデフォルト同期ゲートを適用します。
8. 適切なレイヤーに、最小限かつ完全な変更を実装します。Issue とプロジェクトの契約で必要とされるテストとドキュメントを更新します。
9. UI／UX の作業では、影響を受けるすべての状態をレンダリングし、レビュー可能な変更前／変更後の証拠を記録します。アクセシビリティ、レスポンシブ動作、テーマ、デザインシステムとの一貫性を確認し、その証拠を PR に添付します。
10. 開発中に対象を絞ったチェックを実行します。チェックを弱めず、失敗を修正します。
11. 要件、完了の定義、プロジェクトの規約、ブランチの差分、再現可能な動作に対して /code-review fix-all を実行します。対象範囲内で妥当と確認された指摘をすべて解決します。重大な新たな判断事項、または未解決の Blocking／Important の指摘がある場合は停止します。/code-review が利用できない場合は、同じ範囲に限定したレビューと修正を直接行います。
12. 利用可能であれば /test-against-spec fix を実行します。利用できない場合は、同じブラックボックステストを直接実施します。Issue に明示された要件を使い、ソースコードを証拠として扱わず、利用可能であれば正確なリビジョンのプレビュー環境を優先し、それがなければローカル環境に切り替えます。各要件と、観察された結果または制約を記録します。
13. ステップ11または12で実装を変更した場合、あるいは作業が未完了と報告された場合は、実装を続けてステップ11からやり直します。コードレビューと動作テストの両方が、同じ変更されていない実装で合格するまで繰り返します。利用可能な環境をすべて試しても必須の動作を検証できない場合は、ユーザーが制約を明示的に受け入れるか、不足しているプレビュー環境を得るためにドラフト PR を求めない限り、停止して確認を求めます。
14. 該当する完了の定義とリポジトリゲートを実行します。ゲートの失敗を修正して実装が変わった場合は、ステップ11に戻ります。動作テストのステップで広範なゲートを重複して実行しません。
15. /create-pr を使用し、Closes #<issue> を含め、現時点の完了証拠を引き継ぎ、観察された結果のみを報告します。
16. それ以前に処理を返す場合は、必ずアクティブな実装の終了条件を確認します。終了条件が確立されていない場合は、許可された次の安全なアクションを続行します。