Communitygithub.com

ist-h-i/ui-ux-design

UI構成、ビジュアル仕上げ、タスクのユーザビリティ、およびインタラクションのエビデンスを、選択された配信ワークフローへの補足として形作ります。

ui-ux-design とは?

このスキルは、UIデザイン、実装、レビューを、ユーザーの証拠に基づいた目標、視覚的階層と仕上がり、タスクのユーザビリティ、インタラクションのセマンティクス、結果の認識、復旧可能な状態に制約するためのものです。これはライフサイクル全体の置き換えやビジュアルデザインシステムではなく、あくまで実行時の補足として機能します。主にClaude CodeやCursorなどのAIエージェントが、画面、フォーム、インタラクション状態、ユーザーアクションの取り消し可能性、エラー状態などを扱うタスクで使用されます。このスキルは、ユーザーの証拠に基づいて設計原則とパターンを選択し、具体的な構成、動作の仕様化、障害の境界設定を行うプロセスを提供します。最終的には、現在のタスクの決定記録に補足情報を出力し、既存のワークフローを変更することなく、UIに関する意思決定を明確化・具体化します。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/ist-h-i/agent-spectrum-kernel/tree/HEAD/skills/ui-ux-design

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

UI/UX デザインハーネス

目的

UIの設計、実装、レビューを、ユーザーの証拠に基づいた目標、視覚的階層と仕上げ、タスクのユーザビリティ、インタラクションのセマンティクス、結果の認識、復旧可能な状態に制約します。これは実行時の補足であり、ライフサイクルの置き換えやビジュアルデザインシステムではありません。

最小限の該当サブセットを使用してください。タスクが証拠としないペルソナ、ビジネス上の優先順位、デバイスの想定、復旧の保証、またはインタラクションの振る舞いを発明しないでください。

使用するタイミング

このスキルは、汎用的な配信ワークフローが選択され、タスクがユーザー向けインターフェースを変更またはレビューし、以下のシグナルのうち1つ以上を含む場合にのみ使用します。

  • 画面、フォーム、ナビゲーションフロー、選択、または主要なアクション
  • フォーカス、選択、無効、ローディング、成功、エラー、完了、またはその他のインタラクション状態
  • 結果を伴う、または元に戻せるユーザーアクション
  • 部分的なデータ/レンダリングの失敗、古いまたは欠落しているデータ、再試行、または復旧動作
  • タスクの完了やエラー回復に影響を与えるUIの表現

非UIの作業、純粋に機械が消費する出力、またはすべてのUX問題を読み込む理由としては使用しないでください。プロジェクト固有のブランディング、ユーザー、用語、クリティカルフロー、ビジネスルールはプロジェクトコンテキストのままです。

プロセス

  1. 証拠にアンカーする。 既知のユーザーゴール、使用コンテキスト、最初に気づくべき情報、アクションの優先順位、完了/次のアクション、制約を特定します。その目的に応じて密度と構成を選択します。比較ワークスペースと製品紹介では異なる処理が必要です。既存の契約はインプットであり、品質の上限ではありません。観察された弱点をスコープ内で再検討してください。ペルソナやワークフローを発明せず、結果に依存する欠落した事実に依存する決定のみを停止します。
  2. 該当する原則とパターンを選択する。 references/principles.md、references/decision-patterns.md、references/anti-patterns.md の該当セクションのみを読みます。なぜそれらが適用されるかを記録します。例はエビデンスのプロンプトとして扱い、グローバルな禁止事項として扱わないでください。
  3. 構成を具体的にする。 グループ化、順序、テキスト階層と折り返し、配置アンカー、間隔、イメージとコントロールの関係をタスクに結び付けます。説明を追加する前に明確な構造/状態を優先し、必要な意味とアクセシブルなラベルを保持します。日本語の場合、ラベル、ターゲット/結果の表現、フィードバックを、文法だけでなく、表示された位置と状態で判断します。以下の発見ルールに従い、利用可能な japanese-expression 機能を使用します。
  4. 動作を指定する。 該当するアフォーダンス/シグニファイア、状態セマンティクス、即時フィードバック、トランジション、フォーカス/現在の状態、継続、同等のインタラクションパスを定義します。該当しない懸念事項は明示的にマークし、ホバー、ドラッグ、ジェスチャー、モーションの動作を作り出さないでください。
  5. 結果クラスを分離する。 コミット前のキャンセル、完了した可逆的な変更後の元に戻す、コミットされた変更後の補償アクションを区別します。元に戻せない、または実質的に結果を伴うアクションについては、コミット前にターゲット、スコープ、結果、復旧限界を表示します。リスクの低い可逆的なアクションに一律の確認を追加しないでください。
  6. 障害を境界付ける。 正常、認可済み、意味的に有効な領域とユーザー入力を、独立した領域が失敗した場合でも使用可能に保ちます。解決されていない障害は影響を受ける領域に表示したままにし、再試行をスコープ化し、再試行の結果を検証します。ローディング、正当な空、欠落、古い、部分、完了の状態を区別します。欠落データをゼロで埋めたり、前提条件の真実が不完全な派生アクションを公開したりしないでください。認可、セキュリティ、一貫性、依存関係のセマンティクスがそれを必要とする場合にのみブロックを拡大します。
  7. 実際のレンダリングを調整および検証する。 実装中は、コントロールを微調整する前に代表的な画面全体を検査し、その後に関連するコンポーネントの詳細、狭いレイアウトと状態を独立したレビューの前に調整します。ビジュアルの仕上がり、タスクのユーザビリティ、機能的な動作を別々に判断します。動作するクリック、等しいCSS値、オーバーフローなしは仕上がりを確立しません。該当するトランジション、キーボード/フォーカス、実際の元に戻す、コミット前のキャンセル、保持された入力、スコープ化された再試行を実行します。スクリーンショットは静的な外観をサポートしますが、復旧や状態の復元はサポートしません。references/ui-capability-contract.md の観察とハンドオフルールを使用します。
  8. 利用可能なUI機能に接続する。 契約のみ、既存契約のビルド、直接UIリクエストについては references/ui-capability-contract.md に従います。ここで原則の所有権を維持し、アクティブな環境から外部機能の所有者を解決し、契約から実装、証拠へのリンクを保持します。機能またはランタイムのギャップは、影響を受ける依存作業のみを停止し、レビュー完了としてカウントされることはありません。
  9. 制約を選択されたワークフローに戻す。 requirement-grill、grill-design、controlled-implementation、test-first-verification、レビューゲート、最終マージゲートはそれぞれの責任を保持します。この補足はUIの意思決定を絞り込みますが、それだけで実装や承認を許可するものではありません。

