DESIGN.perfected.md prototype

同じ比較内容を、検証版DESIGN.mdのルールで作るとどう変わるか

前回のHTMLは「既存DESIGN.md寄り」の軽いレポートでした。これは同じ情報を、front matterのトークン、余白ルール、状態色、採点ブロックを強めに使って作った版です。

結論

検証版で作ると、説明資料というより「仕様化された分析レポート」に近づきます。

色・余白・角丸・タイポグラフィがfront matterで細かく決まっているため、各パーツの粒度が揃いやすくなります。一方で、毎回のHTML生成ではルールが重くなり、短いSkillとしての扱いやすさは少し落ちます。

正本
front matter tokens
ページ幅
1120px
角丸
12px
カード余白
24px
構造
31 blocks
既存 DESIGN.md
79

短く、運用しやすい

DESIGN.perfected.md
426

仕様として詳しい

lint result
0

errors / warnings

tokens
49

色・文字・余白・部品

既存版で作った時

読み物として軽い

短い説明、KPI、比較表を中心にして、判断が速いレポートになります。作る側も迷いにくく、Skillとしては扱いやすいです。

軽さ
92
仕様の細かさ
45
再現性
70
検証版で作った時

設計書として強い

トークンとコンポーネントを先に決めるため、同じ種類の資料を量産した時にブレにくくなります。Web UIやTailwind連携まで見据えるならこちらが強いです。

軽さ
58
仕様の細かさ
94
再現性
88

Difference table

同じ内容でも、見せ方はこう変わる

観点 既存DESIGN.md版 DESIGN.perfected.md版 実務判断
第一印象 軽い共有資料。すぐ読める。 設計レビュー資料。情報の型が強い。 日常レポートは既存版、標準化したい資料は検証版。
色の使い方 薄いチップと枠中心。落ち着いている。 primarysecondary、状態色を意味ごとに明確化。 検証版の「意味がある時だけ色を使う」ルールは採用価値が高い。
構造 結論、KPI、比較表、移植候補。 結論、トークン、採点、比較、採用フロー。 意思決定用なら採点ブロックが便利。
再利用性 HTML単体では読みやすいが、他UIへの転用は弱め。 Tailwind themeやcomponent tokenに落とし込みやすい。 Web UI連携を考えるなら検証版が強い。
運用コスト 短く、読む負担が少ない。 426行あるため、毎回読むには重い。 Skill本体は短く、詳細仕様は別紙がよい。
01

短い正本は残す

Skillが毎回読む中心ファイルは、今のように短く保つ方が使いやすいです。

02

検証版を参照資料化する

色運用、余白、状態チップ、Tailwind themeは、詳細ガイドとして分けると効きます。

03

必要な部品だけ移植する

まずはDo/Don't、primaryの使用制限、spacing tokenだけ入れるのが安全です。

Adoption map

どこを採用すると良さそうか

採用

primary は1画面で一番大事な強調だけに使う。資料が派手になりすぎるのを防げます。

採用

状態色は意味がある時だけ使う。成功、警告、危険、情報の使い分けが明確になります。

一部採用

Typography scaleは便利ですが、CSSでは負の letter-spacing を使わず、サイズ階層だけ取り込みます。

別資料

design.tailwind.theme.json はWeb UI連携用として残し、Skillの必読ファイルにはしない方が軽いです。

見送り

front matterを即座に唯一の正本にすると、既存の brand.css と二重管理になります。

Files

今回見ているファイル

/Users/kozawayoshiki/ad-creative-lab/.claude/skills/html-css-delivery/DESIGN.md
/Users/kozawayoshiki/Downloads/design検証結果/DESIGN.perfected.md
/Users/kozawayoshiki/Downloads/design検証結果/design.tailwind.theme.json
/Users/kozawayoshiki/Downloads/design検証結果/DESIGN.perfected.lint.json

このHTMLは、既存の比較内容を検証版のトークン思想で再構成した見本です。既存ファイルは変更していません。