Update to Build iOS Apps

{
  "name": "ios-memgraph-leaks",
  "description": "Capture and inspect iOS leaks and memgraphs. Use when debugging leaked objects, retain cycles, memory growth, or before/after leak evidence.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 247
    },
    {
      "relative_path": "scripts/capture_sim_memgraph.sh",
      "size_in_bytes": 3118
    },
    {
      "relative_path": "scripts/summarize_memgraph_leaks.py",
      "size_in_bytes": 5769
    }
  ],
  "skill_md_contents": "---\nname: ios-memgraph-leaks\ndescription: Capture and inspect iOS leaks and memgraphs. Use when debugging leaked objects, retain cycles, memory growth, or before/after leak evidence.\n---\n\n# iOS Memgraph Leaks\n\nUse this skill to prove iOS leaks from a live simulator process or an existing `.memgraph`. Pair it with `../ios-debugger-agent/SKILL.md` when the task also needs simulator build, install, launch, UI driving, logs, or screenshots.\n\n## Core Workflow\n\n1. Build, launch, and drive the exact flow that should release objects.\n2. Capture a memgraph from the running simulator process with `scripts/capture_sim_memgraph.sh`.\n3. Summarize leaks with `scripts/summarize_memgraph_leaks.py`.\n4. For each app-owned leaked type, inspect ownership with `leaks --traceTree=<address> <file.memgraph>` and grouped leak evidence.\n5. Make the smallest root-cause patch, then recapture the same flow on the same simulator when possible.\n6. Report proof: before/after leak counts, disappeared root types, remaining leaks, memgraph paths, and test/build results.\n\nDo not claim a leak fix from a smaller memgraph alone. A credible fix explains the ownership path that kept the object alive and shows that the same path or type disappears after the patch.\n\n## Capture\n\nPrefer capturing from the simulator already used for the reproduction. Resolve the simulator UDID and app bundle identifier, then capture the running app:\n\n```bash\nSKILL_DIR=\"<absolute path to this loaded skill folder>\"\nSIM=\"<simulator-udid>\"\nBUNDLE_ID=\"<app.bundle.identifier>\"\nMEMGRAPH_DIR=\"$(mktemp -d \"${TMPDIR:-/tmp}/codex-ios-memgraph.XXXXXX\")\"\n\n\"$SKILL_DIR/scripts/capture_sim_memgraph.sh\" \\\n  --udid \"$SIM\" \\\n  --bundle-id \"$BUNDLE_ID\" \\\n  --out-dir \"$MEMGRAPH_DIR\"\n```\n\nDo not derive `SKILL_DIR` from the target app repo's `pwd`; installed plugins usually live outside the app being debugged. Store captures in a run-specific temp or user-chosen folder, not under `SKILL_DIR`.\n\nIf the process cannot be found, confirm the bundle identifier and use `xcrun simctl spawn \"$SIM\" launchctl list` to inspect running labels.\n\n## Summarize\n\nSummarize an existing memgraph:\n\n```bash\n\"$SKILL_DIR/scripts/summarize_memgraph_leaks.py\" \\\n  /path/to/app.memgraph \\\n  --trace-limit 5 \\\n  --out /path/to/leak-summary.md\n```\n\nUse `--trace-limit` sparingly. Trace trees are useful root-cause evidence, but large memgraphs can produce noisy output. If a trace tree says `Found 0 roots referencing`, treat it as an unreachable/self-retained leak candidate and use the summary's grouped leak tree or `leaks --groupByType <file.memgraph>` to identify the retained fields and payload chain.\n\n## Root Cause Rules\n\n- Identify the first app-owned leaked type in the leak output or trace.\n- Determine the intended lifetime: process, session, account, view, request, or task.\n- Treat lazy or deferred allocation as a scope reduction, not a leak fix, unless the original eager allocation itself violated the intended lifetime.\n- Prove retain-cycle claims with either a `traceTree` ownership path or an isolated reproduction.\n- For unreachable/self-cycle leaks, `traceTree` may have no root path; use `leaks --groupByType` plus source verification to find the self-retaining edge.\n- Do not claim success just because total leak count went down; prove the specific type or path disappeared.\n- Separate real root-cause branches from candidate/noise branches.\n- Prefer deleting the retaining edge over adding broad cleanup code.\n\n## Report\n\nA useful leak report includes:\n\n- the exact flow and simulator/app build\n- the memgraph and summary paths\n- app-owned leaked types and counts\n- at least one ownership path, or grouped leak tree evidence when the object is unreachable from roots\n- the smallest proposed or applied retaining-edge fix\n- before/after evidence when a fix was made\n\nIf the memgraph shows only framework/runtime noise, say that and recommend the next narrower capture rather than inventing an app leak.\n"
}