swift-pkg-test

SKILL.md

---
name: swift-pkg-test
description: Build and test a Swift Package Manager package on macOS: run `swift build` then `swift test`, parse compiler and test failures, fix the source, and re-run until the build is clean and all tests pass. Use when asked to build/test/fix a Swift package, get a SwiftPM target green, or triage failing `swift test` output.
allowed-tools: [execute_command, read_file, edit_file, write_file, list_files, search_code]
triggers: ["swift build", "swift test", "fix swift package", "get swiftpm green", "spm tests failing"]
version: 1.0.0
author: Codeep
---

Build and test a Swift Package Manager package, then iterate on failures until everything is green. macOS + a Swift toolchain (Xcode or `swift` on PATH) is assumed.

## Steps
1. Confirm you are at a package root: `list_files` for `Package.swift`. If absent, search upward / pick the directory that has it before running anything.
2. Sanity-check the toolchain: `execute_command: swift --version`. If `swift` is missing, the package can't be built — report that and stop.
3. Build first (faster signal than testing): `execute_command: swift build`.
   - Compiler errors look like `Sources/Foo/Bar.swift:42:9: error:` (also `warning:`). Parse the `path:line:col: error:` prefix, then `read_file` at that path around that line.
4. Only when the build is clean, run tests: `execute_command: swift test`.
   - The tail reports `Executed N tests, with M failures (...)`. A run with `M = 0` and a `0` exit code is the success signal.
   - Failures look like `Sources/.../FooTests.swift:88: error: -[FooTests testBar] : XCTAssertEqual failed: ("a") is not equal to ("b")`. Swift Testing prints `✘ Test ... recorded an issue` with a file:line — parse either form.
5. For each failure, decide intent: a real product bug (fix `Sources/`) vs. a stale/incorrect assertion (fix `Tests/`). Prefer fixing source unless the test is clearly wrong. Use `edit_file` for surgical changes.
6. Re-run the failing scope, not everything: `execute_command: swift test --filter <SuiteName>/<testName>` (or `--filter SuiteName`) to tighten the loop.
7. When the filtered scope passes, run the full `swift test` once more for the green confirmation.

## On failure
- Many errors cascade from one root cause (a missing import, a renamed symbol, a type mismatch). Fix the *first* error, rebuild, and let the list shrink rather than chasing every line.
- "no such module 'X'" → check `Package.swift` `dependencies`/target `dependencies`; run `execute_command: swift package resolve`.
- Stale or corrupt build state → `execute_command: swift package clean` then rebuild.
- Flaky or environment-only failures: re-run once; if still red, treat as real.
- After 5 full build→test cycles without progress, stop and report: the failing test names, the parsed `path:line:col: error:` lines, and what you tried.

## Notes
- Use `--filter` aggressively to avoid re-running the whole suite each iteration.
- Add `-v` (`swift build -v` / `swift test -v`) only when an error message is too terse to locate.
- Never edit files under `.build/` — that's generated output.
- Do NOT use `execute_command` for reading/searching; use `read_file` and `search_code`. Reserve `execute_command` for `swift`, `git`, and package managers.
- Done when: `swift build` exits 0 with no `error:` lines AND `swift test` reports `Executed N tests, with 0 failures` and exits 0.