デザインのスキル

Fix the psychologically significant moment, not the logically significant metric — Rory Sutherland on experience. Use when the outcome is fine but the journey feels bad: complaints about waiting, anxiety, uncertainty, or 'it's technically fast/cheap/correct but people still hate it'; when the user asks 'how do we reduce complaints', 'how do we make waiting/onboarding/checkout feel better', 'people are anxious during X', or is about to spend big to shave a number (wait time, load time, steps) when the real pain is how the moment feels. Covers uncertainty reduction, idle vs occupied waiting, and the peak-end rule. Inspired by Rory Sutherland's *Alchemy*. Routed to from psycho-logic. 日本語の相談（「待ち時間のクレームが多い」「手続きの途中で離脱される」「お客様を不安にさせている」）にも使う。中文咨询（“等待时间投诉多”“办理中途流失”“让客户感到不安”）也适用。

日本語の概要は準備中です。原文の説明を表示しています。

Simulate PlayMode EventSystem UI mouse actions using top-left Game View coordinates. Use for UI clicks, long-presses, or drags from annotated screenshots.

日本語の概要は準備中です。原文の説明を表示しています。

Interact with UI Toolkit (UXML/USS) runtime UI in PlayMode. Use INSTEAD OF uloop-simulate-mouse-ui / uloop-simulate-mouse-input whenever the target UI is UI Toolkit — those tools only reach uGUI and report 'no UI element hit' or silently do nothing on UI Toolkit panels.

日本語の概要は準備中です。原文の説明を表示しています。

Capture Unity Editor windows or Game View rendering as PNG. Use for visual checks, debugging, documentation, or annotated UI element coordinates.

日本語の概要は準備中です。原文の説明を表示しています。

Simulate Mouse.current input in PlayMode through Unity Input System. Use for gameplay clicks, mouse delta, or scroll; use simulate-mouse-ui for EventSystem UI elements.

日本語の概要は準備中です。原文の説明を表示しています。

Unity 6 UI development guide. Use when building user interfaces, menus, HUD, buttons, or any UI elements. Covers UI Toolkit (recommended for new projects — USS, UXML, UI Builder, data binding), uGUI/Canvas (legacy runtime UI), and IMGUI. Based on Unity 6.3 LTS documentation.

日本語の概要は準備中です。原文の説明を表示しています。

デザイン（Figma MCP出力・HTML/CSS・デザイン仕様）からUI Toolkit用UXML/USSを生成し、Unityへのインポート・シーン配置・コンパイル・スクショ検証・ゲームロジック結線検証まで自動で行う。「この画面をUnityに取り込んで」「UXML/USSにして」で使う。

ソースドキュメント（議事録・提案書・ディスカッション資料等）からスライドのページ構成をMarkdownで設計するスキル。各スライドをタイトル・メッセージ・ボディの3層構造で定義し、1スライド1メッセージを厳守する。情報量が多い箇所はバーバラ・ミントのピラミッド構造でサマリ→詳細に分割する。「スライド構成を設計して」「ページ構成を考えて」「スライドの骨子を作って」「プレゼンの構成を設計して」「スライド構成をMDで作って」などのリクエスト時に使用。スライド制作の前段階として機能し、出力MDをスライド制作スキルに渡してスライド化する。

修正完了後に agent-review-kit でレビューHTMLを生成し、ユーザーがブラウザで書いた差分コメントを Codex または Claude Code の同一セッションで受け取り、回答・修正・resolve を未解決0件まで繰り返すレビューループ。AIレビューの指摘を add-comment でブラウザ上のコメントとして表示し、ユーザーが返信した指摘だけ修正する「AIレビューモード」も含む。実装プラン・設計書などの任意HTMLを publish-html でレンダリング済みのまま表示し、要素クリック・テキスト範囲でコメントを受け取る「HTMLレビューモード」も含む。他のレビュースキルの結果の出力先として agent-review-kit が指定された場合も、このスキルを読んで AI レビューモードの手順に従うこと。Use when the user wants to review changes in a browser (GitHub-like diff review), review a rendered HTML doc (plan/design doc) in a browser, iterate on fixes with inline comments, or display AI review findings as browser comments (output target: agent-review-kit).

