stylekit

StyleKit

StyleKit を使用すると、フロントエンド UI に認識可能な視覚的方向性を与えることができます。まずユーザーの目標と対象プロジェクトの既存構造から始めます。スタイル仕様はデザインを導きますが、製品上の意思決定を置き換えるものではありません。

インストール済みのコピーから始める

<skill-root> はこのファイルを含むディレクトリであり、対象プロジェクトの scripts/ ディレクトリではありません。スクリプトには Python 3.10+ が必要です。プレースホルダーは実際のパスに置き換え、パスは引用符で囲んだままにしてください。タスクの成果物は新しいタスク固有のディレクトリ（以下の <work-dir>）に保存してください。別のタスクの仕様ファイルを再利用しないでください。

タグやコミットを固定したインストールの場合、最初のチェックの前に更新を無効化してください。それ以外の場合は次を実行します:

python3 "<skill-root>/scripts/update-skill.py" --auto

UPDATED の場合は、このファイルを再度読み込んでください。その他のステータスの場合は、インストール済みの手順を続行します。オフラインチェックは作業を妨げません。更新は GitHub の main を最大 24 時間に 1 回追跡し、管理対象ファイルにローカルの変更やパスの衝突がある場合は更新全体をスキップします。ピン留め、制御、移行、復旧については updates を参照してください。チェックを通過させるためにローカルの保護を削除しないでください。

実際のタスクをルーティングする

リクエスト	アプローチ
新しい UI を構築する	方向性を選択し、その仕様を読み込み、実際のコンテンツと状態を実装します。
既存の UI を再スタイリングまたは修正する	動作、ルーティング、データを保持し、関連する視覚的決定を変更します。
ライブラリを比較または推薦する	プラットフォームを特定し、公式ソースを用いて適切な候補を比較します。要求された場合にのみ実装します。
一貫性をレビューする	既存の結果を保存された仕様と照らし合わせて検査し、具体的な所見を報告します。
アセットまたはテンプレートを取得する	assets に従い、返された正確な kind/id、可用性、ライセンスを使用します。

モバイル画面、レスポンシブなインタラクション、または ChunUI のようなライブラリについては、mobile UI を参照してください。コンポーネントを選択する前に、Web/H5、React Native/Expo、SwiftUI、または Flutter のいずれかを確定してください。モバイルに見えるブラウザページも、依然として Web 実装です。

理解して選択する

対象アプリを検査し、インストール済みのプリミティブを再利用してください。スタックが不明確な場合:

python3 "<skill-root>/scripts/detect-project.py" "<project-root>"

検出は証拠であり、互換性の保証ではありません。依存関係は宣言された範囲です。バージョンやワークスペースの境界が重要となる場合は、ロックファイルとアプリのサブディレクトリを検査してください。提案されたライブラリに合わせるためにフレームワークを移行しないでください。

明示的なスタイルがある場合は、その正確なスラッグを使用してください。それ以外の場合は検索し、ユーザーのコンテキストから適した方向性を選択してください。未解決の選択が結果を大きく変える場合にのみ尋ねてください。ライブラリの推薦のみでは、スタイル仕様の取得は必要ありません。

python3 "<skill-root>/scripts/fetch-style.py" --search "frosted glass"
python3 "<skill-root>/scripts/fetch-style.py" "<slug>" --json > "<work-dir>/spec.json"

実装と評価には同じ保存済み仕様を使用してください。_stylekitSource.degraded は、厳選された lint ルールを欠く可能性のあるレガシーデータを示します。その制限を説明してください。取得に失敗した場合は、特定済みの保存済み仕様を再利用するか、現在のカタログを検証できなかったことを述べてください。成功した取得、スラッグ、ルールを捏造しないでください。

保存済みの CLI/API/MCP 入力またはローカル API については、spec sources and checks を参照してください。このスキルは MCP パッケージをインストールしたり、クライアント設定を編集したりしません。

コンテキスト内で実装する

哲学、トークン、シグネチャ要素、レシピを、製品に適合する場所で使用してください。明示的なユーザーの選択、既存のインタラクション、アクセシビリティは、スタイルルールと衝突する場合でも保持してください。レシピは出発点です。ネイティブターゲットの場合、視覚的意図をプラットフォームのコンポーネントに変換してください。DOM マークアップと Tailwind クラスはネイティブ API ではありません。

焦点を絞った変更は焦点を絞ったままにしてください。新しい UI には、必要な読み込み中、空、エラー、成功の各状態を含めてください。視覚的レビューには design principles を、style signatures はそれが扱うスタイルにのみ使用してください。

globalCss は既存のカスケードと統合してください。Tailwind v4 では、ユーティリティに譲るべき汎用リセットを @layer base に配置するか、意図的にスコープを設定してください。レイヤー化されていないセレクタはユーティリティスタイルを上書きする可能性があります。

構築されたものを検証する

互換性のある Web クラスルールについては、保存されたスペックに対して分離されたコントロールを確認してください:

python3 "<skill-root>/scripts/eval-check.py" "<slug>" "<component-file>" --spec "<work-dir>/spec.json" --component button --strict

必須クラスは要素ごとではなく、入力ファイル全体にわたって照合されます。ページ全体の厳密なパスは、すべてのコントロールが合格したことを証明できません。欠落しているルールや動的クラスは inconclusive になる場合があります。それらを検査してください。この評価器は SwiftUI、React Native、Flutter、アセット、アクセシビリティのバリデーターではありません。スキャンモードと競合するスペックルールについては、スペックのソースとチェックをお読みください。

対象プロジェクトの該当するチェックを実行し、適切なサイズでレンダリングし、変更された状態を動作確認してください。クラス名だけでなく、計算された色とフォーカス動作を検査してください。ネイティブの作業では、ソースレビュー、ビルド、シミュレーター、デバイスのチェックを区別してください。利用できないランタイムを含め、実装と実際の検証を別々に報告してください。再現可能なエージェント評価については、フォワードテストをご覧ください。