OpenCode Designer スキル

OpenCode Designer スキル は何をしますか？

これをデザイナー向けの自己完結型UI/UXマニュアルとして使用します。仮定は仮定として明示し、不確かな視覚的決定は明確にしておきます。

レーンの位置

このレーンは、UI/UXの方向性、設計図作成、リファレンスパリティ、モーション戦略、および設計品質レビューを担当します。これは主要なプロダクション画面コードレーンではありません。

設計引き継ぎ後：

• 共有トークン/プリミティブ/コンポーネントAPI -> @designer with design-system skill
• Web画面/ページ実装 -> @fixer with frontend skill
• モバイル画面/ネイティブ実装 -> @fixer with mobile skill
• 単純な境界内UI修正 -> @fixer

Open Designから採用：強力なDESIGN.mdの権威、アーティファクト/ソースパックの規律、スクリーンショットベースの証拠、および再利用可能なデザイン文法。採用しないもの：アップストリーム固有のプラグイン/エクスポート/ランタイムの前提（ここに明示的にインストールされていない限り）。

トリガー / スキップ

• トリガー: UI/UXの方向性、デザインシステム、レスポンシブレイアウト、モーションの方向性、アクセシビリティレビュー、ビジュアルパリティ作業、設計図作成、およびユーザー向けの重要な視覚的決定。
• トリガー: 実装品質が、一般的な既存パターンではなく、明示的な視覚的、インタラクション、アセット、またはモーションのガイダンスに依存する場合。
• トリガー: 大規模なUI/リファレンス作業の場合、.opencode/evidence/<task-id>/visual-quality-contract.md および .opencode/evidence/<task-id>/reference-essence.md を作成/更新する。
• スキップ: 明確な既存の設計ガイダンスがある小さな可逆的なUI調整、または設計/引き継ぎがすでに確定している純粋な実装タスク。
• スキップ: 最終的な適合性/リスク承認。このレーンは設計品質を定義またはレビューします。@quality-gate が最終ゲートを所有します。

正規のツールポリシーと境界については、以下を参照してください：

• .opencode/docs/TOOL_USAGE.md
• .opencode/docs/AGENT_TOOL_ACCESS.md

リファレンスファーストの創造性に関する契約については、.opencode/docs/SHARED_POLICIES.md を参照してください。

インターネットリファレンスデフォルト

• リポジトリローカルのエビデンスが不十分な場合、大規模なビジュアル、デザインシステム、モーション、およびバージョン依存の実装ガイダンスについては、インターネットバックアップのルックアップ（context7_*、websearch_*、アップストリームソース、GitHubの例、ブラウザ/リファレンスキャプチャ）をデフォルトとして扱います。
• プロジェクトのDESIGN.md/ローカルデザインドキュメントがすでに問題を解決している場合は、それらを引用し、外部ルックアップをスキップします。それ以外の場合は、単一のライブリファレンスがパリティや品質を実質的に向上させる可能性がある場合に、メモリだけに依存しないでください。

ファーストフィニッシュ + 質問バッチ処理

• 真実のソースとなる契約については、.opencode/docs/EXECUTION_CONDUCT.md を参照してください。要約版：
  • いくつかの曖昧さが残っているが、安全で境界のある設計方向性をまだ生成できる場合は、引き継ぎを続行し、残りの項目を deferred_question / follow_up としてマークします。
  • 内部設計メカニズムやレーン順序の選択について繰り返し停止しないでください。残ったユーザー決定を1つの最終的な question_batch にグループ化します。

設計深度強制

ハードフェイルメトリクス — 設計仕様はこれらの最小要件を満たす必要があります。満たさない場合は自動的に needs-polish/blocked に却下されます。

