product-design

プロダクトデザイン

インターフェースの動作を決めたら、誰が構築し、検証するかを振り分けます。適切なインタラクションを選び、スコープと結果を明確にし、ハッピーパス以外の状況も網羅します。

• 該当すること： 意思決定レイヤーです。ブリーフ、仕様書、モックアップ、意図、既存の UI をもとに、インタラクションとコントロールを選び、各アクションの対象、スコープ、結果を明示し、可逆性と、それに伴うセーフガードを決定し、到達可能なすべての状態を列挙し、レジリエンスに関する期待値を定め、タスク完了の要件としてアクセシビリティを求めます。決定を下したうえで、構築、検証、文言の作業を適切な担当先に振り分けます。
• 該当しないこと：
  • その機能への投資価値や、プロダクトへの適合性の判断：対象外です。未解決のプロダクト上の問いとして明示してください。
  • UI の構築やスタイリング、ビジュアルの方向性、カラーパレット、書体：ui-design が担当します。
  • 構築済みの成果物の監査（レンダリング品質、a11y マークアップ、キーボード操作、レイアウト、パフォーマンス、React または Next のコードレベルでの UX を対象としたリリース可否の判定）：ui-design の Audit モードが担当します。
  • コピーの文言、説得表現、AI らしい言い回しの除去：ghostwriter が担当します。
  • モーション、ジェスチャーの物理挙動、詳細なタイポグラフィ：ui-animation、typography-audit が担当します。
  • エージェント型機能が信頼に値するかどうか：ax-audit が担当します。

担当範囲の境界

product-design はアクションの意味、スコープ、可逆性、意見の分かれる状態の選択を担当します。ui-design はそれらの状態を構築し、スタイリングします。ui-animation はタイミング、ジェスチャー、測定可能なモーションを担当します。読み込み状態やエラー状態が定型的に欠けている場合は UI の構築で対応します。コントロールを置き換えるジェスチャーには、物理挙動を決める前に、プロダクト上の判断とアクセシブルな代替手段が必要です。

リクエストモード

対応を始める前に、ユーザーの動詞と成果物からモードを特定し、そのモードのリファレンスを読み込みます。references/rules.md はすべてのモードで読み込みます。すべての指摘にはそこに記載されたルール ID を引用する必要があり、ルール一覧を確認せずに、ある判断を規定するルールはないと結論づけることはできません。

モード	次の依頼があった場合に選択	読み込むファイル（references/rules.md に加えて）
shape（デフォルト）	「フローを設計して」「ここで使うコントロールは何か」「これはどう動作するべきか」「これは適切なパターンか」、UI がまだ確定していないブリーフ	references/product-judgment.md、references/surfaces.md
spec	「適切なインタラクションを仕様化して」「想定される状態を定義して」、構築の前または途中で判断を適用する依頼	references/product-judgment.md、references/surfaces.md、references/naming-and-copy.md。構築は ui-design に振り分けます
review	「このフローがプロダクトとして正しいかレビューして」「この UX の判断のどこに問題があるか」「これは適切なインタラクションか」	references/interface-quality.md
action	「このアクションは何に影響するべきか」「取り消し可能にするべきか」「確認ダイアログは必要か」、または可逆性が未確定の場合	references/naming-and-copy.md。最終的な文言は ghostwriter に振り分けます
harden	「これを堅牢にして」「ここでは何が問題になるか」、エラー、権限、オフライン、期限切れ、破壊的な操作への対応	references/surfaces.md、references/interface-quality.md、references/product-judgment.md

Review モードの対象は成果物ではなく、フローです。 「このコンポーネントを監査して」「UI を確認して」「このページのデザイン QA をして」は、構築済みのマークアップを対象としているため、ui-design の Audit モードが担当します。このスキルの Review モードでは、フローの背後にある判断が適切かを問い、判断レベルの範囲で止めます。

モードは連携します。shape から spec に進み、review から harden に進みます。意図が曖昧な場合は、動詞から判断できる最も限定的なモードを使用します。URL、スクリーンショット、ルート、コンポーネントはスコープを示すものであり、編集を許可するものではありません。

標準をこのスキルではなく利用側のプロジェクトのリンターに含めるべきかどうかは、codebase-architecture の適用範囲の判断基準が担当します。evals/evals.json はユーザーのタスクでは読み込まず、このスキルを変更する人が使う回帰テスト一式です。

