specs-ui

Tailwind でモックアップする仕様書 UI

このスキルは、ビジネス担当者と開発者の間で参照する、小規模な仕様書サイトを作成します（画面ごとに1ページ、複数ページを1つのアーティファクトとして公開）。各画面は Tailwind でデスクトップ版とモバイル版のモックアップを作成し、画面遷移の中に位置づけてルールを注釈します。動作と表示を検証できるまで反復し、その後の開発では同じトークンとクラスを使用します。

ドキュメント、ラベル、注釈、やり取りはフランス語で記述します。コード（スクリプト、属性、変数、技術的な識別子）は英語で記述し、コメントはフランス語でもかまいません。

仕様書は機能面と UI の仕様です。画面、注釈、ルールに、ライブラリ名、関数名、API フィールド名、技術的な記法を含めてはいけません（redaction-specs.md、「コードなしの機能仕様書」）。

<skill> はこのスキルのフォルダーを指します。スクリプトは、作業者のプロジェクトから node <skill>/scripts/… で実行します。

コンテキストを節約する（最初に読む）

仕様書プロジェクトはすぐに大きくなります。画面が10個ほどあるものを1ページにまとめると、300 KB を超えます。そのため、仕様書は画面ごとのページに分割し、必要のない内容を読み返さないようにします。ルールは次のとおりです。

1. specs/ui/CONTEXTE.md はプロジェクトの記憶です。 作業を再開するときは、まずこれを読み、できる限りこれだけを参照してください。決定事項、アイデンティティ、レイアウト、ペルソナ、一貫したストーリーの正確な文字列で記された事実（識別子、ラベル、時刻など。画面で新たに作成したものはすぐに追加）、アンカー付きの一覧、ロットの状態と URL、プロジェクト固有の規約、未解決事項、次のステップが記載されています。ステップ1で templates/contexte.md をもとに作成し、各ステップの終了時に更新してください。200行未満に保つ必要があります。
2. 作成済みのページ（specs/ui/site/）は絶対に読まないでください。 仕様書は specs/ui/sources/ にあります。画面状態ごとに1ファイルです。必要なファイル（sources/<lot>/070-e15d.html、sources/shared/shells.html）だけを読み、編集してから、再構築します（ステップ3）。
3. キャプチャを確認するときは、コストの低いものから始めてください。 まず capture.mjs の警告を読み、次に縮小版の一覧（--sheet。複数の画面で約1,000トークン）を確認します。個別の枠を開くのは、判断に迷った場合だけです。セクションのキャプチャ（--sections）はコストが高いため、ドキュメントのレイアウトに限って使用してください。
4. 現在の作業に対象を絞ります。 変更した画面だけをキャプチャするには --ids を使い、スキルの参考資料は下の表に従って読みます。
5. 適切なモデルに、必要な範囲だけを委任します（「モデル間で作業を分担する」を参照）。サブエージェントには CONTEXTE.md のパスと作業内容を渡し、プロジェクト全体の要約は渡しません。並行して作業する2つのサブエージェントが同じファイルを扱うことはありません。また、サブエージェントを起動する前に、改訂した一覧（ID、タイトル、アンカー）を CONTEXTE.md に記録します。
6. 変更されたものだけを公開します。 プロジェクト全体は複数ページからなる1つのアーティファクトです。prepare-publish.mjs は前回の公開以降に変更されたページを一覧表示し、そのページだけを送信します。修正をまとめてから公開してください。

モデル間で作業を分担する

画面の HTML を記述・変更する、決定事項を反映する、テキストを抽出する。これらは実行作業であり、最も高性能なモデルは必要ありません。環境でサブエージェントのモデルを選択できる場合（Claude Code の Agent ツールの model パラメーター）、次のように分担します。

