swift-testing-pro — Claude Code skill: Swift Testing reviews
Writes, reviews, and improves Swift Testing code. Use it when reviewing tests, migrating XCTest code, or handling async test behaviour.
npx skills add twostraws/Swift-Testing-Agent-Skill --skill swift-testing-pro -a claude-codeWhat swift-testing-pro does
This skill reviews Swift Testing code for correctness and project conventions, then writes or improves tests when asked. It checks test suite structure, assertions, dependency injection, async cases, confirmations, time limits, actor isolation, and networking mocks. Review findings are grouped by file and include relevant lines, the violated rule, and a before-and-after fix.
It uses references/core-rules.md, references/writing-better-tests.md, references/async-tests.md, references/new-features.md, and references/migrating-from-xctest.md. For a focused task, it loads only the relevant references. It can convert XCTest tests and uses Swift Testing for new unit and integration tests.
The target is Swift 6.2 or later, so an older toolchain is a reason to check the version first. Swift Testing does not support UI tests; those still require XCTest.
What it helps with
- review
#expectand#requireusage - migrate XCTest assertions to Swift Testing
- check async tests for actor isolation issues
- add networking mocks to test code
- fix confirmation and time-limit handling
Example prompts for the agent
- Review the Swift Testing code in `UserTests.swift` and report genuine issues only.
- Migrate the XCTest tests in `UserTests.swift` to Swift Testing.
- Write Swift Testing coverage for async networking code with mocks.
How to install swift-testing-pro
1Skills CLI (Vercel)
npx skills add twostraws/Swift-Testing-Agent-Skill --skill swift-testing-pro -a claude-code2Manually: put the files in place
~/.claude/skills/swift-testing-pro/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/swift-testing-pro/
1Skills CLI (Vercel)
npx skills add twostraws/Swift-Testing-Agent-Skill --skill swift-testing-pro -a codex2Manually: put the files in place
.agents/skills/swift-testing-pro/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add twostraws/Swift-Testing-Agent-Skill --skill swift-testing-pro -a cursor2Manually: put the files in place
.cursor/skills/swift-testing-pro/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install twostraws/Swift-Testing-Agent-Skill swift-testing-pro2Manually: put the files in place
.github/skills/swift-testing-pro/SKILL.md1Skills CLI (Vercel)
npx skills add twostraws/Swift-Testing-Agent-Skill --skill swift-testing-pro -a gemini-cli2Platform CLI
gemini skills install https://github.com/twostraws/Swift-Testing-Agent-Skill --path swift-testing-proManually: put the files in place
.devin/skills/swift-testing-pro/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add twostraws/Swift-Testing-Agent-Skill --skill swift-testing-pro -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Similar
Questions about swift-testing-pro
How do I install swift-testing-pro in Claude Code?
Run npx skills add twostraws/Swift-Testing-Agent-Skill --skill swift-testing-pro -a claude-code, then run npx skills add twostraws/Swift-Testing-Agent-Skill --skill swift-testing-pro -a claude-code again. The skill file is located at ~/.claude/skills/swift-testing-pro/SKILL.md.
What does swift-testing-pro do?
It writes, reviews, and improves Swift Testing code. It can also migrate XCTest tests and report review findings by file and line.
Can swift-testing-pro handle UI tests?
No. Swift Testing does not support UI tests, so those tests must use XCTest.
Source text
SKILL.md · MIT
---
name: swift-testing-pro
description: Writes, reviews, and improves Swift Testing code using modern APIs and best practices. Use when reading, writing, or reviewing projects that use Swift Testing.
license: MIT
metadata:
author: Paul Hudson
version: "1.0"
---
Write and review Swift Testing code for correctness, modern API usage, and adherence to project conventions. Report only genuine problems - do not nitpick or invent issues.
Review process:
1. Ensure tests follow core Swift Testing conventions using `references/core-rules.md`.
1. Validate test structure, assertions, dependency injection, and other best practices using `references/writing-better-tests.md`.
1. Check async tests, confirmations, time limits, actor isolation, and networking mocks using `references/async-tests.md`.
1. Ensure new features like raw identifiers, test scopes, exit tests, and attachments are used correctly using `references/new-features.md`.
1. If migrating from XCTest, follow the conversion guidance in `references/migrating-from-xctest.md`.
If doing partial work, load only the relevant reference files.
## Core Instructions
- Target Swift 6.2 or later, using modern Swift concurrency.
- As a Swift Testing developer, the user wants all new unit and integration tests to be written using Swift Testing, and they may ask for help migrating existing XCTest code to Swift Testing.
- Swift Testing does *not* support UI tests – XCTest must be used there.
- Use a consistent project structure, with folder layout determined by app features.
Swift Testing evolves with each Swift release, so expect three to four releases each year, each introducing new features. This means existing training data you have will naturally be outdated or missing key features.
This skill specifically draws upon the very latest Swift and Swift Testing code, which means it will suggest things you are not aware of. Treat the user’s installed toolchain as authoritative, but there's a fairly high chance Apple's *documentation* about the APIs will be stale, so treat them carefully.
## Output Format
If the user asks for a review, organize findings by file. For each issue:
1. State the file and relevant line(s).
2. Name the rule being violated.
3. Show a brief before/after code fix.
Skip files with no issues. End with a prioritized summary of the most impactful changes to make first.
If the user asks you to write or improve tests, follow the same rules above but make the changes directly instead of returning a findings report.
Example output:
### UserTests.swift
**Line 5: Use struct, not class, for test suites.**
```swift
// Before
class UserTests: XCTestCase {
// After
struct UserTests {
```
**Line 12: Use `#expect` instead of `XCTAssertEqual`.**
```swift
// Before
XCTAssertEqual(user.name, "Taylor")
// After
#expect(user.name == "Taylor")
```
**Line 30: Use `#require` for preconditions, not `#expect`.**
```swift
// Before
#expect(users.isEmpty == false)
let first = users.first!
// After
let first = try #require(users.first)
```
### Summary
1. **Fundamentals (high):** Test suite on line 5 should be a struct, not a class inheriting from `XCTestCase`.
2. **Migration (medium):** `XCTAssertEqual` on line 12 should be migrated to `#expect`.
3. **Assertions (medium):** Force-unwrap on line 30 should use `#require` to unwrap safely and stop the test early on failure.
End of example.
## References
- `references/core-rules.md` - core Swift Testing rules: structs over classes, `init`/`deinit` over setUp/tearDown, parallel execution, parameterized tests, `withKnownIssue`, and tags.
- `references/writing-better-tests.md` - test hygiene, structuring tests, hidden dependencies, `#expect` vs `#require`, `Issue.record()`, `#expect(throws:)`, and verification methods.
- `references/async-tests.md` - serialized tests, `confirmation()`, time limits, actor isolation, testing pre-concurrency code, and mocking networking.
- `references/new-features.md` - raw identifiers, range-based confirmations, test scoping traits, exit tests, attachments, `ConditionTrait.evaluate()`, and the updated `#expect(throws:)` return value.
- `references/migrating-from-xctest.md` - XCTest-to-Swift Testing conversion steps, assertion mappings, and floating-point tolerance via Swift Numerics.
© Paul Hudson · MIT · twostraws/Swift-Testing-Agent-Skill