ui-verification

概要

UI 検証では、稼働中の Web アプリに対して、並行する 2 つのモードを実行します。

1. ビジュアル検証 — ページがデザイン仕様に一致しているかを確認します。デザイン上の指定を CSS ルールのチェックに変換し、getComputedStyle() を介して稼働中の DOM に対して実行します。決定論的であり、ブラウザーの計算済みスタイルを正とします。
2. フロー検証 — ユーザージャーニーが正しく完了するかを確認します。.feature ファイルの Gherkin シナリオを、Nova Act の act()（アクション）と act_get()（アサーション）で実行します。非決定論的であり、ネットワークのタイミングや実際の UI の変化によって、実行ごとに結果が異なります。

どちらのモードも、スキル、MCP サーバー、ブラウザーセッションを共有します。1 回の実行で、両方の種類の出力を生成し、1 つのレポートにまとめられます。また、どちらか一方のモードだけを実行することもでき、その場合は統合レポートからもう一方のセクションが省かれます。

各実行で、以下が生成されます。

1. 構造化アーティファクト — ビジュアル検証ではカテゴリごとの JSON、フロー検証ではフローごとの実行データ
2. 注釈付きスクリーンショット — ページ上のビジュアル検証の失敗箇所を示す赤いバウンディングボックス
3. 検証レポート — ビジュアルの概要、フローの概要（フローごとのステータステーブル）、フローごとの詳細レポートへのリンクをまとめた Markdown

verify_* ツールは決定論的です。ビジョンモデルは使用せず、ブラウザーの計算済みスタイルを正とします。ビジュアル検証のコンパイルと監査の処理は LLM 駆動であり、デザインの意図とアプリの実際の構造を可能な範囲で照合します。フローの各ステップは、実行のたびに Nova Act によって解釈されるため、フローの実行は本質的に非決定論的です。

照合の入力

