메뉴
Run snapshot tests
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Build the project for testing
Build the project
Take the current plan all the way to a ready-to-merge pull request — review the plan (scaled to risk), implement it test-first, code-review and fix, security-review, verify the acceptance criteria, open the PR, and watch it green. Use after you have an approved plan (e.g. from plan mode) and want the rest of the feature pipeline run end-to-end. Invoking it is itself plan approval — it then runs autonomously to a single hard stop: ready-to-merge.
Run a specific test target or test class
Run all unit tests
Capture durable, project-specific learnings from the work just done into the knowledge/ base — gotchas, implementation quirks, tooling traps, SwiftData/CloudKit & TMDb-mapping surprises, things looked up or web-searched, and design decisions (as ADRs). Use before opening a PR (it runs automatically in /deliver), or any time you've learned something worth remembering. Records only non-obvious, reusable facts; skips anything already in the repo, CLAUDE.md, or git history.
| name | test-snapshots |
| description | Run snapshot tests |
Runs the PopcornSnapshotTests test plan on the iOS Simulator. Optional argument: a
<TestTarget>/<TestClass> or <TestTarget>/<TestClass>/<testMethod> for a subset.
Preferred — Xcode MCP (xcode), when running inside Xcode. Get the
tabIdentifier from mcp__xcode__XcodeListWindows, then run
mcp__xcode__RunAllTests (or mcp__xcode__RunSomeTests with <specifier> for a
subset) with that tabIdentifier, targeting the PopcornSnapshotTests plan.
Fallback — make, when the MCP isn't available. For a long-running run you'll block on (e.g. a /deliver pre-PR gate step), prefer a backgrounded Bash (run_in_background: true) that redirects to a log and appends ; echo "EXIT=$?", then — on the completion notification — grep the log for the EXIT= marker plus failing/mismatched snapshots (targeted greps keep the verbose log out of context); it self-reports once on exit, whereas a Haiku subagent driving its own poll loop tends to return premature "still waiting" notes. Otherwise, delegate to a Haiku subagent
(subagent_type: general-purpose, model: haiku). Do not run it yourself. Prompt it to:
Run `mkdir -p .build && make test-snapshots [TEST_CLASS=<specifier>] > .build/last-snapshots.log 2>&1`,
check the exit status, and report ONLY:
- Status: passed or failed
- Counts: total / passed / failed
- Each failing test as `SuiteName/testName` with its `file:line` (omit if none)
- On failure, the log path `.build/last-snapshots.log`
Do not paste passing-test output or raw logs.
Snapshot failures usually mean the rendered UI changed — inspect the failure images to decide whether the change is intentional (and re-record if so).