役割	モデル	タスク
設計と意思決定	セッションのメインモデル	要件の整理、提案（レイアウト＋テーマ）、インベントリ、画面仕様書、qualite-ui.md の評価基準を使った画面確認、対話と質問、CONTEXTE.md、公開
執筆	sonnet	画面仕様書をもとに一式分の画面ファイルを記述する、ソースにフィードバックや決定事項を反映する、コンポーネントを共通化する、プロジェクトを移行する
機械的な実行	haiku	build.mjs と capture.mjs を実行して警告を報告する、指摘されたバッジやリンクを修正する、未解決事項・ログ・インベントリをプレーンテキストに抽出する、一括で名前を変更する

執筆に Sonnet を使う理由：画面の作成には、丁寧なレイアウトを組み立てながら、仕様書、全体のストーリー、品質基準に忠実であることが求められます。Haiku では仕上がりが劣り、価格差を上回るコストのやり取りが発生します。レイアウトの判断がまったく必要ない作業、つまりスクリプトの実行、抽出、名前の変更、指摘されたバッジやリンクの修正には、引き続き Haiku が適しています。

画面仕様書：メインモデルが執筆担当に渡す、画面ごとの 10〜20 行の説明です。各状態の ID とアンカー、目的と主な使い方、フォーカスポイント、正確なコンテンツ（全体のストーリーに含まれる事実）、使用するコンポーネントと参考にする画面、記述する注釈（ルール、条件、参照先）、前後のリンク、モバイル対応の範囲を含めます。仕様書が具体的であるほど、執筆担当に必要なコンテキストは少なくなり、より簡潔にできます。

執筆担当は判断を下しません。仕様書に曖昧な点や不足があれば、独自に補わず、報告で質問します。メインモデルは公開前に必ず画面を確認します。設計上の不備があれば、具体的な指示とともに執筆担当に差し戻します。

タスク	読むもの
引き継ぎ、反復、微調整	CONTEXTE.md、続いて該当するソースファイル。必要に応じて redaction-specs.md §6
新しい仕様一式	CONTEXTE.md、tailwind.md §2〜§6、qualite-ui.md §9、参考となる既存画面 1 つ、shells.html
インターフェースの提案	propositions.md、qualite-ui.md
既存サイト	site-existant.md
インベントリ、横断的な変更	redaction-specs.md §1〜§4

生成ファイル

ワークフロー内の3つのスキルは、成果物をプロジェクトルートにある単一の specs/ フォルダーに格納します。開発中は、アプリケーションのコードリポジトリにも同じフォルダーを置きます。

specs/
├── ui/              ce skill : specs maquettées
├── prototype/       skill prototype-ui (facultatif)
└── requirements/    skill requirements-doc : cahier des charges (facultatif)

