Swift format style workflow

Swift Format Style Workflow

Purpose

Keep Swift formatting and style enforcement explicit, consistent, and aligned with the repository.

Use this skill before and after source organization or modernization cleanup. Hand off to apple-dev-skills when the work becomes Xcode build phases, Xcode source editor behavior, project-file mutation, or Apple app validation.

Repository Inspection

Inspect:

• .swiftformat
• .swiftlint.yml
• Package.swift
• .github/workflows/
• Git hooks or hook installers
• Makefile, justfile, scripts, or CI helpers
• README, CONTRIBUTING, AGENTS, or package docs
• Xcode project or XcodeGen files only when the repo uses them

Tool Responsibility

• Treat SwiftFormat as the primary owner of whitespace, wrapping, sorting, and mechanical formatting shape.
• Treat SwiftLint as a complementary signal layer for clarity, maintainability, safety, naming, documentation expectations, and project-specific hazards.
• Do not let both tools fight over the same formatting rule.
• Prefer checked-in project-root config files for shared repositories.
• Prefer repo-pinned or package-managed tooling over untracked developer-local drift when the repo already has that pattern.

Gale Style Defaults

• Keep fluent chains compact when they read clearly.
• Do not explode readable chains into one line per tiny operation unless the chain needs diagnostic boundaries.
• Prefer shorthand closure syntax, key paths, and trailing closures when the meaning remains obvious.
• Prefer dense but readable Swift over ceremony.
• Let source organization and named intermediate values carry meaning instead of padding code with comments.

Workflow

1. Classify the request:
   • formatter setup
   • linter setup
   • style repair
   • CI or hook alignment
   • pre-cleanup baseline
   • post-cleanup normalization
2. Inspect existing config before proposing changes.
3. Choose one enforcement path:
   • local CLI check
   • Git pre-commit hook
   • CI check
   • Xcode build phase handoff
   • SwiftPM plugin handoff
4. Run or recommend the narrowest useful command:
   • swiftformat --lint .
   • swiftformat .
   • swiftlint lint
5. If source files will be split or moved, hand off to swift-source-organization-workflow, then run formatting again.

Output Shape

Return:

1. Style state: config files and enforcement surfaces observed.
2. Tool split: what SwiftFormat owns and what SwiftLint owns.
3. Changes: config, hook, CI, or source edits.
4. Commands: exact commands run or recommended.
5. Validation: pass, fail, or skipped with concrete reason.

Guardrails

• Do not hand-format Swift when SwiftFormat is available and configured.
• Do not add SwiftLint rules as a casual cleanup without checking current repo tolerance.
• Do not introduce formatter churn unrelated to the requested work.
• Do not claim Xcode build-phase or source-editor behavior without using Apple Dev docs and handoffs.
• Do not override existing project style with a generic template.