xcode-project-analyzer

# Xcode Project Analyzer Use this skill for project- and target-level build inefficiencies that are unlikely to be solved by source edits alone. ## Core Rules - Recommendation-first by default. - Require explicit approval before changing project files, schemes, or build settings. - Prefer measured findings tied to timing summaries, build logs, or project configuration evidence. - Distinguish debug-only pain from release-only pain. ## What To Review - scheme build order and target dependencies - debug vs release build settings against the [build settings best practices](references/build-settings-best-practices.md) - run script phases and dependency-analysis settings - derived-data churn or obviously invalidating custom steps - opportunities for parallelization - explicit module dependency settings and module-map readiness - "Planning Swift module" time in the Build Timing Summary -- if it dominates incremental builds, suspect unexpected input modification or macro-related invalidation - asset catalog compilation time, especially in targets with large or numerous catalogs - `ExtractAppIntentsMetadata` time in the Build Timing Summary -- if this phase consumes significant time, record it as `xcode-behavior` (report the cost and impact, but do not suggest a repo-local optimization unless there is explicit Apple guidance) - zero-change build overhead -- if a no-op rebuild exceeds a few seconds, investigate fixed-cost phases (script execution, codesign, validation, CopySwiftLi...