$npx -y skills add avdlee/xcode-build-optimization-agent-skill --skill xcode-build-orchestratorOrchestrate Xcode build optimization by benchmarking first, running the specialist analysis skills, prioritizing findings, requesting explicit approval, delegating approved fixes to xcode-build-fixer, and re-benchmarking after changes. Use when a developer wants an end-to-end bui
| 1 | # Xcode Build Orchestrator |
| 2 | |
| 3 | Use this skill as the recommend-first entrypoint for end-to-end Xcode build optimization work. |
| 4 | |
| 5 | ## Non-Negotiable Rules |
| 6 | |
| 7 | - Wall-clock build time (how long the developer waits) is the primary success metric. Every recommendation must state its expected impact on the developer's actual wait time. |
| 8 | - Start in recommendation mode. |
| 9 | - Benchmark before making changes. |
| 10 | - Do not modify project files, source files, packages, or scripts without explicit developer approval. |
| 11 | - Preserve the evidence trail for every recommendation. |
| 12 | - Re-benchmark after approved changes and report the wall-clock delta. |
| 13 | |
| 14 | ## Two-Phase Workflow |
| 15 | |
| 16 | The orchestration is designed as two distinct phases separated by developer review. |
| 17 | |
| 18 | ### Phase 1 -- Analyze (recommend-only) |
| 19 | |
| 20 | Run this phase in agent mode because the agent needs to execute builds, run benchmark scripts, write benchmark artifacts, and generate the optimization report. However, treat Phase 1 as **recommend-only**: do not modify any project files, source files, packages, or build settings. The only files the agent creates during this phase are benchmark artifacts and the optimization plan inside `.build-benchmark/`. |
| 21 | |
| 22 | 1. Collect the build target context: workspace or project, scheme, configuration, destination, and current pain point. When both `.xcworkspace` and `.xcodeproj` exist, prefer `.xcodeproj` unless the workspace contains sub-projects required for the build. Workspaces that reference external projects may fail if those projects are not checked out. |
| 23 | 2. Run `xcode-build-benchmark` to establish a baseline if no fresh benchmark exists. The benchmark script auto-detects `COMPILATION_CACHE_ENABLE_CACHING = YES` and includes cached clean builds that measure the realistic developer experience (warm cache). If the build fails to compile, check `git log` for a recent buildable commit. When working in a worktree, cherry-picking a targeted build fix from a feature branch is acceptable to reach a buildable state. If SPM packages reference gitignored directories in their `exclude:` paths (e.g., `__Snapshots__`), create those directories before building -- worktrees do not contain gitignored content and `xcodebuild -resolvePackageDependencies` will crash otherwise. |
| 24 | 3. Verify the benchmark artifact has non-empty `timing_summary_categories`. If empty, the timing summary parser may have failed -- re-parse the raw logs or inspect them manually. If `COMPILATION_CACHE_ENABLE_CACHING` is enabled, also verify the artifact includes `cached_clean` runs. |
| 25 | - **Benchmark confidence check**: For each build type (clean, cached clean, incremental), compare the min and max values. If the spread (max - min) exceeds 20% of the median, flag the benchmark as having high variance and recommend running additional repetitions (5+ runs) before drawing conclusions. High variance makes it difficult to distinguish real improvements from noise. After applying changes, only claim an improvement if the post-change median falls outside the baseline's min-max range. |
| 26 | 4. If incremental builds are the primary pain point and Xcode 16.4+ is available, recommend the developer enable **Task Backtraces** (Scheme Editor > Build tab > Build Debugging > "Task Backtraces"). This reveals why each task re-ran, which is critical for diagnosing unexpected replanning or input invalidation. Include any Task Backtrace evidence in the analysis. |
| 27 | 5. Determine whether compile tasks are likely blocking wall-clock progress or just consuming parallel CPU time. Compare the sum of all timing-summary category seconds against the wall-clock median: if the sum is 2x+ the median, most work is parallelized and compile hotspot fixes are unlikely to reduce wait time. If `SwiftCompile`, `CompileC`, `SwiftEmitModule`, or `Planning Swift module` dominate the timing summary **and** appear likely to be on the critical path, run `diagnose_compilation.py` to capture type-checking hotspots. If they are parallelized, still run diagnostics but label findings as "parallel efficiency improvements" rather than "build time improvements." |
| 28 | 6. Run the specialist analyses that fit the evidence by reading each skill's SKILL.md and applying its workflow: |
| 29 | - [`xcode-compilation-analyzer`](../xcode-compilation-analyzer/SKILL.md) |
| 30 | - [`xcode-project-analyzer`](../xcode-project-analyzer/SKILL.md) |
| 31 | - [`spm-build-analysis`](../spm-build-analysis/SKILL.md) |
| 32 | 7. Merge findings into a single prioritized improvement plan. |
| 33 | 8. Generate the markdown optim |