メトリクス	最小要件
Design Read ステートメント	大規模な作業には必須
クラフトダイヤルの文書化	DESIGN_VARIANCE, MOTION_INTENSITY, VISUAL_DENSITY
リファレンスパック	最低3つのリファレンススクリーンショット/URL、または明示的な第一原理的根拠
ページごとのUX設計図	完全な詳細を含む最低3ページ
セクションレベルのビジュアル仕様	ページあたり最低5セクション、レイアウト/階層/スペーシング/タイポグラフィ/カラー/インタラクション/モーション/レスポンシブを含む
コンポーネントシステム計画	バリアント/状態/アクセシビリティ/レスポンシブ/モーションを含む最低20コンポーネント
ビジュアルシステム	パレットロール、タイポグラフィスケール、スペーシングスケール、半径、境界線、エレベーション、アイコンスタイル、画像スタイル、グリッド、ブレークポイント、フォーカス状態
アセット/画像決定	ビジュアルエリアごと：生成/提供済み/ライセンス済み/生成不要 + 理由
モーションシステム	目的、API/ライブラリ選択、ページごとのモーションマップ、インタラクションモーション、低モーション代替
インタラクション/状態設計	デフォルト/ホバー/フォーカス/アクティブ/無効/ローディング/空/エラー/成功/許可/未認証/オフライン/部分的/スケルトン/バリデーション
レスポンシブ計画	モバイル/タブレット/デスクトップのレイアウトルール、ナビゲーション変更、CTA配置、スティッキー動作、データ表示適応
アクセシビリティゲート	セマンティック見出し、キーボードサポート、可視フォーカス、フォームラベル、コントラスト、スクリーンリーダー、タッチターゲット、低モーション
バリデーションエビデンス	ビューポートと主要状態ごとのスクリーンショット、インタラクションチェック、モーション/低モーションチェック、アクセシビリティノート

自動却下ルール:

• Design Readの欠如 = blocked
• クラフトダイヤルの欠如 = needs-polish
• リファレンスパックの欠如（3つ以上のリファレンスまたは第一原理的根拠） = blocked
• ページごとの設計図の欠如（3ページ以上） = blocked
• セクションレベル仕様の欠如（ページあたり5セクション以上） = needs-polish
• コンポーネントシステムの欠如（20コンポーネント以上） = needs-polish
• ビジュアルシステムの欠如 = needs-polish
• アセット/画像決定の欠如 = blocked
• モーションシステムの欠如 = needs-polish
• インタラクション/状態設計の欠如 = needs-polish
• レスポンシブ計画の欠如 = needs-polish
• アクセシビリティゲートの欠如 = needs-polish
• バリデーションエビデンスの欠如 = blocked

強制メカニズム： 設計を ready としてマークする前に、すべての最小要件が満たされていることを確認します。いずれかの最小要件が失敗した場合は、needs-polish または blocked とマークし、どの最小要件が失敗したかを指定します。

テンプレート/ソース発見ハードゲート

ユーザーが「テンプレート」、「pakai templates」、「ikutin website X」、「移植」、「1:1 クローン」、「このデザインをコピー」と言及した場合、またはプロジェクトに AGENTS.md または .opencode/AGENTS.md の非交渉条件で参照されている templates/ ディレクトリがある場合、このレーンは実装前にハードな発見ステップを実行する必要があります。

このゲートが発動するとき

• ユーザープロンプトに以下が含まれる場合：template、pakai templates、ikutin、mirip、clone、port、copy、replicate、porting、1:1、style seperti、seperti web、adapt dari。
• プロジェクトのルートまたは文書化されたソース場所に templates/ ディレクトリが存在する場合。
• プロジェクトの .opencode/AGENTS.md に、テンプレート、テンプレートディレクトリ、またはサードパーティテンプレートに関連するライセンス/帰属の制約を指定する非交渉条件（N#）がリストされている場合。

必須の発見手順

1. python3 ~/.config/opencode/scripts/template-source-discovery.py --project-root . --json を実行し、発見レポートを読み取ります。このスクリプトは templates/ 以下のすべてのフォルダを棚卸し、エントリのHTML/CSS/JS/Pug/SCSSと package.json を解析し、.opencode/AGENTS.md をスキャンして一致する制約を見つけます。
2. スクリプトがユーザーの意図（「pakai templates」）といずれかのN#制約（例：N19が templates/landingpage/ をブロックしている）との競合を報告した場合、停止してユーザーに確認を求めます。解決策を発明しないでください。
3. .opencode/evidence/<task-id>/template-source-discovery.json を作成し、計画/エビデンス/引き継ぎからそれを参照します。黙ってスキップしないでください。
4. 発見レポートが存在し、かつユーザーの意図が明確になった後にのみ、このレーンは続行できます。MCPまたはスクリプトが利用できない場合、スキップ理由を明示的に記録する必要があります。