出力

現在のタスクの決定記録に、境界付けられた補足を出力します。ローカルな調整の場合は、変更された決定と影響を受ける証拠のみを記録し、新しいJSONコントラクトやテンプレートの入力を要求しないでください。無関係なフィールドは省略するか、not_applicable: <理由> を使用し、推測的にフィールドに入力しないでください。

UX補足:
  user_context:
    user_goal:
    usage_context:
    known_constraints:
    capability_or_environment_considerations:
  task_model:
    page_or_flow_goal:
    primary_action:
    completion_state:
    next_action:
  information_model:
    required_information:
    secondary_information:
    omit:
    language_required_for_clarity:
  interaction_model:
    affordances_and_signifiers:
    state_semantics:
    action_feedback:
    transition_behavior:
    consistency_expectations:
    direct_manipulation:
    equivalent_interaction_paths:
  inclusion_constraints:
    single_cue_dependencies_to_avoid:
    error_prevention:
    recovery_paths:
    input_and_effort_constraints:
  resilience_and_consequences:
    action_reversibility_and_limits:
    pre_commit_consequences:
    failure_boundaries_and_dependencies:
    safe_remaining_content_and_actions:
    partial_failure_and_freshness_feedback:
    scoped_retry_and_recovery_refs:
    blocking_conditions:
  applicable_patterns:
  anti_patterns:
  implementation_constraints:
  verification_scenarios:
  stop_conditions:

各検証シナリオは、検査された状態と観察可能な関係に名前を付けます。インタラクションについては、アクション/入力、期待される可視および基礎となる状態、該当する復旧/継続結果を追加します。別のスキーマを作成するのではなく、設計上の決定は既存の情報モデルと実装制約に留めます。

終了基準

  • 補足は、現在の証拠にUIシグナルが含まれているためにのみ接続されています。
  • ユーザー、製品、ブランド、ビジネスの前提は、情報源が明らかであるか、不明とマークされています。
  • 主要なタスクと次のアクションが、必要なセマンティクスを削除せずに明確になっています。
  • レンダリングされたUIの判断について、構成とコンポーネントの仕上がりには、機能チェックとは異なるレンダリングされた証拠があります。コントラクトのみの作業では、実際の画面承認を主張せずに観察基準を指定します。合格したコントラクトは、観察された粗さを却下しません。
  • 動的な主張には、スクリーンショットのみの証明ではなく、インタラクティブ/状態の証拠要件があります。
  • 可逆的、不可逆的、部分的な障害、および基礎的なブロック動作が、該当する場合に区別されています。
  • 正常な状態とユーザー入力は、独立した障害と再試行にわたって保持されます。
  • 汎用ワークフローと最終レビュー権限は変更されません。

関連スキル