visant-killer

Visant Killer

敵対的な UI 監査です。画面は被告であり、クライアントではありません。互いに置き換えられない二つの側面があります。ゲート（決定論的スクリプトによる判定。AI らしさ、トークン、音声、クロームノイズを二値判定）と、審判（スキルを読み込んだあなた）です。AI スロップはどのリンターでも見逃されます。問題は構文ではなく、判断です。

ルールゼロ（visant-copy より）： 確認済みの欠陥を修正する場合に限り、ファイルを変更します。問題のない箇所は、平板に聞こえたとしてもそのままにします。 好みによる改善は提案表にまとめ、ユーザーが一行ずつ選択します。

ゲートが緑でも、画面を確認したことにはなりません。 リードフォームの AnimatePresence がフリーズした状態でも、6つのゲートを通過しました。そのため、killer-scan は、表層の一覧と画面を開いた記録がない場合、「ゲートオープン」を拒否します。

各ルールの由来：references/cases.md。

厳守事項（見直し時ではなく、作成中に破ると問題になります）

禁止事項	使用するもの	理由
テキスト内の矢印記号（→、←、↑、↓）と手描きのアイコン SVG	実際のライブラリアイコン（@phosphor-icons/react、@radix-ui/react-icons）	規則です。 矢印文字はClaudeが最も使いがちな癖です。フォントのメトリクスを引き継ぐためベースラインからずれ、書体によって形が変わり、太さやサイズを制御できず、テキストとして認識されます。手描きのSVGも、行数が増えるだけで同じ問題があります。アイコンには常にライブラリアセットを使ってください
hover:scale-*、whileHover={{ scale }}	色、影、または境界線を変更する	ホバー時の拡大は、テンプレートを見分ける最大の手がかりです。隣接するレイアウトを動かし、prefers-reduced-motion にも対応できません
隣接するテキストに重なるように大きくなるホバー効果	表示領域を常に確保し、その範囲内で大きくする	ホバーで表示するものは、ほかの要素に重ねてはいけません
--accent が強調色の場合の hover:bg-accent	hover:bg-muted または hover:bg-primary	強調色をマウス状態にしてしまいます。トークンを確認してください。標準の shadcn では --accent はニュートラルなホバー色なので、その場合の hover:bg-accent は適切です
border-accent	border-border	同じ混同です。強調色を装飾にしてしまいます
ダイアログ／シート以外での backdrop-blur	不透明なトークン背景	スクロールのたびに合成処理の負荷がかかります。カードでは、フレームを消費するだけの装飾です
max-width のないオーバーレイ内の white-space: nowrap	max-width: calc(100% - 12px) を指定し、折り返しを許可する	overflow: hidden の親要素内では単語が切れます。その切れはフォントの読み込み後にしか起きないため、リンターでは検出できません
アイテムファクトリー内の固定された強調表示（on: true、active: true）	判定条件（on: q.live）	アイテムごとに一度だけ実行される強調表示では、リスト全体が光ります。何でも強調すると、何も強調されていないのと同じです
同じ種類のデータを入力するための欄を、同じ画面に2つ設ける	画面ごとに1つにするか、違いがわかる名前を付ける（検出器が確認するのは同じ画面内のみです。画面をまたいで同じ名前を使うかどうかは判断が必要です）	横並びの同じURL欄が別々のストアに書き込むと、利用者は運任せに選ぶことになります
transition-all	transition-colors または明示的なプロパティのリスト	レイアウトも含め、指定していないものまでアニメーションします
インタラクティブ要素での duration-300 以上	DUR.base / DUR.slow	約300ミリ秒を超えると、UIの反応が遅く感じられます
生の16進数、rgb()、rgba()	HSLトークン（hsl(var(--x))）	var(--x) 単体は色ではありません。トークンには分割されたチャンネルが格納されています
架空のフレームや「ホバーしてください」というキャプション、複数のバリエーションを並べたコンポーネントのデモ	作品を大きく中央に、一度に1つ表示し、控えめなセレクターを添える	カタログ35～38：タイル内では、説明に隠れて作品が見えなくなります
きれいな状態（光彩、傾き、開いたメニュー）をホバー時だけ表示する	最初から最良の状態で表示し、ホバー時に強調する	タッチ操作では使えず、タイル内やスクリーンショットにも表示されません（カタログ37）
cursor: pointer のないクリック可能なボタン／カード、および grab のないドラッグ操作	シェル内のルール（:is(button,[role=button],a[href])）	Tailwind v4のプリフライトはカーソルをリセットします（カタログ46）
ライブラリ作品内でのクライアント向け文言	汎用的なテキストを使い、pt-BRで記述する	ライブラリはあらゆるクライアント向けに提供されます（カタログ42）