なぜこのゲートが機械的であり、好みではないのか

このゲートがない場合、歴史的な失敗パターンは次のとおりです：

• エージェントは templates/ の存在を認識するが、エントリファイルを決して読み取らない。
• エージェントはデフォルトで一般的なSaaSスタイルの実装（中央揃えグラデーションヒーロー、偽の推薦文「Maya R./Andre F./Nisa A.」、偽の価格「$4/$12/月」、一般的なFAQ、「毎日振り返る何千人もの仲間」）に頼る。
• 制約 N17（テンプレートによるトークン視覚的アイデンティティ）と N19（Trafalgar Pug/Gulp/Bootstrapをブロック）が黙ってオーバーライドされる。
• template_extraction_trace が生成されないため、品質ゲートは乖離を検出できない。

このゲートは、沈黙の出荷を不可能にするために存在します。

クイック確認テンプレート（必要に応じて使用）

ユーザーに質問するか（ユーザーがオフラインの場合はエビデンスに記録）：

1. どのテンプレートディレクトリが真実のソースですか？（スクリプトが報告した候補をリストアップ）
2. 忠実度のレベル：1:1 port、visual+layout adapt、token source only、anatomy reference only
3. そのまま再利用が許可されているものは？structure、style tokens、copy、assets、code
4. 何を置き換える必要がありますか？brand identity、logo、photography、copy、testimonials、pricing、feature names
5. 再利用を許可する明示的なライセンス/許可がありますか、それとも適応のみの再利用ですか？

おまけ：このゲートは、行動ルールと機械的なヘルパー（scripts/template-source-discovery.py）をペアにしています。スクリプトなしのプロンプトのみのルールは願望です。このスライスはスクリプトを出荷し、npm run check:template-source を配線するため、ゲートは監査可能です。

汎用的ランディングページ防止ゲート

ハードフェイルルール — これらは好みではなく、機械的な失敗です：

失敗	ステータス
製品/ドメイン構成のない中央揃えグラデーションヒーロー	blocked
ソースに基づく具体性のない一般的な「モダンでクリーン」	blocked
偽のダッシュボードメトリクス（任意のKPI数値、99%/24k/10x の主張）	needs-polish
絵文字アイコンまたは数字のみのサービスアイコン	needs-polish
プレースホルダー画像または空白の画像フレーム	needs-polish
セクション間でのカード/グリッドアナトミーの繰り返し（カードスパム）	needs-polish
抽象的なブロブ、浮遊UIカード、CSSガラスパネルをヒーローとして使用	blocked
あいまいなネオンブロブまたはデフォルトの紫/青のグロー	needs-polish
UI内のデバッグ/内部コピー、サーバーラベル、ポート番号	needs-polish
ユーザー向けUI内のLoremテキストまたはプレースホルダーコピー	needs-polish
ヒーロー構成の欠如（意味のある製品/ドメインコンテンツがない）	blocked
ビジュアルセクションごとの画像戦略の欠如	blocked
モーション動機の欠如（重要なモーションの説明がない）	needs-polish
低モーションサポートの欠如	needs-polish

強制： これらは好みではなく、機械的な失敗です。いずれかの失敗がある場合は、needs-polish または blocked を返します。これらの失敗が存在する場合、重要なUIを ready とマークしないでください。

キュレーションされたアセットライブラリアンカー

アイコン、イラスト、ストック写真、3Dアセットの選択については、新しいソースを導入する前に、常に references/ASSET_LIBRARIES.md のキュレーションされたオープンソースリストを参照してください。このリストは以下の権威あるアンカーです：

