{"owner":"nicklockwood","repo":"SwiftFormat","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md"],"skills":{"CLAUDE.md":"# SwiftFormat\n\nSwiftFormat is a code formatting tool for Swift. It applies a set of rules to Swift source files, transforming them to follow consistent style conventions.\n\n## Project Structure\n\n- `Sources/Rules/` - Individual formatting rules (one file per rule)\n- `Tests/Rules/` - Test cases for rules\n- `Sources/Formatter.swift` - Core formatter class with token manipulation APIs\n- `Sources/ParsingHelpers.swift` - Parsing helpers for Swift grammar (types, declarations, expressions, etc.)\n- `Sources/FormattingHelpers.swift` - Higher-level formatting utilities\n- `Sources/Options.swift` - Options for configuring the behavior of individual rules\n- `Sources/OptionDescriptor.swift` - Command line flag configuration for rule options\n\n## PR Workflows\n\nAll changes and pull requests should target the `develop` branch, not `main`.\n\nWhen opening a PR that fixes a GitHub issue, reference the issue in the PR description with \"Fixes #100\" etc.\n\n## Building and Testing\n\n```sh\n# Build the project\nswift build\n\n# Run all tests (on macOS)\nswift test\n\n# Run all tests (on Linux)\n# --enable-test-discovery is required because LinuxMain.swift (kept for Mint\n# compatibility) has an empty test list that overrides automatic discovery.\nswift test --enable-test-discovery\n\n# Test a specific rule (works on both macOS and Linux)\n./Scripts/test_rule.sh <ruleName>\n\n# Format the codebase (run after making changes)\n# ./Scripts/test_rule.sh runs this automatically\n./format.sh\n```\n\n## Adding New Rules\n\n### Before You Start\n\n**Read the helper files thoroughly.** Before writing any rule, familiarize yourself with the existing helpers:\n\n- `Sources/Formatter.swift` - Token manipulation APIs\n- `Sources/ParsingHelpers.swift` - Parsing helpers for types, declarations, expressions, properties, functions, etc.\n- `Sources/FormattingHelpers.swift` - Higher-level formatting utilities\n- `Sources/Declarations.swift` - Helpers related to individual declarations\n\nYou MUST review the APIs available in these files using:\n\n```bash\n$ rg \"^    (func|var) \" Sources/Formatter.swift Sources/FormattingHelpers.swift Sources/ParsingHelpers.swift Sources/Declaration.swift\n```\n\nMany rules can be implemented using existing helpers. Before writing custom token parsing code, verify no existing helper does what you need.\n\n### Rule File Structure\n\nCreate a new file in `Sources/Rules/` named after your rule (e.g., `MyRule.swift`). Rules are defined as static properties on `FormatRule`:\n\n```swift\n//\n//  MyRule.swift\n//  SwiftFormat\n//\n\nimport Foundation\n\npublic extension FormatRule {\n    /// Brief description of what the rule does\n    static let myRule = FormatRule(\n        help: \"Description shown in --help output.\"\n    ) { formatter in\n        // Rule implementation goes here. For example:\n        formatter.forEach(.keyword(\"let\")) { i, _ in\n            // Process each occurrence\n        }\n    } examples: {\n        \"\"\"\n        ```diff\n        - before\n        + after\n        ```\n        \"\"\"\n    }\n}\n```\n\nRule tests are implemented in `Tests/Rules/MyRuleTests.swift`.\n\n### Best Practices\n\n- **File author names:** when creating new files, always use the name of the actual user / human author, and the current date. **NEVER** write a file header like \"Created by Claude Code\" or \"Created by GitHub Copilot\". Prefer the user's full name as opposed to just their username.\n- **Minimal changes only.** Only modify tokens when an actual change is needed. Any modification triggers a lint error in `--lint` mode.\n- **Preserve comments.** Prefer preserving code as-is if updating would require removing comments.\n- **Keep it simple.** Write as little code as possible. If a change dramatically increases complexity, consider asking if it should be de-scoped.\n- **Define local helpers** in extensions on `Formatter` at the bottom of the rule file. Mark them `internal` for discoverability. Move helpers used by multiple rules to `ParsingHelpers.swift`. Parsing code should almost always be factored out into a rule-specific helper (or later a shared helper if necessary) rather than being implemented directly in the rule implementation closure.\n\n**Always use Formatter APIs.** Never manipulate token arrays directly:\n\n```swift\n// ✓ Good - use Formatter APIs\nformatter.insert(.space(\" \"), at: index)\nformatter.removeToken(at: index)\nformatter.replaceToken(at: index, with: .keyword(\"let\"))\n\n// ✗ Bad - array manipulation\nvar tokens = Array(formatter.tokens[start...end])\ntokens.append(.space(\" \"))\nformatter.replaceTokens(in: start...end, with: tokens)\n```\n\n**Never use raw index loops.** Always traverse tokens using helpers:\n\n```swift\n// ✓ Good - use traversal helpers\nformatter.index(of: .nonSpaceOrCommentOrLinebreak, after: i)\nformatter.index(of: .keyword(\"func\"), before: i)\nformatter.endOfLine(at: i)\n\n// ✗ Bad - raw index manipulation\nwhile i < formatter.tokens.count { i += 1 }\nfor i in 0..<formatter.tokens.count { ... }\n```\n\n`formatter.forEach` iteration and `formatter.parseDeclarations()` indices are automatically updated as `formatter.tokens` is modified. It is NOT necessary to pre-compute a list of `formatter.tokens` mutaions to then apply later. ALWAYS just modify the `formatter.tokens` directly, through the available methods on `formatter`. In cases where you do have stored token index values that would be invalidated by changes earlier in the `formatter.tokens` array, the most common strategy is to work from bottom-to-top in the function or file.\n\n### Writing Tests\n\nUse the `testFormatting` helper defined in `XCTestCase` extensions:\n\n```swift\nfunc testMyRule() {\n    let input = \"\"\"\n        // input code\n        \"\"\"\n    let output = \"\"\"\n        // expected output\n        \"\"\"\n    testFormatting(for: input, output, rule: .myRule)\n}\n```\n\n- Create several test scenarios covering different cases, but don't exhaustively test every configuration.\n- Use `testFormatting(for: input, [output], rules: [.myRule, .otherRule])` to test multiple rules together.\n- Prefer formatting `input` and `output` code to match the behavior of other rules, instead of excluding other rules with `exclude:`. Only use `exclude:` if the other rule being applied directly conflicts with what the test case is trying to test.\n- Do not use `// MARK` comments in tests.\n- Always use multi-line string literals (\"\"\") for input and output code.\n\n### Debugging\n\nTo debug a rule, run the existing tests or create new test cases. **NEVER** try to directly run SwiftFormat on a file via the command line.\n\nUse print debugging as necessary to gather more context. Run individual test cases using:\n\n```sh\n# On macOS:\nswift test --filter <TestClassName>.<testMethodName>\n\n# On Linux (--enable-test-discovery required):\nswift test --enable-test-discovery --filter <TestClassName>.<testMethodName>\n```\n\n### After Writing the Rule\n\n1. **Run the rule tests:** `./Scripts/test_rule.sh <ruleName>`\n2. **Run the full test suite:** `swift test` (or `swift test --enable-test-discovery` on Linux)\n3. **[VERY IMPORTANT] Review your code** - ensure it follows all best practices above\n4. **[VERY IMPORTANT] Simplify further** - look for functionality that could be removed to reduce complexity\n\n**Note:** Do not modify `Rules.md` directly. It's auto-generated when running the test suite. `MetadataTests` may fail after adding a new rule; re-run after metadata regenerates.\n\n## See Also\n\n@CONTRIBUTING.md\n"},"files":{"CLAUDE.md":"# SwiftFormat\n\nSwiftFormat is a code formatting tool for Swift. It applies a set of rules to Swift source files, transforming them to follow consistent style conventions.\n\n## Project Structure\n\n- `Sources/Rules/` - Individual formatting rules (one file per rule)\n- `Tests/Rules/` - Test cases for rules\n- `Sources/Formatter.swift` - Core formatter class with token manipulation APIs\n- `Sources/ParsingHelpers.swift` - Parsing helpers for Swift grammar (types, declarations, expressions, etc.)\n- `Sources/FormattingHelpers.swift` - Higher-level formatting utilities\n- `Sources/Options.swift` - Options for configuring the behavior of individual rules\n- `Sources/OptionDescriptor.swift` - Command line flag configuration for rule options\n\n## PR Workflows\n\nAll changes and pull requests should target the `develop` branch, not `main`.\n\nWhen opening a PR that fixes a GitHub issue, reference the issue in the PR description with \"Fixes #100\" etc.\n\n## Building and Testing\n\n```sh\n# Build the project\nswift build\n\n# Run all tests (on macOS)\nswift test\n\n# Run all tests (on Linux)\n# --enable-test-discovery is required because LinuxMain.swift (kept for Mint\n# compatibility) has an empty test list that overrides automatic discovery.\nswift test --enable-test-discovery\n\n# Test a specific rule (works on both macOS and Linux)\n./Scripts/test_rule.sh <ruleName>\n\n# Format the codebase (run after making changes)\n# ./Scripts/test_rule.sh runs this automatically\n./format.sh\n```\n\n## Adding New Rules\n\n### Before You Start\n\n**Read the helper files thoroughly.** Before writing any rule, familiarize yourself with the existing helpers:\n\n- `Sources/Formatter.swift` - Token manipulation APIs\n- `Sources/ParsingHelpers.swift` - Parsing helpers for types, declarations, expressions, properties, functions, etc.\n- `Sources/FormattingHelpers.swift` - Higher-level formatting utilities\n- `Sources/Declarations.swift` - Helpers related to individual declarations\n\nYou MUST review the APIs available in these files using:\n\n```bash\n$ rg \"^    (func|var) \" Sources/Formatter.swift Sources/FormattingHelpers.swift Sources/ParsingHelpers.swift Sources/Declaration.swift\n```\n\nMany rules can be implemented using existing helpers. Before writing custom token parsing code, verify no existing helper does what you need.\n\n### Rule File Structure\n\nCreate a new file in `Sources/Rules/` named after your rule (e.g., `MyRule.swift`). Rules are defined as static properties on `FormatRule`:\n\n```swift\n//\n//  MyRule.swift\n//  SwiftFormat\n//\n\nimport Foundation\n\npublic extension FormatRule {\n    /// Brief description of what the rule does\n    static let myRule = FormatRule(\n        help: \"Description shown in --help output.\"\n    ) { formatter in\n        // Rule implementation goes here. For example:\n        formatter.forEach(.keyword(\"let\")) { i, _ in\n            // Process each occurrence\n        }\n    } examples: {\n        \"\"\"\n        ```diff\n        - before\n        + after\n        ```\n        \"\"\"\n    }\n}\n```\n\nRule tests are implemented in `Tests/Rules/MyRuleTests.swift`.\n\n### Best Practices\n\n- **File author names:** when creating new files, always use the name of the actual user / human author, and the current date. **NEVER** write a file header like \"Created by Claude Code\" or \"Created by GitHub Copilot\". Prefer the user's full name as opposed to just their username.\n- **Minimal changes only.** Only modify tokens when an actual change is needed. Any modification triggers a lint error in `--lint` mode.\n- **Preserve comments.** Prefer preserving code as-is if updating would require removing comments.\n- **Keep it simple.** Write as little code as possible. If a change dramatically increases complexity, consider asking if it should be de-scoped.\n- **Define local helpers** in extensions on `Formatter` at the bottom of the rule file. Mark them `internal` for discoverability. Move helpers used by multiple rules to `ParsingHelpers.swift`. Parsing code should almost always be factored out into a rule-specific helper (or later a shared helper if necessary) rather than being implemented directly in the rule implementation closure.\n\n**Always use Formatter APIs.** Never manipulate token arrays directly:\n\n```swift\n// ✓ Good - use Formatter APIs\nformatter.insert(.space(\" \"), at: index)\nformatter.removeToken(at: index)\nformatter.replaceToken(at: index, with: .keyword(\"let\"))\n\n// ✗ Bad - array manipulation\nvar tokens = Array(formatter.tokens[start...end])\ntokens.append(.space(\" \"))\nformatter.replaceTokens(in: start...end, with: tokens)\n```\n\n**Never use raw index loops.** Always traverse tokens using helpers:\n\n```swift\n// ✓ Good - use traversal helpers\nformatter.index(of: .nonSpaceOrCommentOrLinebreak, after: i)\nformatter.index(of: .keyword(\"func\"), before: i)\nformatter.endOfLine(at: i)\n\n// ✗ Bad - raw index manipulation\nwhile i < formatter.tokens.count { i += 1 }\nfor i in 0..<formatter.tokens.count { ... }\n```\n\n`formatter.forEach` iteration and `formatter.parseDeclarations()` indices are automatically updated as `formatter.tokens` is modified. It is NOT necessary to pre-compute a list of `formatter.tokens` mutaions to then apply later. ALWAYS just modify the `formatter.tokens` directly, through the available methods on `formatter`. In cases where you do have stored token index values that would be invalidated by changes earlier in the `formatter.tokens` array, the most common strategy is to work from bottom-to-top in the function or file.\n\n### Writing Tests\n\nUse the `testFormatting` helper defined in `XCTestCase` extensions:\n\n```swift\nfunc testMyRule() {\n    let input = \"\"\"\n        // input code\n        \"\"\"\n    let output = \"\"\"\n        // expected output\n        \"\"\"\n    testFormatting(for: input, output, rule: .myRule)\n}\n```\n\n- Create several test scenarios covering different cases, but don't exhaustively test every configuration.\n- Use `testFormatting(for: input, [output], rules: [.myRule, .otherRule])` to test multiple rules together.\n- Prefer formatting `input` and `output` code to match the behavior of other rules, instead of excluding other rules with `exclude:`. Only use `exclude:` if the other rule being applied directly conflicts with what the test case is trying to test.\n- Do not use `// MARK` comments in tests.\n- Always use multi-line string literals (\"\"\") for input and output code.\n\n### Debugging\n\nTo debug a rule, run the existing tests or create new test cases. **NEVER** try to directly run SwiftFormat on a file via the command line.\n\nUse print debugging as necessary to gather more context. Run individual test cases using:\n\n```sh\n# On macOS:\nswift test --filter <TestClassName>.<testMethodName>\n\n# On Linux (--enable-test-discovery required):\nswift test --enable-test-discovery --filter <TestClassName>.<testMethodName>\n```\n\n### After Writing the Rule\n\n1. **Run the rule tests:** `./Scripts/test_rule.sh <ruleName>`\n2. **Run the full test suite:** `swift test` (or `swift test --enable-test-discovery` on Linux)\n3. **[VERY IMPORTANT] Review your code** - ensure it follows all best practices above\n4. **[VERY IMPORTANT] Simplify further** - look for functionality that could be removed to reduce complexity\n\n**Note:** Do not modify `Rules.md` directly. It's auto-generated when running the test suite. `MetadataTests` may fail after adding a new rule; re-run after metadata regenerates.\n\n## See Also\n\n@CONTRIBUTING.md\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# SwiftFormat\n\nSwiftFormat is a code formatting tool for Swift. It applies a set of rules to Swift source files, transforming them to follow consistent style conventions.\n\n## Project Structure\n\n- `Sources/Rules/` - Individual formatting rules (one file per rule)\n- `Tests/Rules/` - Test cases for rules\n- `Sources/Formatter.swift` - Core formatter class with token manipulation APIs\n- `Sources/ParsingHelpers.swift` - Parsing helpers for Swift grammar (types, declarations, expressions, etc.)\n- `Sources/FormattingHelpers.swift` - Higher-level formatting utilities\n- `Sources/Options.swift` - Options for configuring the behavior of individual rules\n- `Sources/OptionDescriptor.swift` - Command line flag configuration for rule options\n\n## PR Workflows\n\nAll changes and pull requests should target the `develop` branch, not `main`.\n\nWhen opening a PR that fixes a GitHub issue, reference the issue in the PR description with \"Fixes #100\" etc.\n\n## Building and Testing\n\n```sh\n# Build the project\nswift build\n\n# Run all tests (on macOS)\nswift test\n\n# Run all tests (on Linux)\n# --enable-test-discovery is required because LinuxMain.swift (kept for Mint\n# compatibility) has an empty test list that overrides automatic discovery.\nswift test --enable-test-discovery\n\n# Test a specific rule (works on both macOS and Linux)\n./Scripts/test_rule.sh <ruleName>\n\n# Format the codebase (run after making changes)\n# ./Scripts/test_rule.sh runs this automatically\n./format.sh\n```\n\n## Adding New Rules\n\n### Before You Start\n\n**Read the helper files thoroughly.** Before writing any rule, familiarize yourself with the existing helpers:\n\n- `Sources/Formatter.swift` - Token manipulation APIs\n- `Sources/ParsingHelpers.swift` - Parsing helpers for types, declarations, expressions, properties, functions, etc.\n- `Sources/FormattingHelpers.swift` - Higher-level formatting utilities\n- `Sources/Declarations.swift` - Helpers related to individual declarations\n\nYou MUST review the APIs available in these files using:\n\n```bash\n$ rg \"^    (func|var) \" Sources/Formatter.swift Sources/FormattingHelpers.swift Sources/ParsingHelpers.swift Sources/Declaration.swift\n```\n\nMany rules can be implemented using existing helpers. Before writing custom token parsing code, verify no existing helper does what you need.\n\n### Rule File Structure\n\nCreate a new file in `Sources/Rules/` named after your rule (e.g., `MyRule.swift`). Rules are defined as static properties on `FormatRule`:\n\n```swift\n//\n//  MyRule.swift\n//  SwiftFormat\n//\n\nimport Foundation\n\npublic extension FormatRule {\n    /// Brief description of what the rule does\n    static let myRule = FormatRule(\n        help: \"Description shown in --help output.\"\n    ) { formatter in\n        // Rule implementation goes here. For example:\n        formatter.forEach(.keyword(\"let\")) { i, _ in\n            // Process each occurrence\n        }\n    } examples: {\n        \"\"\"\n        ```diff\n        - before\n        + after\n        ```\n        \"\"\"\n    }\n}\n```\n\nRule tests are implemented in `Tests/Rules/MyRuleTests.swift`.\n\n### Best Practices\n\n- **File author names:** when creating new files, always use the name of the actual user / human author, and the current date. **NEVER** write a file header like \"Created by Claude Code\" or \"Created by GitHub Copilot\". Prefer the user's full name as opposed to just their username.\n- **Minimal changes only.** Only modify tokens when an actual change is needed. Any modification triggers a lint error in `--lint` mode.\n- **Preserve comments.** Prefer preserving code as-is if updating would require removing comments.\n- **Keep it simple.** Write as little code as possible. If a change dramatically increases complexity, consider asking if it should be de-scoped.\n- **Define local helpers** in extensions on `Formatter` at the bottom of the rule file. Mark them `internal` for discoverability. Move helpers used by multiple rules to `ParsingHelpers.swift`. Parsing code should almost always be factored out into a rule-specific helper (or later a shared helper if necessary) rather than being implemented directly in the rule implementation closure.\n\n**Always use Formatter APIs.** Never manipulate token arrays directly:\n\n```swift\n// ✓ Good - use Formatter APIs\nformatter.insert(.space(\" \"), at: index)\nformatter.removeToken(at: index)\nformatter.replaceToken(at: index, with: .keyword(\"let\"))\n\n// ✗ Bad - array manipulation\nvar tokens = Array(formatter.tokens[start...end])\ntokens.append(.space(\" \"))\nformatter.replaceTokens(in: start...end, with: tokens)\n```\n\n**Never use raw index loops.** Always traverse tokens using helpers:\n\n```swift\n// ✓ Good - use traversal helpers\nformatter.index(of: .nonSpaceOrCommentOrLinebreak, after: i)\nformatter.index(of: .keyword(\"func\"), before: i)\nformatter.endOfLine(at: i)\n\n// ✗ Bad - raw index manipulation\nwhile i < formatter.tokens.count { i += 1 }\nfor i in 0..<formatter.tokens.count { ... }\n```\n\n`formatter.forEach` iteration and `formatter.parseDeclarations()` indices are automatically updated as `formatter.tokens` is modified. It is NOT necessary to pre-compute a list of `formatter.tokens` mutaions to then apply later. ALWAYS just modify the `formatter.tokens` directly, through the available methods on `formatter`. In cases where you do have stored token index values that would be invalidated by changes earlier in the `formatter.tokens` array, the most common strategy is to work from bottom-to-top in the function or file.\n\n### Writing Tests\n\nUse the `testFormatting` helper defined in `XCTestCase` extensions:\n\n```swift\nfunc testMyRule() {\n    let input = \"\"\"\n        // input code\n        \"\"\"\n    let output = \"\"\"\n        // expected output\n        \"\"\"\n    testFormatting(for: input, output, rule: .myRule)\n}\n```\n\n- Create several test scenarios covering different cases, but don't exhaustively test every configuration.\n- Use `testFormatting(for: input, [output], rules: [.myRule, .otherRule])` to test multiple rules together.\n- Prefer formatting `input` and `output` code to match the behavior of other rules, instead of excluding other rules with `exclude:`. Only use `exclude:` if the other rule being applied directly conflicts with what the test case is trying to test.\n- Do not use `// MARK` comments in tests.\n- Always use multi-line string literals (\"\"\") for input and output code.\n\n### Debugging\n\nTo debug a rule, run the existing tests or create new test cases. **NEVER** try to directly run SwiftFormat on a file via the command line.\n\nUse print debugging as necessary to gather more context. Run individual test cases using:\n\n```sh\n# On macOS:\nswift test --filter <TestClassName>.<testMethodName>\n\n# On Linux (--enable-test-discovery required):\nswift test --enable-test-discovery --filter <TestClassName>.<testMethodName>\n```\n\n### After Writing the Rule\n\n1. **Run the rule tests:** `./Scripts/test_rule.sh <ruleName>`\n2. **Run the full test suite:** `swift test` (or `swift test --enable-test-discovery` on Linux)\n3. **[VERY IMPORTANT] Review your code** - ensure it follows all best practices above\n4. **[VERY IMPORTANT] Simplify further** - look for functionality that could be removed to reduce complexity\n\n**Note:** Do not modify `Rules.md` directly. It's auto-generated when running the test suite. `MetadataTests` may fail after adding a new rule; re-run after metadata regenerates.\n\n## See Also\n\n@CONTRIBUTING.md\n","category":"root","tokens":1841}]}