ds-ascii

デザインシステムを使った ASCII プロトタイピング

平易な言葉で書かれたブリーフを、モノスペースのワイヤーフレームに変換します。各領域は独自のデザインシステムにあるコンポーネントとしてラベル付けされ、説明するのではなく、タイポグラフィの階層が目に見える形で示されます。

チャット、PR の説明、コードコメント、Slack のスレッドなど、テキストを扱える場所ならどこでも読める、実用的な仕様です。レンダリングパイプラインも、コンテキストの切り替えも不要です。さらに、モノスペースのグリッドという制約によって、優れたワイヤーフレーム作成に欠かせない、簡潔なボックスと矢印による思考が促されます。

落書き以上のものにしているのは、すべての領域が、実際にシステムに存在するコンポーネントに、正式な名前で対応していることです。これによって、デザイナーや開発者が実装できる図になります。

3 つのレイヤー

1. GRAMMAR.md — 描画方法。 フレーム、境界線の太さ、陰影の段階、文字サイズの段階、ボタンのランクを定義します。すべてに共通し、コンポーネント名は一切含みません。
2. ARCHETYPES.md — 描画するもの。 ページシェル、ヘッダー、ヒーロー、セクション、グリッド、カード、ボタン、フィールド、フォーム、テーブル、リスト、メディア、オーバーレイ、フッターの 14 種類です。これもすべてに共通します。
3. ds-ascii/PROFILE.md — チームでの呼び方。 アーキタイプと実際のコンポーネント名を対応付ける表です。intake/PROFILE-INTAKE.md で一度作成し、ユーザーのプロジェクト内に保持します。

アーキタイプはデザインシステムが異なっても変わりませんが、コンポーネント名は変わります。この分離が設計の要です。どのシステムにもカードはありますが、その領域の呼び方が一致するシステムはありません。

モード

モード 1 — レンダリング（通常の場合）

1. プロファイルを確認します。 ds-ascii/PROFILE.md があれば読み込み、最新の状態か確認します（「このプロファイルは に確認されています。現在も有効ですか？」）。プロファイルがなければ、先に intake/PROFILE-INTAKE.md を実行します。数分で完了し、その後の作業もすべて速くなります。
2. ブリーフからページの種類を読み取ります。 ホームページ、一覧、フォーム、ダッシュボード、認証画面などです。これによって骨組みが決まります。
3. 忠実度のレベルを選びます。 既定ではワイヤーフレームにします。ブリーフに強いビジュアル上の特徴がある場合はイラスト付きにし、密度の高い領域はコピーを切り詰めるのではなくスケッチにします。
4. 上から下へ構成し、各領域をアーキタイプに、各アーキタイプを対応するコンポーネントに割り当てます。
5. tools/build_example.py のパディングヘルパーを使って作成し、幅を正確に保ちます。手作業で文字数を数えると、レンダリングが崩れます。
6. 実際のコンポーネント名を使った ANATOMY の凡例を下に記載し、文法に手を加える必要があった場合は DEVIATIONS の注記を追加します。

モード 2 — プロファイルの作成または更新

intake/PROFILE-INTAKE.md を実行します。レンダリングで生成された名前が見つからないと言われた場合や、システムのメジャーバージョンがリリースされた場合にも、この方法が適切です。

モード 3 — 別のプロファイルで再レンダリング

ブリーフはそのままに、別のプロファイルを使います。2 つのシステムで何が簡単にできるかを比較するのに便利です。また、examples/ のプルーフゲートでもこの方法を使います。

レンダリングを正確に保つためのルール

1. コンポーネント名を決して作り出さないでください。 プロファイルに対応付けがないアーキタイプは、汎用的な形状を描画し、凡例に <unmapped: hero> と記してください。ほとんどのコンポーネントライブラリにはページレイアウト用のものがないため、これは頻繁に起こりますが、失敗ではありません。その旨を示すレンダリングは、システムについて正しい情報を伝えています。
2. 根拠タグをそのまま引き継いでください。 マニフェストから読み取った対応付けには [verified]、人から聞いた対応付けには [reported] を付けます。レンダリングが [reported] の対応付けに依存する場合は、その旨を凡例の下に記してください。
3. フレーム幅を決して超えないでください。 長い行がひとつあるだけで折り返され、その下のボックスがすべて崩れます。ヘルパーがチェックするので、実行してください。
4. 枠で囲まれた領域に絵文字を使わないでください。 絵文字は全角幅のため、右端の位置がずれます。絵文字はフレームの周囲にある文章で使ってください。
5. 逸脱を明記してください。 実際のページに合わせるため文法を曲げた場合は、その内容を下に記してください。明記された逸脱は、読者が確認できる判断です。明記されていない逸脱はルール違反です。
6. 出力が何ではないかを説明してください。 これはワイヤーフレームの仕様であり、生成されたコードではありません。マークアップを期待してビルドに貼り付けないようにしてください。

アンチパターン

• すべて同じ強さの平坦なテキスト。階層が見えなければ、レンダリングは失敗です。
• ラベルのない ASCII アート。これは装飾であり、プロトタイプではありません。
• 図の中でネストされたパーツにタグを付けること。コンテナーにタグを付け、パーツは凡例に記載してください。
• プライマリボタンとセカンダリボタンを同じ強さでレンダリングすること。優先度を見せる必要があります。
• プロファイルのアンチパターンで禁止されている場合に、カードのメディア領域に見出しを置くこと。
• 幅52カラムのフレームに、実際の文章を3列で配置すること。1行あたりの文字数は約11字しかありません。2列に減らすか、忠実度を下げてください。

このキットのファイル

• GRAMMAR.md — 汎用レンダリング文法
• ARCHETYPES.md — 14種類の形状と、それぞれの対応付けに関する質問
• intake/PROFILE-INTAKE.md — プロファイルを作成する根拠の連鎖
• profiles/PROFILE-FORMAT.md — プロファイルのファイル形式
• profiles/material-web.md、profiles/eddie.md — 意図的に正反対の、実際に検証された2つのプロファイル
• reference/CAPABILITIES.md — このスキルでできること、できないこと
• reference/FIGMA-ACCESS.md — デザインライブラリへのアクセス方法と、各ブリッジが実際に参照できるもの
• examples/ — 同じブリーフを両方のプロファイルに適用してレンダリングした例
• tools/build_example.py — パディング用ヘルパー

状態（ユーザーのプロジェクト内）

ds-ascii/
└── PROFILE.md          ← the binding table, built once

ファイルを書き込める場合は、プロファイルをそこに保存してください。書き込めない場合は、ユーザーが保存して次回貼り戻せるよう、メッセージとして作成してください。