Swift syntax tooling workflow
Skill gaelic-ghost/socket/skills/swift-syntax-tooling-workflow
Parse, inspect, generate, or transform source with SwiftParser and SwiftSyntax while preserving fidelity. Use for Swift codemods, structural linting, generators, syntax-aware edits, or macro trees without inferred types.From its SKILL.md
npx -y skills add gaelic-ghost/socket --skill swift-syntax-tooling-workflowAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.5 KB, 614 tokens by cl100k_base, as published. Nobody here has run it
Swift Syntax Tooling Workflow
Build source-accurate Swift tooling without confusing a syntax tree with the compiler's type-checked AST.
Workflow
- Inspect repository guidance, manifest dependencies, Swift language mode, formatting policy, and existing SwiftSyntax version.
- Resolve whether Swiftly or Xcode owns the compiler used to build the tooling. Record both resolvers on macOS when they are available.
- Classify the task:
- parse or inspect
- visit and collect
- rewrite or migrate
- generate declarations or files
- emit syntax diagnostics
- implement macro expansion syntax
- Select only the needed products. Use references/swift-syntax-components.md for product responsibilities and version alignment.
- Preserve source fidelity:
- operate on syntax nodes instead of text ranges when structure matters
- retain trivia and untouched subtrees
- make malformed-source recovery explicit
- account for
#ifregions and generated source
- Design transformations as pure input-tree to output-tree operations where practical. Isolate filesystem writes, formatting, and reporting at the edge.
- Test with fixtures covering matching input, non-matching input, malformed syntax, trivia, idempotence, and the active Swift version.
- Run the repository's serialized SwiftPM or Xcode validation through its owning workflow.
Toolchain Contract
- Align the SwiftSyntax release with the Swift language and tooling release selected by the repository.
- Prefer the repository's SwiftPM dependency for a distributable tool; do not link against machine-local Xcode libraries in shared package manifests.
- Use Swiftly for explicit Swift.org toolchain matrices and cross-platform package validation.
- Use Xcode through
xcrunwhen the tool must match an Apple SDK, selected Xcode compiler, or Xcode macro behavior. - Report a mismatch instead of silently rebuilding against whichever
swiftappears first onPATH.
Boundaries
- Use
swift-semantic-indexing-workflowwhen the task needs inferred types, USRs, overload resolution, documentation from compiled modules, or project-wide references. - Use
swift-compiler-inspection-workflowwhen the task needs the compiler AST, SIL, IR, module interfaces, or driver jobs. - Hand macro target shape, compiler-plugin dependencies, permissions, generated build products, and Xcode package-plugin execution to the Apple Dev package-extension workflow.
Output
Return the selected toolchain, SwiftSyntax products, transformation contract, preservation rules, changed artifacts, and fixture or build validation.
Guardrails
- Do not present a SwiftSyntax tree as type-checked semantic truth.
- Do not replace structured rewriting with regular expressions for grammar-sensitive changes.
- Do not discard comments, whitespace, source locations, or inactive conditional regions accidentally.
- Do not pin a SwiftSyntax release without checking compatibility with the selected Swift toolchain.
- Do not introduce a macro when an ordinary library or build-time tool is simpler.
What ships with it: 2 files
2.0 KB alongside SKILL.md
agents/
- openai.yaml252 B
references/
Gives 0 of the 12 instructions most automation workflows skills give in 614 tokens
Counted across 813 of the 1,214 authors here whose files we hold, read 2026-09-06
- Use conventional commit message formatin 38 of 813, across 34 files
- Write tests before implementing codein 26 of 813, across 12 files
- Achieve at least 80 percent test coveragein 24 of 813, across 11 files
- Mock external dependencies for unit testsin 22 of 813, across 10 files
- Read product marketing context before asking questionsin 21 of 813, across 6 files
- Implement rollback plans for every deploymentin 21 of 813, across 9 files
- Follow the arrange-act-assert patternin 20 of 813, across 9 files
- Delete branches after mergingin 20 of 813, across 18 files
- Test all edge cases and error scenariosin 20 of 813, across 8 files
- Use semantic selectors for UI testsin 19 of 813, across 7 files
- Define sequence type and audience contextin 18 of 813, across 5 files
- Monitor feature drift and prediction distribution driftin 18 of 813, across 5 files
Said here and by no other author read
- Inspect repository manifest and Swift language mode
- Classify task as parse, visit, rewrite, or generate
- Operate on syntax nodes instead of text ranges
- Retain trivia and untouched subtrees
- Design transformations as pure input-to-output operations
- Test with fixtures covering malformed syntax and trivia
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.