designkit

designkit

誰かの頭の中や Figma の中にあるデザインシステムは、UI を書くエージェントからは見えません。その代わりとしてエコシステムで定着したのが DESIGN.md です。Google Labs が公開したオープンフォーマット（Apache-2.0、google-labs-code/design.md）で、YAML のフロントマターに機械可読なデザイントークンを、本文に人が読める根拠を記述します。コーディングエージェントがすでに読み込むエージェント指示ファイル（CLAUDE.md とその同等ファイル）に意図的に対応するデザイン版であり、セッションをまたいで保持されるリポジトリルートの契約です。また、DESIGN.md に対応するすべてのエージェントが読み込みます。

designkit は、エコシステムで手つかずになっていた部分を担います。他のツールはどれも、Stripe をリバースエンジニアリングしたファイルや、製品タイプの検索テーブルから取得したパレットなど、別の場所からデザインシステムを渡します。designkit は、すでにリリースした UI からあなたのデザインシステムを導き出し、後になって古くなったときに知らせます。

そのため、根拠に基づくというルールがこのスキルの核心です。**すべてのトークンは、コードベースに現れる値でなければなりません。**唯一の例外は、UI がまったくなく、導き出すものがないリポジトリです。その場合、すべてのトークンはユーザーが指定した値です（init のヒアリングを参照）。それでも designkit が値を捏造することはありません。ほぼ同じ 40 種類のグレーをスケールにまとめるのは導出です。丸めやすいという理由で、隣り合うよりきれいな 16 進数値を選ぶのは捏造であり、designkit が決して行わない唯一のことです。

designkit がしないこと

• **UI ジェネレーターではありません。**システムを記録するだけで、コンポーネントやページ、アプリケーション CSS は書きません。好みを定義するスキルが同時にそれを適用するなら、根拠に基づくというルールを守らせることはできません。
• **好みのライブラリではありません。**パレットやフォントの組み合わせ、スタイルカタログは提供しません。プロジェクトにデザインシステムがない場合、designkit はコードですでに使われている値から提案します。UI がまったくない場合は、ユーザーが指定した値から提案します。どちらもない場合は、その旨を伝えます。他者のものを取り込むことは決してありません。
• **仕様の実装ではありません。**リント、コントラストチェック、トークンのエクスポート、スキーマ自体は公式 CLI が担います。designkit は外部コマンドを実行して結果を報告するものであり、二流の実装をもう一つ作るものではありません。
• **デザイン批評ではありません。**システムが良いかどうかを判断するのは人間です。designkit は、そこにあるものを報告します。たとえそれが混乱した状態でも同じです。
• **用語集や意思決定ログではありません。**ドメインの用語やアーキテクチャ上の決定は別の場所に記録します。デザイントークンはそのどちらでもありません。

起動する場面

• init。「DESIGN.md を書いて」「デザインシステムを文書化して」「デザイントークンがない」「このプロジェクトでは実際にどんな色を使っている？」といった場合です。コードベースからファイルを導き出します。
• update。「デザインシステムが変わった」「DESIGN.md を更新して」、または UI 作業の反映直後にデザインを見直す場合です。コードに現在記述されている内容を適用します。
• audit。「DESIGN.md はまだ正確？」「コードと照らしてデザインシステムを確認して」「どこにずれがある？」といった場合です。読み取り専用の確認です。一切書き込みません。
• sync。「DESIGN.md を Tailwind テーマに同期して」「トークンをエクスポートして」、またはファイルとトークンの保存先が食い違っている場合に、フォローアップの init で指定します。DESIGN.md からプロジェクト既存のトークン保存先に書き込みます。

モードが明確でない場合は、質問してください。audit は無料ですが、init はプロジェクトのデザイン契約を書き換えます。両者を決して推測で選ばないでください。

各モードで書き込み可能な内容：

