Lism CSS 実装ガイド

Lism CSSでUI・ページ・コンポーネントを実装する時の判断の起点です。単なるリファレンスではなく、まず変更規模から「事前チェック実行レベル」を判定し、そのレベルに応じて実装前チェック→実装→提出前セルフチェックを通すことで、Primitive・トークン・Property Class・レスポンシブ設計の取りこぼしを防ぎます。

公式ドキュメント: https://lism-css.com/docs/overview.md

バージョン情報: このガイドはlism-css@0.26.0/@lism-css/ui@0.26.0時点の情報に基づきます。プロジェクトで使用中のバージョンが異なる場合は、ユーザーにその旨を伝え、パッケージ側の更新・またはこのスキルの更新を案内してください。

実装フロー（厳守）

資料確認は、コード上の操作の直前に行う。どの操作の手前で何を読むかは「資料確認トリガー」に従う。

0. 実行レベル判定: 変更規模から「事前チェック実行レベル」（不要/軽量/通常/値照合付き）を判定する。判定に迷う場合は一つ上のレベルを選ぶ。「不要」の場合、手順6（実装）以外の手順1〜5・7は行わない（.lism/へのファイル作成もしない）。「軽量」の場合、手順7はチャット内の数行の確認に簡略化し、.lism/review.mdは作らない。
1. 初期確認: SKILL.mdだけで実装しない。実装対象に明らかに関係する最小限の詳細ファイルだけを先に開き、実装プランに「初期確認した資料」を列挙する。リンク表を眺めただけは確認済みにしない。
2. 目的別実装ガイドでPrimitive/コンポーネントの候補を選定する。
3. 実装前チェック（C0–C8）を行い、初期確認した資料、使うPrimitive、コンポーネント、トークン、レスポンシブ方針を列挙した実装プランを出す。未読のまま採用できない判断は🔁を付け、対応する「読む資料」を実装プランの判断行に紐づける。値照合付きレベルでは、実装プランをチャットの返答としてではなく.lism/plan.mdとして保存する（規約はreferences/verification.md）。
4. 「資料確認トリガー」に従い、各操作をコードに書く手前で対応資料を読み、🔁を✅または⏸へ解消する。
5. ⏸が残る項目（px丸め・任意色・挙動変更・公開クラス変更など）は、その部分を実装する前にユーザー確認する。確認が取れない場合の運用は「判定記号」の⏸の項に従う。
6. 実装する。
7. 提出前セルフチェックで実装プランと実装を照合し、🔁の未解消・資料確認ログとの対応・差分・漏れを処理する。照合の実行はできる限り実装した本人から分離する（「提出前セルフチェック」の検証の分離を参照）。

C0–C8の詳細と出力形式はreferences/authoring.mdにまとめています。

判定記号

実装プラン（実装前チェックの成果物）の各行に付ける記号です。

判定記号と注記はここに挙げたものだけを使います（記号は✅/🔁/⏸、✅への注記は✅新規・✅例外・✅前提のみ）。注記を組み合わせたり（例: ✅例外/前提）、新しい記号・注記を作ったりしてはいけません。該当する行は未通過（🔁相当）として扱います。

直書き例外を✅例外にできるのは、antipatterns.mdの「直書きしてよい例外」（1px罫線・transform微調整・@media閾値など）に該当する場合だけです。✅例外の行には、この許可リストのどの項目に該当するかの引用を必ず添えます。引用を書けない場合、その行は⏸です。それ以外の例外化・丸め・新規トークンは⏸にします。この許可リストに例外カテゴリを自作して追加してはいけません。「正確に再現して」等のユーザー指示や実測値であることは✅例外の根拠になりません。デザイン値の既定の扱いはreferences/authoring.mdの「デザインデータ取り込みフロー」（入力種別と既定動作）に従います。

⏸のユーザー確認が取れない状況（自律実行など）では、原則準拠側の選択肢（すり合わせ済みの方針があればそれ、無ければ入力種別ごとの既定動作。例: 最寄りトークンへの丸め）を選び、該当行を選んだ選択肢の注記付きの✅前提（例: ✅前提（p="30"へ丸め））へ更新して前提を実装プランに明示した上で進め、完了報告で論点と代替案を列挙します。⏸のまま実装しない点は通常時と同じです。px直書き・例外カテゴリの新設・公開クラス変更・破壊的変更など逸脱側の選択肢は、この方式では採用できず⏸のままにします。

