lism-css Lism CSS リファクタガイド
このスキルは、既存のLism CSSコードをリファクタするための手順です。対象コードを読み取り、class・Props・CSS宣言・レスポンシブ指定などを確認し、見た目や挙動を変えずにLismらしい書き方へ整理します。
新規実装（デザイン/要件→コード）の作法は、別スキルの../lism-css-guide/SKILL.mdが担当します。このスキルでは、既存コードの確認と整理だけを扱います。token値・Primitive選定・命名規則などの一般ルールはここに重複して書かず、必要な時だけlism-css-guideを参照します。
バージョンによって変わる判断（token値・Primitiveの既定値・API）は、同じ環境に入っている
lism-css-guideを基準にしてください。
前提
このスキルは、lism-css-guideが同じ階層に入っていることを前提にします。
lism-css-guideがない場合は、ユーザーにlism-cli skill addで追加してもらってください。guideなしで、推測だけでリファクタ判断を進めないでください。
基本方針
- 見た目と挙動を変えない。変わる可能性がある提案は、通常のリファクタとは分けてユーザーに確認する。
- 差分を小さくする。すでにLismらしく書けている箇所は触らない。
- 外部から使われている名前は勝手に変えない。公開class名・外部JS・E2Eセレクタ・CMSに依存するclass名やDOM構造の変更は、必ずユーザー確認に回す。
- 関連箇所を同時に直す。CSSだけ直して、JS・テスト・HTML生成側の更新を漏らさない。
- 元の属性を落とさない。コンポーネント抽出やPrimitive置換で、
className/style/data-*/ARIA/event handlerを渡し忘れない。
判定記号
洗い出した各項目には、次のどれかを付けます。
| 記号 | 意味 |
|---|---|
| ✅ | 触らない（すでに問題ない／今回の対象外） |
| 🔧 | 修正する（修正案を出す） |
| ⏸ | ユーザー確認が必要（px丸め・色推測・挙動変更・外部依存など） |
| ⬜ | 意図的に残す（合意済みの例外・独自意図が明確） |
判定記号はこの4つだけを使います。新しい記号を作ったり、記号を組み合わせたり、判定をすり抜けるための注記を発明したり（例: ✅（丸め適用済み））してはいけません。リスト外の記号・注記が付いた行は未確定として扱い、該当Passの判定基準で判定し直します（確定できない場合は⏸）。
✅・⬜の行にも、洗い出し表の根拠列に理由を書きます。⬜の根拠にできるのは、(a) 今回の会話でのユーザーとの合意、(b) 各Passの判定基準に列挙された⬜条件に該当し、それをコード・設定・コメント等の事実で示せる場合（例: $is_container_query:0の設定行）だけです。「たぶん意図的」のような推測や、判定基準に無い例外カテゴリの自作は根拠になりません。事実で示せない場合は⏸にします。
⏸のユーザー確認が取れない状況（自律実行など）では、⏸の行は修正案に含めず現状維持のままにし、完了報告で論点と候補を列挙します。⏸を🔧や✅に変えて適用してはいけません。
注意:
lism-css-guideの新規実装用の表では、同じ記号でも意味が違うことがあります。このスキルの表では、上の意味で使ってください。
Pass（確認ステップ）定義
Passは、このスキル内で使う確認ステップの番号です。いきなり全観点を同時に見ると漏れやすいので、下の順番で1つずつ確認します。
詳しい判定基準・参照先・注意点はreferences/checklist.mdに集約しています。
| Pass | 確認すること |
|---|---|
| Pass1 | 対象コードの洗い出し |
| Pass2 | 構造（div手組みをPrimitive/Traitへ置き換えられるか） |
| Pass3 | 重複（3箇所以上あるものをコンポーネント化できるか） |
| Pass4 | Property Class化（CSSに書いた装飾をProps/classへ移せるか） |
| Pass5 | token（px直書き・存在しない値がないか） |
| Pass6 | 状態・バリエーション（is--の誤用がないか） |
| Pass7 | 命名（class名がLismの命名規則に合うか） |
| Pass8 | レスポンシブ（固定Grid・container指定漏れがないか） |
| Pass9 | 既定値重複（Primitiveが元々持つ指定を重ねていないか） |
| Pass10 | 提示前の見直し（自分の修正案で元の見た目や動きを壊していないか） |
ワークフロー（厳守）
- 範囲を決める。対象ファイル/コンポーネント/選択範囲を明示する。勝手に全体へ広げない。
- 読む。対象コード・周辺コード・利用箇所（CSS/JS/テスト/HTML生成側）を読む。
- Pass1を実行。class・Props・CSS宣言・style・@media・重複している束を1行ずつ洗い出し、洗い出し表を作る。洗い出し表はチャットの返答としてではなく
.lism/plan.mdとして保存し、以降のPassの判定・根拠はこのファイルを更新する（メタデータヘッダ等の.lism/規約はguideのreferences/verification.md）。 - Pass2–9を実行。洗い出し表の各行に判定を付ける。token値・正規Trait・命名規則・Primitive既定値のように、正解がguide側の一覧にある判定は、記憶で確定せず各Passの参照先を開いて照合する。それ以外の構造系の判断は、迷う行だけ
lism-css-guideを参照してよい。「迷わなかった」ことは、一覧照合を省略する理由にならない。 - 修正案の差分を作る。この時点ではまだユーザーに提示しない。
- Pass10を実行。提示前に、元の見た目や動きを壊していないかの確認と、洗い出し表の判定の再審査を行う。サブエージェント／タスク委任機能が使える環境では、この確認と再審査を実装した本人ではなく読み取り専用の評価サブエージェントに委任する（指示テンプレ・報告書式は
references/output-format.md）。評価報告は.lism/review.mdへ保存し、違反ゼロの報告が出るまで修正→再評価を繰り返す。委任できない環境では、本人が修正案を他人のPRとして見直す。 - 修正案を提示する。見直し後の修正案をdiff形式＋根拠つきで出す。⏸の項目はここでユーザーに確認し、勝手に確定しない。
- 適用する。ユーザーが実装を許可している場合だけ適用する。見た目・挙動を変えないことと、差分を小さくしたことを明記する。
- 検証して報告する。テスト/ビルド/型チェックを実行し、残ったリスクを報告する。これらは見た目が変わっていないことを保証しないため、レンダリング確認（devサーバー・スクリーンショット等）ができない環境では、完了報告にユーザーへの目視確認依頼を含める。ビルド成功だけで「見た目・挙動を変えていない」と断定しない。完了報告では
.lism/review.md（評価報告）を参照する。
成果物の書式はreferences/output-format.md、before→afterの実例はexamples/markup.md（Pass2: Primitive化）/ examples/component-extraction.md（Pass3: コンポーネント抽出）/ examples/css.md（Pass4: Property Class化）を参照してください。
参照方針
lism-css-guideの個別ファイルは、各Passの参照先に従って必要なものだけ読む。- Pass10では、
checklist.mdのPass10に従って提示前の見直しを行う。ワークフロー本文では参照先を重複させない。
このスキルファイル自身のアップデート方法
ユーザーがスキル更新を依頼した場合は、lism-cli skill addまたはlism-cli skill updateを案内してください。最新を確認したい場合は、GitHubリポジトリのskills/lism-css-refactorを参照してください。