macOS Runtime Debugger
SkillMonitoring & opsmacOS app runtimes: build, launch, and debug Xcode or SwiftPM GUI/CLI targets with shell-first workflows; diagnose compiler, linker, startup, log, and telemetry failures; exclude iOS Simulator work.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the macOS Runtime Debugger skill
What this skill tells your AI
The instructions your AI receives, as published by xopoko/build-swift-apps in skills/macos-runtime-debugger/SKILL.md and read by ahel’s review.
Before invoking Apple-only binaries, confirm the execution context is macOS. From Windows or Linux, run those steps in a Mac SSH project or through an already configured remote transport; do not retry missing Apple binaries locally.
Reuse the project's existing build/run entrypoint first. For one-shot build,
launch, log, or debug tasks, use the smallest existing command that proves the
requested outcome without adding durable project files. Bootstrap
script/build_and_run.sh through /macos-runtime-debug only when the user asks
for a reusable run loop or no adequate entrypoint exists and repeated use makes
one worthwhile.
Workflow
- Discover project shape and existing entrypoints:
Read repository guidance and inspect existing scripts, schemes, package products, and host actions before introducing another entrypoint.git rev-parse --show-toplevel 2>/dev/null || pwd find . -name '*.xcworkspace' -o -name '*.xcodeproj' -o -name 'Package.swift' - Resolve and prefer the established runnable target/process:
- Xcode: list schemes and prefer the app-producing scheme unless named.
- SwiftPM CLI: run the executable.
- SwiftPM AppKit/SwiftUI GUI: stage a project-local
.appbundle and launch with/usr/bin/open -n; do not run as a raw executable.
- For a one-shot task, run that entrypoint directly and avoid changing project structure merely to make the command repeatable.
- If a durable loop is explicitly requested or clearly useful because no
adequate entrypoint exists, invoke
/macos-runtime-debugand followreferences/run-button-bootstrap.md. Do not duplicate its full snippets. - Add or update
.codex/environments/environment.tomlonly when the user asks for a Codex Run action. Preserve unrelated existing actions. - When the bootstrap script is the selected entrypoint, run the requested mode:
./script/build_and_run.sh ./script/build_and_run.sh --debug ./script/build_and_run.sh --logs ./script/build_and_run.sh --telemetry ./script/build_and_run.sh --verify - Classify failures as compiler, linker, signing, build settings, missing SDK/toolchain, entrypoint/script bug, or runtime launch. Quote the smallest useful error.
Bootstrap Script Requirements
- Apply these requirements only when
/macos-runtime-debugbootstraps or refreshesscript/build_and_run.sh. - Keep the script outside app source in
script/build_and_run.sh. - Xcode projects use
xcodebuild. - SwiftPM command-line tools use
swift buildthen executable launch. - SwiftPM GUI apps create
dist/<AppName>.app, copy the binary toContents/MacOS/, generate minimalInfo.plist(APPL, executable, identifier, name, minimum system version,NSApplication), then launch with/usr/bin/open -n. - For GUI logs/telemetry, launch the bundle first, then stream unified logs.
--verifyshould confirm process existence withpgrep -x <AppName>.
Debugging
- Use
--logs/--telemetryfor config, entitlements, sandbox, and action-event proof. - If a SwiftPM GUI bundle launches but does not foreground, check
NSApp.setActivationPolicy(.regular)andNSApp.activate(ignoringOtherApps: true). - Use
--debugor directlldbfor symbolized crash debugging. - Switch to
macos-telemetry-probewhen verifying specific window/sidebar/menu/menu-bar actions. - Use Xcode-aware MCP only when explicitly requested and it fits macOS discovery/debugging; fall back to shell when it does not.
Guardrails
- Do not initialize source control merely to build, run, or debug an app.
- Do not replace an established project entrypoint with the bootstrap script unless the user explicitly requests that change.
- A bounded one-shot command is appropriate for a one-shot task; create durable automation only when it will be reused or the user requests it.
- Do not write Codex environment config unless the user requests a Run action and the target entrypoint already exists.
- Do not describe mobile/simulator workflows as macOS workflows.
- Do not claim UI state you cannot inspect.
Output
Report detected project type, existing entrypoint selected, command run, build/launch result, any durable artifacts explicitly created, top blocker if failed, and the smallest next action.
Signals
- GitHub stars
- 45
- Forks
- 4
- Last commit
- Aug 2026
Advanced
- Catalog kind
- skill
- Gateway key
macos-runtime-debugger- Source
- github.com/xopoko/build-swift-apps