日本語のUI文言（ボタン・見出し・ラベル・入力欄の説明・空状態・エラー・確認ダイアログ・完了通知・チャットbotの応答文）を書く・直すときの規則。画面やbotがユーザーに見せる日本語を新しく書く時、既存の文言を見直す・統一する時、英語のまま残った表示を日本語にする時、サーバーのエラーメッセージを画面に出す経路を作る時に使用。公開されている日本語UIガイドライン（SmartHR・デジタル庁・Microsoft・Apple・公用文）の一致点を規則にし、食い違う点は採否と理由を定めてある。境界: 人に宛てた文章（PR本文・メッセージ・ドキュメント）は ukwhatn-writing、画面に何を出すかと提示前の完了基準は context/ui-artifact-standards.md、ナビゲーション・重ね方・通知の型とレイアウトは designing-ui、コードの実装原則は writing-code。

要件が確定した大きな機能開発（epic）を、並列調査と全体設計判断を経て PR 構成と実装セッション向け計画書に落とし込む。PR を分けるのは AGENTS.md の分割条件に当たる箇所だけ。「実装計画を立てて」「PR 分割して」「計画書を作って」「タスク分割をして」等の依頼時、複数日・複数セッションにわたる実装の着手前に使用。計画確定後に「PR-X を実装して」と担当を指定された実装セッションでも使う。境界: 要件定義は design-feature、1セッションで調査から実装まで進められる規模は Phase 0-5 を直接適用、PR の作成そのものは create-draft-pr。

Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI, including chat interfaces. Provides project context, component docs, and usage examples. Applies when working with shadcn/ui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for "shadcn init", "create an app with --preset", "switch to --preset", and for building a design system or applying a DESIGN.md or brand spec to shadcn/ui.

日本語の概要は準備中です。原文の説明を表示しています。

画面の設計判断（ナビゲーション・重ね方・通知と空状態と読み込み・外枠とトークンと状態表現）の型を決定表で選び、アプリ内の全画面で揃える。画面・ページ・レイアウト・ナビゲーション・ダイアログ・コンポーネントを新しく作る・作り直す時、モックやダッシュボードを作る時、サイドバー・タブ・モーダル・シート・toast・バナー・空状態のどれを使うか決める時に使用。PJ に components.json があれば shadcn の部品とトークンへの対応も扱う。主要なデザインシステム（Material・HIG・Carbon・Primer・Atlassian・Fluent・GOV.UK・NN/g・WAI-ARIA APG・WCAG）の一致点を規則にし、食い違いの採否を定めてある。境界: 画面の文言は writing-ui-text、画面に何を出すかと提示前の完了基準は context/ui-artifact-standards.md、コードの実装原則は writing-code、shadcn 部品の API と組み立ては shadcn。

抽象的な要件・事業側の要求を深掘りし、既存実装との整合を確認して実装マスタとシステム要件書を作成する。「こういう機能を作りたい」「この要求を満たす機能を設計して」等の抽象要件の提示時、既存機能の拡張や Phase 分割の要件定義開始時、/design-feature 実行時に使用。境界: 要件確定後の実装計画書・PR 分割と実装進行は plan-feature-prs。

ローカルでニュースを生成しブラウザで動作確認する。fetch_news.py実行→http.server起動→index.html/archivesを確認→生成物の差分を戻す。「ローカルで確認」「プレビューして」「動作確認」と言われたら使う。UI変更時は必須。

Write the merged Pencil design reference back into a UI implementation Issue's description. Takes the Issue number as argument, resolves the merged design PR on the `cc-ui-design-<Issue number>` branch, collects the `.pen` and snapshot paths it added, and appends (or replaces) the `## UIデザイン` section at the end of the Issue body using a lost-update-safe edit.

日本語の概要は準備中です。原文の説明を表示しています。

Create or update the Pencil (`.pen`) design for a UI implementation Issue before any code is written, then open a design-only PR. Takes the Issue number as argument, delegates `.pen` edits to the pencil-design-updater agent, pushes `.pen` and snapshot PNGs on the fixed `cc-ui-design-<Issue number>` branch, and opens a PR referencing the Issue with `Refs #<N>` (never a closing keyword).

日本語の概要は準備中です。原文の説明を表示しています。