ワークフロー

Product design pass:
- [ ] Step 1: Classify the request into one mode
- [ ] Step 2: Locate authority (user constraints, project design system, AGENTS.md)
- [ ] Step 3: Load rules.md plus that mode's reference files
- [ ] Step 4: Write the internal brief (shape, spec, harden); stop and ask if job, outcome, or consequence is unfillable
- [ ] Step 5: Name object, scope, consequence, and reversibility for each action in scope (spec, action, review)
- [ ] Step 6: Enumerate reachable states and check coverage (shape, spec, harden)
- [ ] Step 7: Emit output with a rule ID or labeled coverage gap per finding or decision; route follow-on work to siblings
- [ ] Step 8: List unresolved product decisions

ステップ 5 と 6 はモードごとに適用されます。参照先が異なるためです。純粋な action パスでは列挙する状態マトリックスがなく、shape パスではまだ名前を付けられる構築済みのアクションがありません。

出力の長さはテンプレートではなく、作業内容に応じて決まります。決定事項が 1 つに定まっている場合は短く回答し、そのパスで不要だったセクションは埋めずに省略してください。

決定権限

競合時は、上位から次の順で優先します。

1. ユーザーの明示的な目標と制約。
2. 検証済みのユーザーおよび製品の根拠、ならびにシステムの実際の動作。
3. プロジェクトで正規とされるガイダンス：AGENTS.md または CLAUDE.md、プロジェクトのデザインシステム、ルーティングされた関連スキル。
4. 関連スキルの担当範囲：重複させず、適切なスキルに引き継ぎます。
5. このスキルの基準（以下）。
6. 一般的なインターフェースおよびプラットフォームの規約（WCAG 2.2、NN/g、Apple HIG、Material、GOV.UK）。各ルールで引用されている出典は references/rules.md に記載されています。

依頼が複数の権限範囲にまたがる場合は、担当するスキルを明示して引き継いでください。

製品デザイン基準

5 つの柱。それぞれに references/rules.md のルール ID と、詳細を説明する参照先を示します。

• 適切なインタラクション。 選択肢の形に合わせてコントロールを選び、選択肢を見える状態にして元に戻せるようにします。モーダルよりインラインでの開示を優先し、すべてのジェスチャーに代替コントロールを用意し、一貫性を保てる最小限の介入を選びます。rule/control-matches-cardinality、rule/navigation-vs-action、rule/inline-before-modal、rule/no-nested-modals、rule/gesture-has-control-alternative、rule/smallest-intervention。詳細：references/product-judgment.md。
• アクションの命名と結果。 対象、範囲、結果を明示します。まず取り消し可能かどうかを確定し、その後にパターンを選びます。取り消せないアクションには、レビュー、確認、または内容を明示した確認を設けます。「元に戻す」は実際に可能な場合のみ表示します。rule/name-object-scope-consequence、rule/destructive-names-action、rule/destructive-proportional、rule/irreversible-action-safeguard、rule/undo-only-when-honest、rule/preserve-user-input。詳細：references/naming-and-copy.md。
• 状態の網羅。 値が入力された状態だけでなく、到達可能なすべての状態を設計します。空の状態では対象と最初のアクションを明示し、エラーでは原因を説明して復旧手段を提示し、タイマーではデータを破棄する前に警告します。rule/cover-reachable-states、rule/empty-state-action、rule/error-states-recovery、rule/loading-stable-labels、rule/time-limit-adjustable。詳細：references/surfaces.md。
• レジリエンス。 オーバーフロー、極端なデータ、ローカライズと RTL、オフライン、ネットワーク障害を設計上の状態として扱います。すべてのフェッチ結果をいずれかの状態に反映させます。rule/cover-reachable-states を共有します。これは不利な入力に対して同じ要件を適用するものです。詳細：references/surfaces.md > レジリエンス。構築された UI がこれらの状態を表示するかどうかは、ui-design の監査モードで確認します。
• タスク完了のためのアクセシビリティ。 すべてのコントロールに名前を付けます。主要なフローをキーボードで完了できるようにし、フォーカスを視認可能にします。入力済みの情報を再入力させず、認証では支援を許可し、状態と結果を単にラベル付けするだけでなく理解できるようにします。rule/accessible-name-required、rule/keyboard-complete-flow、rule/no-custom-focus-bypass、rule/no-redundant-entry、rule/auth-allows-assistance。詳細：references/interface-quality.md。マークアップとターゲットサイズの確認は、ui-design の監査モードに引き継ぎます。

