Skip to content
← キットに戻る

デザインシステムアドオン

ユーザー向けのインターフェイス面を持つリポジトリに DESIGN.md を与えます。これは、どのコーディングエージェントも読み取る Markdown のデザインシステムファイルで、エージェントが手がかりなしに頼ってしまうスタイルのない統計的にありふれたデフォルトではなく、リポジトリ自身の規約に一貫したインターフェイス出力を生成するためのものです。Deep Work Plan の四番目のオプトイン式アドオンです。

「インターフェイス面」は複数あります。レンダリングされるビジュアル UI、スタイルづけされた CLI 出力、そして会話の面(プロダクトがチャットやメールで語る)のそれぞれが数えられます。アドオンはそれぞれをプロファイルとして独立に検出し、受け入れられたプロファイルは同じ単一の DESIGN.md に積み重なります。

追加されるもの

  • docs/DESIGN.md に置かれる DESIGN.md(リポジトリの他の仕様と並んで。docs/ ツリーがない場合にのみリポジトリのルートに置かれます)。AGENTS.md から参照され、エージェントが他のドキュメントと同じように発見できます。一つのリポジトリに一つのファイル。面ごとの兄弟ファイルは決して作りません。
  • visual-ui プロファイル — 標準のビジュアルのセクション群。概要/雰囲気、カラーパレットと役割(ライト+ダーク)、タイポグラフィ、レイアウトと余白、エレベーションと奥行き、シェイプ、コンポーネント、レスポンシブな挙動、すべきこととすべきでないこと(リポジトリのアクセシビリティルールを含む)。
  • cli-output プロファイル — スタイルづけされたターミナルインターフェイス。出力のボイス、セマンティックなカラーとスタイル(success/error/warning/info/dim を実際のテーマに対応づける)、出力コンポーネント(パネル、テーブル、スピナー、対話的なプロンプト。リポジトリの実際のヘルパーにちなんで名づけられる)、レイアウトの慣習、そして劣化のルール(TTY 対パイプ、NO_COLOR、stdout/stderr の規律、終了コード)。
  • conversational プロファイル — プロダクトのメッセージング面。ボイスとレジスター(トーン、簡潔さ、ブランド名の規則)、メッセージの構造(DM、チャンネル投稿、スレッド返信、その場での編集)、そしてプラットフォームごとのレンダリング(Slack mrkdwn、Discord markdown、Teams アダプティブカード、メール)とプレーンテキストのフォールバック。
  • 共有のエージェント向けプロンプトガイド、そして各プロファイルの整合性を確認する検証ステップ。文書化されたテキストのコントラストが WCAG AA を満たすこと(ビジュアル)、色が意味の唯一の担い手にならないこと(CLI)、リッチなレンダリングがプレーンテキストのフォールバックを記すこと(会話)、そしてトークン参照が解決されること。

挙動

  • コピーするのではなく、推論する。 すべての値は、リポジトリの実際のデザインソース、すなわちスタイルシート、CSS カスタムプロパティ、Tailwind の設定、トークンファイル、コンポーネントのスタイル、CLI の表示/テーマモジュール、あるいはメッセージ組み立てのヘルパーから導かれます。第三者ブランドの DESIGN.md を貼り付けたり、別のプロダクトの規約を丸ごと持ち込んだりすることは決してありません。参照カタログは構造のためのインスピレーションであり、内容のためではありません。
  • 上書きするのではなく、調和させる。 既存の DESIGN.md やトークンソースは、上書きされることなく加算的に調和されます。新しく受け入れられたプロファイルの追加は、そのセクションを書き足すだけで、残りを書き換えません。破壊的な変更には承認が必要です。
  • 参照による発見。 DESIGN.md がどこにあろうとも、AGENTS.md(および CLAUDE.md)がそれを参照します。エージェントがそれを読み込むことを保証するのは、物理的な場所ではなくその指し示しです。
  • 実用的であり、硬く縛られない。 従うべき形として、登場しつつある DESIGN.md の慣習を参照し、それをビジュアル以外の面へ広げ、Markdown を第一としたまま、いかなる単一のトークンスキーマにも縛られません。

インターフェイスに限定され、プロファイルごとの強さを持つ

このアドオンは、実際のインターフェイス面を少なくとも一つ持つリポジトリのためのものです。一つも持たないリポジトリ(純粋なライブラリ、ヘッドレスなサービス、インフラのみのリポジトリ)には決して提案されません。各プロファイルは、それぞれ固有の推奨の強さを持ちます。

  • visual-ui は検出されたときはデフォルトでオン — CSS カスタムプロパティを備えたスタイルシート、Tailwind の設定や @theme ブロック、UI コンポーネント、あるいはブランド/スタイルガイド。オンボーディングはトラストモードでこれを適用し、ガイドモードでは強く推奨します。
  • cli-outputconversational は検出されたとき推奨され、必ず尋ねられ、決して自動適用されません。トラストモードでも同様です。CLI のレンダリングライブラリと意図的な表示レイヤーが前者の、チャットプラットフォームの SDK やメッセージ組み立てレイヤーが後者の合図です。生の print を伴うだけの素朴な引数パーサーは該当しません。

これが必須となることは決してなく、アドオンがゼロのリポジトリも完全に適合しており、どのプロファイルもアドオン全体も、いつでも辞退できます。プロファイルが存在する前に作られた DESIGN.md は、有効な単一プロファイルのビジュアルファイルです。移行は不要です。

任意のコマンド

受け入れられたとき、アドオンはあとで DESIGN.md を再生成または更新するための /design-system 委譲を、リポジトリの .agents/commands/ にインストールすることがあります。コマンドのインストールは任意です。辞退されたアドオンは何もインストールしません。

機能ごとのデザイン文書との関係

これはリポジトリレベルで永続するデザインシステムファイルであり、機能ごとの技術設計文書(ツールに縛られたスペック駆動ワークフローの「要件 → 設計 → タスク」の design.md)とは異なります。Deep Work Plan は、機能ごとの設計文書アーキタイプを意図的に別途備えていません。計画の README、各タスクの受け入れ基準、そして検証ゲートがすでにその役割をカバーしています。このアドオンは、その役割がカバーしない唯一の隙間、すなわち耐久性のある、リポジトリにネイティブなインターフェイスデザインのコンテキストを埋めます。