ui-spec について
ui-specは、根拠のあるブリーフまたは採用済みのビジュアルソースから、実装可能なUI契約を作成するためのルーティングスキルです。UIの準備状況を、製品承認、実装、ランタイム証拠、デリバリー判断と分けて扱います。
主な機能
- 01適用するUIモジュールへの振り分け
- 02機能および共有デザイン契約の定義
- 03スライス単位での証拠・不足・準備状況の管理
- 04UI準備状況とデリバリー権限の分離
活用シーン
- 01選択したページやフローの仕様作成
- 02未承認のビジュアル方向の検討
- 03共有ビジュアルセマンティクスの採用・変更
- 04複数画面の準備状況の評価
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ idaibin/ skills --skill ui-specインストール後、Claude Code で/ui-specを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
agents/openai.yamlassets/DESIGN.mdfrontend-visual-evidence.schema.jsonreferences/candidate-visual-direction.mddesign-md-contract.mddocumentation-boundaries.mdeval-cases.mdevaluation-rubric.mdfrontend-layout-governance.mdfrontend-visual-evidence.mdmeasurement-normalization.mdmulti-surface.mdscene-archetypes.mdsvg-icon-system.mdusage.mdvisual-direction-and-anti-slop.mdvisual-source.mdworkflow.mdscripts/validate-design-md-completeness.pyvalidate-frontend-visual-evidence.py詳細
UI 仕様
目的
Product、共有デザイン、コンポーネント/ソース、ランタイムの根拠、またはデリバリーの権限を置き換えることなく、実装にそのまま使える UI 契約を作成します。このファイルはルーティングマップです。分岐を選択したら、参照先のモジュールのみを読み込みます。
開始条件
- ソースに基づく候補ブリーフ、または選択/承認済みのビジュアルソースが必要です。どちらもない場合は、
evidence-incompleteとして停止します。 - 認可された成果物を書き込む前に、有効なリポジトリガイダンスと現在の Worktree の状態を確認します。
- Product の動作、Feature UI Markdown、採用済みの
DESIGN.md、コンポーネントソース、ランタイムの根拠、Git デリバリーは、それぞれ別個の権限として扱います。
ルートマップ
| リクエストの状態 | 読み込むもの | 結果 |
|---|---|---|
| 適用可否またはソースの選択が不明確 | usage および visual source | 範囲/ソースを確定するか、停止します |
| 方向性が探索段階で未承認 | candidate direction | 同期済みの完全な生成プロンプトを含む、無視対象のローカル候補仕様。DESIGN.md は変更せず、Not Ready とします |
| ページ、フロー、または承認済みの対象範囲が選択済み | workflow および documentation boundaries | Feature Spec とスライスごとの準備状況 |
| 共有ビジュアルセマンティクスを採用または変更する | DESIGN.md contract | 承認・lint 済みの <design-root>/DESIGN.md。Feature Spec からこれを参照します |
| 複数の独立した対象範囲を扱う | multi-surface | 共有インデックスと、個別に読み込み可能なスライス/判定 |
不変条件
- 候補の引き継ぎでは、候補仕様/プロンプトのリビジョンとハッシュを指定します。承認済み契約の引き継ぎと根拠では、承認済みの比較基準リビジョンを指定します。
- Product の動作、正確な値、アセット、コンポーネントの所有権、権利、ランタイムの事実、共有セマンティクスを捏造しないでください。不明な点には、定義済みの根拠レベルを付与します。
- Feature Spec 内で共有トークンやコンポーネントインターフェースを重複させたり、並行する Registry/スキーマを導入したり、変更のないローカルスライスに
DESIGN.mdの採用を強制したりしないでください。 - 構造化プロジェクションを使用するのは、名前の付いた所有者、生成元、非 LLM コンシューマー、セマンティックバージョン、実行可能なバリデーター、ドリフトポリシー、廃止ルールがすでに存在する場合に限ります。
- 外部 AI の操作、画像または SVG ソースの生成/編集、Product ソースの編集、ブラウザー/クライアント状態の操作、Git の変更は行わないでください。これらの操作は、それぞれの担当者に引き継ぎます。
Readyが対象とするのは、UI のビジュアル/インタラクションに関する準備状況のみです。Product の承認、実装、レビュー、ランタイム、デリバリー、デプロイ、本番環境での証明を意味するものではありません。
出力マップ
ライフサイクル/プロファイル、ソースの識別情報と権利、権限の扱い、スライス ID、該当するレイアウト/状態/インタラクション/アクセシビリティ/アセットの契約、差分/根拠の参照、比較基準、スライスごとの準備状況、明示された不足事項を含む [email protected] を返します。候補出力では、無視対象の両方のパス/ハッシュと引き継ぎ状況も返します。タスク固有の根拠は、無視対象であることを確認した .codex/artifacts/ に保存します。DESIGN、ビューポート、SVG、またはランタイムの根拠に関するフィールドは、対応するモジュールが有効化された場合にのみ含めます。
参照マップ
該当する条件に当てはまる場合にのみ、モジュールを読み込みます。
| 条件 | モジュール |
|---|---|
| ビジュアルの方向性、テーマ、色、Preserve/Overhaul の選択 | ビジュアルの方向性 |
| 採用済み/候補のソースでシーンのアーキタイプが指定されている | シーンのアーキタイプ |
| レイアウトの所有権、インセット、オーバーレイ、フォーカス、ヒット順、またはトランジションの変更 | レイアウトとインタラクション |
| ソースの測定値を繰り返し正規化する必要がある | 測定値の正規化 |
| SVG/アイコンの役割またはフォールバックが受け入れ条件に含まれる | SVG アイコンの仕様 |
| 現在のランタイムを選択したソースと比較する | ビジュアルのエビデンス |
| 最終的な準備状況を判断する | 評価基準 |
メンテナーは回帰テストに 評価ケース を使用します。通常の UI 仕様作成では読み込まないでください。
コメント
Markdown 対応