レビュー出力

レビューおよび強化モードでは、ユーザーへの影響が大きい順（P0 から P3）に指摘事項を提示します。それぞれに、場所、検証状況、ルール ID、ユーザーへの影響、および担当スキルとともに最小限の具体的な修正を記載してください。指摘事項は意思決定のレベルにとどめ、行単位のコード修正やフレームワークの修正は ui-design の監査モードで扱います。評価基準と指摘事項の形式：references/interface-quality.md > 重大度の評価基準。

注意点

• アーカイブ、リストからの削除、登録解除など、元に戻せる操作で確認ダイアログを表示すると、ユーザーは確認を流し読みするようになります。そのため、本当に重要な確認である完全削除も、同じ反射的なクリックで実行されてしまいます。これは NN/g の「オオカミ少年」効果に関する知見です。操作を実行して、代わりに元に戻す手段を提示します（rule/destructive-proportional）。
• トーストだけを唯一の復旧手段にすること：トーストは約5秒で消え、オブジェクトも失われます。オブジェクトを復元可能な状態に保つ（ゴミ箱、アーカイブ）か、操作を取り消し不可能にして安全策を設けます。そうでなければ、「元に戻す」とは呼ばないでください（rule/undo-only-when-honest、WCAG 2.2.1）。
• ボタンやメニューによる同等の操作手段がないスワイプ削除やドラッグによる並べ替えは、WCAG 2.5.1 および 2.5.7 に明確に違反し、ほかのすべてのユーザーにとっても見つけにくい機能になります。操作の物理的な挙動を ui-animation に任せる前に、代替手段を仕様に記載します（rule/gesture-has-control-alternative）。
• 英語のラベルを3つ固定幅に収めたセグメントコントロール：10文字未満の文字列は翻訳時に200〜300％長くなるため（W3C）、「Day / Week / Month」はドイツ語では折り返されたり、クリップされたりして見づらくなります。仕様で折り返しや縦積みの挙動を決めます。
• フィルター適用後に結果が0件のリストで、「プロジェクトはまだありません。プロジェクトを作成」という空状態を使い回すこと。ユーザーが重複項目を作成してしまいます。検索した項目はフィルターの背後に存在するからです。空状態は3種類あり、それぞれにデザインが必要です（references/surfaces.md）。
• チェックアウトやサインアップで、2つ前の手順で入力した情報（配送先住所の後に請求先住所、アカウント作成後にメールアドレス）を再度尋ねると、WCAG 3.3.7 に違反し、モバイルユーザーが離脱する手順になってしまいます（rule/no-redundant-entry）。
• 判断内容ではなく、1行単位の修正（prop、hook、className）を出力すること。その修正には妥当性を検証するためのレンダリング結果の確認が伴わず、本来伝えるべきプロダクト上の判断も明示されません。ui-design の監査モードに回します。
• もっともらしいルール ID が存在しない場合に引用すること（rule/clear-labels）。引用先がないため、指摘を ui-design の監査結果と照合して重複を除いたり、ルールをたどったりできません。代わりにカバレッジの不足として記録します。

関連スキル

• ui-design：ビジュアルの方向性と、決定したインタラクションのコードへの実装を扱います。監査モードでは、構築済みの結果、レンダリング品質、アクセシビリティのマークアップを確認し、リリース可否を判定します。
• ghostwriter：このスキルが管理する references/rules.md のコピー用ルール ID に基づいて、名前、エラー、空状態や読み込み中の文言を正確に作成します。
• ui-animation：2つの状態の間の遷移（タイミング、イージング、スプリング、ジェスチャーの物理的な挙動）を扱います。このスキルでは、ジェスチャーがコントロールの代わりになるかどうかと、その代替手段を決定し、ui-animation では動きを実装します。
• ax-audit：構築済みのエージェント機能が信頼に値するかどうかを扱います。このスキルでは、機能が最初に何をすべきかを決定します。
• typography-audit：タイポグラフィの詳細を監査します。