ousiass design-fix
design-review や design-request で作成された Issue・レポートの指摘を修正する。修正後にデザイン観点の検証を行い、トークン準拠やアクセシビリティの維持を確認する。
前提条件
- Claude Code 環境
git,ghCLI
引数
- 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: 指摘の取得と整理
- 引数からデザイン指摘を取得する
- Issue:
gh issue viewで本文・コメントを読み取る - MD ファイル:
Readで内容を読み取る - 引数なし: ユーザーに修正したい内容をヒアリング
- Issue:
- 指摘を個別の修正項目に分解する（各項目: 箇所・現状・期待する状態）
- 重大度（🔴🟠🟡🟢）に基づき修正順を決定（🔴 から着手）
- 現在のブランチをベースブランチとして記録する
git branch --show-currentを実行し、結果をユーザーに「ベースブランチ: <ブランチ名>」と明示的に表示する- このブランチ名をフェーズ4のPR作成時まで保持する
- 作業ブランチを作成する
- Issue 指定:
design/#<Issue番号>（例:design/#45） - その他:
design/<要約>（例:design/header-spacing-fix）
- Issue 指定:
- TaskCreate でタスクを作成
フェーズ2: デザイン基盤の把握
- プロジェクトのデザイン基盤ファイルを検出・読み込む:
- CSS フレームワーク設定（
tailwind.config.*,uno.config.*等） - デザイントークン / テーマ定義（
theme.ts,tokens.*,variables.css等） - グローバルスタイル（
global.css,base.css等） - 既存 UI コンポーネントライブラリ（shadcn, Vuetify, MUI 等）
- CSS フレームワーク設定（
- 修正時に使うべきトークン・変数・コンポーネントを把握する
フェーズ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: プルリクエスト
- 全指摘の修正完了を確認
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本文:
- 修正した指摘一覧（重大度・内容・対応の要約）
- デザイン検証結果のサマリー
- ベースブランチはフェーズ1で記録した開始時のブランチを指定する。
- 修正サマリーをユーザーに報告する
ルール
- 指摘の修正のみ行う。指摘にないリファクタリングや機能変更を混ぜない
- ハードコード値よりトークン・変数を優先する
- 修正ごとにデザイン検証（3-3）を必ず実行する
- 副作用の確認を怠らない（共有コンポーネントの変更は影響範囲を確認）
- 🔴🟠 の指摘は必ず修正。🟡🟢 は Issue に含まれていれば修正する
- TaskCreate/TaskUpdate で進捗を管理する