Setup Swift Library

This documentation was generated with the assistance of AI. Please report any inaccuracies.

Generate the standard Swift Package Manager library toolchain at the repository root — Package.swift, the Sources/<Name>/ and Tests/<Name>Tests/ layout, .swiftlint.yml, a formatter config, a DocC catalog page, and, when opted in, .spi.yml and sonar-project.properties.

Purpose

iru-setup-swift-library bootstraps a new Swift/SwiftPM library from an explicit, genericized house template embedded in the skill itself. It announces up front whether it is creating the package from scratch or updating an existing one, and for every file of its own that already exists it warns and asks Update / Keep as is / Replace / Stop (or applies on-existing from args). Every file starts from swift package init --type library’s own scaffold, then this skill rewrites it: `Package.swift gets // swift-tools-version: 6.0, a platforms: array derived from the selected Apple platforms, a swift-docc-plugin dependency, and swiftLanguageModes: [.v6]; Sources/<Name>/ gets a placeholder Sendable type; Tests/<Name>Tests/ gets both a Swift Testing @Test example and an XCTest example; and .swiftlint.yml, a .swift-format/.swiftformat config, and a DocC catalog page round out the toolchain. It is the Swift/Apple equivalent of Setup Java Library, Setup TypeScript Library, and Setup Android Library for this catalog’s other ecosystems.

Purpose group

Swift/Apple Bootstrap

Plugin

Shipped by the iru-swift plugin of the ai-catalog marketplace (install with /plugin install iru-swift@ai-catalog; see Plugins).

Invocation

/iru-setup-swift-library

Inputs

Argument Required Description Default

args

No

Pre-resolved parameters passed by an orchestrating skill (e.g. Setup Swift Repository) as newline-separated key: value lines covering every field below, parsed in Step 0 so this skill doesn’t ask about any field already resolved this way.

None — if absent or unrecognized, every field is asked interactively.

package-name

Yes (unless supplied via args)

The SwiftPM package identity written to Package(name: …​), e.g. my-example-lib; the PascalCase <Name> used for the product/target/type and every Sources//Tests//DocC directory is derived from it automatically.

None

platforms

Yes (unless supplied via args)

One or more of ios, ipados, macos, watchos, tvos, visionos, linux (multi-select). ios/ipados collapse to a single .iOS(…​) entry; linux adds no platforms: entry at all (and omits the whole key if it’s the only platform chosen).

None

min-deployment-targets

Yes (unless supplied via args)

Minimum OS version per selected Apple platform, e.g. ios=17.0, macos=14.0. Not asked for linux (no deployment-target concept in SwiftPM).

None — no sensible universal default

license

Yes (unless supplied via args)

Resolved via AskUserQuestion: Apache License 2.0, MIT License, No license, or Other (asked for a display name and URL directly).

None — user must choose

developer-name / developer-email / organization-url

Yes (unless supplied via args)

Populates the generated doc-comment license headers (Steps 6). SwiftPM has no POM/package.json-style <developers>/author metadata block, so these are used nowhere else.

None

open-source

No

Whether the repository is open source; drives the recommended defaults offered for publish and sonar.

Asked directly (yes/no) when not resolved via args

publish

No

Whether the library is distributed for other projects to depend on via a git URL/tag; gates whether .spi.yml (Swift Package Index config) is written.

yes when open-source is yes; otherwise asked with no recommended

sonar

No

Whether to wire up a SonarQube/SonarCloud scan (cloud/self-hosted/none), plus sonar-organization/sonar-project-key/sonar-host-url when not none; gates sonar-project.properties.

cloud only when open-source is yes and visibility is public (or unknown); otherwise asked with none recommended (SonarCloud needs a paid plan for private projects), offering self-hosted SonarQube second. With ci: no, none is recommended and a chosen scan only gets the build-side sonar-project.properties.

formatter

No

Which formatter config to write: swift-format (the Swift toolchain’s own bundled formatter, verified end-to-end) or swiftformat (the third-party nicklockwood/SwiftFormat tool, unverified locally).

swift-format

visibility

No

public, private or internal (behaves like private). Only used to key the sonar recommendation; this skill never asks it, it only arrives via args.

Unset (treated as unknown)

ci

No

yes/no — whether GitHub Actions workflows will exist to send Sonar reports. With no, the skill says plainly that no workflow will send analysis automatically and recommends sonar: none; if Sonar is still chosen, the Step 14 report notes that no CI step sends reports.

Unset

on-existing

No

ask, keep, update or replace — answers Step 1’s per-file question for every existing file at once (the warning and file list are still printed).

ask

mode

No

new or existing. existing marks an update rather than a from-scratch run but no longer means a silent gap-fill: Step 1 still warns and asks per existing file. The files actually on disk decide whether each is created or updated.

new

Outputs

  • Package.swift, rewritten in full after swift package init --type library --name <Name>.

  • Sources/<Name>/<Name>.swift (a placeholder Sendable struct), Tests/<Name>Tests/<Name>Tests.swift (Swift Testing @Test), and Tests/<Name>Tests/<Name>XCTests.swift (XCTest), sharing one test target.

  • .swiftlint.yml (opt-in strict rules, excluded: .build) and either .swift-format or .swiftformat, depending on formatter.

  • Sources/<Name>/<Name>.docc/<Name>.md, a DocC catalog page.

  • .spi.yml, only when publish: yes.

  • sonar-project.properties, only when sonar is not none.

  • A report of the resolved package-name/<Name>, platforms and deployment targets, license, and every yes/no/gated choice; the mode announced up front (from scratch or update); per file whether it was created, updated, replaced or kept as is (with each mismatch listed for a kept file, and how visibility/ci shaped the Sonar recommendation); whether swift build/swift test succeeded; and explicit warnings (review before build/commit, SONAR_TOKEN and a CI step still needed for sonar-project.properties to mean anything, .spi.yml alone doesn’t submit to the Swift Package Index, no .gitignore touched, SwiftLint/swiftformat/.spi.yml submission unverified locally).

The generated files' bytes come from template files under templates/ (and, where a template needs variant-specific notes, reference/) in .claude/skills/iru-setup-swift-library/; the skill reads only the files for the variant it resolved, not the whole set, which keeps its SKILL.md small.

Execution flow

flowchart TD A[Start /iru-setup-swift-library] --> B{"Step 0: args supplied?"} B -- yes --> C[Parse key: value pairs from args] B -- no --> D[Treat every field as unset] C --> E["Step 1: Survey repository\nfor existing files"] D --> E E --> F{"Any file already exists?"} F -- none exist --> F1["Announce: creating the\npackage from scratch"] F -- at least one --> F2["Announce: updating an\nexisting package; list files"] F2 --> G{"on-existing set to\nkeep, update or replace?"} G -- yes --> G1["Apply it to every\nexisting file"] G -- no --> G2{"AskUserQuestion per file:\nUpdate / Keep as is /\nReplace / Stop"} G2 -- Stop --> Z1[Report nothing changed; end] G2 -- other --> G3["Record per-file decision;\nread existing Package.swift\nas defaults if replaced or updated"] F1 --> H G1 --> H G3 --> H["Step 2: Collect inputs\n(package-name, platforms,\nmin-deployment-targets, license,\ndeveloper info, open-source,\npublish, sonar, formatter)"] H --> I["Step 3: Infer repository info\n(owner/repo/host, inception year,\nstable branch)"] I --> J["Step 4: Look up swift-docc-plugin\nversion via GitHub Releases API"] J --> K["Step 5: swift package init\n--type library --name &lt;Name&gt;\n(only if no Package.swift),\nthen write Package.swift"] K --> L["Steps 6-9: Build templates for\nSources/&lt;Name&gt;, Tests/&lt;Name&gt;Tests,\n.swiftlint.yml, formatter config,\nDocC page, .spi.yml,\nsonar-project.properties"] L --> M["Step 12: Write each file per its decision:\ncreate / update (diff first) /\nkeep as is / replace"] M --> N["Step 13: Verify via iru-gate-runner\n(swift build, swift test)"] N --> O["Step 14: Report mode, per-file action,\nverification result, and warnings"]

Dependencies

Invokes

None — iru-setup-swift-library is a leaf skill; it does not call any other skill in this catalog.

Invoked by

  • Setup Swift Repository (Step 5, library flavor) — this catalog’s Swift/Apple bootstrap orchestrator runs iru-setup-swift-library after resolving the shared bootstrap inputs, passing them through args so this skill’s own Step 2 questions are skipped.

Related agents

  • iru-gate-runner — Step 13 runs swift build then swift test through this agent so the caller gets a compact pass/fail summary instead of raw command output.

Source

SKILL.md on GitHub — the file this page was generated from.