القائمة
Android Emulator / iOS Simulator 上で実装済みアプリ画面を起動・反映・操作・キャプチャする。現時点では Android/stub 対応、iOS は拡張予定。実装後レビュー、Figma との見た目突合、Emulator/Simulator のスクリーンショット取得が必要なときに使用する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | capture-emulator-screen |
| description | Android Emulator / iOS Simulator 上で実装済みアプリ画面を起動・反映・操作・キャプチャする。現時点では Android/stub 対応、iOS は拡張予定。実装後レビュー、Figma との見た目突合、Emulator/Simulator のスクリーンショット取得が必要なときに使用する。 |
| user-invocable | true |
| argument-hint | <screen_name> [到達手順 / 表示状態] |
| allowed-tools | Bash(adb *), Bash(flutter *), Bash(dart *), Bash(melos *), Bash(python3 *), Bash(bash *), Bash(sleep *), Bash(ls *), Bash(mkdir *), Read, Glob, Grep, AskUserQuestion |
Android Emulator / iOS Simulator 上で、実装済みアプリの画面を最新コード反映後にキャプチャする。
差分判定や修正は、呼び出し元の impl-issue や sync-screen-design が担当する。
.figma_tmp/captures/xcrun simctl io booted screenshot と integration_test フローで拡張する。キャプチャ前に、必ず最新コードが Emulator / Simulator に反映されていることを確認する。 編集前ビルドのスクリーンショットは、修正後レビューの根拠にしてはいけない。
Android Emulator / iOS Simulator が複数起動している場合は、勝手に先頭デバイスを選ばない。
必ず候補（serial / 解像度 / density / アプリインストール状態）を確認し、AskUserQuestion（Cursor では AskQuestion）でユーザーに対象デバイスを選択してもらう。
選択後は ANDROID_SERIAL または adb -s <serial> で対象を固定し、以後の起動・操作・キャプチャを同じデバイスに対して実行する。
他の Skill は、この Skill 名（capture-emulator-screen）を指定して呼び出す。
呼び出し元は、この Skill 配下のスクリプトを直接実行してはいけない。
入力として、対象画面名、到達手順、表示したい状態、必要な反映方法（hot reload / hot restart / full rebuild）を受け取る。 出力として、保存先、反映方法、端末、到達手順、未確認事項を呼び出し元に返す。
詳細は docs/simulator-capture.md を読む。
この Skill の内部実装として、必要に応じて自身の scripts/ 配下のスクリプトを使う。
呼び出し元へ次を簡潔に報告する。
実装キャプチャ:
- 画像: `.figma_tmp/captures/<screen_name>.png`
- 対象: Android Emulator / stub
- コード反映: hot reload | hot restart | full rebuild | 未確認
- 到達手順: <実行した操作>
- 未確認事項: <あれば>
msg-sys 通信基盤（常駐 Codex セッションとの Stop フック経由の非同期往復）の上で、 Codex とのレビュー依頼・所見受領・修正・完了判定を駆動する。3モード（依頼/受信/再開）を持つ。 依頼モードのトリガー句: "msg-reviewでレビュー依頼", "Codexとレビュー往復したい", "常駐Codexにレビューを依頼", "msg-reviewを実行して", "Codexセッションにコードレビューを頼みたい"。 受信モードの起動契機（トリガー句ではなくメッセージ本文の形式で成立）: Stop フックが差し戻した メッセージ本文の先頭が `[msg-review] <種別> review_id=<review_id> round=<n>` である。 再開モードのトリガー句: "msg-reviewを再開したい", "レビューの往復上限到達通知が来た、状況を確認して", "review_idの未解決所見を要約して", "msg-reviewの続きを確認したい"。
設計書から実装戦略を策定し、タスクを抽出して YAML 計画書を作成・更新する。レビュー+自動修正→commit まで一貫実行。 トリガー: "計画書作成", "計画開始", "start plan", "start planning"
計画書からタスクを選び、実装・レビュー・計画更新まで一貫して実行する。 トリガー: "実装開始", "タスク実行", "start implement"
コード・文書をレビューし、品質問題の発見から修正まで自動化できる。重大度 🔴🟡🟢 で分類。 --auto で修正まで一貫実行。code/requirement/design/plan/uxui/generic の6種別に対応。 トリガー: "レビュー", "review", "レビューして", "確認して"
GitHub Issue を軽量実装で進めるか forge の SDD フロー（start-requirements/start-design/start-plan）に委ねるかを判定するスキル。feature namespace の要否も判定する。トリガー：「このIssueをトリアージして」「Issueの進め方を判定して」「#N はどう進めるべきか判定して」
GitHub Issue の実装を準備から完了まで一貫して行う。triage の判定調査結果（仕様書・ルール・類似PR・既存コードの特定）を引き継ぎ、実装計画の策定・Issue への解決内容記載・実装・レビューまで進める。UI Issue の場合は Figma デザイン仕様書・実装設計書の作成、UI 実装、実装レビューまでカバーする。 `/anvil:triage-issue` が軽量実装と判定した Issue に対して Skill ツール経由でのみ起動される（ユーザーからの直接起動は不可）。