モード	書き込み内容	条件
init	DESIGN.md、スウォッチシートとその .gitignore 行	提案
update	DESIGN.md のトークンと本文の編集。条件付き変更で必要な場合は、スウォッチシートとその .gitignore 行	新しいセクション、削除、対象範囲外のずれ
audit	なし	なし
sync	既存のトークン保存先（Tailwind テーマ、:root ブロック）、または DTCG エクスポートファイル	書き込みごと

成果物

DESIGN.md はリポジトリルートに置きます。これは仕様の慣例であり、DESIGN.md 対応ツールがファイルを見つける場所です。整理しやすいからといって docs/ に置かないでください。

トークンスキーマ

フロントマターは、行全体が --- の行で始まり、同じ形式の行で閉じます。これは 2026-08-06 時点で記録されたアルファ版のスキーマです。形式は明示的にまだ変更中のため、CLI が使える場合は最新の内容を直接確認してください。

version: <string>          # optional, current: "alpha"
name: <string>
description: <string>      # optional
omitted: <string[] | OmittedSection[]>   # optional; sections deliberately excluded
colors:
  <token-name>: <Color>            # "#1A1C1E", "oklch(62% 0.18 250)", CSS named
typography:
  <token-name>: <Typography>       # fontFamily, fontSize, fontWeight, lineHeight,
                                   # letterSpacing, fontFeature, fontVariation
rounded:
  <scale-level>: <Dimension>       # 4px, 0.5rem, 9999px
spacing:
  <scale-level>: <Dimension | number>
components:
  <component-name>:
    <token-name>: <string | token reference>   # "{colors.primary}"

値は {path.to.token} 構文で相互参照します。参照のないトークンは orphaned-tokens を引き起こし、同じリテラルを重複させるとシステムにずれが生じるため、リテラルを繰り返すより参照を使うことをおすすめします。

推奨トークン名（規範ではありませんが、プロジェクトに独自の用語がすでにない限り、これに従ってください）：色は primary、secondary、tertiary、neutral、surface、on-surface、error、タイポグラフィは headline-display、headline-lg、headline-md、body-lg、body-md、body-sm、label-lg、label-md、label-sm、角丸は none、sm、md、lg、xl、full です。

セクション

正規の ## 見出しは 8 つあり、次の順序にします。順序が異なるセクションは section-order を引き起こし、見出しの重複はファイルを拒否する重大なエラーになります。

#	セクション	別名	内容
1	概要	ブランドとスタイル	ビジュアルの意図を文章で記述
2	色	なし	パレットの根拠、colors トークン
3	タイポグラフィ	なし	文字の階層、typography トークン
4	レイアウト	レイアウトと余白	グリッド、余白、spacing トークン
5	高さと奥行き	高さ	影とサーフェスの階層
6	形状	なし	角の表現
7	コンポーネント	なし	コンポーネントの指針、components トークン
8	すべきこと、すべきでないこと	なし	ガードレール、アンチパターン、UI コピーの文体

仕様では未知の見出しがエラーなしで保持されるため、「すべきこと、すべきでないこと」の後にさらに 2 つのセクションを追加できます。## Motion と ## Dark Mode です。どちらも文章のみとするのは、下記の理由があるためで、文体上の好みではありません。

文体に関する内容は、独立したセクションではなく、「すべきこと、すべきでないこと」に含めます。画面上の文字列に関するルール（「エラーでは失敗ではなく、解決方法を示す」など）はガードレールであり、仕様にはすでにガードレール用のセクションがあります。

YAML に記述してはいけないもの

ドキュメントから推測したのではなく、リンターを実行して確認済みです。妥当に見える次の 2 つの形式は、他に問題がないファイルでも警告を発生させます。

つい書きたくなるもの	リンターの動作	代わりにすること
トップレベルの motion: トークンマップ	⚠️ token-like-ignored、「デザイントークンマップのように見えますが、認識されるスキーマキーではありません……エクスポートコマンドで黙って無視されます」	## Motion に文章で記述
コンポーネントの transitionDuration:	⚠️ broken-ref、「認識されないコンポーネントのサブトークンです」	## Motion に文章で記述

