원클릭으로
test
chrome-devtools を使って動作確認チェックリストに沿ったテストを実行する。「動作確認して」「テストして」「動作テストして」「ブラウザで確認して」「チェックリストを確認して」などの依頼で発火する。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
chrome-devtools を使って動作確認チェックリストに沿ったテストを実行する。「動作確認して」「テストして」「動作テストして」「ブラウザで確認して」「チェックリストを確認して」などの依頼で発火する。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| 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)に報告するCodex CLI にコードレビューを依頼する。PR が存在する場合は PR を、ローカルブランチの場合はメインブランチとの差分をレビューする。
GitHub issue から PR のタイトルと説明文を作成する。
GitHub issue から計画・実装・テスト・レビュー・PR テキスト・理解確認まで一気通貫で行う。
GitHub issue と実装計画をもとにコードを実装する。計画からの逸脱は implementation-notes.md に記録しながら進める。
research の結果と受け入れ条件をもとに、実装方法を選択し TDD ベースの実装計画と動作確認チェックリストを作成する。
変更内容の解説(explainer)と理解確認クイズを生成する。マージ前に変更を理解しているか確かめたいとき、「この変更を説明して」「クイズを出して」「変更内容を理解したい」などの依頼で使う。