菜单
既存画面の UI polish / 複数画面の redesign 統一 / a11y 対応 / CSS 一貫性修正を軽量ループで実装。Council を使わず tsc/lint のみでゲート。1 画面ずつ Read → Edit → 静的チェック → 次へ。「UI polish して」「画面統一して」「a11y 対応」「CSS 統一」「複数画面 redesign」で発動。新規デザインをゼロから生成する場合は外部プラグイン frontend-design を使う。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | ui-polish |
| description | 既存画面の UI polish / 複数画面の redesign 統一 / a11y 対応 / CSS 一貫性修正を軽量ループで実装。Council を使わず tsc/lint のみでゲート。1 画面ずつ Read → Edit → 静的チェック → 次へ。「UI polish して」「画面統一して」「a11y 対応」「CSS 統一」「複数画面 redesign」で発動。新規デザインをゼロから生成する場合は外部プラグイン frontend-design を使う。 |
| argument-hint | <target description (e.g., 5 画面の a11y 対応)> |
| allowed-tools | ["Read","Edit","Glob","Grep","Bash","AskUserQuestion"] |
| effort | low |
既に明確な方針がある UI 実装タスクを、画面/コンポーネント単位で順次適用し 個別に tsc/lint でゲートする。Council やマルチフェーズ計画は使わない。
| 使う | 使わない |
|---|---|
| 複数画面の統一的 polish（同じデザインシステム適用） | 新機能開発 → /o-m-cc:sisyphus |
| a11y 対応（focus-visible, aria, キーボードナビ） | 要件が曖昧 → /o-m-cc:deep-interview |
| CSS 一貫性修正・デザイントークン適用 | パフォーマンス計測が必要 → /o-m-cc:experiment |
| 既存機能を壊さないリファクタ | 新規デザインをゼロから生成 → 外部プラグイン frontend-design |
| 単発 1 ファイル修正 → 普通の Edit |
frontend-design との棲み分け: このスキルは 既存 UI の統一・修正 に集中する。
ページ/コンポーネントを一から作る要求が来たら Claude は frontend-design へ誘導する。
AskUserQuestion で対象画面/ファイル列と方針を確定する。
$ARGUMENTS で明示されていればそれを候補の出発点にするAskUserQuestion が使えない環境で $ARGUMENTS から対象と方針が推測不能な場合は
エラー停止（推測で盲目的に編集しない）。
各対象について順次:
.me-field のような独自 focus スタイル等、
既存コンポーネントの意図は尊重するbin/lint が存在 → それを実行（プロジェクト標準）npm run lint（package.json の scripts にあれば）npx tsc --noEmit で型チェックAskUserQuestion で判断を委ねる（「無視して次」「ここで止める」等）次の対象に進む前に、前の対象の lint が通過していること。通っていないのに 積み上げると後でまとめて壊れたときに切り分け不能になる。
全対象完了後、変更内容の表を出力:
| 対象ファイル | 変更概要 | lint |
|---|---|---|
| src/components/Foo.tsx | focus-visible 追加 | ✅ |
| src/app/globals.css | トークン統一 | ✅ |
コミットは呼び出し元（ユーザー or 上位ワークフロー）に委ねる。ui-polish は commit しない（短命な変更の連続なので、最終確認はユーザー判断）。
bin/lint が存在すれば必ずそれを使う。プロジェクト標準を優先しないと CI との乖離が起きるfrontend-design（外部プラグイン）にハンドオフ。このスキルは既存の統一・修正に徹する.me-field のような用途別 focus 設定は保護。グローバル :focus-visible はそれらを除外する outline ルールで入れるStep 1 の対象 + 方針確認から開始してください。
新機能を実装まで一気通貫で走らせる action skill。Agent Teams で要件・設計・タスク分解・実装・quality-gate を自動実行し、コードがコミット可能な状態になるまで止まらない（Sisyphus Loop）。auto mode でも planning ではなく action として積極発動する。「実装して」「作って」「機能を追加して」「新機能を作りたい」「要件から実装まで一気に」「計画して」「この機能を実装したい」で発動。
完了宣言の前にエビデンスを収集・確認する。証拠なき成功宣言は不正。「完了前チェック」「本当に動く？」「確認して」「検証して」「コミット前に確認」で発動。実装完了時、バグ修正後、テスト通過を宣言する前に使う。
要件が曖昧なとき、ソクラテス式に1問ずつ質問して要件を掘り下げる。十分に明確になったら discovery-council にハンドオフ。「要件が曖昧」「何を作ればいいか」「掘り下げて」「インタビューして」で発動。※ 完成した plan/design を詰問するなら grill、非対話で一括批判するなら critic。
完成した plan/design を対話で容赦なく詰問し、実装前に穴を潰す。決定木を1枝ずつ降り、各質問に推奨回答を添える。コードで答えが出る点は聞かず自分で調べて埋める。「grill して」「叩いて」「この設計で大丈夫?」「plan を詰めて」「設計を対話レビュー」で発動。※ ゼロから要件を掘り下げるなら deep-interview、非対話で一括批判レポートなら critic。
backlog（atoms/pipeline/outputs）と skill ヘルス（usage/duration/unused）を統合分析し 1 レポートで提示する。kawai 氏型 analytics ループの起点。「次に何やる？」「atom 整理」「放置案件」「stale」「振り返り」「retro」「skill 使用統計」「unused skill」「atom-suggest」で発動。
designer エージェントによるアーキテクチャ設計。requirements.md を基に design.md を作成。「設計して」「アーキテクチャ設計して」「アーキテクチャを考えて」「設計書を作って」で発動。