Design Harness は何をしますか？
再開可能な Web UI ワークフローを 1 つ実行します。ユーザーが意図を制御し、設計の制作とレビューを分離します。
開始と再開
<skill-dir> をこの SKILL.md を含むディレクトリとして解決します。カレントワーキングディレクトリにバンドルスクリプトがあると想定しないでください。
- 質問をする前に
node <skill-dir>/scripts/preflight.mjs --root <project>を実行します。その機能レポートを読み、何もインストールしないでください。欠落しているファイルシステムパスは参考情報として扱います：Impeccable または Jakub が利用できないと宣言する前に、ホストの読み込まれたスキル/プラグインインベントリを確認します。 node <skill-dir>/scripts/state.mjs init --root <project>を実行します。これにより、initは変更コマンドであるため、レガシーステートが安全にアップグレードされます。ステートが存在する場合は、読み取り専用のstatusコマンドを実行し、そのnextPhaseで再開します。完了したフェーズを再開しないでください。再初期化せずにレガシーランをチェックまたはアップグレードするには、明示的なmigrateを使用します。- 現在のフェーズに必要な参照のみを読み取ります：
- discovery/confirmation： references/interview.md
- context/direction： references/context-contract.md
- build/tool choices： references/routing.md
- オプションのソース選択： references/optional-tool-registry.json（アクティベーション条件が確認された後にのみ）
- review/QA/handoff： references/review-and-qa.md
- 各フェーズが完了した後、
node <skill-dir>/scripts/state.mjs advance <phase> --root <project>で状態を進めます。human-feedbackの場合は、--outcome usedまたは--outcome not-usedも渡します。feedback-fixesの場合は、--outcome appliedまたは--outcome not-applicableを渡します。
次の固定された単調増加シーケンスを使用します：
preflight → discovery → confirmation → context → direction → build → internal-review → human-feedback → feedback-fixes → independent-review → fixes → qa → handoff → complete
マシンの状態のみを .design-harness/state.json に保存します。レポートとスクリーンショットは .design-harness/reports/ に属します。完全なチャットトランスクリプト、トークン、クッキー、資格情報、または無関係な環境データを決して保存しないでください。
承認ゲートを実施する
適応的にインタビューし、回答を 1 つの簡潔な確認カードに要約します。製品、オーディエンス、主要な目標、コンテンツ、ページ/サーフェス、望ましい品質と望ましくない品質、肯定的および否定的な参照、制約、モーション、必要な状態、スタック、委任、AI 固有の状態、WebGL トレランス、外部ソースポリシー、および有料ライセンスの境界を含めます。不足している、または重要な詳細についてのみ質問します。
ユーザーが確認カードを明示的に承認するまで、UI プロダクションコードを作成、編集、生成しないでください。事前チェック、質問、読み取り専用の検査、およびチャット内での確認カードまたは提案されたインテントコンテンツのドラフトは許可されています。承認されるまで、プロジェクトのインテント .md ファイルを作成または変更しないでください。
参照がない場合は、説明的な言葉で十分と見なします。具体的なトレードオフを持つ 2 つまたは 3 つの名前付きの方向性を導き出し、ユーザーに選択を求めます。ビジュアルツールが存在し、ユーザーが恩恵を受ける場合にのみビジュアルボードを生成します。ボードを前提条件にしないでください。
承認されたコンテキストを作成する
確認後、ユーザーの回答またはユーザーが明示的に承認した提案から次のファイルを生成します：
PRODUCT.md（承認されたbrandまたはproductレジスタを含む）REFERENCES.mdDESIGN.mdACCEPTANCE.md- 少なくとも 1 つの
.impeccable/surfaces/<slug>.md
PRODUCT、references、design、acceptance、および surface テンプレートから構造をコピーします。すべてのインテントファイルは、ユーザーがその内容を承認した後にのみ承認済みとしてマークします。ビルドの前に node <skill-dir>/scripts/validate-context.mjs --root <project> を実行します。
DESIGN.md の H2 セクションは、Overview、Colors、Typography、Elevation、Components、Do’s and Don’ts の順序で、正確に 1 回ずつ保持します。
PRODUCT.md と DESIGN.md は承認後、保護されたものとして扱います。後で変更する場合は、提案された差分を表示し、明示的な承認を求め、それを適用します。ドリフトを黙って正当化しないでください。
承認されたすべての外部コンポーネント、レシピ、エフェクト、またはフィードバック統合を、その正確なソース、選択されたアイテム、利用可能な場合は固定されたバージョンまたはコミット、アクセス日、意図された目的、現在のライセンス/利用規約の結果、適応、および必要なフォールバックとともに REFERENCES.md に記録します。「外部ライブラリを使用する」は特定のソースに対する承認ではありません。
Impeccable を通じて構築する
インストールされている Impeccable スキルとその承認されたコンテキストを、このパスの唯一の設計およびプロダクション権限とします。そのスキルと関連するドメイン参照を読み込み、承認されたインテントファイルとサーフェスを渡します。Impeccable が discovery を繰り返したり、承認されたインテントを再解釈したりしないようにします。Impeccable に .impeccable/design.json を生成または更新させます。そのサイドカーを手動で編集したり、結果として生じた PRODUCT.md または DESIGN.md の変更を、保護された差分と承認フローなしで受け入れたりしないでください。
同じプロダクションパスで、他の広範なテイストやデザインシステムスキルをロードしないでください。狭いヘルパーは references/routing.md の下でのみルーティングします。承認されたコンテキストが変更を許可しない限り、既存のコンポーネントライブラリとスタックを保持します。オプションのレジストリエントリを自動インストールまたは自動コピーしないでください。正確な境界のある使用法を説明し、最初に承認を取得します。
ビルド後に Impeccable の自己レビューを実行し、結果を記録します。これは internal-review であり、独立したレビューではありません。UI が検査可能なほど安定したら、human-feedback に入ります。承認された Agentation チェックポイントが有用な場合は提供し、そうでない場合は --outcome not-used で Not used を記録して進めます。Agentation はデフォルトで開発専用かつ手動/ローカルに保ちます。MCP、ウェブフック、および自律的な解決には、別途明示的な承認が必要です。feedback-fixes では、裁定されたユーザー注釈のみを適用し、--outcome applied を記録します。フィードバックがスキップされた場合は、Not applicable を --outcome not-applicable で記録し、編集せずに進めます。独立レビューの前にユーザー注釈を解決します。
レビュー、修正、QA を分離する
independent-review では、Jakub の現在の better-interface スキルとその 6 つのドメインスキルを使用して、新しい読み取り専用のサブエージェント/コンテキストを開始します。スクリーンショット、関連する実装ファイル、コンポーネントライブラリの制約、および承認されたインテントドキュメントを渡します。ビルド後に完全なレビューを要求します。レビューアは結果のみを報告し、編集したり黙って再設計したりしてはなりません。
ルートコンテキストですべての所見を PRODUCT.md、DESIGN.md、サーフェス仕様、受け入れ基準、およびコンポーネントライブラリに対して裁定します。承認/拒否/延期とその根拠を記録します。承認された修正は、プロダクション権限を通じて個別に適用し、その後、変更された領域の集中的なクイック読み取り専用レビューを要求します。
references/review-and-qa.md に従います。Impeccable 検出器、Playwright スクリーンショット（モバイル/タブレット/デスクトップ）、axe、Lighthouse を実行します。代表的なルートと、該当するローディング、空、エラー、長文、ホバー、フォーカス、およびモーション削減状態をカバーします。オプションのソースについては、それらのレジストリゲートも実行します：セマンティック/スタティックフォールバック、WebGL なしの動作、承認されたブラウザ、モバイル CPU/GPU またはバンドル予算、および該当する場合の開発ツールのプロダクションからの除外。サポートされていない、または実行されていない状態は Not reviewed とマークします。決して合格として報告しないでください。
意味のあるドキュメントスクロールモーションがあるインターフェース、またはビデオ/デモ準備のために、専用のローカルポートで新しいプロダクションビルドを開始し、スキャフォールドされた設定を適応させた後、node <skill-dir>/scripts/verify-motion.mjs --root <project> --base-url <url> --routes /,<other-routes> --config .design-harness/qa/motion.config.json を実行します。検証ツールは、デフォルトでモバイル、タブレット、デスクトップをテストし、各ルートを新しいコンテキストで分離し、成功したルート応答、設定されたコンテンツルート、期待される観測された URL/リダイレクトチェーン、および測定可能なドキュメントスクロールを必要とし、明示的なプロジェクト設定が各例外を宣言しない限り、アプリケーションリクエストをモックしたり、リダイレクトを許可したりしません。そのスキーマバージョン 4 の Playwright/ブラウザの出所とスクリーンショット/モックハッシュを引き継ぎとともに保持します。最初のフレーム/スタートアッププローブとフレームペーシングのしきい値は、そのマシンとブラウザのみの証拠として扱い、普遍的な 60 FPS の保証としては決して扱いません。
node <skill-dir>/scripts/scaffold-qa.mjs --root <project> を使用して、一般的な QA スキャフォールドをプレビューし、確認カードが QA 計画を承認した後に --apply を追加します。既存のファイルが置き換えられる場合にのみ、再度質問します。依存関係をインストールすることはありません。
引き渡す
承認された受け入れ基準が合格し、ブロッキングな所見や説明のつかない QA ギャップが残っていない場合にのみ、状態を Ready にします。それ以外の場合は、状態を Not ready にします。変更されたファイル、スクリーンショット、レビューの所見と処分、自動チェックと結果、サポートされていない状態、残っているギャップ、および実際に使用されたすべての外部ソースを、そのピン留めされた出所とライセンス結果とともにリストします。handoff を進め、ワークフローが本当に完了した場合にのみ node <skill-dir>/scripts/state.mjs complete --root <project> を実行します。