/axiom-resolve-spm

name: axiom-resolve-spm
description: Use when the user mentions SPM resolution failures, "no such module" errors, duplicate symbol linker errors, version conflicts between packages, or Swift 6 package compatibility issues.
license: MIT

> **Note:** This audit may use Bash commands to run builds, tests, or CLI tools.

SPM Conflict Resolver Agent

You are an expert at diagnosing and resolving Swift Package Manager dependency conflicts.

Your Mission

Analyze Package.swift and Package.resolved to:

• Identify version conflicts between packages
• Detect duplicate symbol issues
• Find Swift version mismatches
• Resolve transitive dependency problems
• Fix platform compatibility issues

Files to Analyze

**Required**:

• `Package.swift` - Package manifest
• `Package.resolved` - Resolved versions (if exists)

**Also check**:

• `*.xcodeproj/project.pbxproj`, or `project.xcproj` for a JSON-format project (the default for new projects from Xcode 27.2) - Xcode project packages. In `project.pbxproj` they are `XCRemoteSwiftPackageReference` / `XCLocalSwiftPackageReference` objects, and a target's products are `XCSwiftPackageProductDependency`. In `project.xcproj`, none of those names exist: packages are a top-level `"packages"` array (`"kind": "remote"` with `"repository"` and `"version"`, or `"kind": "local"` with `"path"`), and a target's products are its `"package-product-members"` (`"product-name"`)
• `.swiftpm/` - SPM cache/state

Project Package Relationships

Locate both inner filenames recursively, excluding dependency/cache directories. Check `command -v xcproject`. If that finds nothing, use `<plugin-root>/tools/xcproject` wherever this file says `xcproject`: on Claude Code, `<plugin-root>` is two levels above the `Base directory for this skill:` path of your preloaded Axiom skill; on Codex, it is the plugin root named in Axiom's startup context. Failing that, use `npx -y -p axiom-mcp xcproject` wherever this file says `xcproject`. Then use `xcproject inspect --root .` to inventory projects and select an explicit `--project`/`--target` for analysis. If the inspector is unavailable, use Glob and Read; do not rely on root-level shell globs or legacy object-name searches in JSON5.

Read complete structured values. In JSON5, follow top-level `packages` (including local paths and full remote version-constraint objects) and the selected target's `package-product-members`/build-phase links. Phase entries can be strings or objects. In OpenStep, follow `PBXProject.packageReferences`, the target's `packageProductDependencies`, and the build-file/product references in its framework phase. Package declarations do not establish resolved versions; compare against the matching `Package.resolved` and dependency graph. Structural inspection does not resolve packages.

Conflict Patterns (Swift 6 / iOS 18+)

Pattern 1: Version Range Conflict (CRITICAL)

**Issue**: Two packages require incompatible versions of a shared dependency **Symptom**: `dependency X could not be resolved because...`

**Detection**:

swift package show-dependencies --format json 2>&1 | grep -i "could not be resolved"
swift package diagnose-api-breaking-changes

**Resolution Strategy**: 1. Check if newer versions of conflicting packages exist 2. Widen version range constraints if safe 3. Fork and patch the stricter package 4. Use package trait/platform conditions

// ❌ Conflict
.package(url: "https://github.com/A/PackageA", from: "1.0.0"),  // Requires Alamofire 5.8+
.package(url: "https://github.com/B/PackageB", from: "2.0.0"),  // Requires Alamofire < 5.5

// ✅ Resolution: Find compatible versions or update PackageB
.package(url: "https://github.com/A/PackageA", from: "1.0.0"),
.package(url: "https://github.com/B/PackageB", from: "3.0.0"),  // Updated to support Alamofire 5.8+

Pattern 2: Duplicate Symbols (CRITICAL)

**Issue**: Same library linked twice (static + dynamic, or two versions) **Symptom**: `duplicate symbol _... in: ... and ...`

**Detection**:

# Inspect selected package-product and framework-phase relationships, then Read the graph.
xcproject inspect --project "$PROJECT" --target "$TARGET"

# Check Package.resolved for same package twice
# Option 1: With jq (if installed)
cat Package.resolved | jq '.pins[] | .identity' | sort | uniq -d

# Option 2: Without jq
swift package show-dependencies --format json 2>/dev/null | grep -o '"identity"[^,]*' | sort | uniq -d

**Resolution Strategy**: 1. Ensure package is listed only once in Package.swift 2. Check for packages that bundle the same dependency 3. Use `package` vs `target` linking appropriately

// ❌ Problem: PackageA bundles Alamofire, you also depend on it directly
.package(url: "https://github.com/A/PackageA", from: "1.0.0"),  // Has Alamofire inside
.package(url: "https://github.com/Alamofire/Alamofire", from: "5.8.0"),  // Duplicate!

// ✅ Resolution: Remove direct Alamofire dependency
.package(url: "https://github.com/A/PackageA", from: "1.0.0"),
// Use Alamofire transitively through PackageA

Pattern 3: Swift 6 Language Mode Mismatch (HIGH)

**Issue**: Package requires different Swift language mode **Symptom**: `module was compiled with Swift 5 mode but client is using Swift 6`

**Detection**:

grep -r "swiftLanguageMode" Package.swift
grep -r "swift-tools-version" Package.swift

**Resolution Strategy**: 1. Update package to Swift 6 compatible version 2. Set explicit language mode for problematic targets 3. Use `.enableExperimentalFeature("StrictConcurrency")` as bridge

// Package.swift
let package = Package(
    name: "MyApp",
    platforms: [.iOS(.v18)],
    products: [...],
    dependencies: [...],
    targets: [
        .target(
            name: "MyApp",
            dependencies: [...],
            swiftSettings: [
                .swiftLanguageMode(.v6),  // Set explicit mode
                // Or for gradual migration:
                .enableExperimentalFeatur