using-design-skills

using-design-skills

タスクに必要なデザインスキルをどれにするか、どの順序で使うか、各段階を誰が実行するかを決めてから、それぞれに委ねます。メンバー一覧、役割表、実行者の詳細は references/design-roles.md にあります。パイプラインを組み立てる時点で読み、記憶を頼りに振り分けないでください。

BYPASS

• バックエンドのみ／UI を伴わない作業 · 1 行の CSS または文言の微調整（その場で対応し、必要なら DESIGN.md を参照） · 1 つのスキルだけで済む規模のタスクで、ユーザーがメンバースキルを 1 つ指定している場合 → 直接対応します。
• ループ型の非デザイン作業（監査、計画→構築） → using-workflows。

TRIGGER

価値が視覚的またはインターフェースの形をとる成果物：ページ、画面、HTML レポート／図表／計画、アーティファクト、ダッシュボード、モーション、モックアップ、モジュール／API インターフェース設計。

QUESTIONS — パイプラインを組み立てる（順に回答）

Q1 基本成果物 — 出力の担当は誰か？ 図表 → すべての図表に diagram-design（ハウススタイル、mermaid、draw.io、PNG-SVG エクスポート） · レポートまたは計画ページ → artifacts-rules に従い、自己完結型の HTML ファイルを 1 つ作成 · Web／モバイル → 対象のスタック · アーティファクト → アーティファクトファイル · 指標、KPI、ステータス、または大規模なスキャンと比較を含むコンテンツ → アーティファクトの種類 Dashboard · アニメーション、解説またはデモ動画、ウォークスルー、モーショングラフィック → アーティファクトの種類 Motion（両方の場合：まずアーティファクトの quickstart を参照し、その後は種類ごとの指示に従って構成を決定） · データファイル → data-report · モジュール／API／ドメイン → パイプライン D · トークン作業 → DESIGN.md 自体 · モックアップのみ → 静的 HTML モックアップ。ビルドループなし · 「これで動くか？」→ prototype のみ。ループなし。 Artifact ツールを利用できない（Codex、Cursor、agy）場合 → 上記の各アーティファクト向けルートを、artifacts-rules に従う自己完結型の HTML ファイル 1 つに置き換え、レポートにその旨を記載します。

Q2 バリエーション。 既存のインターフェース → 監査を先に実施（再構築の前に、権限を持つ担当者が現在のレンダリングを批評します）。新規 → 直接構築します。

Q3 直交する専門スキル（追加）。 データファイルのグラフ → data-report。ページまたは Dashboard 内のグラフ → dataviz。アーティファクト → artifact-design。どちらもロックではなくランタイムにバンドルされています。公開前には artifact-design が必須です。このターンで解決できない場合は、どちらを省略するか明示してください。UI のモーションまたはジェスチャー → apple-design（Motion アーティファクトにも適用されます。担当は引き続きその種類のスキルです）。制約セットはインラインで読み込みます。

Q4 各段階の実行者 — references/design-roles.md の実行者表に従います。方向性の決定はインラインで実施します。手間のかかる構築 → agent-tmux の claude 永続ワーカー。レビューはすべて新規のワンショットで行い、作成者にはレビューさせません（headed と headless の判断：using-tmux-agent-tools §QUESTIONS。新たなレビュー担当者が必要かどうかの判断：judgment-rubrics §2）。

Q5 検証。 レンダリングが対象範囲内 → 以下のビジュアル品質ループを実施します（Gate 0 のスクリーンショット証拠をすべて取得。Motion の場合は開始・中間・終了時のフレーム）。DESIGN.md のみ → 文書のみの証拠（ファイルハッシュ／コミット、トークンの網羅性、コントラスト計算）。パイプライン D → 非ビジュアルループ：新規レビュー担当者が codebase-design の深度基準に照らしてデザイン比較を評価し、判定は PASS／BLOCK とします。prototype → なし。

SELECT — 最新情報を確認してから役割を割り当てる

