Menu
Build the project for testing
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
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
Run snapshot 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 | build-for-testing |
| description | Build the project for testing |
Builds the app and all test targets (so they compile cleanly before running
tests). Like /build, this uses warnings-as-errors.
Preferred — Xcode MCP (xcode), when running inside Xcode. Call it directly
(small structured result, no subagent needed):
tabIdentifier from mcp__xcode__XcodeListWindows.mcp__xcode__BuildProject with that tabIdentifier and buildForTesting: true.mcp__xcode__GetBuildLog with the same tabIdentifier and
severity: "error".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 errors/warnings (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
(Agent tool, subagent_type: general-purpose, model: haiku) so the output stays out
of your context. Do not run it yourself. Prompt the subagent to:
Run `mkdir -p .build && make build-for-testing > .build/last-build-for-testing.log 2>&1`,
check the exit status, and report ONLY:
- Status: succeeded or failed
- Error and warning counts
- Each error/warning as `file:line — message` (omit if none; warnings are errors)
- On failure, the log path `.build/last-build-for-testing.log`
Do not paste raw logs or successful-compilation output.
After fixing any issues, re-invoke this skill to re-check.