lism-css-refactorスキルは同じ記号を別の意味（✅=触らない、⬜=意図的に残す等）で使います。リファクタ時はrefactor側の定義に従い、どちらの意味で使っているかを表の見出しなどで明示してください。

実装プランのC一覧（実装前チェック項目）

このガイドでは、実装前に確認する項目をC0〜C8の番号で表します。CはCheck（確認）の略で、短く参照するためのラベルです。

事前チェック実行レベル

通常レベルでも該当しないCは省略して構いません。表を形だけ埋めず、実装に影響する項目だけ列挙してください。

資料確認トリガー

次の表の左の操作をコードに書く手前で、右の資料をまだ読んでいない場合、その判断は🔁（未通過）にする。対応資料を読んで✅へ解消するか、判断できなければ⏸にする。🔁のままコードへ反映してはいけません。

「必要なら参照」などの曖昧な表現で代替しない。対象操作の直前に読む。

最小ゲート

次のルールを常に守る。迷う・例外にする・既存実装と衝突する場合は、該当資料を読んで🔁を✅または⏸へ解消する。

• 構造は<div>+素のCSSよりPrimitiveを優先する。候補は「目的別実装ガイド」の表から選ぶ。
• c--*/b--*命名はBlockをcamelCase、Elementを_ひとつ、Modifierを--ふたつにする。c--feature-cardや__は使わない。
• 独自クラスは2分類（ベーススタイルを CSS 側で管理する共通基礎部品→b--／それ以外のカスタムクラス全般→c--）で命名する。
• 独自CSSは必ず@layer lism-custom内に置く（b--のベーススタイルだけ@layer lism-block）。
• トークン外のpx/rem/em値を勝手に丸めたり直書きしたりしない。丸め・新規トークン・直書き例外は⏸にする（antipatterns.mdの「直書きしてよい例外」に該当する場合のみ✅例外にできる）。
• c--*のクラスでは、単一要素にだけ効く宣言はCSSに書かず、まずLism Props/Property Classで表せないか確認する。CSSに残すのは擬似要素・子孫セレクタ・状態切替などProperty Classで書けない宣言だけにする。b--*のベーススタイルは対象外で、トークンを使って@layer lism-blockにCSSとして書いてよい（BP切替・hover・例外的な調整はProperty Class）。
• レスポンシブ値はbaseを必ず置く。container query運用なら必要なisContainer祖先を確認する。
• 状態はdata-*/ARIA、見た目バリエーションはBlockと同じプレフィックスのModifier（c--ならc--name--variant、b--ならb--name--variant）で表す。is--activeのようにTrait Classを状態名へ流用しない。

目的別実装ガイド

やりたいことからPrimitive/コンポーネントの候補を引く表です。候補が複数ある行は括弧内の基準で使い分けます。

提出前セルフチェック

実行条件: この節の照合と.lism/review.mdの作成を行うのは、実行レベルが「通常」「値照合付き」の場合だけです。「不要」では行いません。「軽量」では、変更点に関係する最小ゲート項目だけをチャット内で数行確認し、ファイルは作りません。

検証の分離（評価サブエージェント）: サブエージェント／タスク委任機能が使える環境では、この節の照合を実装した本人ではなく読み取り専用の評価サブエージェントに委任します（指示テンプレ・報告書式・再評価ループはreferences/verification.md）。評価報告は.lism/review.mdへ保存し、違反ゼロの報告が出るまで修正→再評価を繰り返してから提出します。完了報告では.lism/review.mdを参照します。委任機能が使えない環境では、同じ照合を本人がこの節の順に自分で実行します。

まず実装プランと実装を1行ずつ照合し、差分を「計画変更（意図的）/実装漏れ（直す）/要確認（再び確認が必要）」に分類します。その後、以下を確認します。

プロセス照合

