vibe-killer

Vibe Killer

誰かがプロンプトを入力し、ウェブページが返ってきました。紫のグラデーションのヒーロー、角丸の小さな四角に入った絵文字付きのカードが3枚、そして世界のどこにもほかに存在しない400行のCSS。見た目は問題ありません。しかし、これは行き止まりでもあります。組織内の誰も保守、テーマ設定、監査ができず、1ピクセルも再利用できません。

このスキルは、そのページをデザインシステムから作り直し、孤立した存在ではなくインフラの一部にします。コンテンツも役割もそのままに、チームがすでに保守しているコンポーネント上で動作します。

目的は、見た目を整えることではありません。自分たちのシステムで作ったページは、その背後にあるあらゆる投資を受け継ぎます。テーマ、アクセシビリティへの取り組み、トークン、ブラウザーサポート、そしてバグを修正する場所が一つにまとまっていることです。バイブコーディングで作ったページには、そのどれも引き継がれず、いつまでも保守し続けることになります。

これは何ではないか

• ds-adoption-planではありません。 こちらは、製品全体の移行にかかる費用とスケジュールを見積もります。これは、今すぐ1ページを変換し、実行できるコードを渡します。
• product-inspectionではありません。 こちらは、リリース済みの製品を10の観点から評価します。これは、単一の成果物を生み出す単一の手順です。
• リンターではありません。 ここでは、元のページについて報告するだけで終わることはありません。実行するたびに、変換済みのページか、ページを生成できなかった理由を正直に説明する内容が得られます。

基本原則

1. コンポーネント、プロパティ、スロット、トークンを決してでっち上げないでください。 出力に含まれる名前はすべて、システム独自のカタログから確認したものにしてください。記憶に頼って何かを使おうとしているなら、いったん止めてカタログを確認してください。存在しない名前のスロットに投影されたコンテンツは、ほとんどのコンポーネントライブラリで黙って破棄されます。その結果、どこにもエラーが出ないままページが空白になり、誰かに指摘されるまで気づかないことになります。
2. すべてにエビデンスタグを付けてください。 [verified] は、システムのカタログ、MCP、マニフェスト、リポジトリ、またはドキュメントで確認し、該当箇所を示せることを意味します。[reported] は、人から聞いた情報であることを意味します。大部分の名前が [reported] でも、変換する価値はあります。その場合は、レシートの冒頭にその旨を明記してください。
3. 独自CSSをゼロにすることを目指し、その不足は調査結果として記録してください。 カスタムクラス、ハードコードされた色や余白、フォントの宣言、Google Fonts への <link> は使わないでください。システムが本当に対応していないものは、システムの不足点です。レシートに記載し、上流に提案し、コード内のプレースホルダーには目立つ形で印を付けてください。黙ってコンポーネントを自作することだけが、この作業全体を無意味にする失敗です。
4. ページの見た目ではなく、ページが果たしている役割を変換してください。 見た目の特徴は意図を知る手掛かりです。ページ上部のグラデーション帯は「ここが導入部分」という意味であり、導入部分はヒーローまたはページヘッダーに対応します。グラデーションそのものは要件ではなく、モデルのデフォルトの好みが表れたものにすぎません。読み解き方については reference/THE-TELLS.md を参照してください。システム側でも同様に、見た目が似ているものではなく、役割を果たすコンポーネントに対応させてください。見出しの上にある小さなテキスト行はバッジのように見えますが、実際には文字の種類です。
5. コンテンツは大切にし、装飾はそうではありません。 変換を簡単にするためにページの文言を書き換えたり、対応づけにくいという理由でセクションを削除したりしないでください。コピー自体にAIらしい特徴がある場合は、レシートに記載し、判断は人に委ねてください。それを決めるのはあなたではありません。
6. アクセシビリティは作業の過程で改善してください。 バイブコーディングで作られたページは、この点で決まって問題があります。ボタンのように振る舞う div、飛ばされた見出しレベル、outline: none、代替テキストのない画像、未確認のコントラストなどです。マークアップを作り直すのですから、正しく作り直してください。修正内容はすべてレシートに記録してください。変換する価値があったことを示す、特に説得力のある根拠になります。
7. 一度もレンダリングしていないページは、結果ではなく主張です。 フェーズ4のチェックを実行してください。レンダリングや検証を行う方法がない場合は、動作するかのようにほのめかさず、その旨をレシートに明記してください。一度も 見ていない 領域も同様に、主張にすぎません。バリデーターを問題なく通過し、すべてのスロットが埋まっているとDOMチェックで確認できたとしても、人が数秒で却下するページである可能性はあります。
8. 決して恥をかかせてはいけません。 誰かが何かを作ったのであり、ものを作ることは良いことです。元のページがばかげているわけでも、作成を依頼した人がばかげているわけでもありません。レシートには件数と事実を記載し、皮肉は書きません。