ビジュアル検証。 5 つのコンパイル済みカテゴリファイル（.ui-verification/specs/*.md）は、最大 3 つの入力から照合されます。

入力	提供する内容	必須？
design.md	自由形式のデザインの意図 — トークン、説明文、デザイン言語、コンポーネント定義	必須
稼働中のアプリ	start_browse + verify_* を介して観測する実際の DOM — 実際のセレクター、実際の計算値	検証に必須（セレクターに反映され、ルールの妥当性が確認されます）
アプリのソースコード	コンポーネント、テーマ／トークン、CSS ファイル — 実装上の正確な情報	任意。アクセスできる場合、セレクターの決定性が高まり、差異の分類がより正確になります

フロー検証。 フローは .ui-verification/flows/ に .feature ファイルとして作成または生成されます。

入力	提供する内容	必須？
.feature ファイル	メタデータヘッダー（フロー ID、タイプ、アプリ URL、任意の認証情報とクリーンアップ情報）を含む Gherkin シナリオ	フロー検証に必須
稼働中のアプリ	シナリオの対象。Nova Act は実際の URL に対して実行します	必須
認証情報	フローの # user: メタデータでログインが必要と指定されている場合に提供	条件付き

ソースコードにアクセスできる場合（ユーザーが自分のアプリを開発している場合）、エージェントはソースコードを検出し、コンパイル、監査、仕様生成の際に使用してください。ソースコードはプロジェクトのルート（output_dir にある package.json + src/）にある場合と、1 階層下にある場合があります（例：output_dir/<package-name>/package.json — 検証ツールをワークスペースのルートで開き、1 つ以上のアプリパッケージがサブディレクトリにあるワークスペース構成）。両方の場所を調べてください。ソースコードが利用できない場合（外部サイトの検証やブラックボックスチェック）、スキルは DOM のみのモードで動作します。セレクターは可能な範囲で特定され、監査では design.md と DOM のみを使用します。

アプリの開発に伴い、5 つのカテゴリファイルが成長します。

• Scribe によって design.md が成長します（ユーザーがチャットでデザインの意図を表現 → design.md を編集）
• コンパイラーがアプリ内で検証可能な箇所をより多く発見し、5 つの md ファイルが成長します

どちらのレイヤーも成長しますが、それぞれ固有の作成経路でのみ成長します。5 つの md ファイルを、観察内容の記録や、実際のサイトで値が異なる場合の値の固定を目的に編集することは決してありません — 以下の厳格なルールを参照してください。

3 つの名前 — 混同しないでください

名前	識別するもの
ui-verification	このスキル（エージェントのプレイブック）
nova-act-mcp	ブラウザーと verify_* ツールを提供する MCP サーバー
.ui-verification/	プロジェクトルートにある成果物ディレクトリ（コンパイル済み仕様、アサーション JSON、レポート）

単語が重複していますが、これらに関連はありません。スキルは成果物ディレクトリの中にはありません。成果物ディレクトリはスキルの中ではなく、プロジェクトルートにあります。

機能

機能	ツール	ソースファイル	チェック内容
ビジュアルスタイル	verify_visual_style	specs/visual-style.md	色、タイポグラフィ、間隔、角の半径、影
コンポーネント	verify_components	specs/component-rules.md	コンポーネントの有無、バリアント、プロパティ
アクセシビリティ	verify_accessibility	specs/accessibility.md	Aria ロール、ランドマーク、見出しの階層
プロジェクトルール	verify_project_rules	specs/project-rules.md	レイアウト構造、間隔のシステム、規約
プラットフォーム規約	verify_platform_conventions	specs/platform-conventions.md	ナビゲーションのパターン、ページ構造
ユーザーフロー	act + act_get	flows/<flow-name>.feature	エンドツーエンドのユーザージャーニー、機能の正確性

ビジュアルルールはルート単位で適用範囲を指定できます。各カテゴリファイルには、## Scope: any（デフォルト）と ## Scope: route=<glob> のセクションを含めることができます。references/spec_authoring.md を参照してください。フローシナリオの対象は、# app: メタデータで宣言された URL です。ルート単位の適用範囲はルールごとではなく、フローごとに設定します。

利用可能な MCP ツール（合計 19 個）

セッション管理

• start_browse(url, intent, browser_mode) — URL を開き、session_id を取得します。検証には browser_mode="local" を使用してください。
• session_close(session_id) — ブラウザーセッションを終了します
• session_list() — アクティブなセッションを一覧表示します

検証 — ビジュアルのみ（すべて session_id と rules JSON が必要。必ず output_dir にプロジェクトルートの絶対パスを指定してください）

• verify_visual_style(session_id, rules, output_dir)
• verify_components(session_id, rules, output_dir)
• verify_accessibility(session_id, rules, output_dir)
• verify_project_rules(session_id, rules, output_dir)
• verify_platform_conventions(session_id, rules, output_dir)

これらはビジュアルモードの検証ツールです。フロー検証では、act() と act_get()（以下を参照）が主な操作手段となります。Gherkin のステップには verify_* は適用されません。

output_dir を省略すると、サーバーはアサーションを /tmp/ の一時ディレクトリに書き込みます。その場合、後続のレポート作成や注釈付けのステップでアサーションを見つけられません。

ブラウザー操作（すべて session_id が必要）

• navigate(session_id, url) — URL に移動します
• click(session_id, selector) — 要素をクリックします
• scroll(session_id, direction, selector?) — 上下にスクロールします
• hover(session_id, selector) — 要素にカーソルを合わせます
• press_key(session_id, key) — キーボード入力
• type_text(session_id, selector, text, clear_first?) — 入力欄にテキストを入力します

コンテンツとキャプチャ（すべて session_id が必要）

• evaluate_js(session_id, script) — ページのコンテキストで JavaScript を実行します
• get_page_content(session_id, format?) — ページを "text" または "html" 形式で取得します
• screenshot(session_id, destination?) — ビューポートをファイルパスにキャプチャします

自然言語（すべて session_id が必要）

• act(session_id, prompt) — ブラウザー操作（スクロール、クリック、移動、フォーム入力など）を指示します。フロー検証では、Given ステップと When ステップの主な操作手段です。ビジュアル検証では、CSS チェックに act() を使用せず、代わりに verify_* を使用してください。
• act_get(session_id, prompt, schema?) — 構造化データの抽出または状態の検証を行います。フロー検証では、Then と（Then の後の）And アサーションの主な操作手段です。確定的なチェックには evaluate_js を補助的に使用してください。ビジュアル検証では、CSS チェックに act_get() を使用しないでください。ページの認識と推論は、エージェントが screenshot と get_page_content を使って行い、CSS の判定には verify_* を使用します。

成果物の構成

<project_root>/
  visual/design.md                   ← visual source spec (or .ui-verification/design.md)
  .ui-verification/
    .integrity.json                  ← compile-state ledger (visual only — see spec_sync.md)
    specs/                           ← compiled visual category files (INPUT to verify_*)
      visual-style.md                  (clean markdown — integrity tracked in .integrity.json)
      component-rules.md
      accessibility.md
      project-rules.md
      platform-conventions.md
    flows/                           ← flow .feature files (INPUT to act() / act_get())
      <flow-name>.feature
    sessions/                        ← per-session output (MCP-owned)
      <session_id>/
        <category>_assertions.json    (visual assertion JSON, write-once)
    reports/                         ← per-run output (skill-owned)
      <YYYYMMDD-HHmmssZ>/            ← UTC run-timestamp (a run can span multiple sessions)
        report.md                    ← combined visual + flow summary
        screenshots/                 ← visual annotated failures
        flow-reports/                ← per-flow reports
          <flow-name>.report.md
        sessions.json                ← manifest of session IDs in this run

毎回の実行で守るべき厳格なルール

ユーザーが範囲を絞らない限り、デフォルトのモードは「両方」です

ユーザーが「[url]を検証して」「[url]の検証を実行して」と指示した場合や、対象を限定しない検証を依頼した場合、実行には必ずビジュアル検証とフロー検証の両方を含める必要があります。ビジュアルのみをデフォルトにしてはいけません。ユーザーが明示的に一方のモードのみを指定した場合（「スタイルのみを確認して」「フローのみを実行して」など）、または判別表が単一モードのパターンに明確に一致する場合に限り、対象を一方に絞ってください。

.feature ファイルがない場合は、生成してください（references/flow_generation.md を参照）。design.md がない場合は、生成してください（references/spec_generation.md を参照）。成果物がない場合は、対象範囲を狭めるのではなく、生成してください。

完全性台帳の条件に該当する場合は監査する

verify_* ツールを呼び出す前に、完全性台帳を確認してください（条件については、以下の「完全性台帳がクリーンな状態を対象とする」を参照）。監査を実行する場合は、対象範囲内の各ルールを入力（design.md、アクセス可能な場合はアプリのソース、実行中のアプリの DOM）と照合してください。これは最善を尽くす LLM によるチェックであり、部分文字列の照合ではありません。Compiler 自体が LLM 駆動で、ルールには design.md の文字列と完全には一致しない情報が正当に含まれる場合があるためです。

各ルール（{Name, Selector, Property, Constraint, Scope}）について、次の3つの質問に答えてください。

1. 意図をたどれるか — ルールの主張（何を検証するか：トークン値、プロパティと値の組み合わせ、要素の存在）が、design.md に明記または示唆されているか、ソースコード内のコンポーネント定義／テーマトークンに対応しているか、または実行中のアプリに見られる慣例に対応しているか。
2. 制約が整合するか — 制約値が、この要素／プロパティの組み合わせに対して design.md が指定する値、ソースコードのテーマ／トークンファイルが指定する値、または実行中のアプリでコンポーネントが通常時に描画する状態と一致するか。design.md やソースによる裏付けなしにライブサイトから抽出された制約は、汚染です。
3. セレクターが妥当か — セレクターが、design.md（またはソース）が説明する要素を対象にしているか。セレクターはアプリから取得して、design.md のみから特定できるものより具体的にしてもかまいませんが、対象は説明されている要素と一致している必要があります。

各ルールを次のように分類してください。

• PASS — 3つの質問すべてが、少なくとも1つの入力と整合する
• ORPHAN — ルールの主張に根拠がない。design.md にその主張はなく、ソースにもその割り当てが定義されておらず、唯一の「根拠」はライブサイトに表示されている内容である。これが汚染にあたります。
• DIVERGENT — 主張自体は design.md にある（トークンが定義されている、コンポーネントが参照されている）が、ルールの制約が design.md の割り当てと矛盾している。たとえば、design.md ではコンポーネント X がトークン Y を使うとされているのに、ルールではコンポーネント X がトークン Z の値を持つと主張している場合です。

現在の実行では ORPHAN と DIVERGENT のルールをスキップし、レポートの「Audit Findings」セクションに提示してください（references/verification_report.md を参照）。これらを検証しても、汚染を黙って確認してしまうか、正しい理由なしに失敗することになります。PASS のルールは引き続き検証してください。ユーザーは次の3つの方法で、自身の判断により汚染を解決します。ルールを削除する、主張を design.md に追加して再コンパイルする、または最初から再コンパイルする。

完全性台帳を記録するタイミング。 条件は1つだけです。ディスク上のカテゴリファイルが、現在の design.md から Compiler が今生成する内容と一致する場合に記録します。

• コンパイルが正常に完了し、スキップされたルールがない → 記録する。
• セレクターの修正または制約構文の修正が完了した → 記録する（元の内容が不適切だと判明した後の修正は、現時点で Compiler が生成する内容にあたります）。
• 監査でルールをスキップした（ORPHAN／DIVERGENT） → 記録しない。これらのルールはファイルに残っていますが、新たにコンパイルした場合の内容とは異なります。次回の実行で再監査されるよう、台帳は未作成または古い状態のままにしてください。
• 検証のみの実行で、ファイルに変更がない → 何もしない。既存の台帳には手を加えない。 セレクターの取得元（ヒューリスティックモードではDOMの観察、ソース認識モードではソースコード）は、台帳への記載可否を決定しません。ルールの主張と制約が design.md にたどれる限り（監査で確認します）、台帳にはコンパイラーが承認した有効な状態が反映されます。ケース一覧の全容については、references/spec_sync.md のCompilationステップ7を参照してください。

整合性台帳（.integrity.json）は、クリーンなケースに対応します。 台帳にすべてのハッシュ（design.md と各カテゴリファイル）が一致すると記録されていれば、ファイルの状態はコンパイラーが最後に書き込んだものだと証明できるため、監査は不要です。references/spec_sync.md の§ Integrity Ledgerを参照してください。

監査は次の場合に実行します。

• いずれかのカテゴリファイルのハッシュが台帳と一致しない（コンパイラー外でファイルが編集された場合。以前のバグのある実行、手動編集、部分的な書き込みなど）
• 台帳がない（整合性の基準がないため、保守的に実行）
• ユーザーが明示的に再監査を要求する（手動の正確性チェック。コンパイラーのバグで不正なルールが書き込まれ、ハッシュも更新された場合は、ルールが有効でもハッシュが古くなることがあります）

ハッシュが一致する場合に監査を省略することは、繰り返し実行する際の実質的な効率向上につながります。ただし、大規模なコンパイルの後や、疑わしい変更があった後は、定期的な手動での再監査（「visual-styleを再監査」など）をおすすめします。

監査コスト。 対象となるカテゴリファイルごと（またはルールのバッチごと。どちらにするかはエージェントが判断します）に、LLMの推論パスを1回実行します。無料ではありませんが、対象となるルールの数に比例し、MCPの呼び出しは発生しないため、コストには上限があります。これは、コンパイラーがルールを書き込む際に使用したものと同種の推論です。監査では、「今あらためてコンパイルするなら、このルールを書くか」を確認します。

アサーションJSONは不変です

<output_dir>/.ui-verification/sessions/<session_id>/*_assertions.json にあるファイルは、verify_* の一度だけ書き込まれる出力です。絶対に編集しないでください。 例外はありません。

このJSONには、ライブDOMに対して verify_* が確認した内容が記録されます。値を書き換えたり、合否を変更したり、スコープを追加したり、所見に「注釈」を付けたり、コメントを追加したりしないでください。フィールドが欠けているように見える場合（例：スコープ）、レポート層が元の情報源（例：カテゴリファイル）から結合します。アサーションJSON自体は、MCPサーバーが書き込んだ状態のままにしてください。

アサーションJSONを開いて何かを修正しようとしていることに気づいたら、そこで止めてください。それはレポートの役割です。エージェントはJSONを読み取りますが、verify_* が書き込んだ後にJSONが変更されることはありません。

5 つのカテゴリファイルは design.md を反映しています

コンパイル済みの 5 つの .ui-verification/specs/*.md ファイルは、design.md から生成されます。これらはスクラッチパッド、作業メモリ、観察結果を記録する場所ではありません。

検証モード（design.md が存在する場合）：

次の場合にのみ、カテゴリファイルを編集してください。

• design.md が変更された（またはチャットが design.md の編集になった）→ 該当するルールを再コンパイルする
• セレクターの修復：既存のルールのセレクターが「selector not found」を返し、動作する代替セレクターが見つかった（セレクターのみ更新し、名前／プロパティ／制約はそのままにする）

次の目的でカテゴリファイルを編集しないでください。

• 実際のサイトの観察結果を記録する（それはレポートの役割です）
• 「差異を記録する」ルールを追加し、実際のサイトで異なる値と一致する制約を設定する（サイトのバグが事実としてひそかに記録され、今後の検出ができなくなります）
• 制約を緩めて、不合格のルールを合格にする
• 調査結果、メモ、コンテキストを記録する

一部のみ／範囲を限定して検証する場合は、適切なカテゴリファイルから既存のルールを選択してください。新しいルールを作成してはいけません。ただし、前回のコンパイル時に見落とされた design.md の主張に遡ってたどれる場合は除きます（これは日常的に行うことではなく、表面化させるべきコンパイラーのバグです）。

生成モード（実際のサイトからのコールドコンパイル。design.md がまだない場合）：

5 つの md ファイルを初めて作成するため、この生成中は上記のルールが緩和されます。生成では、実行中のアプリを観察し、design.md と 5 つの md ファイルを 1 回の処理で書き込みます。生成完了時点の 5 つの md ファイルにある制約が、観察された DOM の値と一致するのは、リバースエンジニアリングの仕様であり、汚染ではありません。

「観察結果を記録しない」というガードが有効になるのは、生成が完了し、ユーザーが design.md を確認した後です。それ以降は、上記の検証モードのルールが適用されます。編集は design.md の変更と再コンパイルを通じて行い、5 つの md ファイルを直接編集してはいけません。

生成モードのルールについては、references/spec_generation.md § Phase 5 を参照してください。生成時にソースコードにアクセスできる場合、ソースコードは名前（トークン名、コンポーネント名）の判断材料になりますが、値の判断材料にはなりません。値については DOM が正となります。生成中に「ソースと DOM の不一致」はありません。DOM はすべてのソース CSS をカスケード解決した結果であり、見かけ上の不一致は、エージェントが読んだソースファイルと、ブラウザーがコンパイルした同じソースとの間に生じているだけです。

実行ごとは独立しています

以前の sessions/<session_id>/ または reports/<run-timestamp>/ ディレクトリにある過去のアサーション JSON や report.md を読んではいけません。実行をまたいで引き継がれる状態は、コンパイル済みの specs/*.md ファイルと .integrity.json 台帳のみです（台帳のすべてのハッシュが現在のファイルと一致する場合、再コンパイルはスキップされます）。過去のアサーションとレポートは履歴上の成果物であり、現在の実行には影響しません。

「比較」するために過去のセッションのアサーションを読んでいることに気づいたら、そこで中断してください。これはセッションをまたぐウォームスタートであり、対応は保留されています。新たに実行し、新しいレポートを作成してください。

flows/ にあるフローファイルのみがフロー入力です

<output_dir>/.ui-verification/flows/ にある .feature ファイルだけが、フロー検証の入力です。実行中にチャットの入力からフローをその場で作成してはいけません。また、実行中に .feature ファイルを変更してはいけません。ユーザーがシナリオの変更を希望する場合、次回の実行前に変更を Scribe に依頼してください（references/flow_sync.md を参照）。

フロー実行は非決定的です

以前のフローセッションの結果を、実行をまたいで引き継いではいけません。Nova Act は実行ごとにステップを再解釈し、ネットワークのタイミングは変動し、実際の UI も変化します。「合格」の判定を引き継ぐと、実際の不安定さや環境の変化が隠れてしまいます。フローは毎回すべて実行してください。フロー側のリグレッションは、ウォームスタートの仕組みではなく、統合レポートのフローごとのステータステーブルで明らかになります。

実行ごとにレポートが生成されます

このルールに例外はありません。ユーザーがサイト全体の検証を依頼した場合でも、design.md の1行だけの検証を依頼した場合でも、次の条件を満たすまで実行は完了しません。

1. ルールがディスク上に保存されている — 検証時（ステップ6）に verify_* に渡されるすべてのルールは、適切な ## Scope: セクションの下にあるカテゴリファイルに、あらかじめ記載されている必要があります。（コンパイル時のセレクター検証は verify_* の別の用途です。verification.md のステップ4を参照してください。）
2. スコープはアサーションに記録するのではなく、レポート生成時に結合される — レポートはアサーション JSON（判定用）とカテゴリファイル（スコープ用）の両方を読み込み、ルール名で結合します。アサーション JSON は MCP サーバーが書き込んだ状態をそのまま維持します。結合については references/verification_report.md を参照してください。
3. レポートが書き込まれる — <output_dir>/.ui-verification/reports/<run-timestamp>/report.md に、失敗の表と注釈付きスクリーンショットを出力します。形式については references/verification_report.md を参照してください。すべて合格した実行でも、レポートは生成されます。
4. ユーザー向けの概要にはアサーション JSON ではなくレポートへのリンクを記載する — JSON は中間出力であり、成果物はレポートです。

1つまたは2つの項目だけを確認する「簡易チェック」も、検証の実行にあたります。同じ4つのルールが適用されます。

ワークフロー

ビジュアル検証タスクでは、references/verification.md を読み込みます。フロー検証タスクでは、references/flow_verification.md を読み込みます。どちらのリファレンスにも、それぞれのモードに対応する完全な判断フローが記載されています。

ユーザーの意図	リファレンス
デザイン仕様に照らして稼働中のサイトを検証する（ビジュアル）	references/verification.md
稼働中のサイトでユーザーフローを実行する	references/flow_verification.md
稼働中のサイトから仕様を生成する（design.md が存在しない場合）	references/spec_generation.md
稼働中のサイトからフローを生成する（.feature ファイルが存在しない場合）	references/flow_generation.md
design.md をカテゴリファイルにコンパイルする。チャットでの編集内容を同期する	references/spec_sync.md
ユーザーの意図を .feature ファイルに同期する	references/flow_sync.md
MCP サーバーとブラウザーセッションをセットアップする	references/setup.md
デザイン仕様ファイルを作成・編集する	references/spec_authoring.md
.feature ファイルを作成する	references/flow_authoring.md
検証レポートを生成する（ビジュアル＋フロー）	references/verification_report.md
ページ上で失敗箇所に視覚的な注釈を付ける	references/annotate_failures.md
制約の構文リファレンス	references/constraint_reference.md
カテゴリごとの翻訳パターン	references/verify_visual_style.md、references/verify_components.md、references/verify_accessibility.md、references/verify_project_rules.md、references/verify_platform_conventions.md
セッションをまたいだウォームスタート（延期 — 対象外）	references/warm_start.md

すべてのリファレンスは、この SKILL.md ファイルを基準とする ./references/<name>.md にあります。絶対パスはスキルのインストール先によって異なります。

• グローバルインストール： ~/.<agent>/skills/ui-verification/references/<name>.md
• ワークスペースへのインストール： <project_root>/.<agent>/skills/ui-verification/references/<name>.md

リファレンスを解決する際は、ワークスペースのルートではなく、この SKILL.md があるディレクトリを基準にしてください。スキルローダーのプログレッシブディスクロージャーでセッション中にリファレンスが表示されていない場合は、適切な絶対パスを指定して Read ツールで直接読み込んでください。find を使ってファイルシステムを検索してはいけません。

識別：ビジュアル、フロー、または両方

ユーザーのリクエストに適したモードを選択します。

フレーズのパターン	モード	操作
「デザインを検証」「スタイルを確認」「仕様に一致しているか確認」「ブランドに沿っているか」	ビジュアルのみ	references/verification.md を読み込みます
「フローを実行」「ユーザージャーニーをテスト」「ログインが機能するか検証」	フローのみ	references/flow_verification.md を読み込みます
追加の条件がない「[url] を検証」「[url] の検証を実行」	両方	まずビジュアル、次にフローを検証し、1つのレポートにまとめます
ユーザーが特定の .feature ファイルまたはフロー ID を指定	フローのみ	references/flow_verification.md を読み込み、そのフローのみ実行します
ユーザーが design.md のテキストを選択するか、カテゴリーを指定	ビジュアルのみ	references/verification.md を読み込み、部分選択フローを使用します

判断に迷った場合は、一度だけユーザーに「ビジュアル検証、フロー検証、または両方を実行しますか？」と尋ねます。リクエストの範囲が本当に曖昧な場合は、推測しないでください。

このスキルの場所

このスキルは、ワークスペースローカルにインストールされている場合は <output_dir>/.<agent>/skills/ui-verification/ に、グローバルにインストールされている場合は ~/.<agent>/skills/ui-verification/ にあります。スキルローダーが読み込んだ場所が、インストール先です。ファイルシステムを検索してはいけません。 find ~/.<agent> も find / も実行しないでください。有効化はランタイムの役割です。この SKILL.md に到達した時点で、ランタイムはすでに場所を把握しています。

references ディレクトリの解決

references/ フォルダーは、ワークスペースや出力ディレクトリではなく、常にこの SKILL.md ファイルと同じ場所にあります。このファイルの読み込みにランタイムが使用したパスを基準として使用してください。

インストールの種類	SKILL.md の場所	References の場所
グローバル	~/.<agent>/skills/ui-verification/SKILL.md	~/.<agent>/skills/ui-verification/references/
ワークスペース	<project>/.<agent>/skills/ui-verification/SKILL.md	<project>/.<agent>/skills/ui-verification/references/

リファレンスを読むときは、スキルのインストール先から絶対パスを構成します。グローバルインストールの例：

~/.<agent>/skills/ui-verification/references/verification.md
~/.<agent>/skills/ui-verification/references/spec_sync.md

スキルがグローバルな場所から読み込まれた場合、references が <output_dir>/.<agent>/skills/ui-verification/references/ にあると想定してはいけません。ワークスペースにコピーがない場合があります。

新しいターンで初めて対応するエージェントで、nova-act-mcp のツールがすぐに利用できない場合、MCP サーバーの起動中である可能性があります。ファイルシステムを検索してスキルを「見つける」のではなく、次のユーザーターンでランタイムから利用可能になるまで待ってください。スキルはすでに読み込まれていますが、スキルの有効化とツールの利用可能化は常に同期するとは限りません。

ツールの実装を検索しない

MCP サーバーのソースコード、制約エンジンのソースコード、その他のツール実装を find で検索してはいけません。verify_* の動作、制約の構文、セレクターのマッチングアルゴリズムについては、すべて references/constraint_reference.md とカテゴリーごとの詳細ドキュメントに記載されています。実行中に制約やプロパティの動作が予想外だった場合は、実装ではなくリファレンスを読んでください。 リファレンスはエージェント向けの正式なドキュメントです。find を使ってエンジンを調べようとするのは、リファレンスの更新が必要だという兆候です。その対応はユーザーに委ねられますが、セッション中はドキュメントに記載された動作に従ってください。