pen.dev CLI（`pencil` / `pen`コマンド）だけを使って.penファイル（pen.devで作成されたデザインファイル）を`execute`による決定論的な編集操作で修正・更新・新規作成するスキル。.penファイルの編集、ボタン追加、レイアウト変更、UIデザインの調整、pen.devデザインの更新、新しい.penデザインの作成などの依頼で必ず使用する。有料の`--prompt`（エージェントモード）は使わず、編集・新規作成はすべてインタラクティブモード（`pencil interactive`）の`execute`（`Insert` / `Update` / `Delete` など）で行い、最後に`save()`する。`Insert` / `Update` に渡すNodeデータは`references/pen-format.md`の.penフォーマット定義に従う。既存ファイルは`-i`と`-o`に同一パスを指定して上書き、新規作成は`-i`を省略して`-o`に新しいパスを指定する。編集・作成後は「**編集・作成したコンポーネントのNodeだけ**」を`execute`の`Export` / `TakeScreenshot`でPNG出力し、`.pen`と同階層の`snapshots/`ディレクトリに保存する。pen.dev MCPには依存せず`pencil`コマンドのみで完結する。.penファイルのgitコンフリクト解消・破損復旧は本スキルではなく`resolve-pencil-conflict`スキルの担当。

pen.dev CLI（`pencil` / `pen`コマンド）だけを使って、.penファイル（pen.devで作成されたデザインファイル）の中のNodeのデザインデータ（属性・構造）とスクリーンショット画像を読み取り専用で取得するスキル。Node ID指定に加え、名前の正規表現（例: 「ヘッダー」「.*Button」）、Nodeタイプ（frame / text / image など）、再利用可能コンポーネント、特定Node配下、ドキュメント全体のトップレベルなど、**ID以外の指定方法**にも対応する。ユーザーが「.penのこのNodeの中身を見せて」「特定コンポーネントのデザインデータを取り出して」「Nodeのスクリーンショットだけ欲しい」「ヘッダーの構造を確認したい」「ボタンのスタイルをコピーしたい」「再利用可能コンポーネント一覧を見せて」「ドキュメント全体の構造を覗きたい」「全てのテキストNodeを取得して」のように.pen内の要素の調査・参照・確認・抜き出しを依頼した場合に必ずこのスキルを使う。インタラクティブモード（`pencil interactive`）で `execute` の `Get` / `Print`（読み取り専用関数のみ）を使ってNode属性を取得し、同じ `execute` の `Export` / `TakeScreenshot` で画像を`.pen`と同階層の`snapshots/`にPNG出力する。編集はしない（`save()` も変更系関数も呼ばない）ため、対象ファイルは絶対に書き換わらない。pen.dev MCPには依存せず`pencil`コマンドのみで完結。

gitコンフリクト状態になった.penファイル（Pencilで作成されたデザインファイル）を、Pencil CLI（`pencil`コマンド）とgitだけで解消するスキル。.penは平文JSONだがテキストマージするとNode IDの重複・参照切れ・JSON構文の破損を起こすため、コンフリクトマーカーの手編集や`git mergetool`は絶対に使わず、「片側採用 → もう一方の変更をPencilで再適用」のフローで解消する。ユーザーが.penファイルのコンフリクト解消、rebase/merge中に`UU`/`AA`状態になった.penの解消、テキストマージで破損した.penの復旧などを依頼した場合に必ずこのスキルを使用する。通常の.penの編集・新規作成は`edit-pencil-design`スキル、PR全体のコンフリクト解消フロー（rebase起点・force-push）は`resolve-pr-conflict`スキルの担当。

直近N日（デフォルト1日）にマージされた `cc-ui-design` ラベル付きPR（UIデザインPR）から確定したビジュアルアイデンティティ（カラー・タイポグラフィ・スペーシング・コンポーネント）をリポジトリルートの `DESIGN.md`（google-labs-code/design.md フォーマット）へ集約・更新し、`design.md` CLI の lint を通してから commit-push + create-pr でPRを作成する（`cc-triage-scope` ラベル + 自分自身をAssignee）。`DESIGN.md` は pencil-design-updater がデザイン時の前提として読み込む。

実装前に参照する設計原則。理解容易性 = 読み手の思考量の少なさを基準に、AI が作りがちな失敗4パターン（引数・依存5個以上、コマンド層肥大・ドメイン貧血症、ポリモーフィズム機会の見逃し、トリッキーな実装）と、実装後セルフチェックの7観点（名称・役割・参照・状態・面積・階層・秩序）を言語化。Use when starting any implementation task, when user says '設計原則', 'design principles', or before writing new entities/commands/repositories.

多分野の専門家を動的に選定し、構造化された議論で多角的な評価・提言をまとめる。 「専門家に聞きたい」「レビューして」「多角的に評価して」「議論して」等で使用。 Webサイト、コード、事業戦略、デザイン、組織設計等あらゆるドメインに対応。

対話または既存トークンファイル（W3C DTCG / CSS variables など）をもとに、プロダクトに合った DESIGN.md を生成する。AIがつくるUIに一貫性を。