design-prim

スキル：design-prim

design（一貫したデザインシステムを固定する）＋prim（洗練され、申し分なく、ちぐはぐさがない）。

1回にまとめて実行します：orca-onboard（Step 0でトークンを自動スキャンするhallmarkがすでにあるため、重すぎるこちらは省略）＋playwright-verify＋ impeccable（doyourmagic/impeccableのバンドル）＋hallmark（デザインの土台＋スロップテスト）＋qc-uiux（シニア向け4項目判定、決定論的なvisual-qaエンジンを使用）。これらのスキルのロジックを書き直さず、正しい順序で、正しい対象に呼び出すだけです。

実行前に読んでください。過去に痛い目を見た落とし穴です： /impeccable documentは、コードに現在あるトークン／色／フォントをそのまま写し取ってDESIGN.mdを生成します（現状を記述するだけで、新しい提案はしません）。その後にhallmark redesignを呼び出すと、HallmarkのStep 0 Pre-flightはDESIGN.mdを固定済みのシステムとして扱い、ほかのすべてに優先します。つまり、取り除くべきスロップなトークンセットそのものを再び固定し、その上で細部を少し直すだけになります。これが、以前のこのスキルが「実行してもページが良くならなかった」理由です。新しいシステムを固定しているつもりでも、実際には古いシステムを再び固定していました。スロップを取り除くフローでは、/impeccable documentを呼び出さないでください。

概要

目的とコンテキスト

• 目的： 任意のプロジェクトをオンボーディングする際にUI/UXのスロップを取り除きます。まず変更前を撮影し、hallmark redesignに独自の新しいデザインシステムを生成させ、その後、スロップテスト、/impeccable audit／critique、/qc-uiuxで測定と修正を行い、問題がなくなるか、2ラウンドを使い切るまで続けます。
• トリガー（使用するタイミング）：
  • 見慣れないプロジェクトを引き継いで（オンボーディング）、UIを一貫した基準に整え、AIスロップが目立たないようにする必要があるとき。
  • ビュー／画面ごとにスタイルがばらばらで、一貫したシステムに固定する必要があるとき。
  • ユーザーが「スロップを取り除いて」「プロジェクトのUIをすっきりさせて」「UI全体を標準化して」「オンボーディングしてUIをきれいにして」「design prim」「/design-prim」と言ったとき。
• 対象外： 小さなコンポーネントを1つだけ修正する場合（hallmarkのコンポーネントスコープを直接使用）、またはUI以外のアーキテクチャ／ビジネスロジックを深く理解する必要がある場合（それには完全版のorca-onboardを使います。このスキルではありません）には使いません。呼び出すスキルのロジックを書き直しません。

メンタルモデル

impeccableはインストール済み？ → ビュー／ルート → 変更前の画像 → PRODUCT.md（コンテキスト。古いトークンは含めない） → hallmark redesign（新しいdesign.md。コードを生成する唯一のステップ） → 3層で測定（スロップテスト・impeccable audit／critique・qc-uiux）＋変更後の画像 → 検出事項に基づいて修正、最大2ラウンド → 既知の制限事項

入力と出力の契約

	フィールド	必須？	意味
入力	対象プロジェクト（ルート＋ルーター／ページ）	はい	すべてのチャットコマンドを実行する場所
入力	<base-url>で実行中のアプリ	/qc-uiuxと画像の取得には必須	playwright-verifyと同様
入力	維持したい有効なdesign.md／DESIGN.md	いいえ	ユーザーが古いシステムの維持を希望し、ブリーフで明示している場合のみ
出力	PRODUCT.md＋新しいdesign.md＋再デザイン済みコード	はい	/impeccable initとhallmarkが生成
出力	各ビューの変更前／変更後の画像＋3層測定の結果	はい	「良くなった」ことの証拠。単なるスコアではありません
出力	最終レポート	はい	2ラウンド後に残った検出事項は既知の制限事項として記載

ルールと機能

• RULE-01（必須）：ステップ0→6の順序を変えません。ステップ4はコードを生成／変更する唯一のステップです。ステップ3はコンテキストのみ、ステップ5〜6は測定と修正のみです。ステップ3で止める、またはステップ4／6に進まずステップ5だけを実行する場合、スコアレポートがあっても「見た目を良くする」作業は未完了とみなします。
• RULE-02（必須）：ステップ3〜6はチャットコマンド（/impeccable ...、hallmarkはスキル）であり、シェルではありません。ターミナルに入力しないでください。
• RULE-03（必須）：ユーザーがUIの範囲外にあるアーキテクチャ／ビジネスロジックの理解を必要としている場合を除き、orca-onboardを勝手に追加しません。
• RULE-04（必須）：impeccableがすでにグローバル（プロジェクトではなく）にインストールされている場合は、ステップ3の実行前に正しいスコープでアンインストールして再インストールし、別プロジェクトの成果物が混ざるのを避けてください（dym-impeccable-install-into-your-projectの落とし穴2を参照）。
• 機能：対象プロジェクトのルート構造を読み取る、チャット経由でほかのUIスキルを呼び出す（シェルは使わない）、ヘッドレスブラウザーを実行して画像を撮影／測定する、対象プロジェクトのUIコードを記述する（再デザイン／修正のステップのみ）。

