一键导入
test
chrome-devtools を使って動作確認チェックリストに沿ったテストを実行する。「動作確認して」「テストして」「動作テストして」「ブラウザで確認して」「チェックリストを確認して」などの依頼で発火する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
chrome-devtools を使って動作確認チェックリストに沿ったテストを実行する。「動作確認して」「テストして」「動作テストして」「ブラウザで確認して」「チェックリストを確認して」などの依頼で発火する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Integrate Firebase Auth (authentication + domain restriction) into internal applications. Includes domain restriction via Blocking Functions and user registration to Firestore.
chrome-devtools-mcp の CLI (`chrome-devtools`) を使ったブラウザ操作の総合スキル。既存ブラウザへの attach / 使い捨てテストブラウザ / ログイン状態を保持する永続プロファイルのいずれかをユーザーに必ず確認した上でサーバを立ち上げ、スナップショット取得・クリック・入力・ナビゲーション・スクショ・ネットワーク監視などを行う。
Access the Firebase Emulator Suite (Firestore, Auth, Functions, Hub) via REST and Admin SDK without trial-and-error. Use this skill whenever you read/write/query/clear Firestore Emulator data, create test users or obtain ID tokens from the Auth Emulator, verify Functions triggers, seed/export emulator data, or hit unexpected 403/404 from an emulator endpoint. Consult it BEFORE curling any emulator port — it encodes the auth header and host-resolution rules that otherwise cause retries.
GitHub issue と実装計画をもとにコードを実装する。計画からの逸脱は implementation-notes.md に記録しながら進める。
GitHub PR のレビューコメントを評価するスキル。コメントの妥当性をコードベースで独立検証し、対応可否の判定・返信文案の作成・(指示があれば)修正実装まで行う。ユーザーが PR コメントの URL を貼って「評価して」「考察して」「妥当性を判断して」「対応可否を考えて」「どう思う?」などの意図を示したら必ず使用する。
GitHub issue から計画・実装・テスト・レビュー・PR テキスト・理解確認まで一気通貫で行う。
| name | test |
| description | chrome-devtools を使って動作確認チェックリストに沿ったテストを実行する。「動作確認して」「テストして」「動作テストして」「ブラウザで確認して」「チェックリストを確認して」などの依頼で発火する。 |
| allowed-tools | Bash, Read, Glob, Grep, Write, Edit, Skill, AskUserQuestion |
chrome-devtools を使って動作確認テストを実行する。
$ARGUMENTS は <issue> [mode] の形式で受け取る。
<issue>: issue 番号(123、#123)または URL。空の場合はユーザーに issue 番号を質問する[mode]: auto / normal。auto の場合はユーザーに質問しない(fallback 時の挙動は手順 2 参照)。省略時は質問してよい/chrome-devtools-cli スキルがインストール済みであることこのスキルのディレクトリにある config.json を読み込み、過去のテストでハマったポイントを把握する。テスト実行時にこれらのポイントに注意し、同じ問題を回避する。
tmp/issues/<issue番号>/checklist.html の存在を確認する。
/plan が生成する checklist.html の出力構造(前提条件 / 正常系 / 異常系 / エッジケース / 補助項目、AC 番号併記、checkbox)に準拠する
normal: AskUserQuestion でどのようなテストを行うか質問し、回答をもとに作成するauto: 質問せず、research.md の AC と plan.md(あれば。md が無ければ html)から自動構築し、その旨をチェックリスト冒頭に明記するtmp/issues/<issue番号>/implementation-notes.md が存在する場合、## Deviations を読み、計画時に作られたチェックリストと実装の実態に乖離がないかを確認する。逸脱によって操作手順・期待結果が変わった項目があれば、テスト実行前に checklist.html を更新する(変更した項目には理由を 1 行添える)。
チェックリストの各項目について、/chrome-devtools-cli スキルを使って動作確認を行う。
/chrome-devtools-cli でブラウザ操作を行い、期待する動作を確認するtmp/issues/<issue番号>/screenshots/ 配下に保存する(ファイル名例: 01_ログイン画面.png, 02_ボタンクリック後.png など、連番と内容がわかる名前をつける)checklist.html 内の対応する <input type="checkbox"> に checked 属性を付与する(例: <input type="checkbox" checked>)<p class="ng">NG: ボタンクリック後にエラーが表示された</p>)/dev の場合、失敗項目の有無が再計画ループの判定に使われる)テスト中に発生した問題や予期しない挙動があった場合、config.json に記録する。記録する内容:
issue: 発生した問題の概要cause: 原因(判明している場合)workaround: 回避策や対処法date: 発生日config.json の既知の問題点を確認し、同じポイントでハマらないようにする/quiz の解説パートでデモとしても再利用される)config.json に有用な知見があれば追記する/dev)に報告する