debug

Diagnose iOS simulator app failures through an evidence-to-root-cause debugging loop.

3|Updated Nov 8, 2014
One-click install
npx skills add https://github.com/mintuz/.dotfiles --skill debug-mintuz
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: debug
Source: https://github.com/mintuz/.dotfiles/tree/main/agents/.agents/skills/debug
Command: npx skills add https://github.com/mintuz/.dotfiles --skill debug-mintuz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When an iOS app fails in the simulator — a build failure, a crash, a wrong screenshot, or wrong behaviour — it is easy to guess at causes, apply random fixes, or wipe user data as a shortcut. This Skill enforces a disciplined evidence-to-root-cause loop that reproduces the failure, proves the runtime identity, traces the true owner of the defect, fixes it once, and proves the terminal state. ## Core Features & Use Cases - Structured five-step loop: Bound and reproduce the failure, prove the runtime identity (scheme, bundle identifier, launched process), trace the owner through state and lifecycle, fix once at the shared cause, and prove the terminal state with fresh evidence. - Authorisation guardrails: Distinguishes diagnosis-only work from authorised fixes, requiring explicit approval before editing code when only a symptom was reported, and stopping before destructive actions like deleting stored data. - Evidence discipline: Captures the right evidence per failure surface (build logs, runtime logs, screenshots), preserves user data, and treats clean builds or reinstalls as controlled experiments rather than proof. - Use Case: Your SwiftUI app crashes on relaunch in the simulator. The Skill reproduces the crash, verifies the installed app matches the source under review, traces the defect to a shared state owner, applies a minimal fix with a regression check, and confirms the crash no longer reproduces across backgrounding and relaunch. ## Quick Start Use the debug skill to find the root cause of my iOS app crashing on launch in the simulator and propose a fix.

Frequently Asked Questions about debug

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug an iOS app crash in the simulator?▼

Reproduce the crash first and capture runtime logs as evidence. Then verify the launched process and bundle identifier match your source, trace the defect through state and lifecycle to its shared owner, and prove the fix by rerunning the exact failing sequence.

How to find the root cause of an iOS build failure?▼

Capture the build log as evidence and reproduce the failure before choosing a cause. Do not launch the app or capture runtime evidence for a failure that occurs before the app builds, and skip the runtime identity step entirely.

When should I not use this debugging loop?▼

Do not use it for Xcode project setup, or for a test that fails while the app itself builds and runs — that scenario belongs to a Swift testing workflow. It targets failures observed in the simulator: build failures, crashes, wrong screenshots, or wrong behaviour.

Can the debugging process delete app data or reset the simulator?▼

No. The loop preserves user data and treats clean builds, reinstalls, or resets as controlled experiments, never as proof or a shortcut. Destructive actions like deleting stored data require stopping and asking for explicit approval first.

Why does my fix not stick after relaunching the iOS app?▼

A fix is only proven when the original failure no longer reproduces across the lifecycle boundary, including backgrounding and relaunch, with persisted state surviving. Unverified live state must be labelled as a gap rather than reported as a pass.