例外もあります（ルート遷移、マーケティング用の作品、WCAGコントラストの参照としての #fff／#000、Dialog 内のぼかし、写真に重ねる暗幕）。例外には、スキャナー形式で行上に理由を記述してください （参照）。無言の audit-ignore は使わないでください。

全手順で使うスクリプトのフルパス：

K=~/.claude/skills/visant-killer/scripts/killer-scan.mjs
R=~/.claude/skills/visant-refine/scripts/refine-scan.mjs
D=~/.claude/skills/visant-killer/scripts/dist-scan.mjs
C=~/.claude/skills/visant-copy/scripts/copy-lint.mjs
T=~/.claude/skills/visant-killer/scripts/corta-scan.js       # runs IN THE BROWSER (Step 5)
V=~/.claude/skills/visant-killer/scripts/verify-screens.mjs  # opens the app logged in (Step 5)
# grafo.mjs is a library (import graph for --roots and repeated-door), not a CLI

ステップ0：まずルートから始める（対象範囲が広い場合）

数十個のファイルが対象となる場合は、ルートごとに調査結果をまとめることから始めます。 node $K --roots <target>（共通部品を fan-out × findings で順位付けします。 仕組み）。コンテナーを1つ間違えるだけで、同じ問題を示す末端ファイルが何百個も生まれ、誤ったファイルを指し示すことになります。ページより先にプリミティブとシェルを確認し、その後で --all を使って残りをファイルごとに分割します。

ステップ 1：対象を分類する（必ず実施）

ティアによって、対象にどれだけ詳しく質問するかが決まります。ティアを誤ると、コンテキストを無駄にしたり、収益に関わる部分を浅くしか監査できなかったりします。

ティア	対象	判断材料	質問数
T1 Leaf	1つのコンポーネント、1つのカード、1つのリスト行	ファイル数が1～3個、独自のルートがない、データベースに書き込まない	5問
T2 Route	画面全体	page.tsx がある、状態（読み込み中、空、エラー）がある、キーボードに対応している	12問
T3 Core	金銭、ID、または複数のルートに関わるフロー	データベースへの書き込み、請求、権限、オンボーディング、セールスパイプライン	20問とポジショニング
混在する対象：フォルダーではなく、領域ごとに分類します（一覧画面内の請求行は、T2の中にあるT3です）。

過剰さだけに関する不満（「文章が多すぎる」「ごちゃごちゃしている」「テンプレートっぽい」、「tá poluído」、「muita label」）の場合は、すぐに declutter.md に進みます。プロジェクトの制約に左右されない方法です（どのリポジトリ、どの言語でも使え、リンターも不要です）。

ステップ 2：ゲート（コードを読む前に実行）

まずレポート、次に検出器（終了コードが完了したように感じられ、エージェントはそこで止まってしまいます）：

node $K --init-report AUDIT.md <target>    # skeleton, one row per route (Shell hint to confirm)
# fill the table BEFORE fixing anything
node $K --report AUDIT.md <target>

完全な --report がない場合は GATE INCOMPLETE と出力して、終了コード 1 で終了します （詳細）。必須の列は 2 つです。

• surface：A は獲得（まだ顧客ではない）、B は業務（毎日利用する）、C は信頼（金銭、許可、破壊的操作）です。B の画面に A の感覚を持ち込むことが、最も高くつくフロントエンドのミスです。
• business variable：この要素が何に影響するかです。ダッシュ、「TBD」、空欄は却下されます。何も入れずに埋めるのは、このステップを省略することだからです。

## Screen seen セクション（見出しは完全一致。## Tela vista も解析されます）も必須です。開いた画面ごとに 1 行記入し、ルート、幅、データの状態、起きたことを記録します。まず environment.md を読んでください。開発サーバーの情報は当てになりません。

killer-scan は 4 つの検出器を実行し、スコアボードを 1 つ出力した後、スキップしたものを列挙する gates: N/4 ran [...] の行で終了します。検出器は、impeccable（AI の指示）、token（リポジトリの audit:design に相当するゲート。それがなければ、生の hex/rgb/hsl とパレットクラスを対象に、リポジトリのトークンレイヤーを認識する、明示ラベル付きの組み込み FALLBACK）、copy（ユーザーの目に触れる文字列のみが対象の文体チェック：JSX のテキスト、label、title、placeholder、aria-label、alt）、chrome noise（noise-scan：各行は正当化できるが、合計すると読みにくくなります）です。詳細と 24 個のノイズルールについては、gates.md を参照してください。

対象リポジトリのゲートを調べてください。 4 つの検出器は最低限です。package.json の lint/audit/design/token/ui/theme/i18n/ratchet という名前のスクリプトと、未接続のスキャナーがないか scripts/ を確認してください。対象リポジトリに存在するものを実行し、実行したものとスキップしたもの、およびその理由を記録してください （コマンド）。

