macos-build-run-debug

Build / Run / Debug

Quick Start

Use this skill to set up one project-local script/build_and_run.sh entrypoint, then use that script as the default build/run path.

Prefer shell-first workflows:

• ./script/build_and_run.sh as the single kill + build + run entrypoint once it exists
• xcodebuild for Xcode workspaces or projects
• swift build plus raw executable launch inside that script for true SwiftPM command-line tools
• swift build plus project-local .app bundle staging and /usr/bin/open -n launch for SwiftPM AppKit/SwiftUI GUI apps
• optional script flags for lldb, log stream, telemetry verification, or post-launch process checks

Do not assume simulators, touch interaction, or mobile-specific tooling.

If an Xcode-aware MCP surface is already available and the user explicitly wants it, use it only where it fits. Keep that usage narrow and honest: prefer it for Xcode-oriented discovery, logging, or debugging support, and do not force simulator-specific workflows onto pure macOS tasks.

Workflow

1. Discover the project shape.

   • Check whether the workspace is already inside a git repo with git rev-parse --is-inside-work-tree.
   • If no git repo is present, run git init at the project/workspace root before building so git-backed features are available. Never run git init inside a nested subdirectory when the current workspace already belongs to a parent repo.
   • Look for .xcworkspace, .xcodeproj, and Package.swift.
   • If more than one candidate exists, explain the default choice and the ambiguity.

2. Resolve the runnable target and process name.

   • For Xcode, list schemes and prefer the app-producing scheme unless the user names another one.
   • For SwiftPM, identify executable products when possible.
   • Split SwiftPM launch handling by product type:
     • use raw executable launch only for true command-line tools,
     • use a generated project-local .app bundle for AppKit/SwiftUI GUI apps.
   • Determine the app/process name to kill before relaunching.