有効なコンポーネントのサブトークンは、backgroundColor、textColor、typography、rounded、padding、size、height、width のみです。 duration も easing も border も gap もありません。それ以外はすべて警告されます。

つまり、このスキーマにはモーション用のトークンを置ける場所はありません。 仕様が置き場所を追加するまでは、時間とイージングカーブは文章で記述するのが正直な表現です。

トークンとして有効なのは、仕様で定義されている関連キーのパターンを使ったインタラクション状態です。例：button-primary、button-primary-hover、button-primary-active。これらは実際のコンポーネントエントリーとして抽出してください。このパターンですでに表現できる状態を保持するために、独自のキーを作らないでください。

スタンプ

designkit が書き込むファイルはすべて、最後のセクションの後に、次の 1 行が見える形で記載されます。

_Extracted from `main`@`a1b2c3d` on 2026-08-06._

どちらの部分にも役割があります。SHA が参照可能な間は、audit が git show <sha>:DESIGN.md でベースラインを復元します。squash merge によって SHA が参照できなくなった後は、日付にフォールバックします。HTML コメントはどのレンダラーでも表示されません。そのため、古いファイルが最新に見えてしまうのです。

スタンプがないファイルは、人が書いたものです。そのファイルを引き継いで作業し、黙って自分のものだと主張しないでください。また、designkit が作成したものではないファイルを編集していることを明確に伝えてください。

CLIが信頼できる情報源です

フォーマットは現在 alpha 版で、活発に開発中です。スキルにスキーマをハードコードすると、スキルが自信満々に誤った情報を返すことになります。そのため、実行時に仕様を読み込み、上記の要約は作成時点のフォールバックとして扱ってください。

コマンド	用途
npx @google/design.md spec [--rules] [--format json]	現在のスキーマとルールセット
npx @google/design.md lint <file> [--format json]	検証します。デフォルトは JSON です
npx @google/design.md diff <before> <after>	2 つのバージョンを比較します
npx @google/design.md export --format {json-tailwind|css-tailwind|dtcg} <file>	トークンを出力します

終了コード：0 は成功、1 はエラーまたはリグレッション、2 はファイルの読み取り失敗です。Windows PowerShell では、.md ファイルの関連付けによってもう一方の形式が横取りされるため、designmd エイリアスを使ってください。

11 個の lint ルールはすべてのファイルで実行されます：broken-ref（エラー）、contrast-ratio、orphaned-tokens、missing-primary、missing-typography、section-order、unknown-key、token-like-ignored（警告）、および token-summary、missing-sections、omitted-rules（情報）。contrast-ratio はすでに WCAG AA の 4.5:1 を適用するため、独自にコントラストを計算しないでください。

抽出エンジン

init、update、audit で共有される単一のエンジンです。init は出力を書き込み、update は差分を確認して適用し、audit は差分を確認して報告します。audit はエンジンが唯一書き込みを行う 作業内容を示す をスキップします。監視対象パスのマニフェストを維持する必要はないため、glob の対象漏れによって変更が見落とされることもありません。

トークンの配置先を見つける

最初に一致した項目を選び、何も書き込む前にどの項目が一致したかを伝えてください。

#	項目	例
1	Tailwind	CSS の @theme（v4）、または tailwind.config.* の theme.extend（v3）
2	CSS カスタムプロパティ	--token: value が記述された :root ブロック
3	プリプロセッサ変数	SCSS の $vars、Less の @vars、マップファイル
4	CSS-in-JS テーマ	プロバイダーに渡されるテーマオブジェクト
5	WordPress	theme.json の settings.color.palette、settings.typography
6	該当なし	どこにも定義済みトークンがありません。システムがない場合を参照してください

宣言ではなく使用状況から導き出す

誰にも使われていない宣言済みトークンはデザインシステムではありません。一方、ハードコードされた 40 個のカラーコードはそうです。両方を確認してください。

