ss-lint について
ss-lint は、デザインルールに沿って UI コードを確認する StyleSeed スキルです。標準チェッカーでアーティファクトに紐づく診断を行い、重大エラーと検出器の警告を区別します。
主な機能
- 01アーティファクトレジストリの確認
- 02JSON と SARIF のスキャン出力
- 03検出結果の安定した証拠
- 04UI 規約の手動チェック
- 05コードを変更しない lint モード
活用シーン
- 01ビルド前の変更 UI ファイル確認
- 02トークンや間隔のずれの検出
- 03機械可読な lint 証拠の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ bitjaru/ styleseed --skill ss-lintインストール後、Claude Code で/ss-lintを入力して読み込まれたか確認します。
詳細
このワークフローを実行する前に、セッションごとに1回だけ更新の事前確認を実行してください。
デザインの静的チェック(クイックチェック)
レジストリ優先の成果物境界
.styleseed/project.json と .styleseed/artifacts/index.json が存在する場合は、まず要求された成果物 ID を解決し、その後 .styleseed/bundles/<artifact-id>.md と .styleseed/manifests/<artifact-id>.json のみを読み取ります。レジストリを使用するプロジェクトで、グローバルなレガシーバンドルにフォールバックしてはいけません。レガシープロジェクトでは、レジストリが存在しない場合に限り .styleseed/effective-rules.md を使用できます。
正規の実行可能チェック
機械可読な出力を伴う、再現可能な成果物に紐づいたスキャンには、次を使用します。
node <installed-ss-score>/scripts/styleseed-check.mjs scan \
--project-root . --artifact <artifact-id> --format json
node <installed-ss-score>/scripts/styleseed-check.mjs scan \
--project-root . --all --format sarif
チェッカーは、コントラクト、包含関係、マニフェスト/ハッシュ、不正なレポート、および必須カバレッジの失敗のみをハードエラーとして扱います。検出結果(SS001~SS006)は警告のままで、安定したファイル名、行番号、証拠スニペット、重大度、および修正方法が含まれます。紐づけられた証拠の実行結果を再計算するには styleseed-check ... verify を使用してください。文字列や古いレポートを合格扱いにしてはいけません。
いずれかのレジストリファイルが存在する場合は、有効で完全なレジストリを必須とし、選択した成果物のバンドルとマニフェストのみをチェックします。レジストリファイルがどちらも存在しない場合に限り、.styleseed/effective-rules.md と .styleseed/manifest.json を読み取ります。リンティングのみのリクエストでは、バンドルを再生成せず、不足または古くなった証拠を報告してください。リンターは決定論的なドリフトを検出します。正確な文法/レシピ/プロファイル/アダプターのコントラクトを違反としてフラグ付けしたり、任意のロック値によって例外を認めたりしてはいけません。
使用しない場合
- デザインの判断(構成、階層、リズム)をより深くレビューする場合 →
/ss-reviewを使用 - アクセシビリティに特化した場合 →
/ss-a11yを使用 - ニールセンの UX ヒューリスティックを確認する場合 →
/ss-auditを使用 - リファクタリングを適用する場合 — このツールは検出結果を示すだけです。修正は、許可された実装ステップで行います
対象:$ARGUMENTS
このツールの動作
実行可能な診断には、上記の正規チェッカーを使用してください。以下の検索は、適用対象となるプロジェクト規約を手動でレビューするためのヒントであり、追加のハードエラー検出器ではありません。要求された場合、またはビルドワークフローで必要な場合に、影響を受ける UI ファイルを対象に実行してください。無関係な編集はリンティングしないでください。
リンティングのみのモードでは、コードを編集しないでください。必須チェックに合格したら、関連する変更があった場合、または問題を示す新たな証拠がある場合にのみ再実行してください。すべての成果物が明示的に対象となっている場合に限り、--all を使用してください。
チェック項目
1. ハードコードされた色
セマンティックトークンを使うべき className 文字列内の 16 進数カラーを検索します:
grep -n '#[0-9a-fA-F]\{3,8\}' [file] | grep -v 'theme.css\|tokens\|\.json'
違反例: text-[#3C3C3C]、bg-[#3182F6]
修正方法: text-text-primary、bg-brand
2. Tailwind の生のピクセル値
grep -n 'p-\[.*px\]\|m-\[.*px\]\|gap-\[.*px\]' [file]
違反例: p-[24px]、gap-[12px]
修正方法: p-6、gap-3
3. 古い幅/高さの構文
grep -n 'w-[0-9] h-[0-9]\|w-\[.*\] h-\[' [file]
違反例: w-4 h-4
修正方法: size-4
4. 物理プロパティ(LTR のみ)
grep -n ' ml-\| mr-\| pl-\| pr-' [file]
違反例: ml-2、mr-4
修正方法: ms-2、me-4
5. コントラクトで定められていないハードブラック
grep -n 'text-black\|bg-black\|#000000\|#000"' [file]
違反例: 選択した文法/プロファイルで正確な構造上の役割が定められていない純粋な黒 修正方法: セマンティックなインクトークンを使用するか、ハードブラックを必須とする保守対象のコントラクトを提示します
6. data-slot の欠落
grep -n 'function [A-Z]' [file] # find components
grep -n 'data-slot' [file] # check if present
違反例: data-slot のないコンポーネント
修正方法: data-slot="component-name" を追加します
7. フォントサイズの CSS 変数(重大 — Tailwind v4 との競合)
grep -n 'text-\[var(--' [file]
grep -n '\-\-text-.*px\|--fs-.*px' [file]
違反例: theme.css 内の text-[var(--text-sm)] または --text-sm: 13px
修正方法: 明示的な text-[13px] を使用します。CSS 変数のフォントサイズは Tailwind v4 の --text-* 名前空間と競合し、Tailwind はそれらをフォントサイズではなく色として読み取ります。
8. cn() を使わない className
grep -n 'className={`' [file]
違反例: テンプレートリテラルの className
修正方法: すべての className の合成に cn() を使用します
9. 汎用的なソフトカードのドリフト
パターンファイル内で、rounded-2xl、shadow-[var(--shadow-card)]、および mx-6 が繰り返し使われている箇所を検索します。
選択されたレシピが calm-consumer でない場合に、この組み合わせをフラグ付けします。
修正方法: ss-pattern-surface、ss-page-gutter および、レシピに対応したその他のヘルパークラスを使用します。
出力形式
🔴 FAIL [file:line] Hardcoded hex: text-[#3C3C3C] → use text-text-primary
🔴 FAIL [file:line] Raw px: p-[24px] → use p-6
🟡 WARN [file:line] Physical prop: ml-2 → use ms-2
🟡 WARN [file:line] Missing data-slot on MyComponent
🟢 PASS No violations found
Total: X errors, Y warnings
エラーが 0 件を超える場合は、違反ごとに具体的な修正内容を列挙してください。