apollo-check
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project…
Open a PR only after a full local build + test pass. When the project's PR CI does not run unit tests, so this skill enforces the gate locally before handing off to /create-pr. Use whenever the user asks to open, create, push, or ship a PR — including phrases like "open a PR",
> /plugin marketplace add carloshpdoc/ios-workflow-claudeHow it fires
How this command gets triggered: by you, by Claude, or both.
/verified-prContext preview
What this command does when you run it.
Open a PR only after a full local build + test pass. When the project's PR CI does not run unit tests, so this skill enforces the gate locally before handing off to /create-pr. Use whenever the user asks to open, create, push, or ship a PR — including phrases like "open a PR",
description: > Open a PR only after a full local build + test pass. When the project's PR CI does not run unit tests, so this skill enforces the gate locally before handing off to /create-pr. Use whenever the user asks to open, create, push, or ship a PR — including phrases like "open a PR", "make a PR", "ship it", "create the pull request", or after a feature/fix is implemented and ready to send out. Prefer this skill over calling /create-pr directly.
> **Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase search for flag/font files), or ask if they cannot be inferred. This plugin ships no per-project config.
Wraps `/create-pr` with a mandatory local build + test gate. PR CI currently runs lint and build only — unit test failures slip into `dev` if we do not catch them locally. This skill closes that gap by refusing to open a PR until both gates pass.
Invoke this skill any time the user is ready to open a PR:
Do **not** invoke this for drafts that explicitly skip CI/tests — defer to `/create-pr` directly if the user passes `--skip-tests` or says "skip tests, just open the PR".
The PR is **only** created when every gate below passes. Stop immediately on the first failure — do not proceed, do not "try anyway", do not open a draft.
Run the build command with a 5-minute timeout:
timeout 300 xcodebuild -workspace <scheme>.xcworkspace -scheme <scheme> -destination 'platform=iOS Simulator,name=iPhone 11,OS=latest' build 2>&1 | grep -E "^/.* error:|BUILD SUCCEEDED|BUILD FAILED" | tail -30
Pass criterion: the output ends with `** BUILD SUCCEEDED **` and no `error:` lines from the project's source paths.
On failure: 1. Surface the exact compiler errors (file paths + messages) from the output. 2. STOP. Do not run Gate 2. Do not create the PR. 3. Tell the user the build failed and wait for them to either fix it or hand it back.
**Simulator issues:** If the build fails due to simulator unavailability or timeout, retry once with a fresh simulator boot:
xcrun simctl shutdown all && xcrun simctl boot "iPhone 11"
Run tests with parallel testing enabled for faster feedback (8-minute timeout):
timeout 480 xcodebuild test -workspace <scheme>.xcworkspace -scheme <scheme> -destination 'platform=iOS Simulator,name=iPhone 11,OS=latest' -parallel-testing-enabled YES -only-testing:<scheme>Tests 2>&1 | grep -E "^/.* error:|Test Case.*passed|Test Case.*failed|Executed|TEST SUCCEEDED|TEST FAILED" | tail -100
Pass criterion: `** TEST SUCCEEDED **` and `Executed N tests, with 0 failures` in the output.
On failure: 1. List the failing test names exactly as they appear (`-[SuiteName testMethodName]`). 2. Report total executed / failed counts. 3. STOP. Do not create the PR. 4. Per the global "Maximum 3 attempts" rule: do not retry the same failure more than twice. After the second retry, hand back to the user.
**Flaky test handling:** Treat **flaky/intermittent failures** as failures. The gate exists precisely because PR CI is not catching these — opening the PR anyway defeats the purpose. If a test fails intermittently: 1. First retry: run the specific failing test class only 2. Second retry: if same test fails, report as genuine failure 3. Do NOT proceed to PR creation
Before delegating to `/create-pr`, confirm:
Once all three gates pass, invoke `/create-pr` and let it do its job unchanged. Do **not** reimplement PR-template, label-selection, base-branch (`--base dev`), or footer logic here — `/create-pr` owns that.
After `/create-pr` returns the PR URL, report:
Keep the summary to those three lines — no extra prose.
| Step | Command | Purpose | |------|---------|---------| | Gate 1 | Build with timeout | Verify compilation (5 min timeout) | | Gate 2 | Test with parallel | Verify all unit tests pass (8 min timeout) | | Gate 3 | Working tree check | Ensure clean state and proper branch | | Create | `/create-pr` | Open PR with team template, label, base `dev`, footer |
When `--quick` is passed, Gate 2 runs only tests related to changed files:
1. Get changed Swift files: `git diff dev --name-only | grep '\.swift$'` 2. E
Reusable Claude Code slash-commands, skills, and workflows extracted from real iOS / backend projects. Packaged as three installable plugins - register the marketplace and /plugin install what you need.
Repo: carloshpdoc/ios-workflow-claude
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project…
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project…
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project…
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project…
**Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project…
Bump the app version or build number across all targets in the current project.