失敗時の境界

• ステップ 3 で止まる、またはステップ 4／6 に到達せずステップ 5 だけを実行する → スコアが付いていても、「見た目を整える」作業は 未完了 です（RULE-01）。
• <base-url> でアプリを実行できない → スクリーンショットを撮影できず、/qc-uiux も実行できません：ブロック としてユーザーに報告します。
• 2 回目のサイクル後も finding が残る → 部分完了 とし、既知の制限事項 を記録して、無限に繰り返さないでください。
• redesign 前に /impeccable document を実行してしまった → 古い slop システムが固定されます：失敗 として、その DESIGN.md を削除してから redesign し直してください。

方法

メインワークフロー

W01～W07 は、以下のステップ 0～6 に対応します。

Step	Type	Inputs	Action	Outputs/exit	Failure/next
W01	deterministic	対象プロジェクトのルート	.claude/skills/impeccable/ を確認し、なければ hub 経由でインストールします	impeccable の準備完了	すでにある場合 → スキップ；global にインストールする場合 → B01
W02	deterministic	router/pages	view/route を列挙します	view の一覧	—
W03	effect	view + <base-url>	playwright-verify で before を撮影します	before の画像	アプリが実行できない → ブロック
W04	judgment	対象プロジェクトのチャット	/impeccable init → PRODUCT.md（document は実行しない）	製品コンテキスト	—
W05	effect	ルート + PRODUCT.md の要約	プロジェクトのルートで hallmark の verb redesign を実行します	design.md + 新しいコード	古いシステムを維持する場合 → B02
W06	deterministic	redesign 済みの view	3 層の測定 + after の撮影	finding + after の画像	P0/P1 が残る／ゲート失敗／要修正 → W07
W07	effect	finding	finding の種類ごとの表に従って修正し、W06 を繰り返します	問題なし	2 回目のサイクル後 → 既知の制限事項

各ステップの詳細（W01～W07 の信頼できる情報源）： 0. 前提条件の確認 — 対象プロジェクトに impeccable はインストール済みですか？ 対象プロジェクトのルートに .claude/skills/impeccable/（前回のインストール時の成果物）が存在するか確認します。存在する場合 → この手順をスキップし、再インストールしないでください。存在しない場合 → /dym-impeccable install-into-your-project を呼び出します（hub 経由で、3 つの場所（sibling npx skills add、project bundle、.claude/skills/）のうち正しい場所を自動で探させます。対象プロジェクトに framework リポジトリの bundle があるとは限らないため、そのパスをハードコードしないでください）。 このファイルに従う際の注意点：必ず npx impeccable install -y --scope=project --providers=claude を実行し、--help は入力しないでください。

1. view／route の一覧表示 — Explore agent を使うか、対象プロジェクトの router／pages config を直接 grep します。専用 skill は不要で、orca-onboard も不要です。

2. 現状のスクリーンショット（before）を取得 — playwright-verify で各 view を撮影し、手順 5 で比較できるように保存します。

3. プロダクトの背景（古い token ではありません） — 対象プロジェクトのチャットで /impeccable init を実行し、 PRODUCT.md（ユーザー、目的、制約、トーン）を生成します。これは、hallmark redesign（verb）が無言で audience／use-case／tone を尋ねないことを補う入力です。手順 4 を呼び出す際に、PRODUCT.md の要約を brief に貼り付けます。/impeccable document は実行しないでください（上記の注意点を参照）。

4. 本格的な redesign — 新しいコードを生成する唯一の手順です。 プロジェクトのルート（個別のファイルではなく、route のディレクトリパス）に対して、verb redesign で hallmark skill を呼び出します → hallmark の multi-page flow が起動します。既存の token／brand を自動でスキャンし、genre／macrostructure／theme を自動で選択し、独自の design.md をルートに自動で作成してから、そのシステムに沿って各 page を再構築します。プロジェクトに有効な design.md／DESIGN.md がすでにあり（手順 3 で禁止した document の出力ではない）、ユーザーが新たに作成するのではなく既存のシステムを維持したい場合は、その旨を brief に明記してください。

