Bootstrap xcode workspace
The Source for macOS Agent Workflows
npx -y skills add gaelic-ghost/socket --skill bootstrap-xcode-workspaceAssembled 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 author says it does
Copied from the file, not written here
Bootstrap a modular Apple .xcworkspace with Apps, Packages, XcodeGen app projects, and optional services. Use for multi-app Apple codebases sharing Core Swift packages; not for one standalone project or package.
SKILL.md
5.8 KB, as published. Nobody here has run it
Bootstrap Xcode Workspace
Purpose
Create the root composition for a modular Apple product without pretending that a workspace, an Xcode project, an app target, and a Swift package are equivalent. The workspace owns related Xcode projects and shared schemes. Each app project owns its targets, build settings, and XcodeGen spec. Each package owns its manifest and target graph.
Use scripts/run_workflow.py to normalize the workspace contract before
creating files. XcodeGen generates each app project; create the .xcworkspace
and add the generated projects through Xcode's documented workspace flow rather
than hand-writing workspace data.
Compatibility
This is portable skill guidance and a local Python runner; it has no Codex-only
plugin hooks, MCP declarations, or custom-agent dependency. The Hermes tap
export decision is therefore no export required: Hermes can consume the
same authored SKILL.md directly, and no translation artifact is needed.
Required Shape
Product/
Product.xcworkspace/
Apps/
ProductiOS/
ProductMac/
Packages/
ProductCore/
Services/ # optional
Apps/contains one or more independently generated Xcode app projects.Packages/contains standalone SwiftPM packages, each withPackage.swift.Services/is optional and contains a server sibling, never an app target or an implicit Apple build dependency.
Workflow
- Collect
name,destination,app_topology, app platforms, and optional service selection. Runscripts/run_workflow.pyfirst. - Apply the Apple docs gate with
explore-apple-swift-docs. Use Xcode MCPDocumentationSearchfirst; use Dash'sXcodeGen : ProjectSpecdocset when XcodeGen detail is needed. - Choose topology:
- Default to
separate-projectsfor independently shipped or materially platform-specific apps. Create one XcodeGen project per app underApps/. - Use
multiplatform-targetonly when iOS, macOS, tvOS, or visionOS share app identity and lifecycle. Keep watchOS in a separate target/project.
- Default to
- Create each Core package under
Packages/withbootstrap-swift-package. Make reusable modules package products; do not use Xcode groups as module boundaries. - Create each app project with
bootstrap-xcode-app-project. For a workspace project, set XcodeGenoptions.schemePathPrefix: "../"; retain the default standalone value for projects that are not opened from a workspace. - In every consuming app's
project.yml, declare the local package in the top-levelpackagesmap and link the required product from the app target'sdependencies. A workspace does not replace that per-project declaration. - In Xcode, create
<Name>.xcworkspaceat the root and add each.xcodeprojat workspace root level. Open the workspace, not an individual project, for product-wide work. - Add an optional service under
Services/only after selecting it:- Hummingbird:
bootstrap-hummingbird-service. - Vapor:
bootstrap-vapor-service. - F#:
choose-fsharp-web-framework, thenbuild-fsharp-projectand the Azure deployment handoff.
- Hummingbird:
- Validate packages and app schemes serially. Use
xcode-build-run-workflowfor workspace/scheme execution andxcode-testing-workflowfor Xcode-native test work.
Dependency And Navigator Rules
- Use a local Swift package for shared Core code. Its
Package.swiftis the source of truth for targets and products. - Use an Xcode cross-project reference only when one
.xcodeprojmust depend on a target from another.xcodeproj; declare it with XcodeGenprojectReferencesand aProjectName/TargetNamedependency. - Use filesystem directories for organization. A group only organizes the Project navigator. A folder reference is for a bundle-preserved resource directory, not ordinary Swift source.
- For Xcode 16 project formats, prefer broad
syncedFolderroots for ordinary app source. UseexplicitFoldersonly when a child must intentionally remain a folder reference. - Keep
project.yml,.xcconfig, entitlements, schemes, and generated project diffs owned by their documented source files. Never hand-edit.pbxproj.
Inputs
name: required product and workspace name.destination: parent directory, default..app_topology:separate-projects(default) ormultiplatform-target.platforms: comma-separated app platforms; defaultios,macos.service:none(default),hummingbird,vapor, orfsharp-azure.dry_run: emit the normalized composition contract without creating files.
Guards And Handoffs
- Stop when the requested root already contains non-ignorable files.
- Stop when
multiplatform-targetincludes watchOS; create a separate watchOS target/project instead. - Do not add packages, services, or projects to the workspace merely for visual symmetry. Add only real dependency or navigation surfaces.
- Do not make a backend part of an Apple app's Xcode target graph.
- Hand off existing workspace guidance to
sync-xcode-workspace-guidance. - Hand off one existing app project to
sync-xcode-project-guidanceand one package tosync-swift-package-guidance.
References
references/workspace-shape.md- Apple: managing multiple projects and dependencies
- Apple: organizing code with local packages
- XcodeGen Project Spec