1. jq -r '.skills|keys[]' ~/.agents/.skill-lock.json はインストール済み一覧です。インストール済みのディレクトリでも読み込まれていなければ呼び出せないため、今回のターンで利用可能なスキル一覧とも照合してください。disable-model-invocation: true で制限されているメンバー（head -8 で確認）は、Skill() 経由ではなく、SKILL.md をインラインで読んで呼び出します。
2. ビジュアルパイプラインの方向性を決める担当は必ず 1 つだけです（パイプライン D／プロトタイプ／些細な微調整では 0）。2 つを重ねてはいけません。競合します。不明なスキルを自動的に方向性の決定担当に昇格させてはいけません。
3. 以前からあるメンバーが不在または呼び出し不能の場合は、計画でその不在と代替手段を明記します。役割が空の場合は、明示的に対応を縮小します。黙って代替してはいけません。
4. 選択した各スキルの SKILL.md を、その段階の開始前に読みます。

DEFER — ステージ間の契約

• DESIGN.md：方向性のステージがこれを書きます（プレーンな読み書きです。design-md ヘルパースキルは削除済みです）。後続のすべてのステージと、すべてのワーカーのプロンプトがこれを読みます。ワーカーはチャットの記憶を持たないため、方向性をチャットだけで伝えてはいけません。
• ディスパッチ：tmux によるディスパッチは using-tmux-agent-tools を通じてルーティングします。ワーカーのプロンプトには delegation-templates を使います。階層は ~/.agents/rules/model-dispatch.md §4–§5 に従い、レビュアーの独立性は §6 に従います。ファンアウト／対話には、ユーザーからの正確な承認が必要です。
• ループのトポロジー（固定）：ビルダーは常駐ワーカーです。BLOCK の指摘は同じビルダーに戻します（ワーカー再利用プロトコル）。各レビュアーは毎回新しい単発ワーカーとし、ビルダーをレビュアーにしてはいけません。また、レビュアーを再利用してはいけません。
• ワーカーのプロンプトへの追記：「DESIGN CONTEXT：まず {repo}/DESIGN.md を読み、そのトークンに準拠してください。SKILL：まず {member-SKILL.md} を読み、従ってください。」
• 図の標準設定（メンバーのオプトイン条件より優先しますが、その仕組みは変更しません）：ストーリーが方向性そのものを示す図（データフロー、アーキテクチャ、依存関係、デプロイメント）には、デフォルトで動きを付けます。Flow トークンのプリミティブを使う diagram-design モード loop を指定します（aria-hidden トークンを1つ、サイクルは3秒以上、再生コントロールなし）。ホップの順序に意味がある場合に限り reveal と Path 描画に切り替え、教育目的の場合に限り step に切り替えます。それ以外の種類の図（ER、象限、棒グラフ、ベン図）は、デフォルトで none とします。示すべきフローがない場合、動きは装飾にすぎません。静的表示優先の契約は緩和されません。JS が無効な場合、また、モーション低減時、印刷時、すべてのエクスポートで、ラベル付きの図全体を表示します。
• 形式：HTML 優先。 すべての図とビジュアル成果物は、自己完結型の .html にします。svg／png はそこからエクスポートし、手作業で作成してはいけません。Markdown（mermaid フェンス）を使うのは、ユーザーが求めた場合、または利用側のツールがテキストのみの場合に限ります。「読者はおそらく画像を見られない」というエージェント自身の推測を理由にしてはいけません。

品質のループ — パイプラインは「ビルド完了」で終わりません

ゲート 0、フェイルクローズ： レビュアーはビルドの識別情報（ハッシュ／コミット）、アーティファクトのパス／URL、スクリーンショットのパス、ビューポート、全ページ表示／切り抜きなしを記録します。レスポンシブ対応の成果物では、デスクトップとモバイルの両方が必要です。証拠がない／古い／切り抜かれている場合 → UNCONFIRMED → 全体を BLOCK とします。コードのみのレビューで PASS にしてはいけません。（ドキュメントのみの例外：DESIGN.md のみの成果物では、代わりにファイルのハッシュ／コミットを記録します。レンダリングが一度でも存在したら、契約全体が再び適用されます。）