5. 再スキャンと比較 — redesign した各 view に対して、3 つの層を実行します（どの層も他の層の代わりにはなりません）。 a. hallmark が slop-test を自動評価します（six-axes pre-emit と 58 gate。手順 4 の Build ですでに実行済みです）。 b. /impeccable audit <view>（P0–P3：a11y、perf、theming、responsive、anti-pattern）と /impeccable critique <view>（hierarchy、IA、cognitive load）。 c. /qc-uiux <view>（アプリを起動しておく必要があります。<base-url> は playwright-verify と同じです）— senior による 4 項目の判定（accessibility · visual-hierarchy · consistency · antipattern）。測定可能な項目（WCAG contrast、tap-target、幾何学的な overlap／misalign）は visual-qa engine で決定論的に実行されます（静的 CSS を読むのではなく、実際の rect を測定します）→ 結論は PASS または 要修正です。 playwright-verify で撮影し直し（after）、手順 2 の before 画像と並べます。これは「より良くなった」ことの証拠であり、単なるスコアではありません。

6. 修正ループ — P0／P1 の finding が残っている、slop-test gate が fail している、または /qc-uiux が要修正と判定した場合は、最初から redesign し直さず、適切なコマンドで修正します。

   finding の種類	修正方法
   a11y（contrast、tap-target、missing label）	/impeccable harden <view>
   performance（読み込み、render、animation）	/impeccable optimize <view>
   theming（view 間で token が不一致）	/impeccable polish <view> — またはシステム全体に不一致がある場合は hallmark audit <view> に戻ります
   responsive（breakpoint、タッチ領域）	/impeccable adapt <view> <context>
   anti-pattern／cognitive load／複雑な IA	/impeccable distill <view> または clarify <view>（copy）
   特定の slop-test gate が fail	/impeccable は不要です。hallmark/references/slop-test.md の該当 gate に従って直接修正します
   qc-uiux の visual-hierarchy／consistency（LLM の目視判定で、測定不可）	該当項目に応じて /impeccable distill／polish <view> を実行します。qc-uiux は最も重大な問題と修正方法を提示するだけで、自動修正はしません
   qc-uiux の測定可能な a11y／antipattern（visual-qa engine：contrast／tap-target／overlap／misalign）	上記の a11y／anti-pattern の行と同じです。同じ問題を両方のツールが検出します

   修正の各ラウンド後に手順 5 を再実行します。最大 2 ラウンドです。 2 ラウンド後も finding が残っている場合は、最終レポートに known limitation と明記し、無限に繰り返さないでください。

ブランチ

ID	種類	ガード	動作	スキップ／失敗	再合流
B01	リカバリー	impeccable がグローバルにインストールされている（プロジェクトにはインストールされていない）	ステップ3の前に、正しいスコープでアンインストール／再インストールする（RULE-04）	—	W04
B02	ユーザー任意	プロジェクトに有効な design.md／DESIGN.md（document で生成されたものではない）があり、ユーザーが保持を希望する	再デザインのブリーフで、そのシステムを保持することを明確に伝える	—	W06
B03	リカバリー	P0／P1 の指摘事項が残っている、slop-test のゲートが失敗する、または /qc-uiux で「修正が必要」となる	ステップ6の表に従って修正し、ステップ5を再実行する	2ラウンドを超える場合 → 既知の制限	W06

検証と停止

互いに独立した3つの測定レイヤー（58個のゲートを持つ slop-test、/impeccable audit＋critique、visual-qa エンジンで測定可能な項目を用いた /qc-uiux）があります。どのレイヤーも他のレイヤーの代わりにはなりません。最終的な証拠は before／after の画像のペアです。問題がなくなるか、修正ラウンドが2回に達した時点で停止します。

例

• 成功例： 6つのルートを持つ管理画面プロジェクトで「/design-prim」を実行 → impeccable はインストール済み（ステップ0をスキップ） → 6画面の before 画像 → PRODUCT.md → hallmark redesign で新しい design.md を生成 → 1回目の /qc-uiux で1画面のコントラスト不合格が報告される → /impeccable harden <view> → 2回目で PASS、before／after 画像を添えて報告。
• 境界／失敗例： エージェントがステップ3で /impeccable document を呼び出してから再デザインする → design.md が古い slop トークンを正確に固定し、「実行は完了したのに見た目が改善しない」ページになる → 記載済みの落とし穴への違反です。その DESIGN.md を破棄し、ステップ3から /impeccable init でやり直します。