ce-test-xcode
$
npx mdskill add EveryInc/compound-engineering-plugin/ce-test-xcodeBuild, install, and test iOS apps on the simulator using XcodeBuildMCP. Captures screenshots, logs, and verifies app behavior.
SKILL.md
.github/skills/ce-test-xcodeView on GitHub ↗
--- name: ce-test-xcode description: "Build and test iOS apps on simulator using XcodeBuildMCP. Use after making iOS code changes, before creating a PR, or when verifying app behavior and checking for crashes on simulator." argument-hint: "[scheme name or 'current' to use default]" disable-model-invocation: true --- # Xcode Test Skill Build, install, and test iOS apps on the simulator using XcodeBuildMCP. Captures screenshots, logs, and verifies app behavior. ## Prerequisites - Xcode installed with command-line tools - XcodeBuildMCP MCP server connected - Valid Xcode project or workspace - At least one iOS Simulator available ## Workflow ### 0. Verify XcodeBuildMCP is Available Check that the XcodeBuildMCP MCP server is connected by calling its `list_simulators` tool. MCP tool names vary by platform: - Claude Code: `mcp__xcodebuildmcp__list_simulators` - Other platforms: use the equivalent MCP tool call for the `XcodeBuildMCP` server's `list_simulators` method If the tool is not found or errors, inform the user they need to add the XcodeBuildMCP MCP server: ``` XcodeBuildMCP not installed Install via Homebrew: brew tap getsentry/xcodebuildmcp && brew install xcodebuildmcp Or via npx (no global install needed): npx -y xcodebuildmcp@latest mcp Then add "XcodeBuildMCP" as an MCP server in your agent configuration and restart your agent. ``` Do NOT proceed until XcodeBuildMCP is confirmed working. ### 1. Discover Project and Scheme Call XcodeBuildMCP's `discover_projs` tool to find available projects, then `list_schemes` with the project path to get available schemes. If an argument was provided, use that scheme name. If "current", use the default/last-used scheme. ### 2. Boot Simulator Call `list_simulators` to find available simulators. Boot the preferred simulator (iPhone 15 Pro recommended) using `boot_simulator` with the simulator's UUID. Wait for the simulator to be ready before proceeding. ### 3. Build the App Call `build_ios_sim_app` with the project path and scheme name. **On failure:** - Capture build errors - Report to user with specific error details **On success:** - Note the built app path for installation - Proceed to step 4 ### 4. Install and Launch 1. Call `install_app_on_simulator` with the built app path and simulator UUID 2. Call `launch_app_on_simulator` with the bundle ID and simulator UUID 3. Call `capture_sim_logs` with the simulator UUID and bundle ID to start log capture ### 5. Test Key Screens For each key screen in the app: **Take screenshot:** Call `take_screenshot` with the simulator UUID and a descriptive filename (e.g., `screen-home.png`). **Review screenshot for:** - UI elements rendered correctly - No error messages visible - Expected content displayed - Layout looks correct **Check logs for errors:** Call `get_sim_logs` with the simulator UUID. Look for: - Crashes - Exceptions - Error-level log messages - Failed network requests **Known automation limitation — SwiftUI Text links:** Simulated taps (via XcodeBuildMCP or any simulator automation tool) do not trigger gesture recognizers on SwiftUI `Text` views with inline `AttributedString` links. Taps report success but have no effect. This is a platform limitation — inline links are not exposed as separate elements in the accessibility tree. When a tap on a Text link has no visible effect, prompt the user to tap manually in the simulator. If the target URL is known, `xcrun simctl openurl <device> <URL>` can open it directly as a fallback. ### 6. Human Verification (When Required) Pause for human input when testing touches flows that require device interaction. | Flow Type | What to Ask | |-----------|-------------| | Sign in with Apple | "Please complete Sign in with Apple on the simulator" | | Push notifications | "Send a test push and confirm it appears" | | In-app purchases | "Complete a sandbox purchase" | | Camera/Photos | "Grant permissions and verify camera works" | | Location | "Allow location access and verify map updates" | | SwiftUI Text links | "Please tap on [element description] manually — automated taps cannot trigger inline text links" | Ask the user using the platform's blocking question tool: `AskUserQuestion` in Claude Code (call `ToolSearch` with `select:AskUserQuestion` first if its schema isn't loaded), `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension). Fall back to numbered options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question: ``` Human Verification Needed This test requires [flow type]. Please: 1. [Action to take on simulator] 2. [What to verify] Did it work correctly? 1. Yes - continue testing 2. No - describe the issue ``` ### 7. Handle Failures When a test fails: 1. **Document the failure:** - Take screenshot of error state - Capture console logs - Note reproduction steps 2. **Ask the user how to proceed:** ``` Test Failed: [screen/feature] Issue: [description] Logs: [relevant error messages] How to proceed? 1. Fix now - debug, propose a fix, rebuild and retest 2. Skip - continue testing other screens ``` 3. **If "Fix now":** investigate, propose a fix, rebuild and retest 4. **If "Skip":** log as skipped, continue ### 8. Test Summary After all tests complete, present a summary: ```markdown ## Xcode Test Results **Project:** [project name] **Scheme:** [scheme name] **Simulator:** [simulator name] ### Build: Success / Failed ### Screens Tested: [count] | Screen | Status | Notes | |--------|--------|-------| | Launch | Pass | | | Home | Pass | | | Settings | Fail | Crash on tap | | Profile | Skip | Requires login | ### Console Errors: [count] - [List any errors found] ### Human Verifications: [count] - Sign in with Apple: Confirmed - Push notifications: Confirmed ### Failures: [count] - Settings screen - crash on navigation ### Result: [PASS / FAIL / PARTIAL] ``` ### 9. Cleanup After testing: 1. Call `stop_log_capture` with the simulator UUID 2. Optionally call `shutdown_simulator` with the simulator UUID ## Quick Usage Examples ```bash # Test with default scheme /ce-test-xcode # Test specific scheme /ce-test-xcode MyApp-Debug # Test after making changes /ce-test-xcode current ``` ## Integration with ce-code-review When reviewing PRs that touch iOS code, the `ce-code-review` workflow can spawn an agent to run this skill, build on the simulator, test key screens, and check for crashes.
More from EveryInc/compound-engineering-plugin
- ce-agent-native-architectureBuild applications where agents are first-class citizens. Use this skill when designing autonomous agents, creating MCP tools, implementing self-modifying systems, or building apps where features are outcomes achieved by agents operating in a loop.
- ce-agent-native-auditRun comprehensive agent-native architecture review with scored principles
- ce-brainstormExplore requirements and approaches through collaborative dialogue, then write a right-sized requirements document. Use when the user says "let''s brainstorm", "what should we build", or "help me think through X", presents a vague or ambitious feature request, or seems unsure about scope or direction -- even without explicitly asking to brainstorm.
- ce-clean-gone-branchesClean up local branches whose remote tracking branch is gone. Use when the user says "clean up branches", "delete gone branches", "prune local branches", "clean gone", or wants to remove stale local branches that no longer exist on the remote. Also handles removing associated worktrees for branches that have them.
- ce-code-reviewStructured code review using tiered persona agents, confidence-gated findings, and a merge/dedup pipeline. In interactive mode it applies safe, verified fixes and commits them when the working tree is clean (it never pushes); in mode:agent it reports only and the caller applies. Use when reviewing code changes before creating a PR.
- ce-commitCreate a git commit with a clear, value-communicating message. Use when the user says "commit", "commit this", "save my changes", "create a commit", or wants to commit staged or unstaged work. Produces well-structured commit messages that follow repo conventions when they exist, and defaults to conventional commit format otherwise.
- ce-commit-push-prCommit, push, and open a PR with an adaptive, value-first description that scales in depth with the change. Use when the user says "commit and PR", "ship this", "create a PR", or "open a pull request". Also handles description-only flows ("write a PR description", "rewrite the PR body", "describe this PR") without committing or pushing.
- ce-compoundDocument a recently solved problem to compound your team's knowledge or CONCEPTS.md, the project's shared domain vocabulary.
- ce-compound-refreshRefresh stale learning and pattern docs under docs/solutions/ by reviewing them against the current codebase, then updating, consolidating, or deleting drifted ones. Use when the user asks to "refresh my learnings", "audit docs/solutions/", "clean up stale learnings", or "consolidate overlapping docs", or when ce-compound flags an older doc as superseded. Do not trigger for general refactor, debugging, or code-review work unless the user has explicitly pointed at docs/solutions/.
- ce-debugSystematically find root causes and fix bugs. Use when debugging errors, investigating test failures, reproducing bugs from issue trackers (GitHub, Linear, Jira), or when stuck on a problem after failed fix attempts. Also use when the user says ''debug this'', ''why is this failing'', ''fix this bug'', ''trace this error'', or pastes stack traces, error messages, or issue references.