設計系スキルの入口。「AIっぽい」「テンプレート感」「もっと洗練させたい」「管理画面のレビュー」など画面設計の相談を受けたら、業務構造の診断(ux-design §0-1〜§13-1)と見た目の素材(jp-web-design)のどれをいつ読むかをここで決める。UIの新規設計・リニューアル・レビューの着手時に必ず最初に開く。
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
AIっぽいUIは、UI部品の平均値を並べた画面。AIっぽくないUIは、業務の構造がそのまま画面の構造になっている。
「AIっぽさ」は色や角丸ではなく、設計判断(何を主役にし・何を隠し・どの操作を一手で終わらせるか)が見えないことの問題。本スキルはその判断を下すための問いを持たず、設計の実体 Skill ux-design と 見た目の素材 Skill jp-web-design のどこを読むかだけを決める。
design-judgment(入口) → ux-design(設計の実体: 業務構造の診断・体験の規律・検収) → jp-web-design(日本語UIの素材: 色(標準カラー既定 / Pop)・タイポ・部品)。逆方向には戻らない。
| 状況 | 読む場所 |
|---|---|
| 新規画面・リニューアルの着手 | ux-design §0(3点)と §0-1(業務構造の発見)で中心対象・最頻操作を確定 → §2-3(主役と隠すもの)→ jp-web-design 起動プロトコル |
| 「AIっぽい」「テンプレート感」「無機質」と指摘された | ux-design §13-1(装飾除去テスト)で崩れた項目を特定 → §0-1 / §2-3 に戻って構造から直す。色・トークンの調整から入らない |
| 「Appleのように」「触り心地」「洗練」を求められた | ux-design §11-1(触りたさの5要素)と references/apple-polish.md |
| 一覧・単票・分析など画面の型で迷う | ux-design references/structure-diagnosis-by-domain.md |
| ダッシュボード・管理画面のレビュー | ux-design §9(ホーム)→ §13(検収)→ jp-web-design references/acceptance-checklist.md |
| 「見づらい・ダサい」の改善依頼 | jp-web-design references/information-design.md §1 で症状特定 → §8 のリライト手順 |
| フォーム・一括操作・エラー回復の実装 | ux-design §4 / §5 / §7 と各 references。見た目の部品は jp-web-design references/components.md |
ux-design/assets/structure-worksheet.md を複製して1行ずつ残す。言葉にできない項目は、まだ判断していないという合図。まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。
run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。
確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。
生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。
Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。