Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add vasilyu1983/AI-Agents-public --skill software-ios-runtime-debugginggit clone --depth 1 https://github.com/vasilyu1983/AI-Agents-publicWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/vasilyu1983/ai-agents-public/software-ios-runtime-debugging)<a href="https://agentmods.dev/skills/vasilyu1983/ai-agents-public/software-ios-runtime-debugging"><img src="https://agentmods.dev/badge/skills/vasilyu1983/ai-agents-public/software-ios-runtime-debugging/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/vasilyu1983/ai-agents-public/software-ios-runtime-debugging"><img src="https://agentmods.dev/badge/skills/vasilyu1983/ai-agents-public/software-ios-runtime-debugging.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 7 findings, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Anti-Refusal · line 126 Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.Fix: Remove instructions that suppress warnings, disclaimers, or ethical commentary. Let the agent surface safety-relevant caveats to the user.
- medium Rogue Agent · line 21 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
- medium Rogue Agent · line 49 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
- medium Rogue Agent · line 68 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
- medium Rogue Agent · line 80 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
- medium Rogue Agent · line 151 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
- medium Rogue Agent · line 179 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00046 | $0.06323 |
| Opus 5 | $0.00023 | $0.03161 |
| Sonnet 5 | $0.00009 | $0.01265 |
| Haiku 4.5 | $0.00005 | $0.00632 |
Grade B, and why
software-ios-runtime-debugging scanned grade B with 2 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Strips warnings and disclaimersmediumAnti-refusal
Omitting safety caveats hides risk from the user and is a common jailbreak preamble.
- **Anti-pattern:** any one of these alone. Buildable folders without warnings-as-errors lets the agent ship deprecated code. `xcbeautify` without a `Makefile` keeps the flag-juggling problem. A `Makefile` over a non-bui Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
| `dataCorrupted` + `<!DOCTYPE html>` response | API routing / auth bug | Log URL, curl it; do not conflate with push-open crashes | How it starts
The opening of the file, as written. The whole thing — 256 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Native iOS Runtime Debugging
Use this skill when the core problem is not app architecture or visual design, but runtime truth: did the current binary build, install, launch, and render on the intended simulator or device — and once that's proven, is the live complaint a hang, a crash, jank, a memory kill, or a launch-time regression?
This skill owns stale-build suspicion, simulator drift, malformed .app bundles, missing executables, XcodeGen resource packaging mistakes, and the proof loop required before trusting screenshots, UI behavior, or downstream API/auth debugging. It also owns classifying and diagnosing live runtime performance and stability complaints once that proof exists: hangs and watchdog kills, crash symbolication, jank against frame budgets, Jetsam/memory pressure, and launch-time measurement traps.
Quick Reference
| Symptom | First Move | Notes |
|---|---|---|
| Screenshot does not match source | Uninstall -> install -> launch | Assume stale app first |
| Tool cannot read a simulator screenshot temp path | Re-capture from the current simulator | Temp screenshot files expire or move. Do not treat a missing temp path as invalidating the user's visible report |
| Install says app is missing executable | Inspect built .app bundle |
Verify Info.plist and executable path before touching Swift |
| Simulator behaves inconsistently | Prove destination, boot, install, launch state | Do not debate UI until runtime truth exists |
| XcodeBuildMCP is unavailable | Fall back to xcodebuild, simctl, xcresulttool |
Switch immediately |
| Auth appears to succeed but next screen is unauthenticated | Inspect token persistence and auth propagation after fresh launch | Do not redesign UI first |
| Push works on Xcode build but fails on TestFlight | Inspect archived entitlements and newest backend device row | Wrong APNs environment is more likely than feature-code regression |
APNs returns BadDeviceToken for older installs |
Check device-row environment and staleness first | Often stale tokens or env mismatch, not a current-device blocker |
Push tap opens to black screen, freeze, or _performBlockAfterCATransactionCommitSynchronizes |
Start at references/swift-concurrency-crash-triage.md; web-search the exact symbol before any code review |
Known root cause family: nonisolated async UN delegate + nested MainActor.run, bare Task { } in @MainActor class, actor → @MainActor round-trip, @Sendable async closure, or SCNView updateUIView scene reassign. Separate transport proof from push-open proof: if APNs accepted delivery and the banner appeared, the bug is app-side |
App stuck on a stale binary after ⌘R |
Delete DerivedData + delete app from device + reopen Xcode + reinstall | Xcode incremental build sometimes fails to detect actor isolation changes and reuses cached object files. Verify the fresh binary is on the device with the DEBUG marker print pattern (temporary print("[<class>] build marker — <date>") in a class init). See references/swift-concurrency-crash-triage.md → "iOS app builds fine in terminal but Xcode shows compile errors, or device runs old binary" |
| Cold-start push tap re-crashes on every relaunch | Delete + reinstall to clear pendingRoutePath in UserDefaults |
A prior crashed launch staged a route in UserDefaults that the next cold launch tries to consume and re-crashes on before recovery. Primary bug is higher up (one of the Swift Concurrency patterns); this is the persistent secondary symptom. See references/swift-concurrency-crash-triage.md → "app freezes/black-screens on push tap AND persists across cold relaunches" |
| UITest env var is present but the wrong screen is captured | Verify branch execution and a screen-specific accessibility marker | Process env alone is not runtime proof |
| Route state changes but the destination never appears | Prefer a direct presentation hook for isolated proof | NavigationStack state is not the same as a visible screen |
| "cannot find X in scope" after adding new files | XcodeGen project not regenerated | Regenerate: scripts/generate-xcodeproj.sh or xcodegen generate |
"cannot find X in scope" in a .pbxproj project after adding files |
New file not added to target membership | Add the file to the target before touching Swift feature code |
| CoreSimulatorService "Connection refused" | Simulator service crashed | Use generic/platform=iOS destination instead of simulator; or restart Simulator.app |
| DerivedData write failure / sandbox error | Build sandbox restrictions | Use dangerouslyDisableSandbox: true for xcodebuild, or build from Xcode.app |
| Canvas view renders empty on cold start | animatedProgress starts at 0, .onAppear fires before data loads |
Start progress at 1 or trigger animation on data arrival |
| Swift "failed to produce diagnostic" | Type inference overload in complex ViewBuilder | Simplify: inline optional views, remove AnyView, split large computed properties |
| 401 from a backend route with a valid JWT | Check whether the route or middleware defaults to cookie or session auth | Explicitly enable bearer or JWT auth for that route, and keep privileged server clients behind the server boundary |
| 404 with the correct endpoint name | Inspect base URL and route-prefix composition before changing client code | Double-prefixed path segments such as /api/api/... and environment-specific base URLs are common culprits |
| PATCH or UPDATE returns 200 but no data changes for a first-time record | Check whether the write path assumes the row already exists | Use explicit insert-or-update (upsert) or create-on-miss behavior when the domain allows it |
| "Copy Bundle Resources contains entitlements" warning | Check whether the entitlements file was added as a bundled resource | Keep entitlements in signing configuration only; exclude them from copied app resources |
Background xcodebuild … | tail -N output file stays 0 bytes until exit |
Looks like a stall; not one | tail emits only when its input stream closes. Combined with run_in_background, the output file appears empty for the entire 3–8 minute xcodebuild run, which looks stuck but is actually normal. Alternatives: 2>&1 | tee output.log for live progress, or drop tail entirely and accept the full output. The tail -N recipe trades live visibility for clean final output — pick based on whether you need progress signals during the run |
| Simulator boot + install takes 2–5 min before first test output | First xcodebuild output appears ~90–120s after start | Not a stall. The sequence is: compile → xcodebuild starts → simulator boot → install .app → TEST HOST launch → first Test Case '…' line. During this window the output file may be 0 bytes or contain only build headers. Wait for the background Bash task completion notification rather than polling |
| API returns English on a localized screen even after locale-picker change | Stored profile locale wins over explicit request locale | Request-locale priority should be explicit override (?locale= or equivalent) > Accept-Language header > stored profile. If the priority is inverted, localized clients can get cached content under the wrong locale contract |
EXC_BREAKPOINT in LocalizationStore.resolvedTemplate / LocalizationStore.text |
Inspect generated locale catalogs and their source generator | This is usually a missing-key assertion in the app bundle, not a SwiftUI layout or simulator problem. Patch the durable locale source, regenerate, and run key coverage before continuing UI work |
| Raw test output too long to skim | xcodebuild test emits ~10k-50k lines for a full run |
Pipe through xcbeautify for design-review loops, or use -quiet + trailing | tail -200 for the final summary. For background runs where you want the pass/fail gate only, grep -E "(TEST SUCCEEDED|TEST FAILED|Executed.*tests)" gives a one-line outcome |
| Xcode Cloud build fails with "The file X couldn't be opened" for a committed-looking file | Check git ls-files for the path, not just ls |
Classic "works on my machine" failure mode: a gitignored folder contains some tracked files (added pre-gitignore) and some untracked generated files. Local builds regenerate the missing file; Xcode Cloud clones only what is actually committed. Fix with git add -f <path>; verify no new file added to the folder is ever untracked |
Local Ld failed + "file couldn't be opened" immediately after xcodegen |
Delete ~/Library/Developer/Xcode/DerivedData/<project>-*, not just xcodebuild clean |
XcodeGen reshuffles file-reference UUIDs in project.pbxproj. DerivedData's build manifest is keyed by those UUIDs, so the cached build plan dangles. xcodebuild clean does not purge DerivedData; a project's repo-level scripts/clean-ios.sh typically does both |
Xcode Cloud xcodebuild exits with 65, no clear error in the summary view |
Expand the "Building project …" row; exit 65 is Apple's generic compile/link failure code | Usual culprits (in order of frequency on Xcode Cloud): missing generated file that the pbxproj references (Info.plist, manifest.json, locale JSON), App ID capability missing for an entitlement declared in .entitlements (Push, Sign in with Apple, Associated Domains), no team selected in the Xcode Cloud workflow, provisioning profile lookup failed. The one-line summary is always "non-zero exit code 65" — root cause only appears in the nested log |
| Xcode Cloud ci_post_clone.sh not taking effect | Verify path, permissions, and that the step ran | Must be at ci_scripts/ci_post_clone.sh (exactly — convention-based, no configuration). Must be chmod +x. Must exit 0. Its log appears under the Post-Clone step in the Xcode Cloud build log; if you see "Post-Clone script not found at ci_scripts/ci_post_clone.sh" the hook is not recognised. Same convention for ci_pre_xcodebuild.sh and ci_post_xcodebuild.sh |
| Xcode Cloud build needs a sibling repo that doesn't exist on CI | Don't try to clone it inside ci_post_clone; commit the generated output instead | Xcode Cloud clones only one repo into /Volumes/workspace/repository. Scripts that cd ../<sibling>/<path> will fail because the sibling is absent. Commit the exported artefacts (locale JSONs, manifests, generated bundles) into the building repo, even if the build step is gitignored locally. Prefer git add -f over relaxing the ignore rule so new untracked files don't silently regress |
App terminates with 0x8badf00d / WATCHDOG reason |
Not a code crash — a callback (scene-create, background task) failed to return in time | Read the reason string for which subsystem timed out; treat as a hang that ran out the clock. See references/runtime-performance-triage.md |
| Process still alive but input goes unanswered | Hang, not crash — no crash log will exist | Capture a main-thread backtrace via the Hangs instrument or lldb bt all; do not search for a nonexistent crash report |
| Scrolling or animation stutters but the app stays responsive | Jank — a missed frame budget, not a hang | Profile with Hitches/SwiftUI Profiler, not the Hangs template. 60 Hz = 16.67 ms/frame, ProMotion 120 Hz = 8.33 ms/frame (adaptive, not fixed) |
| App disappears with no crash log after memory growth | Suspect a Jetsam kill | Confirm via MXMemoryExceptionDiagnostic or a jetsam event report; do not assume a normal crash was swallowed. Apple publishes no official per-device memory-limit table — treat any specific MB figure as empirical |
| "Main thread blocked" in a trace, but the code path looks fine | Possible priority inversion, not main-thread overwork | Check the QoS of every thread in the backtrace before moving work off main; a low-priority thread holding a lock the main thread needs looks identical to a slow main-thread task |
| Launch-time regression only shows up in some samples | Prewarming skew | The OS may prewarm the process before the user taps the icon; there is still no supported API to detect or opt out of it. Treat a single launch sample as unverified — use MetricKit's launch-type-bucketed metrics or a large field sample |
| MetricKit payload never arrives during local testing | Expected — MetricKit only reports from App Store/TestFlight builds | It does not fire in Simulator or local Debug builds; ship to TestFlight before relying on it for verification |
What ships with it
10 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
- agents/openai.yaml 603 B
- assets/template-ios-runtime-debug-request.md 593 B
- data/sources.json 6.8 KB
- learnings.consolidated.md 606 B
- learnings.md 1.5 KB
- references/runtime-performance-triage.md 20 KB
- references/runtime-proof-loop.md 645 B
- references/stale-build-triage.md 4.4 KB
- references/swift-concurrency-crash-triage.md 23 KB
- references/xcodegen-resource-packaging.md 737 B
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 256 lines · 46 tokens per session scan B 2899f27d6ab5
software-ios-runtime-debugging is a skill published in the GitHub repository vasilyu1983/AI-Agents-public (87 stars, last pushed 10d ago), licensed MIT. It adds 46 tokens to every session and 6,323 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it B with 2 findings (strips warnings and disclaimers, makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
debugging-strategies
Master systematic debugging techniques, profiling tools, and root cause analysis to efficiently track down bugs across any codebase or technology stack. Use when investigating bugs, performance issues, or unexpected behavior.
git-advanced-workflows
Master advanced Git workflows including rebasing, cherry-picking, bisect, worktrees, and reflog to maintain clean history and recover from any situation. Use when managing complex Git histories, collaborating on feature branches, or troubleshooting repository issues.
parallel-debugging
Debug complex issues using competing hypotheses with parallel investigation, evidence collection, and root cause arbitration. Use this skill when debugging bugs with multiple potential causes, performing root cause analysis, or organizing parallel investigation workflows.
error-handling-patterns
Master error handling patterns across languages including exceptions, Result types, error propagation, and graceful degradation to build resilient applications. Use when implementing error handling, designing APIs, or improving application reliability.
ios-simulator
Verify and debug native, React Native, Expo, or Flutter apps on an iOS Simulator with agent-device. Use when an agent needs to launch an app, inspect its live UI, tap, type, scroll, validate a code change, collect failure evidence, or reproduce a workflow on an iPhone or iPad Simulator.
Debroid CLI Debugger
Orchestrate headless Android debugging via JDWP. ACTIVATE this skill whenever asked to debug an Android application, set line or exception breakpoints, inspect runtime variables or Jetpack Compose state, step through execution, evaluate live expressions, watch fields, or diagnose runtime crashes.