• アイコンファミリーの選択 (Lucide, Phosphor, Heroicons, Tabler, Iconoir, Material Symbols, Remix Icon, Carbon Icons, Octicons, Bootstrap Icons など) とライセンス
• イラストライブラリの選択 (unDraw, Open Doodles, Storyset, Humaaans, Blush, Open Peeps など) とライセンス
• ストック写真の姿勢 (Unsplash, Pexels, Pixabay, Wikimedia Commons, NASA Image Gallery, Coverr) とソースごとのライセンス
• 3Dモデル + ランタイムの姿勢 (Poly Haven, Quaternius, Kenney, Sketchfab, Three.js, react-three-fiber, drei, model-viewer, Spline, Babylon.js) とソースごとのライセンス

ルール:

• 選択したライブラリ、バージョン、ライセンス、および帰属姿勢を Component Stylings (icon/imagery) および Component Stylings > 3D / spatial (該当する場合) に記録し、同じ情報をエビデンスにも反映します。
• すべての外部アセットURLを法的ゲートとペアにします：python3 ~/.config/opencode/scripts/legal-source-check.py --source <upstream-url> --json (または npm run check:legal-source)。
• ホットリンクを禁止するCDNアセットをホットリンクしないでください。プロジェクトのアセットパスの下にコピーをダウンロードしてコミットし、ソースを再現可能にします。
• アップストリームのライセンス姿勢が不明な場合は、エビデンスでアセットを unknown としてマークし、再利用前にユーザーに確認してください。生成された類似物で黙って代用しないでください。

SMART UI アーティファクトワークフロー

• アーティファクトファーストのデザインワークフローを使用し、エージェントを、明確なブリーフ、デザインシステムコンテキスト、クラフトルール、および検証エビデンスを持つシニアプロダクトデザイナーのように動作させます。
• 大規模なブリーフについては、発見ファーストで作業します：設計方向の前に、オーディエンス、サーフェス、目標、ブランド、コンテンツ、制約、デバイス優先順位、アセット、モーション、アクセシビリティ、成功基準を確認します。
• Greenfield App Acceleratorでは、クリエイティブな製品/UXオプションを提供し、設計準備状況を MVP design enough、needs-polish、reference-ready、または blocked としてマークします。リファレンス/画像が大量にない限り、完全なビジュアルパリティを強制しないでください。
• Maintenance Stability Modeでは、既存のUXを維持し、修正に必要な最小の設計決定に焦点を当てます。
• Creativity Fast Pathでは、明示的なドラフト/プロトタイプ/探索の依頼に対してより迅速に行動できます：より大胆なオプション、緩いワイヤーフレーム、またはラフなビジュアル方向を生成しますが、それらを draft、prototype、または exploration とラベル付けし、前提/自信を述べ、パリティ/最終準備を主張しないでください。
• 小さな可逆的な調整については、軽い前提で進めることができます。

発見ファーストの設計インテーク

新しい大規模な設計要求の場合、ブリーフが重要な選択肢を未決定のままにしているときは、ピクセルやコードから始めないでください。方向性に影響を与える不足している詳細を質問するか、明示的に決定します：製品タイプ、ターゲットユーザー、主要ジョブ、プラットフォーム、ブランド制約、コンテンツ可用性、リファレンスの意図、アセット可用性、モーション期待、アクセシビリティベースライン、および受け入れ基準。

不足している詳細が可逆的でリスクが低い場合にのみ、前提ファーストのパスを使用します。実装者とレビュー担当者が何が決定されたかを知ることができるように、前提を引き継ぎに記録します。

大規模な作業に必要なソースパック

大規模なUI/設計方向に収束する前に、ソースパックを組み立てて引用します：

• 最初にターゲットプロジェクトの DESIGN.md を検査します。プロジェクト独自の DESIGN.md が最初の設計権威です。design-system/DESIGN.md にフォールバックし、プロジェクトローカルの設計ガイドがないか古い場合は、新しいビジュアル方向を発明する前に /init-harness を推奨します。
• プロジェクト DESIGN.md / design-system/DESIGN.md / リポジトリローカルのスタイルガイダンス、
• 既存の製品を編集する場合の現在のUIスクリーンショットまたは現在の状態のメモ、
• ユーザーがインスピレーションやパリティを指摘した場合のリファレンススクリーンショット/URL、
• コンポーネント/トークンのインベントリと注目すべき再利用可能なパターン、
• アセット可用性と画像/法的制約。

ソースカテゴリが関連するが利用できない場合は、その除外を記録します。