ousiass/design-fix

design-fix

design-review や design-request で作成された Issue・レポートの指摘を修正する。修正後にデザイン観点の検証を行い、トークン準拠やアクセシビリティの維持を確認する。

前提条件

• Claude Code 環境
• git, gh CLI

引数

• Issue 番号 (例: /design-fix #45): GitHub Issue からデザイン指摘を取得
• Issue URL (例: /design-fix https://github.com/owner/repo/issues/45): 同上
• MD ファイルパス (例: /design-fix design-review-report.md): ローカルレポートから指摘を取得
• 引数なし: ユーザーにヒアリング

フェーズ1: 指摘の取得と整理

1. 引数からデザイン指摘を取得する
   • Issue: gh issue view で本文・コメントを読み取る
   • MD ファイル: Read で内容を読み取る
   • 引数なし: ユーザーに修正したい内容をヒアリング
2. 指摘を個別の修正項目に分解する（各項目: 箇所・現状・期待する状態）
3. 重大度（🔴🟠🟡🟢）に基づき修正順を決定（🔴 から着手）
4. 現在のブランチをベースブランチとして記録する
   • git branch --show-current を実行し、結果をユーザーに「ベースブランチ: <ブランチ名>」と明示的に表示する
   • このブランチ名をフェーズ4のPR作成時まで保持する
5. 作業ブランチを作成する
   • Issue 指定: design/#<Issue番号> （例: design/#45）
   • その他: design/<要約> （例: design/header-spacing-fix）
6. TaskCreate でタスクを作成

フェーズ2: デザイン基盤の把握

1. プロジェクトのデザイン基盤ファイルを検出・読み込む:
   • CSS フレームワーク設定（tailwind.config.*, uno.config.* 等）
   • デザイントークン / テーマ定義（theme.ts, tokens.*, variables.css 等）
   • グローバルスタイル（global.css, base.css 等）
   • 既存 UI コンポーネントライブラリ（shadcn, Vuetify, MUI 等）
2. 修正時に使うべきトークン・変数・コンポーネントを把握する

フェーズ3: 修正サイクル（各指摘で繰り返し）

3-1: 対象の確認

• 修正対象のファイルを Read で確認し、現状を正確に把握する

3-2: 修正

• デザイン基盤のトークン・変数を使用して修正する
• ハードコード値は避け、既存のトークンを活用する
• 既存コンポーネントがあればそれを活用する

3-3: デザイン検証

修正後に以下を確認する：

| 検証項目 | 確認内容 | |---------|---------| | トークン準拠 | ハードコード値を導入していないか | | 一貫性 | 同一コンポーネントの他の箇所と統一されているか | | アクセシビリティ | ARIA、フォーカス、コントラストが維持されているか | | レスポンシブ | ブレークポイント対応が崩れていないか | | 副作用 | 同じコンポーネントを使う他の画面に意図しない影響がないか |

3-4: Review

• review エージェントで修正内容をレビューする

3-5: 改善サイクル

• レビュー指摘あり → 修正 → 再レビュー → 指摘なしまで繰り返す

3-6: Format & Lint

• プロジェクト設定に従い変更ファイルに format/lint を実行。設定なしならスキップ

3-7: Commit

• コミットメッセージは CLAUDE.md の規約に従う
• 指摘項目ごとにコミットを分ける

フェーズ4: プルリクエスト

1. 全指摘の修正完了を確認
2. gh pr create --base <ベースブランチ> でPRを作成
   • ベースブランチはフェーズ1で記録した開始時のブランチを指定する。main や master にフォールバックしないこと。
   • 不明な場合は git log --oneline --graph HEAD...main 等で分岐元を確認する
   • Issue 指定時: タイトルに Issue 番号を含め、PR作成後に gh pr edit <PR番号> --add-issue <Issue URL> でリンクする（Closes は使わない）
   • PR本文:
     • 修正した指摘一覧（重大度・内容・対応の要約）
     • デザイン検証結果のサマリー
3. 修正サマリーをユーザーに報告する

ルール

• 指摘の修正のみ行う。指摘にないリファクタリングや機能変更を混ぜない
• ハードコード値よりトークン・変数を優先する
• 修正ごとにデザイン検証（3-3）を必ず実行する
• 副作用の確認を怠らない（共有コンポーネントの変更は影響範囲を確認）
• 🔴🟠 の指摘は必ず修正。🟡🟢 は Issue に含まれていれば修正する
• TaskCreate/TaskUpdate で進捗を管理する