品質基準： アワード受賞レベル — Awwwards、Webby Awards、または FWA で受賞できるような作品です。「正しくて、きれい」は基準ではありません。

レビューの順序（必ず人間が最後）：

1. 内部：ビルダーがまず品質基準に照らしてレンダリングを自己チェックし、その後、advisor または opus／sonnet の単発レビューで最大 3 ラウンドの批評を行います。ラウンドの間に修正します。品質基準に近づく改善点が何も見つからなくなったら終了します。
2. 外部（任意、難易度で判断）：難しい作業 — 新しいビジュアルの方向性、複雑なインタラクションやモーション、または重要度の高い作業 — では、あるいは内部ラウンドの意見が分かれた場合は、新しい CLI レビュアー（consensus-gate、args.cli）を 1 つ追加します。簡単な作業では省略します。追加した理由、または省略した理由をレポートに記載してください。
3. ユーザー：最後に、ゲート 0 の証拠一式を添えて提示します。 各ラウンドでは品質基準とのギャップを見つける必要があります。見つからなければ終了します。レビューを実施したことを示すだけのためにラウンドを追加してはいけません。

評価基準、順番どおり： 1. THE SLOP TEST — 権限者の監査評価基準を、上記の品質基準に照らして判定します。ありきたりなグラデーションのヒーロー／絵文字の箇条書き／カードグリッドの画一性は、正しくても BLOCK です。アワード受賞レベルに達していない、きれいなレンダリングも同様です。2. 文章の規律 — 埋め草がなく、ざっと読んで把握できる階層構造であること。 3. DESIGN.md への準拠。 4. ステージで凍結された ACCEPTANCE 基準。

BLOCK と見なすもの： 上記の評価項目、または凍結された ACCEPTANCE 基準のみです。どの ACCEPTANCE 項目にも明記されていないアクセシビリティの仕上げ（ヒット領域、コントラスト、aria 名、フォーカスリング、スキップリンク）は NOTE とします。列挙はしますが、それを理由に BLOCK にしたり、修正ラウンドを開始したりしてはいけません。NOTE だけを返すレビュアーの判定は VERDICT: PASS です。

レポートの契約： 項目ごとに PASS／FAIL／UNCONFIRMED と一行の理由を記載します。指摘には persistent／new／regression／evidence-gap のタグを付け、すべてのブロッカーを 1 回のパスで報告します。最終行は VERDICT: PASS または VERDICT: BLOCK と完全に一致させ、レポート内で引用符なしでそのまま記載します。VERDICT: 行がないレポートは、そのレビュアーの形式上の不備です。同じレビュアーにその一行だけを再度依頼してください。取得のために別のレビュアーを立ち上げてはいけません。

ラウンド： BLOCK → 同じ継続中のビルダーが修正 → 新しいレビュアーが再監査します。修正ラウンドは最大 2 回です。その後は原因に応じて振り分けます。同じ根本原因の失敗と、方向性の誤りを示すシグナル（judgment-rubrics.md §4）→ 方向性の検討に戻る · evidence-gap → 証拠の経路を修復して再監査 · new／regression → 個別にトリアージ · それ以外 → 失敗の経緯を添えて停止し、ユーザーに確認します。 PASS → 最終トークンを DESIGN.md に書き込み、証拠一式を添えてレポートします。 「ビルドして監査済み：PASS」は完了の主張ですが、「ビルド済み」だけでは完了を意味しません。

Polish／Operate モード — まず人間が確認： 最初のレンダリング済みビルドは、レビュアーを立ち上げる前にユーザーへ提示します（URL／スクリーンショット、デスクトップ＋モバイル）。方向性はユーザーが決めます。レビュアーは、ユーザーが承認した方向性だけを確認します。レビューはループせず、1 ラウンドのみです。

NOT-FOUND

必要な役割に割り当てられたメンバーがインストールされていない場合は、パイプラインを明示的に縮退させ、省略した内容を伝えます。ステージを実行したふりをしてはいけません。メンバーの契約：各スキルの SKILL.md · 名簿／役割／実行担当者：references/design-roles.md · ワーカーの仕組み：tmux-agent-tools · プロンプト：delegation-templates