• 実装プラン内の🔁が、提出前に✅または⏸へ解消されているか。🔁のままコードに反映した判断がないか。
• 資料確認ログの各行が、実装プラン内の判断項目と対応しているか。未読のまま採用したPrimitive/トークン/命名/レスポンシブ判断がないか。

ルール照合

• 「最小ゲート」の各項目に違反していないか。
• antipatterns.mdとantipatterns-layout.mdのTOCを開き、実装コードに該当しうる項目を1つずつ照合する。リンク表を眺めただけは確認済みにしない。

プラン再審査

実装プランの判定自体を再審査します。プラン段階で✅にした逸脱は実装との差分照合では検出できない（差分ゼロ＝合格になってしまう）ため、差分照合とは別に行います。

• ✅例外を含む✅判定を、最小ゲート・antipatterns.mdの「直書きしてよい例外」・すり合わせ済みの値マッピング方針に再照合する。許可リスト外の✅例外は⏸へ戻す。
• 値照合付きレベルでは、.lism/plan.mdにトークン差分表（差分列付き）が存在するか確認する。無ければその実装プランは無効。差分表を作成して照合をやり直す。スケール前提（画像の書き出し倍率等）が実測・整合チェックで検証済みかどうかも確認する（未検証なら差分表全体が無効）。
• 実行レベル判定が妥当だったかを見直す（デザイン再現なのに「値照合付き」へ上げず、トークン差分表を回避していないか）。

個別確認（最小ゲート・antipatternsでカバーされない項目）

• @lism-css/uiの既存コンポーネントで置き換えられないか。
• 同じProperty Classの組み合わせが3箇所以上ならコンポーネント化を検討したか。
• 既存の命名・レイヤー・ファイル配置に合っているか。
• デザイン再現（値照合付き）では、レンダリング結果の確認を完了報告の前提にする。環境的に確認できない場合は、完了報告にユーザーへの目視確認依頼を含める。HTTPステータスやビルド成功だけで完了扱いにしない。

詳細リファレンス

各ファイルの内容と、読むタイミングの目安です。

クラス単位の詳細リファレンス

Layout Primitives

• l--box/<Box>: primitives/l--box.md
• l--flex/<Flex>: primitives/l--flex.md
• l--stack/<Stack>: primitives/l--stack.md
• l--cluster/<Cluster>: primitives/l--cluster.md
• l--grid/<Grid>: primitives/l--grid.md
• l--flow/<Flow>: primitives/l--flow.md
• l--center/<Center>: primitives/l--center.md
• l--frame/<Frame>: primitives/l--frame.md
• l--columns/<Columns>: primitives/l--columns.md
• l--tileGrid/<TileGrid>: primitives/l--tileGrid.md
• l--autoColumns/<AutoColumns>: primitives/l--autoColumns.md
• l--switchColumns/<SwitchColumns>: primitives/l--switchColumns.md
• l--withSide/<WithSide>: primitives/l--withSide.md

Trait Class

• is--container/<Container>: trait-class/is--container.md
• is--wrapper/<Wrapper>: trait-class/is--wrapper.md
• is--layer/<Layer>: trait-class/is--layer.md
• is--boxLink/<BoxLink>: trait-class/is--boxLink.md
• has--transition: trait-class/has--transition.md
• has--gutter: trait-class/has--gutter.md
• has--snap: trait-class/has--snap.md
• has--mask: trait-class/has--mask.md

Atomic Primitives/Property Class

• a--icon/<Icon>: primitives/a--icon.md
• a--divider/<Divider>: primitives/a--divider.md
• a--spacer/<Spacer>: primitives/a--spacer.md
• a--decorator/<Decorator>: primitives/a--decorator.md
• -bd/-bd-{side}系: property-class/bd.md
• -hov:*系: property-class/hov.md
• -max-sz:full/-max-sz:bleed: property-class/max-sz.md

このスキルファイル自身のアップデート方法

ユーザーがスキル更新を依頼した場合は、lism-cli skill addまたはlism-cli skill updateを案内してください。最新を確認したい場合は、GitHubリポジトリのskills/lism-css-guideを確認してください。