implement-idea

アイデアを実装する

アイデアを確認済みのミニ仕様に落とし込み、現在のリポジトリで最初から最後まで実装します。

ゲート

• まず、スペースを含めて400文字以内の暫定ミニ仕様を作成します。アーティファクトを使った検討を経た後に限り、ユーザーに見える成果、範囲／対象外、テスト可能な成功指標を網羅する最終ミニ仕様を確認します。
• 判断を下す前に、プロジェクトの指示、ビジョン、貢献ガイド、着手準備の定義、完了の定義、関連するドメインスキル、実際のプロジェクトコマンド、影響を受けるコードパス、テスト、関連作業を確認します。
• 選択肢を提示する前に、必ず最新の根拠を得るためのウェブ検索を実行し、その記録を残します。公式および一次情報を優先し、チェックアウト内のバージョンと照合します。記憶しているリンクは検索の手がかりとしてのみ扱います。判断に関連する最新の根拠を検索で得られない場合は停止します。
• 自動モード以外では、登録済みの grilling と render-html のスキル、および Python 3 が必要です。依存関係が利用できない場合は停止します。アドホックな質問で模倣せず、実際の grilling の意思決定ループを使用します。
• 選択肢を提案する前に、リポジトリ、再現結果、プロジェクトの契約、最新のウェブ調査、共有されている最新状況のアーティファクトから、中立的な根拠パケットを1つ作成します。すべての選択肢は、この同じパケットから導きます。
• 確認済みの成果、制約、成功指標に基づいて、採点前に比較基準を1つ定めます。実行可能な各選択肢について、意思決定に関わる検証を同等に行います。
  • UI／UXに違いがある場合は、実質的に異なる体験をそれぞれ示します。
  • アーキテクチャやワークフローに違いがある場合は、関連するフローをそれぞれ示します。
  • インタラクションが多い場合や技術的な主張の場合は、静的な根拠では判断できないときに、比較可能な短期間のプロトタイプまたは測定を行います。 同等の検証に、同じ実装工数は必要ありません。観測された事実、提案する動作、プロトタイプ限定の簡略化を明示します。
• 選択肢によって根拠の不足が明らかになった場合は、影響を受けるすべての選択肢に対して同じ関連チェックを行います。それが不可能な場合は、検証状況に差があることを開示し、比較前に確信度を下げます。
• プロトタイプはローカルで使い捨てとし、レビュー可能なキャプチャと調査結果のみを保持します。検討の終了時に削除し、デプロイも公開もしません。明示的なユーザー承認がある場合に限り、プロトタイプを保持または昇格します。承認されたプロトタイプの成果物は、git-workflow の同期ゲートに合格するまで、選択されたワークツリーの外に保管します。
• 実質的に異なる、実行可能な選択肢を2〜4個、明示した比較基準に照らして比較します。その後、1つを推奨し、自動モードが適用されない限りユーザーの選択を待ちます。最も関連性の高い出典リンク、確認したプロジェクトのバージョン、スコア、残る不確実性を含む、簡潔な根拠の要約を添えます。
• 自動モード以外では、grilling の意思決定ループに入る前に、render-html を使って比較内容を一時的なインタラクティブ影響レポートとして提示します。共有の構造化された根拠、明示した比較基準、各選択肢の影響、長所、短所、スコア、不確実性、コピー可能な検討用プロンプトを含めます。中立的な選択肢をすべて示した後、最後のセクションで推奨案を提示します。
• 選択肢の選定後、または自動モードでの開始後は、ステータス確認、診断、修正、ゲート失敗の間も、承認された実装作業を継続します。成果が完成するか、外部ブロッカーによって安全に範囲内で進められる作業がなくなるか、継続に新たな権限または重要な未解決の判断が必要になるまで、制御を返しません。既知の修正や推奨案があることは、作業の終了を意味しません。
• コードまたはテストを変更した場合は、変更のない同一の実装に対して /code-review fix-all とブラックボックステストを繰り返し、両方に合格するまで続けます。その後、プロジェクトのゲートを完了し、/create-pr を実行します。