デザインシステム：エビデンスの連鎖

このスキルは特定のデザインシステムに依存しません。利用できるものを使って、次の連鎖に沿ってシステムのカタログをたどってください。特定のベンダーを必須にしてはいけません。

1. システム独自の MCP サーバーまたは CLI。 コンポーネントの検索、検索、組み立て、検証を行うツールがあれば、実行のたびに使用してください。マッピングを [verified] とできる唯一の情報源であり、自動で最新状態が保たれる唯一の情報源でもあります。
2. 機械可読なエクスポート。 custom-elements.json、コンポーネントマニフェスト、トークン JSON、Storybook の index.json などです。ユーザーに場所を指定してもらってください。
3. リポジトリ。 システムのソースがディスク上にあるかアクセス可能なら、コンポーネントファイルを読んでください。時間はかかりますが、完全に信頼できます。
4. ドキュメントサイト。 コンポーネントのページには API と使用方法のガイダンスが記載されています。古くなっていないか注意してください。公開ドキュメントは、リリース済みバージョンに後れを取っていることがよくあります。
5. デザインライブラリ。 システムに含まれるものとデザイン側の命名については信頼できますが、コード API についてはそうではありません。Figma で Primary とラベル付けされたバリアントを見ても、プロパティが variant なのか appearance なのかは分かりません。アクセス方法については reference/FIGMA-ACCESS.md を参照してください。
6. 聞き取り。 質問してください。得られた情報にはすべて [reported] を付けてください。

名前だけでなく、使ってはいけないものも確認してください。 名前から直感的に判断できるコンポーネントが、実際には不適切なことがよくあります。優れたカタログなら、そのガイダンスに明記されています。マッピングを決める前に、対象の「使用しないでください」という注意書きとアクセシビリティに関する注意事項を読んでください。

そのガイダンスも主張として扱ってください。 カタログは人が作成するものであり、その下にあるコードとの乖離が生じます。使用上の注意で、コンポーネント自身のスタイルが想定していない用途が推奨されていることもあります。カタログの説明が最初の直感を覆したら、その訂正を書き留めてください。ただし、その領域をレンダリングして確認するまでは、成功と見なしてはいけません。検証記録で最も有用な一文は、カタログとレンダリング結果が食い違っている箇所であることがよくあります。

モード

モード 1 — ページを変換する（一般的なケース）

4 つのフェーズを順番に実行してください。各フェーズの間に、1 行で状況を伝えてください。

1. プロファイルを取得します。 vibe-killer/SYSTEM.md があれば読み、現在も有効か確認してください。ない場合は、先に intake/SYSTEM-INTAKE.md を実行してください。数分で完了し、その後の作業がすべて速く、正確になります。
2. 以下の姿勢に関する質問をします。 省略したり、推測したりしないでください。
3. フェーズ 1 — 調査（phases/phase-1-forensics.md）。ソースを読み、手掛かりを整理して、各領域の目的を書き留めます。
4. フェーズ 2 — マッピング（phases/phase-2-mapping.md）。各領域に、実在するコンポーネント、実在する組み合わせ、または正直な未対応事項を割り当てます。
5. フェーズ 3 — 変換（phases/phase-3-conversion.md）。ページを作成します。
6. フェーズ 4 — 検証（phases/phase-4-proof.md）。検証し、変更点を数え、記録を作成します。

モード 2 — システムプロファイルを作成または更新する

intake/SYSTEM-INTAKE.md を単独で実行してください。システムのメジャーバージョンがリリースされたとき、変換時に誰も見つけられないコンポーネント名が出てきたとき、またはランタイム URL が機能しなくなったときにも、適切な対応です。

モード 3 — 別のシステムを使って変換する

同じページに対して、2 つ目のプロファイルを使います。これは直接比較です。それぞれのシステムで何が簡単になり、どこで独自のマークアップを書くことになるかを確認します。両方の記録を残し、未対応事項のリストを比較してください。

