chrome-devtools-mcp の CLI (`chrome-devtools`) を使ったブラウザ操作の総合スキル。既存ブラウザへの attach / 使い捨てテストブラウザ / ログイン状態を保持する永続プロファイルのいずれかをユーザーに必ず確認した上でサーバを立ち上げ、スナップショット取得・クリック・入力・ナビゲーション・スクショ・ネットワーク監視などを行う。
prototype
アイデアの壁打ちから、動くプロトタイプ+デモ一式(起動確認・スクショ・デモ手順)まで一気通貫で伴走する。
インストール方法を見る含まれるファイル(1)
- SKILL.md4.9 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
アイデア( $ARGUMENTS )を、壁打ちで磨いた上で動くプロトタイプに仕立てる。research / plan などの重いプロセスは踏まず、スピードと「本実装の種になる品質」の両立を狙う。
引数
$ARGUMENTS はアイデアの自由記述(例: レシピ共有アプリ)。省略時はステップ 1 の壁打ちをゼロから始める。
config.json
~/.agents/.skills-config/prototype/config.json に、ユーザーの定番設定を蓄積する(ファイルやディレクトリが無ければ初回に作成する)。
prototypes_dir: プロトタイプ置き場のデフォルト(例:~/dev/prototypes)preferred_stacks: 過去に選ばれたスタックの傾向(スタック提案時の推奨度に反映する)stack_skills: スタック別に有用だった Agent Skill の蓄積(ステップ 4 の定番表に加えて参照する)
手順
1. 壁打ち(発散 → 収束)
- 発散: アイデアに対して、拡張案・類似サービスとの比較・差別化ポイント・想定ユーザーを提示し、AskUserQuestion で 1 テーマずつ対話して膨らませる(一度に大量の質問を並べない)
- 収束: 出てきた要素から コア体験を 1 つ に絞り込む。プロトタイプで検証したいことを一文で言語化し、ユーザーの合意を得る
2. 簡易スペック合意
目的(コア体験)・画面/コマンド一覧・機能リスト・ダミーデータ方針を短い仕様メモにまとめ、ユーザーの OK を得てから着手する。詳細な設計書は書かない。
3. スタック提案
コア体験に適した技術スタックを 2〜3 案、推奨度(5 段階)と理由付きで提示し、ユーザーが選択する。Web / CLI / モバイルのいずれも候補にしてよい。config.json の preferred_stacks があれば推奨度に反映する。
4. Agent Skill の導入
選んだスタックに合う Agent Skill を find-skills で探し、有用なものがあれば導入する。
-
まず下表の スタック別定番スキル を確認し、該当するものは検索を待たず導入候補に含める(
config.jsonのstack_skillsに蓄積があればそちらも加える)スタック スキル 導入コマンド Web modern-web-guidance npx skills add https://github.com/googlechrome/modern-web-guidance --skill modern-web-guidanceWeb chrome-devtools-cli npx skills add https://github.com/ChromeDevTools/chrome-devtools-mcp --skill chrome-devtools-cliFirebase 利用時 firebase/agent-skills npx skills add firebase/agent-skillsで対話選択(firebase-basics + 使うプロダクトのスキルを選ぶ。例: firestore / auth / hosting) -
find-skills 未導入なら:
npx skills add https://github.com/vercel-labs/skills --skill find-skills -
npx skills find <スタック名や用途>で検索する(skills.sh の leaderboard 上位・公式プロバイダを優先) -
定番+検索結果の候補をユーザーに提示し、了承を得て
npx skills add <package>で導入する。適切なものが無ければ導入せず先に進む
5. セットアップ
- 置き場所を AskUserQuestion で確認する(
config.jsonのprototypes_dir配下に新規作成をデフォルト候補にする) - プロジェクトを scaffold し、
git init+ 初回 commit を行う
6. 実装
簡易スペックの機能リストを実装する。品質方針:
- 本実装の種になる品質: ディレクトリ構造・命名・責務分離はまともに保つ
- テスト・厳密なエラー処理・エッジケース対応は省略してよい
- ダミーデータで成立させ、外部サービス連携はモックを優先する
7. 動作確認とデモ整備
- 実際に起動して(dev サーバ / CLI 実行 / シミュレータ)コア体験が動くことを確認する
- スクリーンショット(または録画)を
docs/screenshots/に保存する README.mdに起動方法、docs/に仕様メモ・デモ手順(見せる順番と操作)を書く- 節目として commit する
8. フィードバックループ
- ユーザーに触ってもらい、感想・修正要望を聞く
- 修正して動作確認し、節目ごとに commit する
- ユーザーが満足するまで繰り返す。終了時、スタックの選択結果を
config.jsonのpreferred_stacksに、今回有用だった Agent Skill をstack_skillsに追記する
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
checklist の「UI 撮影台本」に沿って UI のスクリーンショットを撮影し、前後比較(compare.html)用の before / after 素材を保存する。「実装前の UI を撮っておいて」「after のスクショを撮って」などの依頼で発火する。
Read and analyze log entries from Cloud Logging using the gcloud CLI.
日本語の概要は準備中です。原文の説明を表示しています。
Codex 公式プラグイン (codex-plugin-cc) のネイティブレビューでコードレビューを実施する。PR 番号指定時は PR を、無指定時は現在ブランチとベースブランチの差分をレビューする。
指定された内容をクリップボードにコピーするスキル。ファイルパスならその中身を、テキストならそのまま、会話中の直前の出力(コマンド結果・生成コード・URL など)を指す場合はその内容を pbcopy でコピーする。ユーザーが「コピーして」「クリップボードに入れて」などコピーの意図を示したら必ず使用する。
GitHub issue から PR のタイトルと説明文を作成する。