補助ゲート：グラフ、ゲージ、アニメーションがある場合は node $R <target> を実行します。サーフェス A では、見た目を整える前に node $D <app-root> を実行してください。カードなしで共有されたり、イベントなしでコンバージョンしたりするページはトークンでは修正できず、UI 検出器も反応しません （distribution.md）。

ゲートの失敗は、各指摘を file:line で確認した後、提案ではなく修正として扱います（既存コードにはノイズが多いため、読まずに修正するとバグを書き込むことになります）。

• 確認済みの誤検知に対する正しい修正は 1 つだけです。ルールを修正し、そのケースをフィクスチャに追加して固定してください。ファイルに audit-ignore を追加してはいけません（次の誤検知が見えなくなります）。
• 明記する例外： EXCEPTION to <scanner>/<rule>: reason（または EXCEÇÃO ao）を該当行、もしくはその 8 行上までに記述します。ミュート用の許可リストは禁止です （契約）。
• CI ラチェット： ベースラインを記録し直すのは、合計数が減った場合のみです。増加分を吸収するために更新してはいけません。常にアプリ全体を対象にしてください （gates.md）。
• 指摘より先にルールを確認： 指摘が多く、ほとんどが実際の問題ではない場合、欠陥は RULE にあります。フォルダーごとに分類し、ルールの意図を読み、ルール内に理由を記述して対象範囲を絞り、そのうえで残った指摘を修正してください （false-positives.md）。

ステップ 3：判断（すべてを常に読み込まず、階層ごとに読み込む）

スキルのメモリはスキルそのものではありません。階層ごとに読み込み、読み込まなかったものを報告してください。

階層	読み込むもの	読み込まないもの
T1 リーフ	このスキル以外は何もありません	4 つ。禁止事項の表と slop-catalog だけでカードには十分です
T2 ルート	visant-frontend + visant-motion	ルートで何かを販売する場合を除き、revenue-centric-design
T3 コア	4 つすべて	なし

軽量 T3（コンテキストが限られている場合）：各 SKILL.md のみ。指摘事項がある場合に限り、リファレンスも読み込みます。 順序：まず visant-frontend（選別テスト：すべての要素が、それによって動くビジネス変数を示せること。示せなければ削除します。ステップ 2 のサーフェス表がその出力です）、次に visant-motion（イージング／時間の SSoT と操作感に関する注意点）、visant-copy （文体。ゲートで構文を検出しました）、revenue-centric-design（ステップ 4 の材料としてのみ使用）。

判断する前に slop-catalog.md を読んでください（すべてのリンターを通過する slop：症状、原因、修正）。**複数のエージェントを同時に使う場合：**ファイルの担当を重複させず、i18n はフラグメントごとに行って一度だけ統合し、編集を終えてから計測してください（multi-agent.md）。

ステップ 4：あえて反論する

目標は、ピクセル単位の作業を半分不要にするコンセプトの変更です。階層ごとの質問集：devils-advocate.md。

• その階層に該当する質問だけを選び、それ以上は問いません（T1 で追加の質問をするのは、カードについての哲学論です）。 固定ブロック F1～F6 はすべての階層で実施します：再利用、デザインシステムとの一貫性、計測されたレスポンシブ性とパフォーマンス、ICP に向けた段階的なフロー、非表示にするものやアイコン化するもの、シリコンバレー水準にするために不足しているもの。
• まず自分で回答し、file:line 形式で示してください。何も試さずに質問を投げ返すのは、厳密さを装った怠慢です。実装内容を変えるもので、コードからは答えが分からない場合に限り、推奨案を先に示してユーザーに尋ねます。
• 該当する場合は revenue-centric-design の仕組みに名前を付けてください（注意の階層、Swiss Knife Index、最適な使い方、デフォルトを意思決定として扱うこと、証明の規模に見合う約束）。仕掛けの名前を示すことに価値があります。
• 画面をなくすほどの質問 1 つは、些細な修正 12 個に勝ります。率直な答えが「この画面は存在すべきではない」なら、そう書いてください。

ステップ 5：検証（コンパイルできることと、実際に見たことは別です）

まず画面を開きます（## Screen seen に入力されます）。ログイン後のアプリ：対象リポジトリから node $V を実行します（はみ出し、テキストの切れ、生の i18n キー、コンソール、/api の 4xx/5xx、空の画面、テーマ、有料ルートのロック）。 公開 URL：corta-url.mjs <base> route。手動で開く場合：コンソールで $T を実行します。 フラグと有料ルートのロックについては、verification.md を参照してください。 計測前に、environment.md にある 4 つのシグナルを確認します。ルートがウォームアップ済みであること、readyState ではなく DOM マークでハイドレーションが確認できること、最悪のレコードを含む実データがあること、ノード数が手動で開いたページと一致することです。