• スタイルシート、テンプレート、コンポーネントにあるすべてのカラーリテラル。つまり、hex、rgb()、hsl()、oklch()、色名です
• 実際に適用されているフォントサイズ、ウェイト、行の高さ
• 繰り返し使用されているパディング、マージン、ギャップの値
• 使用されている角丸とシャドウ
• 実際にスタイル指定されているインタラクション状態：:hover、:focus-visible、:active、disabled と、フレームワークでの同等の状態
• ダークモード：.dark、prefers-color-scheme、dark: バリアント、[data-theme] を grep します

出現回数を数えてください。90 回使われる値と 1 回だけ使われる値は、同じ程度にシステムの一部とは言えません。出現回数が、次の作業の妥当性を裏付けます。

すべてのトークンを分類する

各トークンには 3 つの状態のいずれかが割り当てられ、分類は同意確認の段階で表示されます。

状態	意味
extracted	値がコード内にそのまま存在し、システムとして扱えるほど十分に使われています
consolidated	似た値 N 個からまとめられています。統合をレビュー可能かつ元に戻せるよう、それらの値を列挙します
omitted	コードから導き出せないため、仕様のネイティブな omitted フィールドに記載します。決して作り出しません
supplied	抽出対象の UI がないリポジトリで、init のインタビュー中にユーザーから提供された値です

omitted は失敗ではなく、機能です。 このフィールドは、意図的な除外を宣言し、不足セクションの警告を抑制するために設けられています。正直にエレベーションを省略した DESIGN.md のほうが、シャドウスケールを作り出すものより優れています。

システムが存在しない場合

最も現実的に起こりそうな入力は、ハードコードされた値が何百個もあり、トークンを定義する場所がなく、一貫性もない状態です。designkit はクラスタリングして提案します。拒否したり、好みが画面上にすでに現れているのに、ただ雑然としているという理由でインタビューに切り替えたりはしません。

提案はグラウンディングのルールに従います。提案するすべてのトークンは、コード内に存在する値です。 ほぼ重複している値をクラスタリングし、各クラスタで最も使用頻度の高い値を代表として選び、取り込んだ値を列挙します。コードベースに一度も存在したことのない値は、決して出力しません。

クラスタのしきい値はプロジェクトに合わせて調整し、使用したしきい値を明記してください。これは判断を伴うため、明記されていなければレビューできません。色には知覚距離、スペーシングとタイポグラフィには最も近い段階を使います。ひとつのシステムと呼ぶにはクラスタの幅が広すぎる場合は、無理に統合せず分割し、その旨を伝えます。

作業内容を示す

このステップは init で実行し、update ではゲートされた変更のレビューが必要な場合にのみ実行します。audit はファイルに書き込むため、このステップをスキップします。

何かを書き込む前に、使い捨てのスウォッチシートを出力します。色チップ、タイポグラフィの見本、スペーシングバー、角丸を並べたシンプルな HTML ページで、それぞれにトークン名、状態、取り込んだ値をラベルとして付けます。「40 個のグレーが 6 個になった」という変更を YAML の差分でレビューするのは現実的ではありませんが、スウォッチなら数秒で確認できます。

これは成果物ではなく、レビューを支援するものです。 Git で無視されるスクラッチ用パスに書き込み、そのパスが対象になっていなければ .gitignore に追加し、同意を求める際にその場所を伝え、保存しておかないでください。これは、このスキルが書き込みを拒否する生成 UI とは明確に異なり、判断のための証明シートです。

モード：init

1. 根拠を確認する

抽出エンジンを実行します。提案を始める前に、該当した段階、カテゴリごとに見つかった異なる値の数、ダークモードの判定を伝えます。すべてのカテゴリ（色、タイポグラフィ、スペーシング、角丸、シャドウ、状態、ダークモード）に件数または「見つかりません」が示されたら、このステップは完了です。