specs/ui/
├── CONTEXTE.md                 mémoire du projet (à jour à chaque étape)
├── tokens.css                  identité : bloc @theme Tailwind, injecté dans chaque document
├── propositions.html           propositions d'interface et décision (jamais supprimé ; copié dans le site)
├── captures/                   captures du site existant (étape 1B)
├── assets/                     (facultatif) images du produit : logos, illustrations, photos de démonstration
├── sources/
│   ├── site.json               titre, introduction, URL de l'artifact, liste ordonnée des lots, dossier des images
│   ├── shared/shells.html      coquilles <template id="tpl-shell-…"> communes à tous les lots
│   └── <lot>/                  lot.json, 000-header.html, NNN-<id>.html (un état d'écran par fichier), templates.html
└── site/                       construit par build.mjs, ne pas modifier à la main :
                                index.html (accueil), <lot>/index.html (en-tête, règles, écrans, points ouverts,
                                journal), <lot>/eN.html (une page par écran, tous ses états), propositions.html,
                                assets/ (les images citées par les pages)

製品の画像。 ロゴ、マスコット、イラスト、バッジなど、インターフェースに表示するものは、代わりの単色の図形ではなく、モックアップに表示します。これらがないと、画面を見分けられません。ソースでは画像を assets/<chemin> で指定します。すでに画像があるプロジェクト（既存のアプリケーション）では、画像をコピーする代わりに、sources/site.json → "assets" で画像フォルダーを指定します（specs/ui/ からの相対パス。例："../../apps/web/public/assets"）。build.mjs は、指定された画像のみを site/assets/ にコピーし、prepare-publish.mjs はページとともに画像を公開します（tailwind.md §7）。

確認用のスクリーンショットは一時フォルダー（存在する場合はセッションのスクラッチパッド）に保存し、プロジェクトには置きません。

git リポジトリでは、ソースと、公開内容を示す site/.published.json をコミットしますが、ビルド済みのサイトはコミットしません。ビルドは再現可能で数秒で完了し、チームは公開済みのアーティファクトで仕様を確認します。プロジェクトの .gitignore には、specs/ui/site/* に続けて !specs/ui/site/.published.json を記述します。新しいクローンでは、prepare-publish.mjs の前に build.mjs を実行します。チームが何もビルドせず、アーティファクトも開かずに HTML を読む必要がある場合に限り、サイトをバージョン管理します。スクリーンショットと公開用フォルダーは、リポジトリの外に置きます。

スキルのリソース

ファイル	役割
references/tailwind.md	トークン、フレーム、再利用可能なブロック、注釈、コンポーネントカタログ
references/qualite-ui.md	UI 品質の原則と公開前レビュー用チェックリスト
references/propositions.md	3 つの提案を作成（レイアウト＋テーマ）
references/site-existant.md	既存のサイトまたはアプリに機能を追加
references/redaction-specs.md	インベントリ、画面の構造、状態、反復、横断的な変更
templates/specs.html	仕様書のひな形：装飾、スクリプト、サンプル画面 2 枚
templates/propositions.html	比較ページ：3 つのレイアウト、3 つのテーマをライブで組み合わせ可能
templates/tokens.css, templates/contexte.md	アイデンティティファイル、プロジェクトのメモリ
scripts/build.mjs	ソースからサイトを構築：ページ、ページ間のリンク、トークン、タイポグラフィ、装飾、タイポグラフィ設定；変更されたページを一覧表示
scripts/split.mjs	ロットを作成（--new <lot> --root specs/ui）、または既存のドキュメントをソースに分割
scripts/capture.mjs	ファイルまたはサイト全体をチェック；画像：--sheet、--frames、--thumbnails、--sections、--themes、--ids
scripts/check-contrast.mjs	トークンの WCAG AA 準拠をチェック
scripts/prepare-publish.mjs	サイト（メインページ＋変更されたページ）または単独のドキュメントの公開準備；--check は、成果物がローカルサイトより古いかどうかを示す
scripts/migrate-layout.mjs	古いレイアウト（specs-ui/、prototype-ui/、cdc/ が並列）で構成されたプロジェクトを specs/ に整理
scripts/extract-identity.mjs	サイト（URL）またはコード（フォルダー）のアイデンティティを抽出、キャプチャ
scripts/upgrade.mjs	古いドキュメント（ソースなし）をモックアップに触れずにテンプレートの水準に更新
scripts/typography.mjs	フランス語のタイポグラフィ（build.mjs によって自動適用）
scripts/export-design-system.mjs	（任意）Design System Claude Design のフォルダーを準備：トークン、基礎要素、コンポーネント、README
scripts/design-sync-package.mjs	（任意）/design-sync で Claude Design に送る「トークンのみ」のパッケージを作成
templates/design-system.html	Design System にエクスポートされるコンポーネントカタログ
templates/design-sync/	パッケージのテンプレート：build.mjs、規約の草案、同期メモ

テンプレートには架空の製品「Orbe」（顧客からの依頼）が含まれていますが、形式を示すためだけのものです。内容はすべて置き換えてください。

質問の提出先。 質問を会話の中だけにとどめてはいけません。選択肢が限られた質問には、利用可能であればインタラクティブな質問ツール（AskUserQuestion）を使い、推奨オプションを示します。回答待ちの内容はすべて、公開するドキュメント（提案の「要確認」、仕様の「未解決事項」）と CONTEXTE.md にも記載します。メッセージでは、何を回答してほしいのかを伝えます。

ステップ 0 · 枠組みを決める

1. 再開ですか？ specs/ui/ が存在する場合は、CONTEXTE.md を読み、該当するステップから再開します。旧レイアウトのプロジェクト（ルートに specs-ui/ があり、バージョンが 2.x）は、まず node <skill>/scripts/migrate-layout.mjs <projet>（結果を確認するには --dry-run）で整理してから再構築します。成果物の URL は維持されます。CONTEXTE.md も sources/ もないプロジェクト（バージョン 1.x で作成された、ロットごとに 1 つのドキュメントがあるプロジェクト）は、まず移行します。
   • 各仕様ドキュメントに対して、ロットの順に split.mjs を実行する；
   • 古いドキュメントを specs/ui/archives/ に移動する；
   • build.mjs specs/ui を実行し、capture.mjs specs/ui/site <tmp> で確認する；
   • ページを読むのではなく、未解決事項とログからテキストを抽出して CONTEXTE.md を作成する；
   • サイトを新しい成果物として公開し、古い成果物には置き換え済みであることを記録する。
2. アイデンティティの出所を会話から判断します。未定義 → ステップ 1A；既存のサイトまたはコード → ステップ 1B；提供済み（ガイドライン、デザインシステム、トークン） → 直接 tokens.css を作成し、その後ステップ 2 に進みます。Claude Design の Design System を持っていて、それを起点にしたい場合（任意です。存在する場合にのみ提案します）は、それを読み込みます（Artifact ツール：タイプ「Design System」で list を実行し、README とトークンを read）。その内容を tokens.css とシェルに変換します。この場合、ステップ 1A は不要です。
3. 機能要件：目的、ユーザー、ルール、提供されたドキュメント。ライブラリやドキュメントに基づくブリーフは、設計前に読み、機能用語に置き換えます（redaction-specs.md §1）。ライブラリの名称を仕様に記載することはありません。

情報が不足している場合は、すべてを 1 つのメッセージで質問します。ブリーフで十分な場合は質問せず、前提を記述して作成します。製品名がない場合は仮の名前を選び、その旨を伝えます。

ステップ 1A · 3 つの案：レイアウト＋テーマ

references/propositions.md に従います。各案は、レイアウト（ナビゲーション、構成、作業方法）とテーマ（配色、タイポグラフィ、形状、密度）を組み合わせたものです。3 つの案では、同じ代表的な画面と同じ実際のコンテンツを使い、デスクトップとモバイルの両方で、レイアウトとテーマの両面を変えます。templates/propositions.html を起点にします。レイアウトごとにマークアップがあり、ボタンを使って任意のテーマを任意のレイアウトに適用できます。

確認事項：check-contrast.mjs、続いて capture.mjs --thumbnails（サムネイルのテスト：3 つのレイアウトがひと目で区別できること）、2～3 種類の組み合わせに対する --themes、および qualite-ui.md のグリッド。公開後、選択を依頼します。回答は、1 文字、組み合わせ、または修正案のいずれかです。ステップ 2 の項目一覧も、同じ確認タイミングで「確認事項」セクションに提示します。

フィードバック（「A と C は似ています」など）があった場合は、同じファイルと同じ成果物でステップをやり直し、「前のバージョンからの変更」という囲みを追加します。選択が決まったら：

• テーマを tokens.css に固定します（出所と日付を記載し、コントラストを再確認）。レイアウトは sources/shared/shells.html に固定します；
• propositions.html に「決定」という囲みを追加し、「確認事項」を決定済みとして記載します。propositions.html は決して削除しないでください。

複数の案を組み合わせた選択は、適用前に具体的に言い換えて確認します。質問できず、なお曖昧さが残る場合は、最も妥当な解釈を採用し、前提として明記したうえで、最初の質問として提示します。

ステップ 1B · 既存サイトを引き継ぐ

references/site-existant.md に従います。extract-identity.mjs <url> --screenshots specs/ui/captures（またはコードのディレクトリ）を実行し、レポートとキャプチャを照合します。正確な値とその出所を記載した tokens.css を作成し、キャプチャの隣に E0 · 既存としてページを再現して、忠実度の確認を依頼します。機能の配置が不確かな場合は、統合レイアウトを 2～3 案提示します。

ステップ 2 · 画面の一覧

references/redaction-specs.md §1 に従います。モックアップを作成する前に、画面の表（ID、目的、状態）、ユーザーフロー、把握したルール、仮定、および質問を多くても 2〜3 件提示します。公開ドキュメントと CONTEXTE.md にも、各画面のアンカーとともに記載します。承認を待ちます。大規模なブリーフはロットに分割します（ロットごとに 1 ドキュメント、番号は全体で通し番号）。まず、枠組みを決めるロットから着手します。モバイル版は、担当者が縮小範囲を承認した場合を除き、各画面についてモックアップを作成します。

ステップ 3 · 仕様の作成（画面ごとのソース）

ロットを作成する：

node <skill>/scripts/split.mjs --new <lot> --root specs/ui     # → sources/<lot>/, inscrit dans sources/site.json

すでに枠組みがあるプロジェクトでは、ロットは空のひな形（ヘッダー、ルール、未解決事項、記入用の変更履歴、既存ロットから引き継いだアイデンティティ付録）から開始します。CONTEXTE.md に記載されたモデル画面を出発点にします。 次に、sources/<lot>/ で以下を行います。

• lot.json を記入します。label（「ロット 2 · プロジェクトとリポジトリ」）、title、fonts、screens（各画面の短いタイトル：{ "e4": "作成アシスタント" }）を設定します。
• ヘッダー（000-header.html）に、コンテキスト、ルール、ユーザーフローを記入します。
• 画面の状態ごとに 1 ファイル（020-e4a.html、030-e4b.html…）を作成し、サンプル画面を置き換えます。同じ画面の eN… セクションは 1 つのページを構成します。それ以外のセクション（ルール、未解決事項、変更履歴、付録）はロットのインデックスに配置します。

画面のないロットにすることもできます。たとえば、未解決事項のレビューや、決定事項の一覧を作成できます。表のみにして（「フィードバック」欄を設けて注釈できるようにします）、ホームのカード用に lot.json に "summary" を設定します。

枠組みの変更は、すべてのロットに適用されるよう shells.html で一度だけ行います。複数のロットで共通のコンポーネント（プロジェクトヘッダーなど）は、sources/shared/components.html に配置します。レイヤーの背景と再利用するコンテンツは templates.html に配置します。リンクはシンプルに記述します（#e13b、sessions.html#e13b、propositions.html#retenu）。ビルド時に適切なページへのリンクに書き換えられます。

変更のたびにビルドする：

node <skill>/scripts/build.mjs specs/ui

build.mjs は specs/ui/site/ を生成します。tokens.css、各ページに必要な枠組み、最新のテンプレートの装飾とスクリプトを挿入し、画面間のナビゲーションを追加し、リンクを書き換えて、フランス語のタイポグラフィを適用します。ビルド済みページを手作業で更新する必要はありません。解決できないリンクを通知し、変更されたページを一覧表示します。

コンテンツ：tailwind.md（トークンのみ、コンポーネントカタログ、注釈）と qualite-ui.md（主要な用途、フォーカルポイント、階層）に従います。各画面には、ID、タイトル、バッジ、メモ、「前の画面 / 次の画面」、デスクトップのモックアップ、再設計したモバイルのモックアップ、および 3〜6 件の注釈を含めます。ヘッダーと最初の画面を作成してビルドし、確認してから、残りを作成します。

ステップ 4 · 検証してから公開

node <skill>/scripts/capture.mjs specs/ui/site <tmp>/captures                       # contrôles seuls, aucune image
node <skill>/scripts/capture.mjs specs/ui/site <tmp>/captures --sheet --ids e4,e5   # planches des écrans touchés

スクリプトは、テンプレートのバージョン、不明なアイコン、組み立てられていないブロック、切り取られたコンテンツ、テキストに重なったり、端で切れたりしているバッジ（フレーム、番号、覆われたテキストを表示）を報告します。これらの警告を修正し、qualite-ui.md §9 のチェックリストに沿って画面一式を読み返してください。疑問がある場合に限り、単独のフレームを開き（--frames --ids …）、最も目立つ3つの欠陥を修正して、影響を受けた画面を再キャプチャします。この反復作業を、検証は一度だけという一般的な指示より優先してください。ブラウザーがない場合は、その旨を伝えてください。

公開（Artifact ツールがあれば使用します。ローカルファイルを正とします）。プロジェクト全体を1つの複数ページ Artifactにします。

node <skill>/scripts/prepare-publish.mjs specs/ui/site <tmp>/publish    # page principale + pages à envoyer

• 準備したメインページ（file_path）と、スクリプトが表示する files テーブル（公開先のパス → specs/ui/site/ のファイル）を Artifact ツールに渡します。セカンダリページは完全なドキュメントです。ページ間の相対リンクはそのまま機能します。
• 初回公開時はすべてのページを公開します（--all）。以降は、前回の公開から変更されたページのみを公開し、それ以外のページはオンラインに残します。Artifact が見つからない場合（削除された場合、または別の claude.ai アカウントから公開された場合）は、新しいものに置き換えます。--all を指定して公開し、URL をすべての箇所（site.json、CONTEXTE.md、プロトタイプと仕様書の設定、プロジェクトの README）で置き換え、旧 URL は置き換え済みとして記録します。url を指定したときに、ツールがファイル一覧を確認済みであることを求める場合は、ページを再読するのではなく、一覧を要求します（scope: "files"）。
• 公開に成功したら、prepare-publish.mjs specs/ui/site --confirm を実行します。URL を sources/site.json（artifact）と CONTEXTE.md に記録します。
• 公開時は Artifact ツールのルールに従い、タイトルは2～4語にします。

最後に、パス、リンク、短い概要、必要な判断事項を伝え、フィードバックの方法も案内します。各ページの「Retours」ボタンを押してから、エクスポート内容を貼り付けてもらいます（ステップ5の「Retours de relecture」を参照）。CONTEXTE.md を更新します。

ステップ 5 · 反復

redaction-specs.md §6 に従います。フィードバックごとに、次の作業を行います。

• ID を安定したまま維持し、該当するソース（および影響を受けるソース）のみを変更してから再構築します。
• イテレーション番号を増やし、ログに項目を追加し、未解決の項目を更新します。
• 検証して再公開し、CONTEXTE.md を更新します。

変更の種類に応じて、次のように対応します。

• アイデンティティ：tokens.css を経由して変更し、再構築します。
• 誤植：shells.html で修正してから再構築します（これは保守作業であり、イテレーションではありません）。
• 議論になっている画面のレイアウト：E5-A / E5-B のバリエーションを横並びで作成します。
• 横断的な変更：影響を分析し、判断事項を整理し、CONTEXTE.md と提案のインベントリを改訂してから、その変更を担うロットから制作を開始します。

レビューコメント

サイトの各ページには**「コメント」ボタンがあります（文書の表示要素で、スクリーンショットや印刷には表示されません）。レビュアーは「注釈」モードに切り替え、モックアップやテキスト（ルール、注釈、未解決項目）の該当箇所をクリックして、修正依頼または質問**を入力します。各コメントにはクリックした位置に識別子（R1、R2…）が付与され、ブラウザー内にのみ保存されます。その後、Markdown にエクスポートして会話に貼り付けます。「エクスポートをコピー」、「エクスポートを表示」（クリップボードへのアクセスが拒否された場合にコピーとテキスト選択ができる大きな閲覧ウィンドウ）、および artifact 以外では「ダウンロード」を利用できます（artifact で公開されたページからはダウンロードを開始できません）。エクスポートでは、画面の状態ごとにコメントをまとめ、それぞれについてソースファイル（build.mjs が各セクションに記録する sources/<lot>/NNN-<id>.html）、フレーム（e4c-desktop）、フレーム内の位置、対象テキストを記載します。

エクスポートに対応するには：

1. **エクスポートだけを読み、その中で参照されているソースファイルだけを確認します。**引用されたテキスト、フレーム、フレームの幅と高さに対する位置（％）を使って要素を特定します。ビルド済みページを読み直すことは決してありません。
2. ルールや決定事項に沿った明確な修正依頼は、ソースに反映します。曖昧な修正依頼、ルール、CONTEXTE.md の決定事項、または別の画面と矛盾する修正依頼については、独断で対応せず、質問ツールで選択肢を絞って担当者に確認します。
3. 質問には会話で回答します。決定が必要な場合は、推奨案を添えて、そのロットの未解決項目（および CONTEXTE.md）に追加します。
4. コメント一連につき1回のイテレーションを実施します。ロットのログに対応したコメント（「R1、R3：…」）を記録し、再ビルドして、該当する画面を撮影（--ids）し、変更したページを再公開します。
5. コメント | 対応内容 | 画面 の表で回答します（修正済み、質問済み、未解決、採用せずとその理由）。その後、担当者がパネル内でコメントを「対応済み」にするか、削除します。

コメントは各レビュアーのブラウザーに保存されます。複数のレビュアーはそれぞれコメントをエクスポートでき（入力した名前が署名になります）。実装ステータスが付いた、すでに納品済みの画面へのコメントは、手順7のサイクルに従います。つまり、コードも変更するか、差分として扱います。

オプション · Design System Claude Design

任意の機能です。利用するかどうかは各自で決められます。一度だけ、クローズドクエスチョン（「アイデンティティを Design System Claude Design にエクスポートしますか？」はい／いいえ／後で）で提案します。ステップ1Aの決定直後、またはステップ6で提案し、回答をCONTEXTE.mdの「設定」セクションに記録して、同じ質問を繰り返さないようにします。許可なくエクスポートしてはいけません。

回答が「はい」の場合は、2つの段階で進めます。

1. カタログ（specs/ui/design-system/）：

node <skill>/scripts/export-design-system.mjs specs/ui

README（テーマ、トークンの用語、使用ルール）、tokens.css、基礎要素（色、タイポグラフィ、形状）、カタログのコンポーネント、プロジェクトのコンポーネント（sources/shared/）が含まれます。各カードには Claude Design のカードマーカーが付いています。

2.「トークンのみ」パッケージ（specs/design-system-package/、specs/ui/の隣）。Claude Design はパッケージをもとに React で構築します。仕様には React コンポーネントが含まれていないため、トークンとユーティリティクラスの形式でアイデンティティを渡します。カタログのカードは、プロジェクトで表示されるカードになります。

node <skill>/scripts/design-sync-package.mjs specs/ui
cd design-system-package && npm install && npm run build

• CONTEXTE.mdをもとに.design-sync/conventions.mdを英語で作成し、2,000～4,000文字にまとめます。これはデザインエージェントが読むヘッダーです。各トークンの名前と使用する場面、繰り返し使うパターン（バッジ、シェル、ヘッダー）を記述し、現実的な例を示す必要があります。
• その後、各自がこのディレクトリから/design-syncを実行し、求められた場合は/design-loginでアクセスを許可します。このスキルが独自に何かを送信することはありません。
• 再構築の手順と既知の注意点は.design-sync/NOTES.mdに記載されています。

アイデンティティまたは共有コンポーネントを更新した後は、エクスポートを再実行し、パッケージ内でnpm run buildを実行してから、/design-syncを実行します。

ステップ6 · 開発に進む

未解決の項目が作業を妨げていないことを確認し、実装ステータスを有効にします（ステップ7）。まだ回答していない場合は Design System のエクスポートを提案し（上記のオプションを参照）、繰り返し使うコンポーネントの一覧作成を提案します。また、tokens.cssは@import "tailwindcss";の後にそのまま貼り付けることを伝えます。希望があれば、注釈を受け入れ条件としてストーリーに分割します。

開発前に操作フローをテストしたり、デモを見せたりする場合、prototype-uiスキルを使うと、これらの仕様をクリック可能なプロトタイプに変換できます（同じ画面、シミュレーションデータ、テストシナリオ）。開発を開始するには、requirements-docスキルを使うと、チーム向けの要件定義書（受け入れ条件、アーキテクチャ、技術スタック、インフラ、作業単位、見積もりを含む作業単位ごとの仕様）を作成できます。

ステップ 7・開発中のメンテナンス

開発が始まった後も、仕様書は基準であり続けます。画面ごとにアプリケーションの動作を記述し、実装に合わせて更新します。specs/ ディレクトリはアプリケーションのリポジトリ内に置きます。

実装ステータス。 sources/site.json で有効にし（"implementation": true）、各ロットの lot.json で最新の状態に保ちます：

"status": { "e1": "done", "e2": "doing", "e3": { "status": "gap", "note": "Codex pas encore pris en charge" } }

• 値：todo（未着手、デフォルト）、doing（進行中）、done（リリース済み）、gap（差異：アプリケーションが仕様書と異なる場合。注記でその内容を説明します）。
• ビルド時に各状態の「新規」バッジがステータスに置き換わり、ナビゲーションにインジケーターが表示され、ロット一覧とホームに進捗が表示されます。要件定義書の抽出時にもステータスが引き継がれます。

開発中に見つかった差異は、判断を下し、コードと同じ変更に含めて反映します（同じブランチ、同じ PR）。

1. コードが正しい場合（技術的な制約、承認済みのより良い案）：画面のソースを変更し、イテレーションを増やし、その理由とともにロットのログに「実装に合わせて調整」と記録します。識別子（画面、状態、ルール番号）は維持します。コードとテストで参照されるためです。
2. 仕様書が正しい場合：コードを修正します。それまでは、注記を添えてステータスを gap にします。
3. 未解決の質問がある場合：ロットと CONTEXTE.md に未解決事項として記録し、ステータスを gap にします。

続いて、次の順に行います：

• 仕様書を再構築する；
• プロトタイプが画面を接続している場合は、その差異をプロトタイプに反映する（スキル prototype-ui の「仕様に従う」）；
• 要件定義書を再抽出し、影響を受ける受け入れ基準を調整する（スキル requirements-doc の「メンテナンス」）；
• 該当する成果物を公開する（prepare-publish.mjs … --check で更新が必要なものがわかります）；
• ソースと .published.json を一緒にコミットする（ビルド済みのサイトがバージョン管理されている場合は、それらも含めます）。

安定した番号付け。 機能ルールの番号は維持します。新しいルールはリストの末尾に追加し、廃止されたルールは「廃止」と記載して残します。削除された画面や状態の識別子も、予約済みのままにします。要件定義書の RF 識別子は、これらの番号をもとにします。

このスキルで行わないこと

• アプリケーションのコードは書きません。モックアップは静的であり、仕様書が引き続き基準となります。
• 第三者製品のアイデンティティを模倣しません。外部サイトは構成の参考としてのみ使用し、ビジュアルの手本にはしません。