make-interfaces-feel-better
デザインエンジニアリング原則に基づいて、インターフェースを洗練された印象にするための設計方法です。UIコンポーネント構築、フロントエンドコード確認、アニメーション実装、ホバー状態、影、枠線、タイポグラフィ、マイクロインタラクション、出入りアニメーションなどの視覚的な詳細作業の際に使用します。UI磨き、デザイン細部、使い心地の向上、不自然さの修正、アニメーション遅延、角丸、光学的配置、フォント最適化、表形式の数字、画像枠線、ボックス影といった場面で活用できます。
description の原文を見る
Design engineering principles for making interfaces feel polished. Use when building UI components, reviewing frontend code, implementing animations, hover states, shadows, borders, typography, micro-interactions, enter/exit animations, or any visual detail work. Triggers on UI polish, design details, "make it feel better", "feels off", stagger animations, border radius, optical alignment, font smoothing, tabular numbers, image outlines, box shadows.
SKILL.md 本文
インターフェースをより良く見せるディテール
優れたインターフェースは、単一の要素から生まれることはほとんどありません。通常は、多くの小さな詳細が積み重なって、優れた体験になります。UI コードを構築またはレビューするときに、これらの原則を適用してください。
クイックリファレンス
| カテゴリ | 使用する場面 |
|---|---|
Typography | テキストの折り返し、フォントスムージング、表形式の数字 |
Surfaces | ボーダーラディウス、光学的な配置、シャドウ、画像のアウトライン、ヒットエリア |
Animations | 割り込み可能なアニメーション、入場・退場トランジション、アイコンアニメーション、押下時スケーリング |
Performance | トランジション特異性、will-change の使用 |
コア原則
1. 同心ボーダーラディウス
外側のラディウス = 内側のラディウス + パディング。ネストされた要素のラディウスが一致していないのは、インターフェースが違和感を感じさせる最も一般的な原因です。
2. 幾何学的配置より光学的配置
幾何学的
...
詳細情報
- 作者
- jakubkrehel
- ライセンス
- unknown
- 最終更新
- 不明
Source: https://github.com/jakubkrehel/make-interfaces-feel-better / ライセンス: unknown
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理（非同期ジェネレータを含む）、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。