Swift Testing Code Review

Reviews Swift Testing code for proper use of

Security Scan

This is an instruction-only code-review skill focused on Swift Testing patterns; its requirements and runtime instructions are consistent with that purpose and it does not request credentials or install software.

Purpose & Capability

The skill's name, manifest, and SKILL.md all describe reviewing Swift Testing constructs (#expect/#require, parameterized tests, async testing, organization). It requests no unrelated binaries, env vars, or config paths, so its declared needs are proportionate to a code-review task. (Minor note: the top-line description in metadata is truncated and the skill's source/homepage are unknown.)

Instruction Scope

Runtime instructions are narrowly scoped to inspecting .swift files that contain Swift Testing markers and to citing FILE:LINE evidence; they explicitly require loading a separate review protocol (beagle-ios:review-verification-protocol) before reporting issues. There are no directives to read unrelated system files, export secrets, or call external endpoints. The external protocol dependency is a functional dependency (not a direct security red flag) but you should verify that the referenced protocol skill is trusted.

Install Mechanism

No install spec and no code files — instruction-only — so nothing is written to disk or fetched during install.

Credentials

The skill requests no environment variables, credentials, or config paths. All checks operate on repository files and included reference docs which is proportionate for a code review.

Persistence & Privilege

always is false and the skill does not request persistent system presence or modify other skills' configurations. Autonomous invocation is enabled by default but not combined with other concerning factors.

Assessment

This skill is instruction-only and appears coherent for reviewing Swift Testing code. Before installing/using it: ensure you trust the agent's file access (it will open .swift files in scope), verify the external protocol it references (beagle-ios:review-verification-protocol) is a trusted skill or resource, and note that the metadata lacks a source/homepage — if provenance matters, ask the publisher for more info. It does not request credentials or install anything.

Hard gates

Complete in order before recording Swift Testing review findings. Stack with beagle-ios:review-verification-protocol for universal review rules.

1. Scope: You have an explicit list of .swift paths under review (or a user-named single file). Pass: Paths captured in working notes or one line: No Swift files in scope — then stop with no findings.
2. Swift Testing surface: For each path you treat as Swift Testing code, confirm import Testing or @Test / #expect / #require / @Suite appears in that file (open or search). Pass: At least one match per critiqued file, or you exclude that file from Swift Testing review with a one-line reason (e.g. XCTest-only).
3. Evidence + protocol: Load beagle-ios:review-verification-protocol before asserting any issue. Pass: Each finding meets that skill’s anchor rules; any violated Review Checklist item cites [FILE:LINE] evidence. If you report zero issues, state Protocol applied; no Swift Testing issues (or equivalent) in the review summary.

Quick Reference

Issue Type	Reference
#expect vs #require, expression capture, error testing	references/expect-macro.md
@Test with arguments, traits, zip() pitfalls	references/parameterized.md
confirmation, async sequences, completion handlers	references/async-testing.md
@Suite, tags, parallel execution, .serialized	references/organization.md

Review Checklist

• Expressions embedded directly in #expect (not pre-computed booleans)
• #require used only for preconditions, #expect for assertions
• Error tests check specific types (not generic (any Error).self)
• Parameterized tests with pairs use zip() (not Cartesian product)
• No logic mirroring implementation in parameterized expected values
• Async sequences tested with confirmation(expectedCount:)
• Completion handlers use withCheckedContinuation, not confirmation
• .serialized applied only where necessary (shared resources)
• Sibling serialized suites nested under parent if mutually exclusive
• No assumption of state persistence between @Test functions
• Disabled tests have explanations and bug links

When to Load References

• Reviewing #expect or #require usage -> expect-macro.md
• Reviewing @Test with arguments or traits -> parameterized.md
• Reviewing confirmation or async testing -> async-testing.md
• Reviewing @Suite or test organization -> organization.md

Review Questions

1. Could pre-computed booleans in #expect lose diagnostic context?
2. Is #require stopping tests prematurely instead of revealing all failures?
3. Are multi-argument parameterized tests creating accidental Cartesian products?
4. Could zip() silently drop test cases due to unequal array lengths?
5. Are completion handlers incorrectly tested with confirmation?