소스 정보
- 저장소
- jaydubya818/New_baseline
- 최근 소스 활동
- 2026년 3월 27일 04:15
- 감지된 SKILL.md 언어
- 영어
- 스타
- 0
- 포크
- 0
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
메뉴
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/jaydubya818/New_baseline --skill test-xcode명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | test-xcode |
| description | Build and test iOS apps on simulator using XcodeBuildMCP |
| argument-hint | [scheme name or 'current' to use default] |
| disable-model-invocation | true |
Build, install, and test iOS apps on the simulator using XcodeBuildMCP. Captures screenshots, logs, and verifies app behavior.
Check that the XcodeBuildMCP MCP server is connected by calling its list_simulators tool.
MCP tool names vary by platform:
mcp__xcodebuildmcp__list_simulatorsXcodeBuildMCP server's list_simulators methodIf 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.
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.
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.
Call build_ios_sim_app with the project path and scheme name.
On failure:
On success:
install_app_on_simulator with the built app path and simulator UUIDlaunch_app_on_simulator with the bundle ID and simulator UUIDcapture_sim_logs with the simulator UUID and bundle ID to start log captureFor 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:
Check logs for errors:
Call get_sim_logs with the simulator UUID. Look for:
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.
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 question tool — e.g., AskUserQuestion in Claude Code, request_user_input in Codex, ask_user in Gemini — or present numbered options and wait):
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
When a test fails:
Document the failure:
Ask the user how to proceed:
Test Failed: [screen/feature]
Issue: [description]
Logs: [relevant error messages]
How to proceed?
1. Fix now - I'll help debug and fix
2. Create todo - Add a todo for later (using the todo-create skill)
3. Skip - Continue testing other screens
If "Fix now": investigate, propose a fix, rebuild and retest
If "Create todo": load the todo-create skill and create a todo with priority p1 and description xcode-{description}, continue
If "Skip": log as skipped, continue
After all tests complete, present a summary:
## 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
### Created Todos: [count]
- `006-pending-p1-xcode-settings-crash.md`
### Result: [PASS / FAIL / PARTIAL]
After testing:
stop_log_capture with the simulator UUIDshutdown_simulator with the simulator UUID# Test with default scheme
/test-xcode
# Test specific scheme
/test-xcode MyApp-Debug
# Test after making changes
/test-xcode current
When reviewing PRs that touch iOS code, the ce:review workflow can spawn an agent to run this skill, build on the simulator, test key screens, and check for crashes.