2. 読み取るものがない場合に限り、インタビューする

リポジトリに UI がなければ、抽出するものもありません。基本事項（ブランドの意図、既存のパレット、タイポグラフィの好み）を尋ねます。ユーザーが提示した値はすべて supplied トークンになり、designkit が独自に値を追加することはありません。レポートとファイルの Overview の両方で、結果が抽出したものではなく、提案したものであることを明確に伝えます。まだ不明なものは omitted にします。エンジンが UI を見つけた場合は、このステップをスキップします。スキーマのすべてのカテゴリに supplied トークンがあるか、omitted になったら、このステップは完了です。

3. 提案し、ゲートで確認を取る

スウォッチシートに加え、extracted／consolidated／omitted の内訳、クラスタのしきい値、見つかったすべての不整合を提示します。ユーザーがファイルの作成前に提案を受け入れる、削る、または方向を変えるため、ここが重要なゲートです。ユーザーが、必要に応じて内容を削ったうえで提案を受け入れたら、このステップは完了です。

4. 書き込み、スタンプの追加、検証

リポジトリのルートに DESIGN.md を書き込み、スタンプを追加してから lint を実行し、残っているものも含め、検出結果をそのまま報告します。受け入れることにした警告は抑制せず、受け入れたと報告します。lint が終了コード 0 を返すか、残っているすべての検出結果を報告するか、lint の未対応箇所を明示したら、このステップは完了です。

5. 引き継ぎ

このスキルの引き継ぎはすべて手順の文体で記述します。1文につき指示を1つにし、能動態、現在形、比喩なしで記述します。

変更内容。 作成したファイル、一致した段階、各状態に入ったトークンの数、省略したものを報告します。

保存先。 リポジトリのルートにある DESIGN.md、スウォッチシートの一時パス（破棄可能であることも明記）、および lint の結果を示します。

次の手順。 ファイルを読みます。これはプロジェクトのビジュアルアイデンティティに関する主張であり、人間が実際に確認すべき唯一のものです。次に、commitkit がインストールされていればそれを使ってコミットし、そうでなければ git add DESIGN.md を実行してコミットします。プロジェクトにトークンの保存場所があり、ファイルの値がそこにある値と異なる場合は、sync が次の手順です。保存場所がない場合、同期するものはなく、次の手順を新たに作る必要もありません。

モード：update

1. 対象を特定する

まず、未コミットの作業ツリーの変更を確認します（git status --porcelain が空でない場合は git diff HEAD を使い、git diff には表示されない未追跡ファイルも含めます）。それ以外の場合は、gitkit がインストールされていればそれを使ってベース参照との差分を取得し、そうでなければ gh repo view --json defaultBranchRef でリポジトリのデフォルトブランチを確認します。main と決めつけてはいけません。 選んだ対象を1行で明記します。対象によって、慎重に適用するで update が適用する範囲を定めます。対象の範囲を示し、未追跡ファイルも含めた変更済み UI ファイルを列挙した対象行ができたら、この手順は完了です。

2. 再抽出して差分を確認する

現在のコードに対してエンジンを実行し、その結果をコミット済みの DESIGN.md と比較します。記録された SHA にまだアクセスできる場合は、構造化されたトークン単位の比較のために npx @google/design.md diff <baseline> <current> も実行します。使用数を正確に保つため、対象だけでなくコードベース全体を再抽出します。その後、各差分を分類します。対象の変更されたハンクまたは未追跡ファイルに値がある場合は対象内、それ以外は対象外です。すべての差分を分類したら、この手順は完了です。

3. 慎重に適用する

ブランドカラーが変わった場合は、カラーのトークンを編集します。ファイルは再生成しません。編集前に、影響を受けるセクションと、意図的に変更しないセクションを明記します。変更しないセクションの一覧は重要な要素であり、スキルが何をそのままにするか理解していることを示します。

