audit
Freeプロジェクト監査。「監査して」「audit」「/audit」で発火。設計/UX/品質/テストなどの観点でコードベース全体を監査し、課題をissuesディレクトリに書き出す。実行ログで重複実行を防止。特定の差分・コミットのレビューには使わない(codex-review / cross-review を使う)。
The English summary is being prepared. Showing the original description.
色合いのキツさ・隣接要素の色被り・トーン不統一・視認性の悪さを使用感ベースのUX観点で検出し、修正案を標準出力に報告する。報告のみでコードは変更しない。WCAG コントラスト比など数値基準の準拠検証は style-review を使う
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
実装コードからカラー定義と使用箇所を抽出し、「人間の目で見た時に見づらい・疲れる・区別しにくい」問題を検出するスキル。
WCAG 準拠の技術的検証ではなく、実際の使用感に基づくUXレビュー(WCAG 検証は /style-review の担当)。
/ux-visibility-review [対象ディレクトリ]
高彩度・高明度の色が広い面積で使われていると視覚的に攻撃的になる。
検出基準(HSL ベース):
修正案の方向:
#FF0000 → #DC2626(少しだけ暗く)、#00FF00 → #22C55E(彩度を落とす)横並び・縦並びで隣り合う UI 要素の色が近すぎると、境界が曖昧になり認知負荷が上がる。
検出基準(CIE ΔE 2000):
隣接要素の推定方法:
VStack/HStack/List 内の子ビュー同士flex/grid コンテナの子要素修正案の方向:
テキスト色と背景色の「暖色/寒色」や「彩度レベル」が不統一だと違和感が生まれる。
検出基準:
修正案の方向:
同じ意味の要素に別の色が使われていると、ユーザーが混乱する。
検出基準:
修正案の方向:
Light モードでは問題ないが Dark モードに切り替えると破綻するパターン。
検出基準:
1. プロジェクト種別判定
├── *.xcodeproj / Package.swift → Swift App
└── package.json / *.css → Electron App
2. カラー定義の抽出
├── Swift: Asset Catalog JSON + コード内 Color/NSColor/UIColor
├── CSS: 変数定義 (:root) + プロパティ値
└── テーマファイル: エクスポートされた色定数
3. 色の使用コンテキスト分析
├── どの要素にどの色が使われているか
├── 隣接関係の推定(レイアウトコンテナの解析)
└── Light/Dark 両モードでの色マッピング
4. 問題検出
├── HSL 変換して彩度・明度チェック
├── CIE ΔE 2000 で隣接色の色差計算
├── トーンの一貫性チェック
└── セマンティック色の統一性チェック
5. 修正案の生成
├── 具体的な色コード(HEX)を提案
├── 変更前後の色差を数値で示す
└── 標準出力に Markdown で報告
1. Glob: **/*.colorset/Contents.json → Asset Catalog の色定義
- "components" の r/g/b/a 値を抽出
- "appearances" から Light/Dark の色を分離
2. Grep: Color\(|\.foregroundColor|\.foregroundStyle|\.background|\.tint
→ コード内の色使用箇所
3. Grep: \.primary|\.secondary|\.accentColor → システムカラー使用
4. レイアウト構造: VStack/HStack/List/ForEach を追跡して隣接関係を推定
1. Glob: **/*.css, **/*.scss → スタイルファイル
2. Glob: **/theme*.{ts,js}, **/colors*.{ts,js} → テーマ定義
3. Grep: --[a-z-]*color|--bg-|--text-|--border- → CSS 変数
4. :root と prefers-color-scheme: dark の色を分離
5. flex/grid コンテナ内の子セレクターから隣接関係を推定
人間の色知覚に基づく色差指標。数値が大きいほど違って見える。
| ΔE 値 | 体感 |
|---|---|
| < 1 | 人間には区別不能 |
| 1〜5 | 注意すれば分かる程度 |
| 5〜10 | 一目で分かるが「似ている」 |
| 10〜25 | 明確に異なる色 |
| > 25 | 全く別の色 |
RGB → HSL 変換:
H (色相): 0〜360°
S (彩度): 0〜100%(0=無彩色, 100=純色)
L (明度): 0〜100%(0=黒, 100=白)
「キツい色」= S > 80% かつ 40% < L < 60%
## UX Visibility Review
### 概要
- プロジェクト種別: Swift App
- 検証ファイル数: 12
- 検出問題数: 7 (High: 2, Medium: 3, Low: 2)
---
### High: サイドバーのアイテム色が隣接で区別できない
**場所**: `Views/SidebarView.swift:34-52`
**問題**: `HStack` 内の `.labelColor (#3B82F6)` と `.iconColor (#4F8EF7)` の色差 ΔE = 3.2 で、ほぼ同じに見える
**修正案**:
- `.iconColor` を `#1D4ED8` に変更 → ΔE = 18.5(明確に区別可能)
- または `.labelColor` をグレー系 `#374151` にしてアイコンに色を持たせる
---
### High: アクションボタンの赤がキツすぎる
**場所**: `Styles/buttons.css:23`
**問題**: `.btn-danger` の `background-color: #FF0000` は彩度 100% の純色で、長時間の使用で目が疲れる
**修正案**:
- `#DC2626` に変更(S: 89%, L: 50% → 十分に「赤」だがトーンが落ち着く)
- Hover 時: `#B91C1C`
---
### Medium: ナビゲーションタブの選択/非選択が似ている
**場所**: `Components/TabBar.swift:18-25`
**問題**: 選択タブ `#2563EB` と非選択タブ `#3B82F6` の色差 ΔE = 7.8 — 区別はつくが弱い
**修正案**:
- 非選択を `#9CA3AF`(グレー系)にして明度差で区別 → ΔE = 32
- または非選択のテキストを細字にして色 + ウェイトで区別
---
### Low: ダークモードでセカンダリテキストが沈んでいる
**場所**: `Assets.xcassets/secondaryText.colorset/Contents.json`
**問題**: Dark モードの `#6B7280` は暗い背景 `#1F2937` に対して明度差が小さく読みにくい
**修正案**:
- Dark モードの secondaryText を `#9CA3AF` に変更(明度差 +15%)
| severity | 基準 | 例 |
|---|---|---|
| High | 隣接要素が区別できない (ΔE < 5)、または色がキツすぎて不快 | 同色のタブ、純色の大面積使用 |
| Medium | 区別しにくい (ΔE 5〜10)、トーン不統一、Dark モード破綻 | 似た青の並び、暖色寒色混在 |
| Low | 改善すれば快適になる | 微妙な明度差の不足、パレット未統一 |
| 状況 | 対応 |
|---|---|
| カラー定義が見つからない | "カラー定義が検出できませんでした" と報告 |
| 隣接関係が推定できない | 色の一覧を出して「手動で隣接確認を推奨」 |
| CSS 変数が外部参照で解決不能 | "解決不能" マーク + 手動確認推奨 |
| Agent | 役割 | 起動条件 |
|---|---|---|
css-expert | CSS カラー分析、セレクター隣接解析 | Electron/CSS プロジェクト |
swiftui-macos-designer | SwiftUI ビュー構造・カラー分析 | Swift プロジェクト |
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
プロジェクト監査。「監査して」「audit」「/audit」で発火。設計/UX/品質/テストなどの観点でコードベース全体を監査し、課題をissuesディレクトリに書き出す。実行ログで重複実行を防止。特定の差分・コミットのレビューには使わない(codex-review / cross-review を使う)。
The English summary is being prepared. Showing the original description.
AVFoundation (AVPlayer / AVPlayerLayer / AVPlayerItemVideoOutput / AVAsset) の落とし穴・文書化されていない実装挙動・debugging チェックリストを集約した reference skill。Swift / Objective-C で AVPlayer を使った動画再生 / seek / scrub / frame stepping を実装・debug するときに発火。VLCKit ではなく **AVFoundation 系** の問題に特化。
The English summary is being prepared. Showing the original description.
このセッションで行った変更をコミットする。「コミットして」「commit」「/c」で発火。push はしない/クレデンシャルは混入させない。
The English summary is being prepared. Showing the original description.
ディレクトリ・レイヤーごとに置いた CLAUDE.md と README.md が実体 (コード・コマンド・構成) とずれていないかを点検し、裏の取れた乖離だけを直す。引数で対象のディレクトリを任意に指定できる (省略時は repo 全体)。「CLAUDE.md を refresh して」「README が古くないか見て」「claude-md-refresh」「/claude-md-refresh」で発火。issues/ の更新漏れは issue-writeback / issue-sync の担当で、この skill は扱わない。
The English summary is being prepared. Showing the original description.
一時領域 (/private/tmp の Claude Code の作業場所・$TMPDIR・dotfiles の tmp/) に溜まったものを bin/tmpclean で数え、消す候補を種類ごとに見せて、ユーザーが承認した plan の古くて使用中でないものだけをゴミ箱へ移す (dotfiles の tmp/ は別の承認を取って make clean-tmp で消す)。「/tmp を掃除して」「一時ファイルを片付けて」「TMPDIR が溜まっていないか見て」「cleanup-tmp-dir」で発火。消す前に必ず承認を取る。
The English summary is being prepared. Showing the original description.
Codex が設計・実装を担い、Claude が要件確定・成果物の検証・反復・commit/push を管理する。「codex に書かせて」「codex メインで実装」「codex-drive」で発火。大きめの機能・移植・プロトコル実装向け。余剰トークンを厚く使う運用も選べる。
The English summary is being prepared. Showing the original description.