プロジェクトの定義

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

自動モード

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

ワークフロー

1. 暫定ミニ仕様を、スペースを含めて400文字以内で作成します。 確定した契約ではなく、出発点として扱います。
2. 該当するプロジェクトの契約と専門スキルを読み込みます。
3. 既存の拡張ポイント、再利用可能なパターン、関連機能、テスト、アーキテクチャ上の制約を確認します。必ず最新のウェブ検索を行い、その結果をチェックアウト済みの内容と照合します。アイデアが目指す成果について課題トラッカーを検索し、仕組みだけを検索するのではありません。既存の課題には過去の決定と受け入れ基準が含まれています。アイデアがすでに存在する場合は、それを使うことを推奨します。一部だけ存在する場合は、重複させずに拡張します。
4. 中立的なエビデンスパケットと比較基準を作成し、選択肢を導き出して、それぞれについて意思決定に関連する同等の確認を行います。まず比較し、その後でのみ推奨します。
5. 自動モード以外では、ワークツリーの外に一時ディレクトリを作成します。 render-html のスキーマに従い、選択肢の比較をそのディレクトリにレンダリングします。レポートを開いて確認します。インラインのホストプレビューが利用できない場合は、その絶対パスを提示して続行します。レポートと共有エビデンスを使って、一度に1つずつ grilling を実施し、最終ミニ仕様を確定してから、チャットでユーザーの選択を待ちます。ユーザーが明示的に保持を求めない限り、選択後に一時レポートとその入力を削除します。
6. 選択後、目的に合ったブランチ／ワークツリーを再利用または作成し、編集前に git-workflow のリモートデフォルト同期ゲートを適用します。
7. 正しいレイヤーで、完全な変更のうち最小限のものを実装します。ミニ仕様とプロジェクトの契約で必要とされるテストとドキュメントを更新します。
8. UI/UX の作業では、影響を受けるすべての状態をレンダリングし、確認可能な変更前／変更後のエビデンスを取得します。アクセシビリティ、レスポンシブ動作、テーマ、デザインシステムとの一貫性を確認し、エビデンスを PR に添付します。
9. 開発中に対象を絞ったチェックを実行します。チェックを弱めるのではなく、失敗を修正します。
10. 成功指標、完了の定義、プロジェクトの規約、ブランチの差分、再現可能な動作に照らして /code-review fix-all を実行します。範囲内で妥当性が確認された指摘をすべて解決します。重要な新たな判断が必要な場合、または未解決の Blocking もしくは Important な指摘がある場合は停止します。/code-review が利用できない場合は、同じ範囲に限定したレビューと修正を直接行います。
11. 利用可能であれば /test-against-spec fix を実行します。利用できない場合は、同じブラックボックステストを直接行います。確定したミニ仕様を使い、ソースコードを証拠として扱わず、利用可能であれば正確なリビジョンのプレビューデプロイを優先し、利用できない場合はローカル環境を使います。各要件と、観測した結果または制約を記録します。
12. 手順10または11によって実装が変更された場合、または作業が未完了と報告された場合は、実装を続けて手順10からやり直します。同一で変更のない実装に対して、コードレビューと動作テストの両方が合格するまで繰り返します。利用可能な環境をすべて使っても必要な動作を検証できない場合は、ユーザーが制約を明示的に受け入れるか、不足しているプレビュー環境を得るためにドラフト PR を明示的に依頼しない限り、停止して確認を求めます。
13. 該当する完了の定義とリポジトリのゲートを実行します。ゲートの失敗を修正したことで実装が変更された場合は、手順10に戻ります。動作テストの手順で広範なゲートを重複して実行しないでください。
14. /create-pr を使い、現在のミニ仕様、実現した成果、観測済みの完了エビデンスを PR に引き継ぎます。
15. それ以前に作業を返す前に、アクティブな実装の終了条件を確認します。終了条件が確定していない場合は、次に安全で許可された作業を続行します。