# Audit Xcode Security Settings > Audit and enable security-oriented Xcode build settings. Progressively enables compiler warnings, static analyzer checkers, and Enhanced Security features. Use when: user wants to secure their Xcode project, audit security settings, enable hardening, review security posture of build configuration, set up security-focused static analysis, enable static analysis, improve warning coverage, harden diagnostics, or catch more bugs at compile time in C/C++/Objective-C/Swift. SKIP: network security (TLS/ATS), code signing, privacy APIs. - Skill: `tartinerlabs/audit-xcode-security-settings` (Agent Skill, multi-file: 17 files) - Install (CLI): `npx skillmds add tartinerlabs/audit-xcode-security-settings` - Raw SKILL.md: https://api.skillmd.com/api/skills/tartinerlabs/audit-xcode-security-settings/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: tartinerlabs (https://skillmd.com/u/tartinerlabs) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/tartinerlabs/audit-xcode-security-settings --- # Audit Xcode Security Settings Assess an Xcode project's security posture and progressively enable security build settings and entitlements — from broadly applicable warnings through Enhanced Security hardening. ## Tool Preferences When XcodeGlob, XcodeGrep, XcodeRead, XcodeLS, and XcodeUpdate tools are available, ALWAYS use them. Do not fall back to Bash filesystem tools (`ls`, `find`, `cat`, `grep`) to learn about the project. They trigger extra permission prompts and bypass project scoping. - **XcodeGlob** for file discovery — `find` is forbidden for files inside the project. - **XcodeGrep** for content search — `grep`/`rg` is forbidden for files inside the project. - **XcodeRead** for file contents — `cat`/`Read` is forbidden for files registered in the project. - **XcodeLS** for directory listing — `ls` is forbidden for any path inside the project. - **XcodeUpdate** for in-place edits of project-registered files — same `filePath` / `oldString` / `newString` (+ optional `replaceAll`) signature as the built-in `Edit` tool, but accepts project-org paths. `Edit` is forbidden for files registered in the project; use it only for on-disk files that aren't project-indexed (e.g. `.entitlements` plists translated to filesystem absolute paths per the failure-modes table below). **Project root and name are already in the system prompt context.** Do NOT run `ls` to "verify" the project layout before starting. The system prompt already tells you the working directory and the project structure. **Empty XcodeGlob results are not a failure.** The `.xcodeproj` and `.xcworkspace` are not indexed as files inside the Xcode project organization — `XcodeGlob "**/*.xcodeproj"` correctly returns 0 matches. Use the project name from system-prompt context instead. Do not fall back to filesystem `ls`/`find`. **Path translation between project-org and filesystem.** XcodeGlob returns project-org-relative paths. To read or edit a file: - Prefer `XcodeRead` / `XcodeUpdate` with the project-org path. - If that path is rejected (some on-disk files like `.entitlements` plists may not be navigable through `XcodeRead`), translate to a filesystem absolute path by prepending the project root from system context. Do NOT use `find` to discover the on-disk path. Fall back to Bash only for operations the Xcode tools cannot do (e.g., `plutil` for plist editing, git operations). ### Common Failure Modes | Symptom | Cause | Correct Response | |---|---|---| | `XcodeGlob "**/*.xcodeproj"` returns 0 matches | The `.xcodeproj` itself isn't a project-indexed file | Use the project name from system context; do not fall back to `find` or `ls` | | `XcodeRead ` fails for a config-type file (`.entitlements`, `.xcsettings`, `.xcconfig`) | Some on-disk artifacts aren't navigable via project paths | Translate to filesystem absolute path using the project root from system context, then use `Read` / `Edit` | ## Workflow ## Phase 1: Briefing Before doing any work, tell the user — in two or three sentences — what this skill is, what it will do, and roughly how much of their time and attention to expect: - **What it is.** An audit of the project's Xcode security build settings and entitlements (compiler warnings, hardened-process capabilities, pointer authentication, universal binaries for libraries, etc.). - **What happens.** I analyze the project, write an editable plan file at the project root for you to review, and apply only the changes you approve. Nothing is modified until you pick Run. - **Time commitment.** A few minutes of my time to analyze (longer on projects with many targets — I'll narrate progress). Then your review time on the plan file, which can be quick or thorough — your call. After Run, applying is fast; two things can pause for your input — the inquiry step (if there are deliberately-disabled settings whose rationale isn't documented), and a final yes/no on whether to keep the plan file in your project as a record. This all usually takes about 15-30 minutes, depending on the number of build targets and how long it takes for you to review and approve the plan. Keep it tight — the user already invoked the skill knowing they wanted an audit. The briefing exists so they have realistic expectations. ## Phase 2: Discovery Read the Environment block in the system prompt. Relevant fields: - `Primary working directory` — the project root (the project name is the basename). - `Is a git repository` — whether the project is git-tracked (used by Phase 4 Step 1). ## Track Progress Every per-target / per-setting action that needs to happen must have its own task for transparency. - Phase 3 creates one task per target (`Audit `); the task closes once Phase 3 has produced both the per-target audit-table rows and (for supported product types) the Enhanced-Security bucket for that target. After all per-target tasks complete, Phase 3 writes `/xcode-security-audit-scratchpad.md` via the `Write` tool (filesystem only — the scratchpad is agent-internal state, not user-facing, so it deliberately is **not** registered in the Xcode project). Phases 4–7 re-read it via `Read`; they never assume the data is in memory. Do not stage this file in git. - Phase 4 (Plan & Approve) is one task that completes when the user picks Run/Cancel. - On Run, Phase 4 step 5 parses the plan, appends a `## Plan Selection` section to the scratchpad, and creates fine-grained tasks: - One `Apply Enhanced Security to ` per target needing changes (only if "Enhanced Security" is checked). - `Apply Basic Clang Safety Warnings` if checked. - `Apply Hardware Memory Tagging` if checked. - `Apply Additional Diagnostic Settings` if checked. - `Emit Bounds Safety Adoption guidance` if checked. - One `Inquire about on ` per Phase-6 candidate (only if "Inquire about disabled settings" is checked). - `Report and update decision document`. - `Remove scratchpad` — always second-to-last; also fires on error paths. - `Prompt to remove plan file` — always last; also fires on error paths. When entering each phase or sub-step: - Print one line: "▶ Phase N: …" (or "▶ Phase N / Step M: …" for sub-steps). - Update the task to `in_progress`. When finishing each phase or sub-step: - Print one line: "✓ Phase N: …" (with a brief outcome if applicable, e.g., "✓ Phase N: No disabled settings found."). - Update the task to `completed`. ### Phase 3: Analyze Project and Settings No user interaction. Gather facts in the background. #### Step 1: Locate the existing decision document `XcodeGlob '**/xcode-security-settings.md'`. If found, `XcodeRead` it and extract languages + prior setting decisions with their statuses and rationale. This informs subsequent phases. #### Step 2: Detect languages One `XcodeGlob` per language. Empty result is not a failure — record the language as absent. - `**/*.c` → C - `**/*.cpp`, `**/*.cxx`, `**/*.cc` → C++ - `**/*.m` → Objective-C - `**/*.mm` → Objective-C++ - `**/*.swift` → Swift #### Step 3: Build the audit table See `references/reading-build-settings.md` for column definitions, the construction recipe, and the canonical predicates ("already hardened", "at default OFF", "deliberately disabled"). At a glance: 1. Enumerate the project's explicit targets. Skip implicit/aggregate targets (no real product type). 2. For each target: `TaskCreate "Audit "`, set in_progress. Call `GetTargetBuildSettings`, run `scripts/filter_build_settings.py` over the resulting JSON, and record `evaluatedValue` and `setAtTargetLevel` (`yes` if `targetValue` is present in the JSON). Leave the task in_progress — Step 4 closes it. 3. One project-wide `XcodeGrep` for the catalog regex over `*.xcconfig` and `**/project.pbxproj`. Record per-macro `numMatchesInXCConfigs`, `numMatchesInPbxproj`, and the file:line citations. 4. The audit table is the joined view: one row per (target, catalog macro). Phases 4, 5, and 6 all consume this table; nothing else is re-fetched. This step scales with target count: each `GetTargetBuildSettings` call takes several seconds, and there is one per target. On projects with roughly ten or more targets it can take a few minutes. #### Step 4: Per-target Enhanced-Security state Route each target into one of three buckets by product type (inferred per the table in `references/reading-build-settings.md`): - **Entitlements-supported** — product type is in the "Supported Product Types" list of `references/enhanced-security.md` (applications, XPC services, system extensions, driver extensions [build settings only], tools). Read the resolved `CODE_SIGN_ENTITLEMENTS` plist and bucket the target as **Up-to-date**, **Partial**, **Off**, or **No-entitlements-file**. - **Library/framework** — product type is in the qualifying set listed in `references/universal-binaries-for-libraries.md` (frameworks, static frameworks, static libraries, dynamic libraries). No entitlements read. Phase 5 will configure a universal-binary `ARCHS` recommendation for these. - **Skipped** — anything else (test bundles, app extensions, etc.). `TaskUpdate "Audit "` to completed once the bucket is recorded (immediately for **Library/framework** and **Skipped** — they need no entitlements read). Phases 4 and 5 consume these buckets — neither re-reads entitlements. On large projects this iterates over many `.entitlements` plists — if Step 3 took noticeable time, this one will too. #### Step 5: Persist the analysis Write `/xcode-security-audit-scratchpad.md` via the **`Write` tool** (not `XcodeWrite` — the scratchpad is agent-internal state and intentionally is not registered in the Xcode project, so it doesn't clutter the user's Project Navigator). Resolve `` from the Environment block's `Primary working directory`. The file has two sections: - `## Audit Table` — the rows from Step 3. - `## Enhanced-Security Buckets` — one line per target with its bucket and a short delta hint (e.g. `Foo: Partial — missing hardened-heap, has deprecated platform-restrictions`). Phase 4 step 5 (on Run) will append a third section `## Plan Selection` via `Edit`. The final `Remove scratchpad` task in Phase 7 removes the scratchpad via `Bash rm`. If the file is missing at re-read time during a later phase, that phase aborts with an error — never re-derive silently. ### Phase 4: Plan & Approve This phase produces a tailored, editable plan file that the user reviews before any changes happen. Once approved, Phases 5–7 run end-to-end with no further prompts. #### Step 1: Check for version control The project is **version-controlled** if either: - The Environment block's `Is a git repository` field is `true`, or - A single filesystem check at the project root finds any of `.git`, `.hg`, `.svn`, `.bzr`, `.fslckout`, `_FOSSIL_`, `CVS`. Otherwise the project is **not version-controlled**. #### Step 2: Skip if everything is already configured Inspect the scratchpad. Early-exit if **all** default-checked plan items are already at their target state: - Every Enhanced-Security bucket is **Up-to-date** or **Skipped**. - Every relevant Basic-Clang-safety setting is `already hardened` on every applicable target. - The `deliberately disabled` predicate yields no rows (after the Phase-6 exclusions below). Optional follow-ups (Additional diagnostic settings, Bounds safety adoption) do **not** block early-exit. Report "Everything in scope is already configured" and exit; do not write a plan file. #### Step 3: Write the plan file Create `xcode-security-audit-plan.md` at the **root of the Xcode project organization** via `XcodeWrite` (path: `xcode-security-audit-plan.md`, no parent group). `XcodeWrite` both writes the file to disk under `/` and registers it in the project so the user can open it directly from Xcode's Project Navigator. Include only items that apply to the project (see omission rules below). Use this template — substitute the placeholders in `<…>`: ````markdown # Xcode Security Audit — Plan **Project:** · targets · languages: **Generated:** > ⚠️ **No version control detected.** This skill modifies build settings and entitlements. > Without Version Control System (e.g., Git), rollback requires manual undo. Consider running `git init` or copying the project before picking **Run**. Edit the items below — set what steps to perform now, or leave them unchecked to defer them. ## Phases - [x] **Enhanced Security** — apply to: . Adds hardened-process entitlements and sets `ENABLE_ENHANCED_SECURITY=YES`. - [x] **Basic Clang safety warnings** — settings, applied to all C/C++/ObjC targets. - [x] **Inquire about disabled settings** — found (e.g., `=NO` on ``). May trigger follow-up questions if no rationale is documented. - [x] **Hardware memory tagging** — applies to . Adds soft-mode MTE entitlement. - [ ] **Additional diagnostic settings** — extra warnings/checkers. Produces more findings to review. See `references/additional-settings.md`. - [ ] **Bounds safety adoption** — pointer to a separate skill. No changes applied here. ## Decision document The skill creates or updates `xcode-security-settings.md` to record every setting decision (kept, deferred, disabled, with rationale). Edit the path to relocate. - Path: `xcode-security-settings.md` ```` Include the ⚠️ blockquote only when the project is **not version-controlled**; omit it otherwise. The decision document should live in the same directory as the rest of the documentation, or at the project level. ##### Item omission rules A plan item is omitted entirely when it doesn't apply: - **Enhanced Security** — omit if every supported-product-type bucket from Phase 3 step 4 is **Up-to-date** or **Skipped**. - **Basic Clang safety warnings** — omit if pure-Swift, or if every relevant setting is `already hardened` on every applicable target. - **Inquire about disabled settings** — omit if the `deliberately disabled` predicate yields no rows (after excluding `ENABLE_POINTER_AUTHENTICATION = NO` on non-arm64e platforms). - **Hardware memory tagging** — omit if no target's `SUPPORTED_PLATFORMS` / `SDKROOT` matches `macosx`, `iphoneos`, `iphonesimulator`, `xros`, or `xrsimulator`. - **Additional diagnostic settings** — never omitted; always offered. - **Bounds safety adoption** — omit if no C or C++ code is present. ##### Default check state Items under **Phases** are default-checked (`[x]`); items (`[ ]`) are default-unchecked. The user can flip either by editing the plan file before picking **Run**. #### Step 4: Ask for approval Tell the user: > "Plan written to `xcode-security-audit-plan.md` and added to the Xcode project — open it to review. Edit it as needed — uncheck or delete items to skip them; edit the decision document path to relocate. When ready, pick Run. Pick Cancel to abort without changes. Nothing is modified until you pick Run." Then ask via `AskUserQuestion` with single-select options: - **Run** — proceed to "Phase 5" - **Cancel** — abort #### Step 5: Handle the response If **Cancel**: run the two final cleanup tasks (see "Phase 7: Report and Decision Document" below — `Remove scratchpad`, then `Prompt to remove plan file`). The keep-or-remove prompt is offered on Cancel too, so the user's choice to abandon the audit doesn't silently differ from a normal completion. Report "Cancelled — no changes applied," and exit the skill. If the plan file is missing at re-read time (the user deleted it from disk before responding), treat it as a Cancel — but skip the `Prompt to remove plan file` task (there's nothing to remove). Still run `Remove scratchpad`. If **Run**: `XcodeRead xcode-security-audit-plan.md`. Parse: - Each `- [x]` or `- [X]` bullet is a checked item; the item name is the bold portion (between `**…**`). - Items written as `- [ ]` and items deleted from the file are skipped — both produce identical skip behavior. - Under the "Decision document" heading, the value after `Path:` is the decision document location. Append a `## Plan Selection` section to the scratchpad via `Edit` capturing the parsed checked items and the decision-document path. Then create the fine-grained tasks listed in **Track Progress**. Phase 5 onward reads the scratchpad via `Read` rather than relying on memory. If the parsed plan has zero checked items, run the two final cleanup tasks immediately and report "Plan was empty — nothing to do." ### Phase 5: Apply Settings Read only from the audit table for build-setting state. **How to apply build settings:** - **Project uses `.xcconfig` files** — edit the xcconfig directly. Supports both project-level and target-level settings. - **Project uses `.pbxproj` only** — use `UpdateTargetBuildSetting` for target-level settings and `UpdateProjectBuildSetting` for project-level settings. - **Mixed** — if a target has an `.xcconfig` file, edit the xcconfig. Otherwise, use the Xcode build setting tools. Never introduce a new configuration method. Prefer project-level when possible (less duplication). For most projects, `ENABLE_ENHANCED_SECURITY` should be set at project level such that any existing and future build targets inherit this setting. This setting should be disabled only after serious consideration and with strong justification. #### Step 1: Enhanced Security The fine-grained `Apply Enhanced Security to ` tasks created in Phase 4 step 5 already enumerate the targets needing changes (the **Partial**, **Off**, and **No-entitlements-file** buckets — **Up-to-date** and **Skipped** are excluded). Walk those tasks. Read `references/enhanced-security.md` for the full key list, defaults, deprecated keys, version migration, and the supported product-type list. For details on individual sub-options, see: - `references/pointer-authentication.md` — arm64e pointer signing - `references/typed-allocators.md` — type-aware memory allocation - `references/stack-zero-init.md` — automatic stack variable zeroing - `references/readonly-platform-memory.md` — dyld state protection - `references/runtime-restrictions.md` — dylib and Mach message restrictions - `references/security-compiler-warnings.md` — security-focused compiler warnings - `references/cpp-hardening.md` — C++ stdlib hardening and bounds checking - `references/hardware-memory-tagging.md` — ARM MTE **Pointer authentication and binary dependencies.** Enhanced Security is a bundle of independent protections; only pointer authentication cascades to `arm64e`. Always recommend `ENABLE_ENHANCED_SECURITY = YES` at the project level. If the project has a binary Swift Package, xcframework, or prebuilt framework that does not ship `arm64e`, the right mitigation is to override `ENABLE_POINTER_AUTHENTICATION = NO` at the target level on every target that links the dependency — not to skip Enhanced Security. List the offending dependencies in the report so the user can ask the vendor for `arm64e` support and lift the override later. **Producer side — universal binary on library/framework targets.** Pointer authentication is highly recommended on library and framework targets too — do not skip it on the grounds that the universal recipe produces a larger on-disk artifact (RAM footprint and execution cost are unchanged; dyld loads only one slice). For each target in the **Library/framework** bucket from Phase 3 step 4, Phase 5 below also applies a target-level `ARCHS = "arm64 arm64e"` and `ONLY_ACTIVE_ARCH = NO` (Release) so consumers can pick either slice. See `references/universal-binaries-for-libraries.md`. For each task: 1. **Compose the change set** from the bucket delta in the scratchpad. - **Entitlements-supported** buckets (Partial / Off / No-entitlements-file): entitlements add/remove/update; create `.entitlements` if missing and wire `CODE_SIGN_ENTITLEMENTS`. DriverKit targets are supported for build settings only — skip entitlement changes for them. - **Library/framework** bucket: no entitlements work. The change set is the universal-binary recipe — see item 2 below. 2. **Build settings:** if xcconfig, set `ENABLE_ENHANCED_SECURITY = YES` at project level there; otherwise `UpdateProjectBuildSetting`. Because a project-level `ENABLE_ENHANCED_SECURITY = YES` cascades `ENABLE_POINTER_AUTHENTICATION = YES` to every target, pre-write a target-level `ENABLE_POINTER_AUTHENTICATION = NO` override on each target that either (a) has a platform that doesn't support arm64e (detect via `SDKROOT` / `SUPPORTED_PLATFORMS` from the audit table), or (b) links a binary dependency that doesn't ship `arm64e`. Skip targets that already have an explicit target-level value per the audit table. For each **Library/framework**-bucket target where pointer authentication will end up enabled (the target's platform supports arm64e and there is no existing target-level `ENABLE_POINTER_AUTHENTICATION = NO`), also pre-write target-level `ARCHS = "arm64 arm64e"` and `ONLY_ACTIVE_ARCH = NO` (Release configuration). Use the target's xcconfig if it has one, otherwise `UpdateTargetBuildSetting`. Skip targets that already have an explicit `ARCHS` per the audit table. Do not auto-enable default-OFF sub-options (MTE family); those are handled by Step 3 below if checked. 3. **Apply** entitlements edits, build-setting changes, and any new `.entitlements` files atomically per target. After all targets are processed, report: "Enabled Enhanced Security on N target(s). Removed M deprecated entitlement(s). Upgraded version string to 2 on K target(s). Added arm64e override on T target(s). Configured universal binary on U library/framework target(s)." The user already approved this in "Phase 4" — no further prompt is needed. The per-target `Apply Enhanced Security` tasks dominate Phase-5 wall time on multi-target projects. Each one writes build settings and edits the target's `.entitlements` plist. #### Step 2: Basic Clang Safety Warnings If pure Swift, skip. Skip individual settings whose audit-table row is `already hardened` on a given target. Otherwise apply target-level (see "How to apply build settings"): - `GCC_WARN_ABOUT_RETURN_TYPE = YES_ERROR` - `GCC_WARN_UNINITIALIZED_AUTOS = YES_AGGRESSIVE` - `CLANG_WARN_IMPLICIT_FALLTHROUGH = YES` - `GCC_WARN_64_TO_32_BIT_CONVERSION = YES` - `GCC_TREAT_IMPLICIT_FUNCTION_DECLARATIONS_AS_ERRORS = YES` (C/ObjC/ObjC++ only) - `CLANG_ANALYZER_SECURITY_FLOATLOOPCOUNTER = YES` - `CLANG_ANALYZER_SECURITY_INSECUREAPI_RAND = YES` - `CLANG_ANALYZER_SECURITY_INSECUREAPI_STRCPY = YES` Report briefly: "Enabled additional compiler warnings." #### Step 3: Hardware Memory Tagging If the **Hardware memory tagging** plan item was unchecked or deleted, skip this step. Hardware memory tagging is supported only for targets whose `SUPPORTED_PLATFORMS` (or `SDKROOT`) is `macosx`, `iphoneos` / `iphonesimulator`, or `xros` / `xrsimulator`. Hardware backing is M5-class Apple silicon and later. Read `references/hardware-memory-tagging.md` and apply the soft-mode MTE entitlement to every supported target. The user already approved this in "Phase 4" — no further prompt is needed. #### Step 4: Additional Diagnostic Settings If the **Additional diagnostic settings** plan item was unchecked or deleted, skip this step. Read `references/additional-settings.md` and follow it. The user already approved this in "Phase 4" — no further prompt is needed. #### Step 5: Bounds Safety Adoption If the **Bounds safety adoption** plan item was unchecked or deleted, skip this step. This step does not apply changes — it emits guidance only. For C projects, print: > "To adopt `ENABLE_C_BOUNDS_SAFETY` (annotation-based bounds safety for C), invoke the `adopt-c-bounds-safety` skill." For C++ projects, print: > "To adopt `ENABLE_CPLUSPLUS_BOUNDS_SAFE_BUFFERS` (C++ bounds-safe buffer patterns), read the documentation at https://clang.llvm.org/docs/SafeBuffers.html" ### Phase 6: Inquire about Disabled Settings If the **Inquire about disabled settings** plan item was unchecked or deleted, skip this phase. This phase pauses for one user response per deliberately-disabled setting that lacks a documented rationale. If the candidate list is long, surface the count up front so the user knows what to expect ("I found 7 deliberately-disabled settings; let me ask about each"). A row is a candidate when the `deliberately disabled` predicate (defined in `references/reading-build-settings.md`) holds. Exclude `ENABLE_POINTER_AUTHENTICATION = NO` rows on targets whose platform doesn't support arm64e (the skill itself sets it there); flag arm64e-capable targets. Restrict to settings whose Scope (in `references/settings-and-entitlements-catalog.md`) covers a language detected in Phase 3 step 2. For each candidate, walk the corresponding `Inquire about on ` task created in Phase 4 step 5: - If the decision document has an entry with status `Disabled` and a rationale → note it in the report and move on. - Otherwise → `AskUserQuestion`: "I found `` explicitly set to `NO` with no explanation. Is there a reason for this?" Double-check that the macro is `deliberately disabled` and not merely at Xcode's default OFF — only call out explicit overrides. Record the rationale (or recommend re-enabling if none). Same flow applies to `ENABLE_ENHANCED_SECURITY = NO` if present in the audit table. ### Phase 7: Report and Decision Document Produce a lean summary: 1. **Enabled** — project-wide settings that were enabled. 2. **Enhanced Security per target** — one line per target: name, final status (up-to-date / applied / skipped-by-user), terse delta (entitlements added, deprecated keys removed, version bumps, whether an entitlements file was created). Roll up Skipped targets into one line. 3. **Already active** — settings already configured correctly. 4. **Inquired** — settings found disabled and the outcome of the inquiry. **Decision document.** Read `references/decision-document.md` and follow it to create or update the decision document. After Phase 7 — and on any error path during Phases 5–7 — these two final tasks run in order: 1. **`Remove scratchpad`** — `Bash rm /xcode-security-audit-scratchpad.md`. The scratchpad is agent-internal state with no value to preserve; removal is unconditional. 2. **`Prompt to remove plan file`** — ask the user via `AskUserQuestion`: "The audit is complete. Remove the plan file `xcode-security-audit-plan.md` from your project?" - **Yes, remove it (Recommended)** → `XcodeRM xcode-security-audit-plan.md deleteFiles:true` - **No, keep it** → leave it in place; it stays in the Project Navigator as a record of what was approved. The user can delete it later from Xcode or Finder. If either removal fails, warn the user but do not block exit. ## User-Facing Interaction Guidelines - **Keep replies lean.** Short sentences. - **Keep user questions minimal.** Two scheduled questions: the plan approval prompt (Run / Cancel) at the end of "Phase 4", and the keep-or-remove-plan-file prompt at the end of "Phase 7". Other questions are situational: inquiries about deliberately-disabled settings during "Phase 6" (only when an explicit `= NO` lacks a documented rationale). - **Report progress** so the user can track: "Enabling...", "Evaluating...", "Keeping/Reverting..." - **Use `AskUserQuestion`** for the plan approval (Run / Cancel), for inquiring about disabled settings during "Phase 6", and for the keep-or-remove-plan-file prompt at the end of "Phase 7". - **When asking a question provide context the user needs to answer the question**. For example, describe the benefit of the security protection before asking whether to enable it. Describe it in terms of the protection it provides, not how it is enabled. - **When emitting lists of Xcode build settings, use bullet lists** Don't use comma-separated lists.