PluginBench
Skill
Pass
Audit score 90

xcode-project-analyzer

avdlee/xcode-build-optimization-agent-skill

Audit Xcode project configuration, build settings, and schemes to identify build-time improvements with approval gates.

What is xcode-project-analyzer?

Analyzes Xcode project structure, build settings, target dependencies, and run script phases to find build inefficiencies. Use this when investigating slow incremental builds, reviewing project-level configuration, or optimizing build parallelization without modifying source code.

  • Review scheme build order and target dependencies for serial bottlenecks
  • Audit debug vs release build settings against best practices
  • Analyze run script phases for missing dependency metadata and optimization opportunities
  • Identify zero-change build overhead from fixed-cost phases like codesign and validation
  • Detect asset catalog compilation inefficiencies and parallelization opportunities
  • Diagnose module planning time spikes and unexpected input invalidation using Build Timing Summary

How to install xcode-project-analyzer

npx skills add https://github.com/avdlee/xcode-build-optimization-agent-skill --skill xcode-project-analyzer
Prerequisites
  • Xcode project with .xcodeproj or .xcworkspace file
  • Access to project build settings and scheme configuration
  • Build Timing Summary data (from Xcode build log)
Claude Code
Cursor
Windsurf
Cline

How to use xcode-project-analyzer

  1. 1.Run the analyzer against your Xcode project to generate an audit report
  2. 2.Review the findings, which include evidence, scope, and estimated impact for each issue
  3. 3.Approve or reject recommendations before any project file changes are applied
  4. 4.For package graph or build plugin issues, hand off to spm-build-analysis skill
  5. 5.Implement approved changes and re-run analyzer to measure improvement

Use cases

Good for
  • Investigate why incremental builds remain slow despite no source changes
  • Review build settings configuration across Debug and Release targets
  • Optimize run script phases by adding input/output declarations and .xcfilelist files
  • Identify serial dependencies in schemes that block parallelization
  • Audit target dependencies to remove unnecessary or missing links
Who it's for
  • iOS/macOS developers optimizing build performance
  • Build engineers reviewing project configuration
  • Teams migrating from CocoaPods to SPM
  • Developers investigating slow incremental builds

xcode-project-analyzer FAQ

What's the difference between this skill and source-level optimization?

This skill focuses on project configuration, build settings, schemes, and run scripts—issues unlikely to be solved by editing source code. For package dependencies and build plugins, use spm-build-analysis.

Do I need to approve changes before they're made?

Yes. This skill requires explicit approval before modifying project files, schemes, or build settings.

How does it handle CocoaPods projects?

If CocoaPods is detected, the skill recommends migrating to SPM and does not attempt CocoaPods-specific optimizations.

What build settings does it check?

It compares Debug and Release configurations against best practices for build performance only—not language migration settings like SWIFT_STRICT_CONCURRENCY.

Can it diagnose why tasks re-run in incremental builds?

Yes, using Task Backtraces (Xcode 16.4+) from Scheme Editor > Build > Build Debugging to pinpoint unexpected input changes.

Full instructions (SKILL.md)

Source of truth, from avdlee/xcode-build-optimization-agent-skill.


name: xcode-project-analyzer description: Audit Xcode project configuration, build settings, scheme behavior, and script phases to find build-time improvements with explicit approval gates. Use when a developer wants project-level build analysis, slow incremental builds, guidance on target dependencies, build settings review, run script phase analysis, parallelization improvements, or module-map and DEFINES_MODULE configuration.

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
  • 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, CopySwiftLibs)
  • CocoaPods usage -- if a Podfile or Pods.xcodeproj exists, CocoaPods is deprecated; recommend migrating to SPM and do not attempt CocoaPods-specific optimizations (see project-audit-checks.md)
  • Task Backtraces (Xcode 16.4+: Scheme Editor > Build > Build Debugging) to diagnose why tasks re-run unexpectedly in incremental builds

Build Settings Best Practices Audit

Every project audit should include a build settings checklist comparing the project's Debug and Release configurations against the recommended values in build-settings-best-practices.md. Present results using checkmark/cross indicators ([x]/[ ]). The scope is strictly build performance -- do not flag language-migration settings like SWIFT_STRICT_CONCURRENCY or SWIFT_UPCOMING_FEATURE_*.

Apple-Derived Checks

Review these items in every audit:

  • target dependencies are accurate and not missing or inflated
  • schemes build in Dependency Order
  • run scripts declare inputs and outputs
  • .xcfilelist files are used when scripts have many inputs or outputs
  • DEFINES_MODULE is enabled where custom frameworks or libraries should expose module maps
  • headers are self-contained enough for module-map use
  • explicit module dependency settings are consistent for targets that should share modules

Typical Wins

  • skip debug-time scripts that only matter in release
  • add missing script guards or dependency-analysis metadata
  • remove accidental serial bottlenecks in schemes
  • align build settings that cause unnecessary module variants
  • fix stale project structure that forces broader rebuilds than necessary
  • identify linters or formatters that touch file timestamps without changing content, silently invalidating build inputs and forcing module replanning
  • split large asset catalogs into separate resource bundles across targets to parallelize compilation
  • use Task Backtraces to pinpoint the exact input change that triggers unnecessary incremental work

Reporting Format

For each issue, include:

  • evidence
  • likely scope
  • why it affects clean builds, incremental builds, or both
  • estimated impact
  • approval requirement

If the evidence points to package graph or build plugins, hand off to spm-build-analysis by reading its SKILL.md and applying its workflow to the same project context.

Additional Resources