差分が対象内にある既存のトークンや説明文の編集は、この制約の範囲内で直接適用し、レビュー可能な差分として残します。新しいセクション、削除、対象外の差分には同意が必要です。 対象外の差分は今回の変更より前に生じたものなので、一覧にし、許可された場合にのみ適用します。それ以外の場合は audit に回します。ボタンが1つ変わっただけでデザインシステム全体を書き換えるスキルは、スキルがないよりも劣ります。対象内の差分をすべて適用し、同意が必要な項目すべてに判断が下されたら、この手順は完了です。

4. 記録を更新して検証する

現在の参照と SHA で記録を更新し、lint を実行して結果を報告します。記録に現在の SHA が記載され、lint の結果が報告されたら、この手順は完了です。

5. 引き継ぎ

変更内容。 編集したトークン（値の変更内容を示し、1行に1つ）、提案したセクションとその判断、対象外の差分とその判断、意図的に変更しなかったセクションを報告します。

保存先。 DESIGN.md と lint の結果を示します。

次の手順。 commitkit を実行し、ブランチでの作業の場合は続けて prkit を実行します。それ以外の場合は git commit と gh pr create を実行します。デザインシステムは、それを変更した UI の変更と同じコミットに含めます。これをリポジトリに置いておくのは、そのためです。

モード：audit

読み取り専用です。書き込みは一切行いません。 結果を報告して次の対応先を案内します。修正は別の呼び出しで行います。

3 つのチェックがあります。

• Lint。 npx @google/design.md lint を実行し、検出結果をそのまま報告します。
• ドリフト。 これは designkit だけが実行できるチェックです。リンターはファイルをそれ自体と照合するだけで、コードベースを参照できないためです。確認する方向は 2 つです。ファイル内にあるもののコードにはもう現れないトークンと、コード内にあるものの、どのトークンにも対応していない値です。
• ベースライン。 SHA に到達可能な場合、git show <stamped-sha>:DESIGN.md と比較するために npx @google/design.md diff を実行します。ベースラインのコピーはシステムの一時ディレクトリ（mktemp）に書き込み、リポジトリには決して書き込みません。

スウォッチシートを使わずに抽出エンジンを実行します。3 つのチェックそれぞれに結果または明示された不足事項が示されたら、監査は完了です。

レポート

判定	意味
current	ファイル内のトークンは、コードで使われているものと一致しています
stale	コード内でトークンの値が変わっています
orphaned	ファイル内のトークンがコード内のどこにも現れません
uncovered	コードで使われているものの、どのトークンにも対応していない値です
unverified	designkit が一度もチェックしていない、人が作成したファイルです

まず、スキャンしたファイル数とスキップしたファイル数を明記したカバレッジの行から始めます。UI の一部しか確認していないのに黙って済ませると、監査結果が問題なしという報告そのものに見えてしまうためです。その後、次の対応を 1 つだけ示します。

引き継ぎ

変更点。 何もありません。読み取り専用モードで何かが書き込まれたかどうか、読者に疑問を抱かせないよう、明確に伝えます。

保存先。 この返信内に記載します。既定では監査成果物はありません。求められた場合にのみ、保存を提案します。

次の対応。 最も重大なドリフトを 1 つ選び、update に案内します。ファイルが間違っているのではなく存在しない場合は、init に案内します。「ドリフトはありません」も有効な明示的な結果です。その場合は、システムが最新であると伝えて終了します。

モード：sync

同意を得た場合に限り、トークンの配置先がすでに存在する範囲だけを対象にします。 designkit は、トークンの配置先がないプロジェクトにトークンシステムを導入しません。それはドキュメントではなく、ビルドツールに関する判断だからです。トークンの配置先がない場合は、その旨を伝えて終了します。同期するものはありません。

1. 配置先と差分を確認する

エンジンのトークンの配置先を探すを実行し、該当する段階を明記します。各 DESIGN.md トークンと配置先の値を比較します。すべてのトークンに、配置先と同じ、異なる、または配置先にない、のいずれかが付いたら、この手順は完了です。

