Implementation
レビュー所見を修正仕様に落とす
良いレビューでも、修正仕様が曖昧なら実装はぶれます。何を変え、何を変えないか、どの状態で完了かを先に定義します。
ui.design: handoffui.design: tasks-json
まず確認する症状
- 『CTAを強くする』だけで、どのCTAをどう変えるか決まっていない。
- デザイン変更と文言変更と計測変更が1つの大きな作業に混ざっている。
なぜ問題か
- 自動コーディングでは、曖昧な目的語や広すぎるタスクが失敗の原因になります。
- 非目標を明記すると、余計なリファクタリングやデザイン崩れを防げます。
診断で見る指標
対象URL
対象コンポーネント
変更内容
非目標
確認条件
修正方法
最小修正
1タスク1成果にする
CTA文言、フォーム説明、見出し構造などを分けます。
推奨修正
非目標を明記する
配色刷新しない、認証機能を触らない、など今回やらないことを書きます。
さらに改善
再スキャン条件を仕様に含める
該当checkIdや期待スコア変化を受け入れ条件へ入れます。
受け入れ条件
- 01PCとスマホの両方で目視確認し、主なCTAまたは操作対象が迷わず見つかる。
- 02キーボード操作、読み上げ補助、または自動検査で再発しやすい項目を確認する。
- 03修正後にui.designで再スキャンし、同じ所見が残る場合は原因を分解する。
コーディングエージェント向け修正指示
目的: レビュー所見を、対象、変更内容、非目標、確認方法を持つ修正仕様へ整理してください。広すぎる変更は複数タスクに分割してください。
参考資料
よくある失敗
- 『いい感じに改善』のような曖昧な指示を残す。
- 見た目だけを整え、見出し、リンク、フォームラベルなどの意味構造を直さない。
- 1つの指摘だけを直し、同じ原因から出た別画面の再発を確認しない。