既存画面の UI polish / 複数画面の redesign 統一 / a11y 対応 / CSS 一貫性修正を軽量ループで実装。Council を使わず tsc/lint のみでゲート。1 画面ずつ Read → Edit → 静的チェック → 次へ。
「UI polish して」「画面統一して」「a11y 対応」「CSS 統一」「複数画面 redesign」で発動。新規デザインをゼロから生成する場合は外部プラグイン frontend-design を使う。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
既に明確な方針がある 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 の対象 + 方針確認から開始してください。
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.
backlog（atoms/pipeline/outputs）と skill ヘルス（usage/duration/unused）を統合分析し 1 レポートで提示する。kawai 氏型 analytics ループの起点。「次に何やる？」「atom 整理」「放置案件」「stale」「振り返り」「retro」「skill 使用統計」「unused skill」「atom-suggest」で発動。
The English summary is being prepared. Showing the original description.
要件が曖昧なとき、ソクラテス式に1問ずつ質問して要件を掘り下げる。十分に明確になったら discovery-council にハンドオフ。「要件が曖昧」「何を作ればいいか」「掘り下げて」「インタビューして」で発動。※ 完成した plan/design を詰問するなら grill、非対話で一括批判するなら critic。
The English summary is being prepared. Showing the original description.
designer エージェントによるアーキテクチャ設計。requirements.md を基に design.md を作成。「設計して」「アーキテクチャ設計して」「アーキテクチャを考えて」「設計書を作って」で発動。
The English summary is being prepared. Showing the original description.
3エージェント（researcher, analyst, scout）による並列要件分析 Council。peer-to-peer で相互検証し requirements.md を確定。「要件を整理して」「要件定義して」「現状分析して」「要件をまとめて」で発動。
The English summary is being prepared. Showing the original description.
技術記事の並列レビュー Council。anti-ai-slop / fact-checker / narrative-critic / reader-advocate を並列 spawn、severity 付き findings を最大3ラウンドで収束。Zenn などのドラフト完成後に使う。「記事レビュー」「editorial swarm」「編集会議」「記事推敲」「記事添削」で発動。
The English summary is being prepared. Showing the original description.
スキルの自己進化。auto-memory と実行履歴から学びを抽出し、各スキルの Gotchas セクションに自動追記する。セッション終了前、定期的な改善サイクル、問題に遭遇した後に使う。「スキルを進化させて」「学びを反映して」「Gotchas を更新」「evolve」で発動。
The English summary is being prepared. Showing the original description.