agentsclimarketplace
Sign in

Avdlee spm build analysis

Skill JordanCoin/ios-skills-collection/skills/avdlee--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 slowness, package resolution time, build plugin overhead, duplicate module builds from configuration drift, circular dependencies between modules, oversized modules needing splitting, or modularization best practices.From its SKILL.md

Install
npx -y skills add JordanCoin/ios-skills-collection --skill avdlee--spm-build-analysis

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

6.0 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

SPM Build Analysis

Use this skill when package structure, plugins, or dependency configuration are likely contributing to slow Xcode builds.

Core Rules

  • Treat package analysis as evidence gathering first, not a mandate to replace dependencies.
  • Separate package-graph issues from project-setting issues.
  • Do not rewrite package manifests or dependency sources without explicit approval.

What To Inspect

  • Package.swift and Package.resolved
  • local packages vs remote packages
  • package plugin and build-tool usage
  • binary target footprint
  • dependency layering, repeated imports, and potential cycles
  • build logs or timing summaries that show package-related work

Verification Before Recommending

Before including any local package in a recommendation, verify that it is actually part of the project's dependency graph. A Vendor/ directory may contain packages that are not linked to any target.

  • Check project.pbxproj for XCLocalSwiftPackageReference entries that reference the package path.
  • Check XCSwiftPackageProductDependency entries to confirm the package's product is linked to at least one target.
  • If a local package exists on disk but is not referenced in the project, do not include it in build-time recommendations.

When recommending version pins for branch-tracked dependencies:

  • Use the helper script to scan all branch-pinned dependencies at once: 
    python3 scripts/check_spm_pins.py --project App.xcodeproj
    This checks git ls-remote --tags for each branch-pinned package and reports which have tags available for pinning.
  • If no tags exist, recommend pinning to a specific commit revision hash for determinism instead.
  • Note which packages are branch-pinned because the upstream simply has no tags, versus packages that have tags but are intentionally tracking a branch.

Focus Areas

  • package graph shape and how much work changes trigger downstream
  • plugin overhead during local development and CI
  • checkout or fetch cost signals that show up in clean environments
  • configuration drift that forces duplicate module builds
  • risks from package targets that use different macros or options while sharing dependencies
  • dependency direction violations (features depending on each other instead of shared lower layers)
  • circular dependencies between modules (extract shared contracts into a protocol module)
  • oversized modules (200+ files) that widen incremental rebuild scope
  • umbrella modules using @_exported import that create hidden dependency chains
  • missing interface/implementation separation that blocks build parallelism
  • test targets depending on the app target instead of the module under test
  • Swift macro rebuild cascading: heavy use of Swift macros (e.g., TCA, swift-syntax-based libraries) can cause a trivial source change to cascade into near-full rebuilds because macro expansion invalidates downstream modules
  • swift-syntax building universally (all architectures) when no prebuilt binary is available, adding significant clean-build overhead
  • multi-platform build multiplication: adding a secondary platform target (e.g., watchOS) can cause shared SPM packages to build multiple times (e.g., iOS arm64, iOS x86_64, watchOS arm64), multiplying SwiftCompile, SwiftEmitModule, and ScanDependencies tasks

Modular SDK Migration Caveat

Migrating a dependency from a monolithic target to a modular multi-target SDK (e.g., replacing one umbrella library with separate Core, RUM, Logs, Trace modules) does not automatically reduce build time. Modular targets increase the number of SwiftCompile, SwiftEmitModule, and ScanDependencies tasks because each target must be compiled, scanned, and emit its module independently. The build-time trade-off depends on the project's parallelism headroom and how many of the modular targets are actually needed.

When considering a modular SDK migration:

  • Compare the total SwiftCompile task count before and after.
  • Benchmark both configurations before recommending the migration for build speed.
  • If the motivation is API surface reduction (importing only what you use), note that build time may stay flat or increase while import hygiene improves.
  • Only recommend modular SDK migration for build speed when the project currently compiles large portions of the monolithic SDK that it does not use, and the modular alternative lets it skip those unused portions entirely.

Explicit Module Dependency Angle

When the same module appears multiple times in timing output, investigate whether different package or target options are forcing extra module variants. Uniform options often matter more than shaving a small amount of source code.

Reporting Format

For each finding, include:

  • evidence
  • affected package or plugin
  • likely clean-build vs incremental-build impact
  • CI impact if relevant
  • estimated impact
  • approval requirement

If the main problem is not package-related, hand off to xcode-project-analyzer or xcode-compilation-analyzer by reading the target skill's SKILL.md and applying its workflow to the same project context.

Additional Resources

What ships with it: 3 files

17.5 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most research analysis skills give in ~1.1k tokens

Counted across 1,063 of the 1,754 authors here whose files we hold, read 2026-08-07

  • Generate a markdown reportin 32 of 1063, across 23 files
  • Cite each claim's sourcein 30 of 1063, across 15 files
  • Define the ideal customer profilein 20 of 1063, across 2 files
  • Search for companies matching the criteriain 20 of 1063, across 2 files
  • Assign a fit score from one to tenin 20 of 1063, across 2 files
  • Analyze the codebase to understand the productin 19 of 1063, across 1 file
  • Ask clarifying questions about the value propositionin 19 of 1063, across 1 file
  • Look for signals of immediate needin 19 of 1063, across 1 file
  • Identify the target decision maker rolein 19 of 1063, across 1 file
  • Suggest a personalized contact strategyin 19 of 1063, across 1 file
  • Provide conversation starters for outreachin 19 of 1063, across 1 file
  • Format results in a scannable markdown templatein 19 of 1063, across 1 file

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,782. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.