/xcode-project-analyzer
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
$ npx -y skills add omarshahine/HomeClaw --skill xcode-project-analyzer --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/xcode-project-analyzer
Context preview
The summary Claude sees to decide when to auto-load this skill.
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
SKILL.md
xcode-project-analyzer.SKILL.mdname: 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](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, 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](references/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](references/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`](../spm-build-analysis/SKILL.md) by reading its SKILL.md and applying its workflow to the same project context.
Additional Resources
- For the detailed audit checklist, see [references/project-audit-checks.md](references/project-audit-checks.md)
- For build settings best practices, see [references/build-settings-best-practices.md](references/build-settings-best-practices.md)
- For the shared recommendation structure, see [references/recommendation-format.md](references/recommendation-format.md)
- For Apple-aligned source summaries, see [references/build-optimization-sources.md](references/build-optimization-sources.md)
Read more
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](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, 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](references/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](references/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`](../spm-build-analysis/SKILL.md) by reading its SKILL.md and applying its workflow to the same project context.
Additional Resources
- For the detailed audit checklist, see [references/project-audit-checks.md](references/project-audit-checks.md)
- For build settings best practices, see [references/build-settings-best-practices.md](references/build-settings-best-practices.md)
- For the shared recommendation structure, see [references/recommendation-format.md](references/recommendation-format.md)
- For Apple-aligned source summaries, see [references/build-optimization-sources.md](references/build-optimization-sources.md)
HomeKit smart home control via MCP — lights, locks, thermostats, and scenes for Claude Desktop, Claude Code, and OpenClaw
Repo: omarshahine/HomeClaw
Other skills on homeclaw.
- /ios-app-intents
Design and implement App Intents, app entities, and App Shortcuts for iOS apps so useful actions and content are available to Shortcuts, Siri, Spotlight, widgets, controls, and other intent-driven system surfaces. Use when exposing app actions outside the UI, adding `AppEntity`
Open skill - /ios-debugger-agent
Use XcodeBuildMCP to build, run, launch, and debug the current iOS project on a booted simulator. Trigger when asked to run an iOS app, interact with the simulator UI, inspect on-screen state, capture logs/console output, or diagnose runtime behavior using XcodeBuildMCP tools.
Open skill - /ios-ettrace-performance
Capture and interpret ETTrace profiles for iOS simulator apps, including symbolicated launch and runtime flamegraphs. Use when asked to profile an iOS app flow, gather simulator performance traces, identify CPU-heavy stacks, compare before/after traces, or produce flamegraph
Open skill - /ios-memgraph-leaks
Capture, inspect, compare, and root-cause iOS memory graph leaks using Apple's leaks and memgraph tools. Use when debugging leaked iOS objects, simulator memgraphs, retain-cycle suspicions, memory growth after navigation/logout/account changes, or when asked to prove an iOS leak
Open skill - /spm-build-analysis
Analyze Swift Package Manager dependencies, package plugins, module variants, and CI-oriented build overhead that slow Xcode builds. Use when a developer suspects packages, plugins, or dependency graph shape are hurting clean or incremental build performance, mentions SPM
Open skill - /swiftui-expert-skill
Use when writing, reviewing, or refactoring SwiftUI code for iOS or macOS, including state management, view composition, performance, Liquid Glass adoption, or Instruments `.trace` capture/analysis for hangs, hitches, CPU hotspots, or
Open skill

