| name | app-automation |
| description | Apple app automation guide โ iOS Simulator + macOS app UI interaction, accessibility verification, screenshots/video, workflow automation. Activate on "์๋ฎฌ๋ ์ดํฐ ์๋ํ", "์ฑ ์๋ํ", "app automation", "UI ํ
์คํธ", "์ ๊ทผ์ฑ ๊ฒ์ฆ", "์คํฌ๋ฆฐ์ท", "์๋ฎฌ๋ ์ดํฐ ํญ", "macOS ์ฑ ์กฐ์", "์ธํฐ๋์
ํ
์คํธ", "์ํฌํ๋ก์ฐ ์๋ํ" requests. |
| argument-hint | [target app, scenario, or question to automate] |
| hooks | {"Stop":[{"matcher":"","hooks":[{"type":"agent","model":"sonnet","timeout":90,"prompt":"You are the final verifier for the app-automation skill.\nHook input JSON:\n$ARGUMENTS\n\nFirst classify the task:\n- If the skill turn was advisory-only (docs, explanations, planning, recommendations) and the assistant did not claim to execute runtime automation or verification, return {\"ok\": true}.\n- If the assistant claimed to run or verify simulator/macOS automation, enforce the runtime evidence gates below.\n\nRuntime evidence gates:\n1. There must be environment evidence such as doctor/baepsae_version success, or you should run a lightweight environment check if missing.\n2. There must be pre-action UI evidence via analyze_ui/query_ui or an explicit reason why this was impossible.\n3. There must be post-action state evidence via query_ui/analyze_ui. Screenshot alone is not enough for PASS.\n4. There must be at least one artifact: screenshot path, video path, or UI tree result summary.\n5. If verification failed, the response must identify the exact failed step and propose a retry strategy.\n\nPrefer lightweight verification. Use baepsae tools when available. Do not modify project files.\nReturn JSON only:\n- {\"ok\": true}\n- {\"ok\": false, \"reason\": \"what evidence is missing or what claim failed\"}\n"}]}]} |
user: "์๋ฎฌ๋ ์ดํฐ์์ ์ฑ UI๋ฅผ ์๋์ผ๋ก ํญํ๊ณ ์คํฌ๋ฆฐ์ท ์ฐ์ด์ค"
assistant: "baepsae MCP ๋๊ตฌ๋ฅผ ์ฌ์ฉํด ์๋ฎฌ๋ ์ดํฐ์์ UI ์์๋ฅผ ํญํ๊ณ ์คํฌ๋ฆฐ์ท์ ์บก์ฒํ๊ฒ ์ต๋๋ค."
user: "macOS ์ฑ์ ๋ฉ๋ด๋ฅผ ์๋์ผ๋ก ํด๋ฆญํ๊ณ ๊ฒฐ๊ณผ๋ฅผ ํ์ธํด์ค"
assistant: "baepsae์ macOS ์๋ํ ๋๊ตฌ๋ก ์ฑ ๋ฉ๋ด ์ก์
์ ์คํํ๊ณ UI ์ํ๋ฅผ ํ์ธํ๊ฒ ์ต๋๋ค."
user: "๋ก๊ทธ์ธ โ ๋ฉ์ธ ํ๋ฉด โ ์ค์ ์์๋ก ์๋ํ ์ํฌํ๋ก์ฐ ๋ง๋ค์ด์ค"
assistant: "run_steps๋ก ๋ฉํฐ์คํ
์ํฌํ๋ก์ฐ๋ฅผ ๊ตฌ์ฑํ์ฌ ๋ก๊ทธ์ธ๋ถํฐ ์ค์ ํ๋ฉด๊น์ง ์๋ํํ๊ฒ ์ต๋๋ค."
user: "์ฑ์ ์ ๊ทผ์ฑ ํธ๋ฆฌ๋ฅผ ๋ถ์ํด์ค"
assistant: "analyze_ui๋ก ํ์ฌ ํ๋ฉด์ ์ ๊ทผ์ฑ ํธ๋ฆฌ๋ฅผ ํ์
ํ๊ณ UI ์์ ๊ตฌ์กฐ๋ฅผ ๋ถ์ํ๊ฒ ์ต๋๋ค."
app-automation
Apple app automation guide โ iOS Simulator + macOS app UI interaction, accessibility verification, screenshots/video, workflow automation.
Use the baepsae MCP server as the core toolset; if the axe-simulator plugin is present, use it via compatibility mapping.
Respond to the user in Korean.
Tool reference: see references/baepsae-tools.md
1. Tool detection pattern
Before starting automation work, detect available tools in this priority order.
Priority 1: baepsae MCP
When the baepsae MCP server is connected, all automation features are directly available. It supports the full set of 35 tools.
- Check: call
baepsae_version or doctor
- Supports both iOS Simulator and macOS apps
Priority 2: axe-simulator plugin
When the axe-simulator MCP plugin is active, you can perform iOS Simulator automation. It has fewer tools than baepsae but covers the core features.
- Check: call
mcp__plugin_axe-simulator_axe-simulator__axe_list_simulators
- iOS Simulator only (no macOS app automation)
- For tool mapping, see the axe-simulator compatibility section below
Priority 3: CLI fallback
When no MCP tools are available, use the xcrun simctl CLI for basic simulator operations.
xcrun simctl list devices available
xcrun simctl install booted /path/to/App.app
xcrun simctl launch booted com.example.app
xcrun simctl io booted screenshot /tmp/screenshot.png
xcrun simctl openurl booted "https://example.com"
xcrun simctl terminate booted com.example.app
The CLI fallback does not support UI interaction (tap, swipe, etc.) or accessibility analysis. If those features are needed, guide the user to install baepsae or axe-simulator.
2. iOS Simulator automation
Simulator management
list_simulators # ์ฌ์ฉ ๊ฐ๋ฅํ ์๋ฎฌ๋ ์ดํฐ ๋ชฉ๋ก
install_app(path) # .app ๋ฒ๋ค ์ค์น
launch_app(bundleId) # ์ฑ ์คํ
terminate_app(bundleId) # ์ฑ ์ข
๋ฃ
uninstall_app(bundleId) # ์ฑ ์ญ์
open_url(url) # URL ์คํด/๋ฅ๋งํฌ ์ด๊ธฐ
UI interaction
tap(selector) # ์ ๊ทผ์ฑ ์
๋ ํฐ๋ก ํญ (label, id, type)
tap(x, y) # ์ขํ๋ก ํญ
tap_tab(label) # ํญ๋ฐ ์์ดํ
ํญ
swipe(direction, selector) # ์ค์์ดํ (up, down, left, right)
scroll(direction, selector) # ์คํฌ๋กค
drag_drop(from, to) # ๋๋๊ทธ ์ค ๋๋กญ
type_text(text) # ํ
์คํธ ์
๋ ฅ
key(key) # ๋จ์ผ ํค ์
๋ ฅ
key_sequence(keys) # ํค ์ํ์ค
key_combo(keys) # ํค ์กฐํฉ
touch(x, y) # ์ขํ ๊ธฐ๋ฐ ํฐ์น
button(name) # ํ๋์จ์ด ๋ฒํผ (home, lock, volumeUp ๋ฑ)
gesture(name) # ํ๋ฆฌ์
์ ์ค์ฒ (scrollUp, scrollDown, pinchIn, pinchOut ๋ฑ)
Accessibility tree analysis
analyze_ui() # ์ ์ฒด ์ ๊ทผ์ฑ ํธ๋ฆฌ ๋คํ โ UI ๊ตฌ์กฐ ํ์
์ ์ฒซ ๋จ๊ณ
analyze_ui(appBundleId) # ํน์ ์ฑ์ ์ ๊ทผ์ฑ ํธ๋ฆฌ
query_ui(selector) # ํน์ ์์ ๊ฒ์ (id:"loginBtn", label:"๋ก๊ทธ์ธ", type:"Button")
Usage pattern:
- Use
analyze_ui() to understand the overall UI structure
- Identify the target element's selector (label, id, type)
- Interact with that element via
tap(selector), etc.
- Run
analyze_ui() again to confirm the UI state change
Screenshot / video
screenshot() # ํ์ฌ ํ๋ฉด ์คํฌ๋ฆฐ์ท
screenshot(path) # ์ง์ ๊ฒฝ๋ก์ ์ ์ฅ
record_video(path, duration) # ๋น๋์ค ๋
นํ (์ด ๋จ์)
stream_video() # ๋น๋์ค ์คํธ๋ฆฌ๋ฐ
3. macOS app automation
macOS automation is supported by baepsae MCP only. It is not available via axe-simulator or the CLI fallback.
App management
list_apps() # ์ค์น๋ ์ฑ ๋ชฉ๋ก
activate_app(bundleId) # ์ฑ ํ์ฑํ/ํฌ์ปค์ค
get_focused_app() # ํ์ฌ ํฌ์ปค์ค ์ฑ ์ ๋ณด
list_windows(bundleId) # ์ฑ์ ์๋์ฐ ๋ชฉ๋ก
UI interaction
tap(selector, appBundleId) # macOS ์ฑ ๋ด ์์ ํญ
type_text(text, appBundleId) # macOS ์ฑ์ ํ
์คํธ ์
๋ ฅ
right_click(selector) # ์ฐํด๋ฆญ (์ปจํ
์คํธ ๋ฉ๋ด)
menu_action(app, menu, item) # ๋ฉ๋ด ๋ฐ ์ก์
์คํ
key_combo(keys) # ํค๋ณด๋ ๋จ์ถํค (Cmd+S, Cmd+A ๋ฑ)
clipboard(action, text) # ํด๋ฆฝ๋ณด๋ ์ฝ๊ธฐ/์ฐ๊ธฐ
Screenshot
screenshot_app(bundleId) # ํน์ ์ฑ ์๋์ฐ ์คํฌ๋ฆฐ์ท
screenshot_app(bundleId, windowId) # ํน์ ์๋์ฐ ์บก์ฒ
macOS automation tips:
- Bring the app to the foreground first with
activate_app
- Confirm the currently active app with
get_focused_app before acting
- Specify the menu bar path exactly for
menu_action (e.g. "File" โ "Save As...")
- Accessibility permission may be required โ diagnose the environment with
doctor
4. Workflow automation
run_steps: multi-step scenario execution
Bundle multiple automation steps into a single workflow and run them sequentially.
{
"steps": [
{ "action": "launch_app", "bundleId": "com.example.app" },
{ "action": "wait", "seconds": 2 },
{ "action": "tap", "selector": "label:๋ก๊ทธ์ธ" },
{ "action": "type_text", "text": "user@example.com", "selector": "id:emailField" },
{ "action": "tap", "selector": "label:๋ค์" },
{ "action": "type_text", "text": "password123", "selector": "id:passwordField" },
{ "action": "tap", "selector": "label:๋ก๊ทธ์ธ" },
{ "action": "wait", "seconds": 3 },
{ "action": "screenshot", "path": "/tmp/after-login.png" },
{ "action": "analyze_ui" }
],
"continueOnError": false
}
Key options:
continueOnError: true โ keep running the remaining steps even if a step fails
continueOnError: false (default) โ stop immediately on failure
- Use a
wait step to wait for animations/network
- Returns each step result as an array
Selector wait/retry pattern:
When a UI element has not yet rendered:
- Add a
wait step (1-3s)
- Confirm the element exists with
query_ui
- Retry if absent
{
"steps": [
{ "action": "query_ui", "selector": "label:๋ฉ์ธ ํ๋ฉด" },
{ "action": "wait", "seconds": 2 },
{ "action": "query_ui", "selector": "label:๋ฉ์ธ ํ๋ฉด" },
{ "action": "tap", "selector": "label:์ค์ " }
],
"continueOnError": true
}
5. apple-craft harness integration
The harness-evaluator from the apple-craft plugin can use this plugin's automation tools to perform runtime verification.
Evaluator usage scenarios
| Evaluator stage | app-automation tool | Purpose |
|---|
| App launch check | launch_app + analyze_ui | Whether the built app launches normally |
| UI rendering verification | screenshot + analyze_ui | Whether the screen renders as designed |
| Interaction verification | tap + query_ui | Whether tapping a button transitions to the expected screen |
| Accessibility verification | analyze_ui | Whether every element has an accessibility label |
| E2E scenario | run_steps | Whether the full user flow works correctly |
Integration method: after the build completes, the Evaluator calls the automation tools to verify runtime state. Use analyze_ui to inspect the UI tree and screenshot to capture the visual result.
6. axe-simulator compatibility
In environments where the axe-simulator plugin is installed, use the tool mapping below to perform iOS Simulator automation.
| baepsae tool | axe-simulator tool | Note |
|---|
tap | axe_tap | Supports both selector and coordinates |
swipe | axe_swipe | Same direction parameter |
type_text | axe_type | |
key | axe_key | |
key_combo | axe_key_combo | |
button | axe_button | home, lock, etc. |
gesture | axe_gesture | Preset gestures |
screenshot | axe_screenshot | |
analyze_ui | axe_describe_ui | Accessibility tree analysis |
list_simulators | axe_list_simulators | |
run_steps (simplified) | axe_batch | Multi-step batch |
Features missing in axe-simulator:
- All macOS app automation (activate_app, menu_action, screenshot_app, etc.)
query_ui (specific element search)
record_video, stream_video
drag_drop, right_click, clipboard
install_app, uninstall_app, open_url
- Advanced
run_steps options (continueOnError, etc.)
axe-simulator provides only the core iOS Simulator features. Use the baepsae MCP when the full feature set is needed.
7. Verification agent integration
This plugin also ships a ui-verifier agent. Its purpose is to separate automation execution from automation verification.
When to use it
- "์๋ํ๊ฐ ์ง์ง ์ฑ๊ณตํ๋์ง ๊ฒ์ฆํด์ค"
- "์ค์ ํ๋ฉด๊น์ง ๊ฐ๋ค๊ณ ํ๋๋ฐ selector evidence๋ก ๋ค์ ํ์ธํด์ค"
- "์ด ํ๋ก์ฐ๊ฐ ์ฌํ ๊ฐ๋ฅํ์ง ํ์ธํด์ค"
Recommended pattern
- actor step โ perform the flow via
run_steps, tap, type_text, launch_app, etc.
- observer step โ
ui-verifier checks evidence via query_ui, analyze_ui, screenshot
- exit gate โ this skill's
Stop agent hook catches missing verification before the final response
Manual invocation examples
Use the ui-verifier agent to verify the last simulator flow
Have the ui-verifier agent check whether the settings screen actually opened
ui-verifier hard gate
doctor or equivalent environment check succeeds
- UI state evidence exists before the interaction
- Expected state evidence exists after the interaction
- At least one of screenshot/video/UI tree exists
- On failure, report the blocked step + retry strategy
If only a screenshot exists without selector evidence, the default verdict is REFINE, not PASS.
Rules
- Inspect the current UI state with
analyze_ui (or axe_describe_ui) before automation work, since selectors depend on the live UI tree.
- Prefer selectors in order
id: โ label: โ type: โ coordinates (most to least stable).
- Use coordinate-based taps only as a last resort, since they are resolution-dependent.
- Place
wait steps appropriately to account for asynchronous UI updates.
- Confirm accessibility permission for macOS automation (diagnose with
doctor), since it is required for UI access.
- Save screenshots to
/tmp/ or a project-designated directory.
- Respond in Korean, keeping tool names and parameter names in their original form.
- Read
references/baepsae-tools.md when a tool reference is needed.