Install any skill in seconds. Free to start, no credit card required.
Get Started Free →dpearson2699/debugging-instruments
Debug iOS apps and profile performance using LLDB, the interactive Memory Graph Debugger, and Instruments.
Passed 20 of 22 test cases with the skill, and 17 of 22 without it.
3 fixed17 passed either way2 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
Where in Xcode's scheme settings is Thread Sanitizer enabled for diagnosing data races during automated test runs?
| Checked | Without skill | With skill |
|---|---|---|
| Directs to Scheme > Run > Diagnostics to enable Thread Sanitizer. | Missed | Passed |
The instructions your model reads when the skill loads.
Keep interactive graph and Instruments triage here. Route detailed .memgraph
command-line ownership/growth analysis and ETTrace work to their focused skills.
Start with a small, repeatable workflow:
(lldb) br set -f ViewModel.swift -l 42 # Stop at file and line
(lldb) v myLocal # Inspect without executing code
(lldb) po myObject # Use debugDescription when needed
(lldb) bt all # Capture every thread's backtrace
(lldb) frame select 3 # Inspect a relevant frame
(lldb) br modify 1 -c "count > 10" # Narrow a noisy breakpoint
(lldb) w set v self.score # Stop on an unexpected write
Use v over po when you only need a local variable value — it does not
execute code and cannot trigger side effects. Expression evaluation can execute
or mutate program state, and hardware watchpoints are scarce, so use both
deliberately.
test cases passed, vs 17 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.