# Design Fix

> デザインレビューやデザイン変更Issueの指摘を修正し、デザイン検証付きでPRを作成する。

- Skill: `ousiass/design-fix` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ousiass/design-fix`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ousiass/design-fix/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ousiass (https://skillmd.com/u/ousiass)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/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 で進捗を管理する