姿勢についての質問（実行のたびに尋ねる）

変換の進め方は2通りあり、仕上がるページは実際に大きく異なります。 フェーズ2の前に、次のような言葉で尋ねてください。

どちらの進め方にしますか？

A. あなたのシステムのルールを優先する（こちらをおすすめします）。ページの目的、コンテンツ、階層、各領域の役割を把握し、最初からあなたのシステムで作っていたならどうなっていたかを考えて再構築します。元のページの判断があなたのシステムと相容れない場合は、あなたのシステムを優先します。仕上がりはあなたのプロダクトらしい見た目になります。元のページのスクリーンショットのようにはなりません。

B. 元のページに合わせる。 あなたのコンポーネントで可能な限り、元のレイアウトとビジュアル上の判断を維持し、その下にあるものを置き換えます。変換前後で形を一致させる必要がある場合、デザインを純粋に気に入っている人がいる場合、またはページが実在するものを忠実に再現したモックアップの場合に適しています。

デフォルトはAです。 雰囲気でコーディングされたページの多くには、実際には誰も決めていないデザイン上の判断が含まれています。それを忠実に移植すると、誰かの偶然の産物をコードベースに持ち込んで保守することになります。

ユーザーがBを選んだ場合は、始める前にBを選ぶと何が必要になるかを率直に伝えてください。正直なところ、「元の見た目を維持する」と、差分リストが長くなることがよくあります。システムに相当するものがない独自のビジュアル上の選択は、差分かオーバーライドのいずれかになります。そしてオーバーライドこそ、このスキルで削除しようとしているものです。後から読む人がページの見た目の理由を把握できるよう、解剖記録の先頭に姿勢を記録してください。

変換後のページの配置先

デフォルト：単独で実行できる1ページ。 ビルド手順なしで、システムの実際のランタイムを読み込み、ブラウザーでレンダリングできる単一ファイルです。これがデモであり、誰にでも渡せる成果物です。

配置先を尋ねてください。 代わりにリポジトリへ書き込み、フレームワークの構文で実際のテンプレートとして、他のページと並べて配置したい人もいます。一度尋ねて、その希望どおりに進めてください。リポジトリに書き込む場合は、ここに書かれている内容よりもそのプロジェクトの規約を優先し、プロジェクトに存在しないフォルダーやパターンを決して新たに作らないでください。

どちらの場合も、作業の記録は vibe-killer/ に残します。

このキットのファイル

• intake/SYSTEM-INTAKE.md — SYSTEM.md を作成するためのインタビュー
• reference/THE-TELLS.md — 雰囲気でコーディングされたページを見分けるためのガイドと、各サインが意図について示すこと
• reference/CAPABILITIES.md — このスキルでできること、できないこと
• reference/FIGMA-ACCESS.md — デザインライブラリへのアクセス方法と、各ブリッジで実際に確認できるもの
• phases/phase-1-forensics.md — ページを読み解き、サインを記録する
• phases/phase-2-mapping.md — 根拠を添えて領域をコンポーネントに対応付ける
• phases/phase-3-conversion.md — ページを作成する
• phases/phase-4-proof.md — 検証し、集計し、記録を作成する
• templates/system.md、templates/autopsy.md、templates/receipt.md — 出力用のひな形

状態（ユーザーのプロジェクト内）

vibe-killer/
├── SYSTEM.md                        ← the design system profile, built once
└── kills/
    └── YYYY-MM-DD-<slug>/
        ├── autopsy.md               ← tells found, regions mapped
        ├── receipt.md               ← the before/after scorecard
        └── (the converted page, unless it went into the repo)

ds-inspection/、product-inspection/、ds-adoption-plan/ のいずれかのフォルダーと同じ階層に配置します。これらは1つのプロジェクト内で問題なく共存できます。ファイルを書き込める場合は、このフォルダーを保持してください。書き込めない場合（通常のチャット）は、ユーザーが保存できるよう各成果物をそれぞれ別のメッセージとして出力し、まとめないでください。

文体

率直で、活気があり、具体的に。調査結果は雰囲気ではなく、数とファイル参照で示します。「カスタムクラス名31件、ハードコードされた16進数値47件、フォーカススタイル0件」は、「カスタムCSSがたくさんあります」よりも明確です。記録を読む人が、何がシステムに移行され、何が移行されなかったか、そして移行されなかった部分にどう対処するかを正確に把握できるようにしてください。