その後に限り（実行できなかった項目はレポートに記載します）：

チェック	方法
型と lint	npx tsc --noEmit とリポジトリの lint を実行します。dev の実行中に next build を実行しないでください（.next が壊れます）
水平方向のはみ出し	$V（estouro 列）：390px でのドキュメントの scrollWidth - clientWidth。修正のたびに再計測します。要素ではありません。overflow-hidden の下にある装飾用の blob が、実際には存在しない 64px のはみ出しとして一度計測されたことがあります
テキスト切れと重なったオーバーレイ	$V（corta 列）またはコンソールで $T：クリッピングする親要素に隠れた単語、同じ隅で別の要素に重なるオーバーレイ、枠からはみ出した要素
配信	ページは外部から見つけられますか？ title、description、共有カード、コンバージョンイベント、sitemap、robots（distribution.md）
実データ	最良と最悪のレコードを使った画面。空の状態では、あらゆるはみ出しが隠れます
ライトテーマ	$V --theme both。ダークテーマ優先のアプリは、誰も確認しないライトテーマで壊れます
バックエンド障害	バックエンドを停止した状態で実行します。無言のゼロ表示は、最もよくある偽りです。失敗した fetch が「0」を表示すると、実際のゼロと見分けがつきません
キーボード	focus-visible で、ホバー時に表示されるすべての要素にアクセスできること
操作感	DevTools、Animations、25% の速度

ステップ 6：レポート

同じ AUDIT.md に、今度は指摘事項とスコアを先頭に記載します。チャットの文章だけで済ませてはいけません （scorecard.md）。スコアは褒め言葉ではありません。ゲートのスコアが 100 でも、T3 があり、ポジショニングの検証がなければ、監査は不完全です。そのことをレポートに記載します。

禁止事項

• スクリプトを実行せずに高スコアを宣言したり、サーフェス表が空のまま「すべて合格」と宣言したりしないでください。スコアは雰囲気ではなく、プロセスに基づきます。
• 明示的な許可なく、新しいデザインシステムのコンポーネントを作成しないでください。再利用してパラメーター化してください。必要な要素がない場合は、まず Visant ライブラリ (ui.visantlabs.com、監査済みアイテム 150 件以上。インデックスは /llms.txt、シートは /r/<name>.md) を確認し、次に公式の shadcn プリミティブを確認してください。どちらも npx shadcn@latest add @visant/<name> でインストールできます（components.json のレジストリは "@visant": "https://ui.visantlabs.com/r/{name}.json"）。事前にその旨を伝えてください。
• 根本原因より先に末端の問題を修正しないでください（ステップ 0、--roots）。
• verify-screens のロックなしで、読み込み時にクレジットを消費するルートを開かないでください。
• 報告された不具合をコードで確認せずに、その上にリファクタリングを重ねないでください。 診断は意見ではなく、file:line で示します。
• 画面を開かずに完了を宣言しないでください。このスキル全体が守ろうとしているのは、この一点です。
• ギャンブル、カジノ、ベッティング製品に適用しないでください。拒否し、その理由を説明してください。これは好みではなく、revenue-centric-design の再利用条件です。

クレジットと系譜

このスキルは入り口です。判断力は、読み込むハウススキルから得られます。 visant-frontend（カットテスト、サーフェス）、visant-motion（motion-lint）、 visant-refine（refine-scan）、visant-copy（copy-lint）です。外部からの要素は次のとおりです。

内容	提供者	取り入れ方
impeccable	Paul Bakaus（pbakaus/impeccable、Apache-2.0）	killer-scan のゲート 1（npx impeccable detect）
revenue-centric-design	Richard による原則（@richardrx）、heliocosta-dev によるパッケージ化	Step 4 の材料、および devils-advocate 内の「RCD n」引用
Emil Kowalski skills（emil-design-eng、apple-design、improve-animations、review-animations）	animations.dev と Apple の Designing Fluid Interfaces（WWDC 2018）に基づく、Emil Kowalski のスキル	visant-motion 経由で、モーション原則の起源として
vercel-react-view-transitions	Vercel（vercel-labs/agent-skills）	visant-motion 経由で、ルート遷移に使用
dataviz	Anthropic（Claude スキル）	visant-frontend 経由で、チャートの正確性に使用
shadcn/ui と Radix	shadcn、WorkOS	独自のコンポーネントを作る代わりに、公式プリミティブを使用
Playwright	Microsoft	corta-scan と verify-screens で実際の画面を開く

このスキルが新たに使い始める、または要点を抽出するスキルは、同じ コミットでこの表に追加されます。