用途：在 iOS 系统权限弹窗出现之前，先生成一块“预请求引导”界面，向用户解释应用为何需要该权限，替代直接冷启动系统弹窗的做法，以提升授权通过率。适用于推送通知、相机、相册、定位（使用期间/始终）、麦克风、通讯录、健康（HealthKit）、App Tracking Transparency 等权限场景。
主要能力：生成统一的权限元数据与状态枚举；提供 PermissionManager 负责检查状态、发起请求、打开系统设置；生成 PermissionPrimingView 预请求界面（支持全屏、仿弹窗、内嵌卡片三种样式，可含 SF Symbol、自定义插图或纯文字，并可选择是否提供“以后再说”）；生成 PermissionStatusTracker 监听用户在设置中的状态变化；生成 PermissionGatedModifier，用 .permissionGated(.camera) 之类方式把功能内容挡在权限检查之后。
使用方式：先检测项目上下文与已有权限代码，搜索 requestAuthorization、AVCaptureDevice、UNUserNotificationCenter、CLLocationManager、PHPhotoLibrary 等调用，并检查 Info.plist 中对应的 NS*UsageDescription 键；缺少必需键时警告可能崩溃并给出键名与建议文案。随后通过 AskUserQuestion 收集要处理的权限、样式、是否含“以后再说”、是否含插图等配置，再按项目结构生成到 Sources/Permissions/、App/Permissions/ 或 Permissions/ 目录。基本用法为 PermissionPrimingView(permissionType: .notifications) { 已授权逻辑 } onDenied: { 被拒逻辑 }，或给视图加 .permissionGated(.camera)。
限制与注意事项：用户一旦拒绝，系统弹窗不会再次出现，必须引导到“设置 > 隐私”重新开启，需妥善处理 .denied 状态。ATT 必须在追踪开始前请求，引导文案不得误导，且不能以激励方式诱导用户允许追踪。HealthKit 使用其自带的双列读写授权界面，无法自定义，引导页只能先解释需要哪些健康数据及原因。定位“始终”需渐进式授权：先请求 .whenInUse，待用户使用后再单独请求 .always，不可一开始就请求。iOS 12+ 的临时（provisional）通知不弹窗而静默投递到通知中心，需先判断是否可接受再决定是否做引导页。缺少 Info.plist 的 NS*UsageDescription 键会直接导致崩溃。
其他：技能参考 templates.md 中的生产级 Swift 模板，并与推送通知设置、同意流程等生成器相关。