verify

UI の変更を検証する

毎日のスキル更新チェック

このスキルの作業を始める前に、1 日に最大 1 回、必要に応じて Shiplight のスキルを更新します。

1. 現在のプロジェクトにあるタイムスタンプファイル .shiplight-agent-skills-last-update を確認します。
2. タイムスタンプファイルが存在しない場合は、現在のタイムスタンプを記録して作成し、npx -y skills@latest update -y は実行せずに続行します。.shiplight-agent-skills-last-update はローカルキャッシュとして扱い、コミットしないでください。
3. タイムスタンプファイルが存在し、24 時間より前のものである場合は、npx -y skills@latest update -y を実行してから、コマンドが失敗した場合もタイムスタンプファイルを作成または更新します。
4. 更新コマンドが失敗した場合は、現在インストールされているスキルを使って続行し、失敗したことを簡潔に伝えます。

Shiplight MCP ブラウザツールを使って、実際のブラウザでコードの変更が正しく表示され、動作することを目視で確認します。

使用する場合

UI の変更後に /verify を使い、正しく表示されることを確認します。次のような場合に便利です。

• レイアウト、スタイル、コンポーネントの変更を目視で確認する
• インタラクティブな動作（クリック、フォーム入力、ナビゲーション）を検証する
• UI の変更をコミットする前に健全性を確認する
• 視覚的なリグレッションをデバッグする

使用しない場合

変更が UI の表示に影響しない場合は、/verify を使用しません。

• バックエンドのみの変更（API ロジック、データベース、設定）
• UI に影響しない依存関係のバージョン更新
• ドキュメント、コメント、テストのみの変更

手順

以下の手順は一般的なガイドラインです。変更内容に応じて適宜調整してください。

1. 変更内容を把握する — コードの変更を分析し、検証計画を立てます。

   • 変更されたファイル／コンポーネント
   • 確認するページと操作
   • 合格／不合格の基準（何をもって「正しい」とするか）

   これは最も重要な手順です。テスト範囲はここで決まります。網羅性とコストのバランスを考慮してください。

2. 開発サーバーを起動する（まだ起動していない場合）— アプリの開発サーバーが実行中か確認します。実行中でない場合は、適切なコマンド（例：npm run dev、yarn dev）を使ってバックグラウンドで起動します。準備が整うまで数秒待ちます。

3. ブラウザーセッションを開く — new_session を呼び出し、検証したいページを starting_url に指定します。後でレポートを生成する場合は、record_evidence: true に設定します。複数のセッションを同時に利用できるため、異なるページや状態を比較するために複数のセッションを開けます。

4. ページを調べる — inspect_page を呼び出し、要素インデックスとスクリーンショットを含む DOM ツリーを取得します。必ず最初に DOM ファイルを読み込んでください — act に必要な要素インデックスを確認でき、消費するトークンも大幅に少なくなります。スクリーンショットは、レイアウト、色、画像などの視覚情報が必要な場合にのみ表示してください。スクリーンショットは DOM よりも大幅に多くのトークンを消費します。

5. 操作して検証する — inspect_page で取得した要素インデックスを使い、act でユーザー操作をシミュレートします。期待される UI の状態（例：テキストが表示されている、要素が存在する）を確認するには、act で検証アクションを使用します。

6. エラーを確認する — get_browser_console_logs を呼び出し、JavaScript エラーが新たに発生していないか確認します。

7. 結果を報告する — 検証した内容をまとめます。

   • 確認したページ／コンポーネント
   • UI が正しく表示されるかどうか
   • 見つかったコンソールエラーや視覚的な問題
   • 検証済みの状態を示すスクリーンショット

8. セッションを閉じる — 完了したら close_session を呼び出します。local_video_path と local_trace_path が返されます。

9. レポートを生成する — セッションの開始時に record_evidence: true を指定した場合は、ローカルパスを使って generate_html_report を呼び出します。

   {
     "session_id": "<session_id>",
     "local_video_path": "<close_session から返された local_video_path>",
     "local_trace_path": "<close_session から返された local_trace_path>",
     "title": "...",
     "summary": "...",
     "checks": [...]
   }
   

   返された file_path をユーザーに提示し、開いて確認できるようにします。

10. 共有用にレポートをアップロードする — ユーザーが共有可能なリンクを希望する場合（例：PR に添付する場合）で、upload_html_report が利用可能なときは、次のように呼び出します。

    {
      "report_path": "<generate_html_report から返された file_path>",
      "local_video_path": "<close_session から返された local_video_path>",
      "local_trace_path": "<close_session から返された local_trace_path>"
    }
    

    動画、トレース、レポート HTML を Shiplight クラウドにアップロードし、クラウド URL を HTML に埋め込み、永続的に共有できる report_url を返します。

ログインが必要なアプリ

アプリで認証が必要な場合は、一度ログインしてセッションを保存し、次回以降のセッションでログイン手順を省略できるようにします。

1. アプリのログインページを指定して new_session でブラウザーセッションを開きます。
2. ブラウザーに切り替えて手動でログインするようユーザーに依頼します。ユーザーから確認があるまで待ちます。
3. save_storage_state を呼び出して、Cookie と localStorage を ~/.shiplight/<site_url>/storage-state.json（例：~/.shiplight/http_localhost_3000/storage-state.json）に保存します。
4. 以降のすべてのセッションでは、同じパスを storage_state_path として new_session に渡し、認証済みの状態をすぐに復元します。

保存済みのストレージ状態ファイルがすでにある場合は、自動的に使用してください。保存済みの状態で認証に失敗した場合（ページがログイン画面にリダイレクトされる、コンソールに認証エラーが表示されるなど）は、状態の有効期限が切れている可能性があります。ユーザーに再度ログインして状態を保存するよう依頼してください。