2. 同意を得てエクスポートし、書き込む

書き込みによって生じるトークンの変更を提示し、1 回だけ確認を求めます。許可された場合は、次の表に従って書き込みます。

トークンの配置先	方法
Tailwind	公式の export --format json-tailwind または css-tailwind
通常の :root カスタムプロパティ	css-tailwind はカスタムプロパティの v4 @theme ブロックを出力するため、これは変換ではなく転記となり、直接書き込みます
SCSS マップ、CSS-in-JS、WordPress theme.json	export --format dtcg を実行し、Style Dictionary などの変換ツールへ引き継ぎます

境界となるのはフレームワークではなく、変換の有無です。公式エクスポーターがすでに必要な形式を出力するなら、designkit が書き込みます。実際の変換が必要なら、designkit は DTCG を出力し、使用するツールを明記します。独自に作成した変換ツールは、いずれかの形式が変わるとすぐにずれてしまいます。

異なる、または配置先にないトークンをすべて書き込むか、変換ツールを明記したうえで DTCG としてエクスポートするか、ユーザーが辞退した時点で、この手順は完了です。

3. 引き継ぐ

変更点。 書き込んだトークンの配置先と、変更されたトークンを 1 行ずつ報告します。ユーザーが辞退した場合は、その旨を報告します。

保存先。 トークンの配置先のパス、または DTCG のエクスポート先のパスと、実行する変換ツールを示します。

次の対応。 commitkit がインストールされている場合は commitkit を使い、トークンの配置先と DESIGN.md をまとめてコミットします。インストールされていない場合は git commit を使います。

率直に状況を伝える

npx が使えない、ネットワークに接続できない、または CLI がないのは通常の状況であり、エラーではありません。上記のフォールバック用スキーマから抽出して書き出し、lint と export はスキップし、結果と同時に不足しているものを明示してください。

DESIGN.md を作成しました（12 色、6 種類のタイポグラフィスタイル）。npx が利用できなかったため、lint は実行していません。バンドルされた alpha フォールバックのスキーマを使用しました（2026-08-06 取得）。

実施していない検証を行ったと主張してはいけません。何もチェックしていないのに問題なしと報告されたファイルは、未チェックと報告されたファイルより悪いものです。

ファイルシステムがまったくない場合（ブラウザベースのエージェントなど）は、完成した DESIGN.md をパスをラベルにしたフェンス付きコードブロックで出力し、スウォッチシートは書き出さずに説明し、ユーザー自身が実行すべきコマンドを示してください。

注意事項

• 根拠を示すルールは、網羅性より優先されます。 情報が少なくても正直なファイルのほうが、情報を作り上げた完全なファイルより優れています。スケールを省略するか推測するかで迷ったら、省略してその旨を伝えてください。
• 操作による同意。 モードごとの表はこの処理が実行されるときを参照してください。update で対象範囲内の既存トークンを編集する場合は、抑制ルールに従い、レビュー可能な差分に反映されるため、確認を求めません。audit は変更を加えないため、何も求めません。
• 警告は抑制せず、報告してください。 lint の警告が残った場合は、受け入れた理由とともにレポートに記載してください。
• 既存プロジェクトの規約を優先します。 独自のトークン名、ファイルの配置場所、デザインドキュメントのレイアウトを採用しているリポジトリでは、その規約に従い、designkit はどの規約に従ったかを明示します。
• 仕様は alpha です。 セクション、スキーマキー、ルールは変更されます。実行時に CLI から読み取ってください。バンドルされたフォールバックを使用した場合は、その旨を伝えてください。
• 文章は理由を伝え、トークンは値を伝えます。 エージェントに必要なのは色の背景説明ではなく、16 進数値です。文章は、トークンだけでは表現できない意図と、何を使うべきでないかの説明にとどめてください。そうした文章全般を見直す場合は、インストールされていれば humankit を使用してください。