{"owner":"jacklandrin","repo":"OnlySwitch","hasSkills":true,"totalSkillsCount":51,"totalTokensCount":24166,"categories":["anthropic-skill","root-instruction","project-spec","plugin-manifest","marketplace"],"hasMcp":false,"mcpConfig":null,"found":["doc/skills/app-store-review/SKILL.md","OpenClaw/skills/onlyswitch-deeplink/SKILL.md","AGENTS.md","doc/skills/writing-plans/SKILL.md","doc/skills/swiftui-pro/SKILL.md","doc/skills/swift-concurrency-pro/SKILL.md","doc/skills/swift-testing-pro/SKILL.md","doc/skills/app-store-review/README.md","ARCHITECTURE.md","doc/skills/writing-plans/plan-document-reviewer-prompt.md","doc/skills/app-store-review/.codex-plugin/plugin.json","doc/skills/README.md","doc/skills/app-store-review/.claude-plugin/marketplace.json","doc/skills/app-store-review/.claude-plugin/plugin.json","doc/skills/app-store-review/agents/openai.yaml","doc/skills/app-store-review/rules/1-safety.md","doc/skills/app-store-review/rules/2-performance.md","doc/skills/app-store-review/rules/3-business.md","doc/skills/app-store-review/rules/4-design.md","doc/skills/app-store-review/rules/5-legal.md","doc/skills/swift-concurrency-pro/references/actors.md","doc/skills/swift-concurrency-pro/references/async-streams.md","doc/skills/swift-concurrency-pro/references/bridging.md","doc/skills/swift-concurrency-pro/references/bug-patterns.md","doc/skills/swift-concurrency-pro/references/cancellation.md","doc/skills/swift-concurrency-pro/references/diagnostics.md","doc/skills/swift-concurrency-pro/references/hotspots.md","doc/skills/swift-concurrency-pro/references/interop.md","doc/skills/swift-concurrency-pro/references/new-features.md","doc/skills/swift-concurrency-pro/references/structured.md","doc/skills/swift-concurrency-pro/references/testing.md","doc/skills/swift-concurrency-pro/references/unstructured.md","doc/skills/swift-concurrency-pro/agents/openai.yaml","doc/skills/swift-testing-pro/references/async-tests.md","doc/skills/swift-testing-pro/references/core-rules.md","doc/skills/swift-testing-pro/references/migrating-from-xctest.md","doc/skills/swift-testing-pro/references/new-features.md","doc/skills/swift-testing-pro/references/writing-better-tests.md","doc/skills/swift-testing-pro/agents/openai.yaml","doc/skills/swiftui-pro/references/accessibility.md","doc/skills/swiftui-pro/references/api.md","doc/skills/swiftui-pro/references/data.md","doc/skills/swiftui-pro/references/design.md","doc/skills/swiftui-pro/references/hygiene.md","doc/skills/swiftui-pro/references/navigation.md","doc/skills/swiftui-pro/references/performance.md","doc/skills/swiftui-pro/references/swift.md","doc/skills/swiftui-pro/references/views.md","doc/skills/swiftui-pro/agents/openai.yaml","OpenClaw/skills/onlyswitch-deeplink/references/switch-ids.md","doc/skills/app-store-review/.agents/plugins/marketplace.json"],"skills":{"doc/skills/app-store-review/SKILL.md":"---\nname: app-store-review\ndescription: Evaluates code against Apple's App Store Review Guidelines. Use this skill when reviewing iOS, macOS, tvOS, watchOS, or visionOS app code (Swift, Objective-C, React Native, or Expo) to identify potential App Store rejection issues before submission. Triggers on tasks involving app review preparation, compliance checking, or App Store submission readiness.\nlicense: MIT\nmetadata:\n author: safaiyeh\n version: \"1.1.0\"\n---\n\n# App Store Review Guidelines Checker\n\nComprehensive guide for evaluating iOS, macOS, tvOS, watchOS, and visionOS app code against Apple's App Store Review Guidelines. This skill covers EVERY guideline point to identify potential rejection issues before submission.\n\n**Supports:** Swift, Objective-C, React Native, and Expo apps\n\n**Guidelines current through:** Apple's June 8, 2026 App Review Guidelines update.\n\n## When to Apply\n\nUse this skill when:\n- Preparing an app for App Store submission\n- Reviewing code for compliance issues\n- Implementing features that may trigger review concerns\n- Auditing existing apps for guideline violations\n- Building features involving payments, user data, or sensitive content\n\n## Guideline Sections\n\nRead individual rule files for detailed explanations, checklists, and code examples:\n\n| Section | File | Key Topics |\n|---------|------|------------|\n| **1. Safety** | [rules/1-safety.md](rules/1-safety.md) | Objectionable content, UGC moderation, Kids Category, physical harm, data security |\n| **2. Performance** | [rules/2-performance.md](rules/2-performance.md) | App completeness, metadata accuracy, hardware compatibility, software requirements |\n| **3. Business** | [rules/3-business.md](rules/3-business.md) | In-app purchase, subscriptions, cryptocurrencies, other business models |\n| **4. Design** | [rules/4-design.md](rules/4-design.md) | Copycats, minimum functionality, spam, extensions, Apple services, login |\n| **5. Legal** | [rules/5-legal.md](rules/5-legal.md) | Privacy, data collection, intellectual property, gambling, VPN, MDM, developer code of conduct |\n\n## Risk Levels by Category\n\n| Risk Level | Category | Section | Common Rejection Reasons |\n|------------|----------|---------|--------------------------|\n| CRITICAL | Privacy & Data | 5.1 | Missing privacy policy, unauthorized data collection |\n| CRITICAL | Payments | 3.1 | Bypassing in-app purchase, unclear pricing |\n| HIGH | Safety | 1.x | Objectionable content, inadequate UGC moderation |\n| HIGH | Performance | 2.x | Crashes, incomplete features, deprecated APIs |\n| MEDIUM | Design | 4.x | Copycat apps, minimum functionality issues |\n| MEDIUM | Legal | 5.x | IP violations, gambling without license |\n\n---\n\n## Quick Reference: High-Risk Rejection Patterns\n\n### Critical Issues (Immediate Rejection)\n\n**Swift:**\n```swift\n// π΄ Private API usage\nlet selector = NSSelectorFromString(\"_privateMethod\")\n\n// π΄ Hardcoded secrets\nlet apiKey = \"sk_live_xxxxx\"\n\n// π΄ External payment for digital goods\nfunc purchaseDigitalContent() {\n openStripeCheckout() // Use StoreKit instead\n}\n```\n\n**React Native / Expo:**\n```typescript\n// π΄ Hardcoded secrets in JS bundle\nconst API_KEY = 'sk_live_xxxxx'; // REJECTION\n\n// π΄ External payment for digital goods\nLinking.openURL('https://stripe.com/checkout'); // Use react-native-iap\n\n// π΄ Dynamic code execution\neval(downloadedCode); // REJECTION\n\n// π΄ Major feature changes via CodePush/expo-updates\n// OTA updates for bug fixes only, not new features!\n```\n\n### High-Risk Issues\n\n**Swift:**\n```swift\n// π‘ Missing ATT when using ad SDKs\nimport FacebookAds // Without ATTrackingManager\n\n// π‘ Account creation without deletion\nfunc createAccount() { } // But no deleteAccount()\n```\n\n**React Native / Expo:**\n```typescript\n// π‘ Missing ATT (use expo-tracking-transparency)\nimport analytics from '@react-native-firebase/analytics';\nanalytics().logEvent('event'); // Without ATT prompt = REJECTION\n\n// π‘ Account deletion via website only\nLinking.openURL('https://example.com/delete'); // Must be in-app!\n\n// π‘ Social login without a privacy-preserving alternative (4.8)\n // Also offer a login meeting 4.8 criteria\n // (Sign in with Apple is the simplest option)\n\n// π‘ Custom review prompts (5.6.1)\nshowCustomAlert('Rate us 5 stars!'); // Use StoreReview.requestReview()\n```\n\n### Medium-Risk Issues\n\n```typescript\n// π Vague purpose strings in Info.plist\n\"This app needs camera access\" // Be specific!\n\n// π WebView-only app (insufficient native functionality)\nconst App = () => ;\n\n// π References to Android in iOS app\nconst text = \"Also available on Android\"; // REJECTION\n\n// π console.log in production\nconsole.log('debug'); // Remove or wrap in __DEV__\n```\n\n---\n\n## Pre-Submission Checklist\n\n### Privacy (Section 5.1)\n- [ ] Privacy policy link in App Store Connect\n- [ ] Privacy policy link accessible within app\n- [ ] All purpose strings are specific and accurate\n- [ ] App Privacy details completed in App Store Connect\n- [ ] ATT implemented if tracking users\n- [ ] Account deletion available if accounts exist\n- [ ] Data minimization - only requesting necessary permissions\n- [ ] User consent obtained before data collection\n\n### Payments (Section 3.1)\n- [ ] StoreKit used for all digital purchases\n- [ ] Restore purchases implemented\n- [ ] Subscription terms clearly displayed\n- [ ] Loot box odds disclosed if applicable\n- [ ] No external payment for digital goods (unless entitled)\n- [ ] Credits/currencies don't expire\n\n### Safety (Section 1.x)\n- [ ] No objectionable content\n- [ ] UGC moderation implemented (filter, report, block, contact)\n- [ ] UGC violations can be removed quickly and backed by a remediation plan\n- [ ] Kids and teens receive age-appropriate experiences inside the app\n- [ ] Parental gates for Kids Category apps\n- [ ] No false information or prank features\n- [ ] Medical disclaimers if applicable\n- [ ] No substance promotion\n\n### Performance (Section 2.x)\n- [ ] No crashes or bugs\n- [ ] All features complete and functional\n- [ ] No placeholder content\n- [ ] IPv6 tested and functional\n- [ ] Demo account provided if needed\n- [ ] Using only public APIs\n- [ ] No deprecated APIs\n- [ ] Proper background mode usage\n\n### Design (Section 4.x)\n- [ ] Sufficient native functionality (not just web wrapper)\n- [ ] No copycat concerns\n- [ ] Original app name and branding\n- [ ] No duplicate Bundle ID spam or low-effort saturated-category clones\n- [ ] Live Activities, push notifications, and Game Center are not used for spam, phishing, or unsolicited messages\n- [ ] Extensions comply with guidelines\n- [ ] Login alternatives if using social login\n- [ ] Not monetizing built-in capabilities\n\n### Legal (Section 5.x)\n- [ ] No unlicensed third-party content\n- [ ] Proper Apple trademark usage\n- [ ] Gambling license if applicable (with real location-based geo-restriction)\n- [ ] VPN uses NEVPNManager API\n- [ ] COPPA/GDPR compliance for kids\n- [ ] Review prompts use the system API only (no custom prompts)\n- [ ] No review, chart, search, or referral manipulation (5.6)\n\n---\n\n## References\n\n- [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)\n- [Apple Developer Program License Agreement](https://developer.apple.com/support/terms/apple-developer-program-license-agreement/)\n- [June 8, 2026 App Review Guidelines update](https://developer.apple.com/news/?id=a233fmpw)\n- [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/)\n- [App Store Connect Help](https://developer.apple.com/help/app-store-connect/)\n- [Apple Developer Documentation](https://developer.apple.com/documentation/)\n","OpenClaw/skills/onlyswitch-deeplink/SKILL.md":"---\nname: onlyswitch-deeplink\ndescription: Invoke OnlySwitch built-in switches or buttons via deeplink. Use when the user asks to toggle or trigger an OnlySwitch action (e.g. empty trash, keep awake, dark mode, mute, hide desktop, clear clipboard, eject discs, Xcode derived data, and any other built-in switch or button). Resolve the request to the correct switch id and open the onlyswitch deeplink.\nmetadata: {\"openclaw\":{\"os\":[\"darwin\"],\"homepage\":\"https://github.com/jacklandrin/OnlySwitch\"}}\n---\n\n# OnlySwitch Deeplink\n\nInvoke OnlySwitch built-in switches or one-shot buttons by opening its deeplink. OnlySwitch must be installed and allowed to handle the `onlyswitch://` URL scheme.\n\n## Workflow\n\n1. **Resolve intent to switch id** \n Map the user's request to a single built-in switch/button using [references/switch-ids.md](references/switch-ids.md). Match phrases like \"empty trash\", \"toggle keep awake\", \"mute mic\", \"clear xcode cache\" to the correct **id** (e.g. empty trash β 16384, keep awake β 16).\n\n2. **Open the deeplink** \n Run on the user's machine (macOS):\n\n ```bash\n open \"onlyswitch://run?type=builtIn&id=\"\n ```\n\n Replace `` with the numeric id from the reference table. Example for \"empty trash\":\n\n ```bash\n open \"onlyswitch://run?type=builtIn&id=16384\"\n ```\n\n3. **Confirm** \n Tell the user which action was triggered (e.g. \"Emptied trash via OnlySwitch\" or \"Toggled Keep Awake via OnlySwitch\").\n\n## Notes\n\n- One deeplink per request: resolve to exactly one switch id per user message.\n- If the request doesn't match any built-in (e.g. custom switch or unknown action), say that OnlySwitch deeplinks only support the built-in list and suggest checking the app or docs.\n- IDs are raw enum values from `SwitchType` in the OnlySwitch app (see project's `SwitchType.swift` for the source of truth; this skill's reference table is derived from it).\n","AGENTS.md":"# OnlySwitch Agent Guidance\n\nThis file defines the default workflow for changes to the OnlySwitch project. It applies to the macOS app, widgets, remote app, Swift Package modules, tests, OpenClaw integration, and project documentation.\n\n## Workflow\n\nFor every task, follow these steps in order. Each phase is delegated to the named subagent/model, and its output is handed to the next phase:\n\n1. **Identify the task β subagent: 5.6 Luna.** Restate the requested outcome, inspect the relevant project files, and analyze the primary use cases, failure modes, and edge cases. Include impacts on macOS permissions, menu-bar behavior, widgets, remote control, persistence, localization, accessibility, and security when relevant.\n2. **Write the implementation plan β subagent: 5.6 Terra.** Ask the user whether they want an implementation plan written first. When accepted, load the `writing-plans` skill, save the completed plan under `doc/plan/`, and use it as the source of truth while implementing. For small, self-contained changes, the user may choose to proceed without a saved plan.\n3. **Load relevant skills using Context Routing β subagent: 5.6 Luna.** Select only the skills whose routing conditions match the task. Do not load every skill or every skill markdown by default. See [Context Routing](#context-routing).\n4. **Summarize constraints β subagent: 5.6 Luna.** Before changing files, briefly summarize applicable architecture rules, platform/deployment constraints, compatibility requirements, existing conventions, and any assumptions.\n5. **Implement unit tests β subagent: 5.6 Terra.** Ask whether the user wants test-driven development for the task. If yes, write or update tests before production code where practical. If no, still add or update focused regression tests when the risk warrants them. Skip this phase only when tests are not meaningful for the requested change.\n6. **Implement the feature β subagent: 5.6 sol.** Make the smallest coherent change that satisfies the task, following the applicable Context Routing guidance and the saved plan when one exists.\n7. **Review the code β subagent: 5.6 Terra.** Review the implementation and tests for correctness, architecture compliance, edge cases, concurrency safety, permissions/privacy risks, and regressions. Apply or request fixes before reporting completion. Run the narrowest relevant checks, then broader checks when appropriate, and report what changed, what was verified, and any known limitations.\n\nWhen a task is explicitly urgent or the user has already answered one of the workflow questions in the current conversation, do not ask the same question again; carry that decision forward for the task.\n\n## Context Routing\n\nSkills are opt-in by task context. First inspect the task and repository; then load only the matching skill instructions. A skill is not loaded merely because it is available.\n\n| Context or trigger | Load skill guidance when | Do not load when |\n| --- | --- | --- |\n| `swiftui-pro` (`doc/skills/swiftui-pro/SKILL.md`) | Reviewing, designing, or implementing SwiftUI views, view state, navigation, accessibility, animations, or SwiftUI performance | The task does not inspect or change SwiftUI code |\n| `swift-concurrency-pro` (`doc/skills/swift-concurrency-pro/SKILL.md`) | Reviewing, designing, or implementing Swift concurrency, actors, `Sendable`, isolation, async streams, cancellation, or strict-concurrency fixes | The task does not inspect or change concurrency code |\n| `swift-testing-pro` (`doc/skills/swift-testing-pro/SKILL.md`) | Writing, migrating, reviewing, or improving Swift Testing/XCTest code or test strategy | No test code or test strategy is in scope |\n| `app-store-review` (`doc/skills/app-store-review/SKILL.md`) | The user explicitly requests an App Store submission-readiness review | Any macOS app task; App Store constraints are out of scope by default for this project |\n| `writing-plans` (`doc/skills/writing-plans/SKILL.md`) | The user requests a multi-step implementation plan, or the workflow's plan step is accepted | The user declines a plan or the task is small and self-contained |\n\nUse the narrowest applicable skill. If several conditions match, load the smallest set that covers the work and state the selection in the task update. Skill instructions may route to more specific references; follow only those references needed for the current task. For the project-local `writing-plans` skill, always save plans as `doc/plan/YYYY-MM-DD-.md`; this project location overrides any generic default path in the skill.\n\n## Project-specific working rules\n\n- Treat `ARCHITECTURE.md` as the source of truth for architectural constraints.\n- Keep implementation plans in `doc/plan/`. Keep reusable skill notes, routing supplements, and project-specific skill instructions in `doc/skills/`.\n- Keep business logic out of SwiftUI views. Move state transitions, validation, orchestration, and side effects into TCA reducers, domain types, or injected clients.\n- Preserve the boundaries between the macOS app, widget extension, remote app, and reusable Swift Package modules.\n- Prefer focused, composable modules and reusable abstractions over expanding monolithic files.\n- Maintain Swift 6 concurrency safety, including explicit sendability and actor isolation at networking, persistence, and process-boundary crossings.\n- Treat shell commands, Apple Events, keychain access, system settings, and user permissions as security-sensitive effects that require explicit dependencies and testable failure handling.\n- Do not evaluate macOS app changes against App Store constraints unless the user explicitly requests an App Store submission-readiness review.\n- Design new or substantially changed UI with modern platform styling, adopting Liquid Glass where supported, providing compatible fallbacks, supporting light and dark modes, and adapting layouts for macOS, iPhone, and iPad sizes as applicable.\n- Translate every new user-facing string into every language supported by OnlySwitch; do not ship newly added source-only strings.\n- Avoid unrelated formatting or refactoring. Update documentation when a change alters an architectural decision or workflow.\n","doc/skills/writing-plans/SKILL.md":"---\nname: writing-plans\ndescription: Use when you have a spec or requirements for a multi-step task, before touching code\n---\n\n# Writing Plans\n\n## Overview\n\nWrite comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.\n\nAssume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.\n\n**Announce at start:** \"I'm using the writing-plans skill to create the implementation plan.\"\n\n**Context:** If working in an isolated worktree, it should have been created via the `superpowers:using-git-worktrees` skill at execution time.\n\n**Save plans to:** `doc/plan/YYYY-MM-DD-.md`\n- This project path is mandatory for OnlySwitch implementation plans.\n\n## Scope Check\n\nIf the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans β one per subsystem. Each plan should produce working, testable software on its own.\n\n## File Structure\n\nBefore defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.\n\n- Design units with clear boundaries and well-defined interfaces. Each file should have one clear responsibility.\n- You reason best about code you can hold in context at once, and your edits are more reliable when files are focused. Prefer smaller, focused files over large ones that do too much.\n- Files that change together should live together. Split by responsibility, not by technical layer.\n- In existing codebases, follow established patterns. If the codebase uses large files, don't unilaterally restructure - but if a file you're modifying has grown unwieldy, including a split in the plan is reasonable.\n\nThis structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.\n\n## Task Right-Sizing\n\nA task is the smallest unit that carries its own test cycle and is worth a\nfresh reviewer's gate. When drawing task boundaries: fold setup,\nconfiguration, scaffolding, and documentation steps into the task whose\ndeliverable needs them; split only where a reviewer could meaningfully\nreject one task while approving its neighbor. Each task ends with an\nindependently testable deliverable.\n\n## Bite-Sized Task Granularity\n\n**Each step is one action (2-5 minutes):**\n- \"Write the failing test\" - step\n- \"Run it to make sure it fails\" - step\n- \"Implement the minimal code to make the test pass\" - step\n- \"Run the tests and make sure they pass\" - step\n- \"Commit\" - step\n\n## Plan Document Header\n\n**Every plan MUST start with this header:**\n\n```markdown\n# [Feature Name] Implementation Plan\n\n> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.\n\n**Goal:** [One sentence describing what this builds]\n\n**Architecture:** [2-3 sentences about approach]\n\n**Tech Stack:** [Key technologies/libraries]\n\n## Global Constraints\n\n[The spec's project-wide requirements β version floors, dependency limits,\nnaming and copy rules, platform requirements β one line each, with exact\nvalues copied verbatim from the spec. Every task's requirements implicitly\ninclude this section.]\n\n---\n```\n\n## Task Structure\n\n````markdown\n### Task N: [Component Name]\n\n**Files:**\n- Create: `exact/path/to/file.py`\n- Modify: `exact/path/to/existing.py:123-145`\n- Test: `tests/exact/path/to/test.py`\n\n**Interfaces:**\n- Consumes: [what this task uses from earlier tasks β exact signatures]\n- Produces: [what later tasks rely on β exact function names, parameter\n and return types. A task's implementer sees only their own task; this\n block is how they learn the names and types neighboring tasks use.]\n\n- [ ] **Step 1: Write the failing test**\n\n```python\ndef test_specific_behavior():\n result = function(input)\n assert result == expected\n```\n\n- [ ] **Step 2: Run test to verify it fails**\n\nRun: `pytest tests/path/test.py::test_name -v`\nExpected: FAIL with \"function not defined\"\n\n- [ ] **Step 3: Write minimal implementation**\n\n```python\ndef function(input):\n return expected\n```\n\n- [ ] **Step 4: Run test to verify it passes**\n\nRun: `pytest tests/path/test.py::test_name -v`\nExpected: PASS\n\n- [ ] **Step 5: Commit**\n\n```bash\ngit add tests/path/test.py src/path/file.py\ngit commit -m \"feat: add specific feature\"\n```\n````\n\n## No Placeholders\n\nEvery step must contain the actual content an engineer needs. These are **plan failures** β never write them:\n- \"TBD\", \"TODO\", \"implement later\", \"fill in details\"\n- \"Add appropriate error handling\" / \"add validation\" / \"handle edge cases\"\n- \"Write tests for the above\" (without actual test code)\n- \"Similar to Task N\" (repeat the code β the engineer may be reading tasks out of order)\n- Steps that describe what to do without showing how (code blocks required for code steps)\n- References to types, functions, or methods not defined in any task\n\n## Self-Review\n\nAfter writing the complete plan, look at the spec with fresh eyes and check the plan against it. This is a checklist you run yourself β not a subagent dispatch.\n\n**1. Spec coverage:** Skim each section/requirement in the spec. Can you point to a task that implements it? List any gaps.\n\n**2. Placeholder scan:** Search your plan for red flags β any of the patterns from the \"No Placeholders\" section above. Fix them.\n\n**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.\n\nIf you find issues, fix them inline. No need to re-review β just fix and move on. If you find a spec requirement with no task, add the task.\n\n## Execution Handoff\n\nAfter saving the plan, offer execution choice:\n\n**\"Plan complete and saved to `doc/plan/.md`. Two execution options:**\n\n**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration\n\n**2. Inline Execution** - Execute tasks in this session using executing-plans, batch execution with checkpoints\n\n**Which approach?\"**\n\n**If Subagent-Driven chosen:**\n- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development\n- Fresh subagent per task + two-stage review\n\n**If Inline Execution chosen:**\n- **REQUIRED SUB-SKILL:** Use superpowers:executing-plans\n- Batch execution with checkpoints for review\n","doc/skills/swiftui-pro/SKILL.md":"---\nname: swiftui-pro\ndescription: Comprehensively reviews SwiftUI code for best practices on modern APIs, maintainability, and performance. Use when reading, writing, or reviewing SwiftUI projects.\nlicense: MIT\nmetadata:\n author: Paul Hudson\n version: \"1.0\"\n---\n\nReview Swift and SwiftUI code for correctness, modern API usage, and adherence to project conventions. Report only genuine problems - do not nitpick or invent issues.\n\nReview process:\n\n1. Check for deprecated API using `references/api.md`.\n1. Check that views, modifiers, and animations have been written optimally using `references/views.md`.\n1. Validate that data flow is configured correctly using `references/data.md`.\n1. Ensure navigation is updated and performant using `references/navigation.md`.\n1. Ensure the code uses designs that are accessible and compliant with Appleβs Human Interface Guidelines using `references/design.md`.\n1. Validate accessibility compliance including Dynamic Type, VoiceOver, and Reduce Motion using `references/accessibility.md`.\n1. Ensure the code is able to run efficiently using `references/performance.md`.\n1. Quick validation of Swift code using `references/swift.md`.\n1. Final code hygiene check using `references/hygiene.md`.\n\nIf doing a partial review, load only the relevant reference files.\n\n\n## Core Instructions\n\n- iOS 26 exists, and is the default deployment target for new apps.\n- Target Swift 6.2 or later, using modern Swift concurrency.\n- As a SwiftUI developer, the user will want to avoid UIKit unless requested.\n- Do not introduce third-party frameworks without asking first.\n- Break different types up into different Swift files rather than placing multiple structs, classes, or enums into a single file.\n- Use a consistent project structure, with folder layout determined by app features.\n\n\n## Output Format\n\nOrganize findings by file. For each issue:\n\n1. State the file and relevant line(s).\n2. Name the rule being violated (e.g., \"Use `foregroundStyle()` instead of `foregroundColor()`\").\n3. Show a brief before/after code fix.\n\nSkip files with no issues. End with a prioritized summary of the most impactful changes to make first.\n\nExample output:\n\n### ContentView.swift\n\n**Line 12: Use `foregroundStyle()` instead of `foregroundColor()`.**\n\n```swift\n// Before\nText(\"Hello\").foregroundColor(.red)\n\n// After\nText(\"Hello\").foregroundStyle(.red)\n```\n\n**Line 24: Icon-only button is bad for VoiceOver - add a text label.**\n\n```swift\n// Before\nButton(action: addUser) {\n Image(systemName: \"plus\")\n}\n\n// After\nButton(\"Add User\", systemImage: \"plus\", action: addUser)\n```\n\n**Line 31: Avoid `Binding(get:set:)` in view body - use `@State` with `onChange()` instead.**\n\n```swift\n// Before\nTextField(\"Username\", text: Binding(\n get: { model.username },\n set: { model.username = $0; model.save() }\n))\n\n// After\nTextField(\"Username\", text: $model.username)\n .onChange(of: model.username) {\n model.save()\n }\n```\n\n### Summary\n\n1. **Accessibility (high):** The add button on line 24 is invisible to VoiceOver.\n2. **Deprecated API (medium):** `foregroundColor()` on line 12 should be `foregroundStyle()`.\n3. **Data flow (medium):** The manual binding on line 31 is fragile and harder to maintain.\n\nEnd of example.\n\n\n## References\n\n- `references/accessibility.md` - Dynamic Type, VoiceOver, Reduce Motion, and other accessibility requirements.\n- `references/api.md` - updating code for modern API, and the deprecated code it replaces.\n- `references/design.md` - guidance for building accessible apps that meet Appleβs Human Interface Guidelines.\n- `references/hygiene.md` - making code compile cleanly and be maintainable in the long term.\n- `references/navigation.md` - navigation using `NavigationStack`/`NavigationSplitView`, plus alerts, confirmation dialogs, and sheets.\n- `references/performance.md` - optimizing SwiftUI code for maximum performance.\n- `references/data.md` - data flow, shared state, and property wrappers.\n- `references/swift.md` - tips on writing modern Swift code, including using Swift Concurrency effectively.\n- `references/views.md` - view structure, composition, and animation.\n","doc/skills/swift-concurrency-pro/SKILL.md":"---\nname: swift-concurrency-pro\ndescription: Reviews Swift code for concurrency correctness, modern API usage, and common async/await pitfalls. Use when reading, writing, or reviewing Swift concurrency code.\nlicense: MIT\nmetadata:\n author: Paul Hudson\n version: \"1.0\"\n---\n\nReview Swift concurrency code for correctness, modern API usage, and adherence to project conventions. Report only genuine problems - do not nitpick or invent issues.\n\nReview process:\n\n1. Scan for known-dangerous patterns using `references/hotspots.md` to prioritize what to inspect.\n1. Check for recent Swift 6.2 concurrency behavior using `references/new-features.md`.\n1. Validate actor usage for reentrancy and isolation correctness using `references/actors.md`.\n1. Ensure structured concurrency is preferred over unstructured where appropriate using `references/structured.md`.\n1. Check unstructured task usage for correctness using `references/unstructured.md`.\n1. Verify cancellation is handled correctly using `references/cancellation.md`.\n1. Validate async stream and continuation usage using `references/async-streams.md`.\n1. Check bridging code between sync and async worlds using `references/bridging.md`.\n1. Review any legacy concurrency migrations using `references/interop.md`.\n1. Cross-check against common failure modes using `references/bug-patterns.md`.\n1. If the project has strict-concurrency errors, map diagnostics to fixes using `references/diagnostics.md`.\n1. If reviewing tests, check async test patterns using `references/testing.md`.\n\nIf doing a partial review, load only the relevant reference files.\n\n\n## Core Instructions\n\n- Target Swift 6.2 or later with strict concurrency checking.\n- If code spans multiple targets or packages, compare their concurrency build settings before assuming behavior should match.\n- Prefer structured concurrency (task groups) over unstructured (`Task {}`).\n- Prefer Swift concurrency over Grand Central Dispatch for new code. GCD is still acceptable in low-level code, framework interop, or performance-critical synchronous work where queues and locks are the right tool β don't flag these as errors.\n- If an API offers both `async`/`await` and closure-based variants, always prefer `async`/`await`.\n- Do not introduce third-party concurrency frameworks without asking first.\n- Do not suggest `@unchecked Sendable` to fix compiler errors. It silences the diagnostic without fixing the underlying race. Prefer actors, value types, or `sending` parameters instead. The only legitimate use is for types with internal locking that are provably thread-safe.\n\n\n## Output Format\n\nOrganize findings by file. For each issue:\n\n1. State the file and relevant line(s).\n2. Name the rule being violated.\n3. Show a brief before/after code fix.\n\nSkip files with no issues. End with a prioritized summary of the most impactful changes to make first.\n\nExample output:\n\n### DataLoader.swift\n\n**Line 18: Actor reentrancy β state may have changed across the `await`.**\n\n```swift\n// Before\nactor Cache {\n var items: [String: Data] = [:]\n\n func fetch(_ key: String) async throws -> Data {\n if items[key] == nil {\n items[key] = try await download(key)\n }\n return items[key]!\n }\n}\n\n// After\nactor Cache {\n var items: [String: Data] = [:]\n\n func fetch(_ key: String) async throws -> Data {\n if let existing = items[key] { return existing }\n let data = try await download(key)\n items[key] = data\n return data\n }\n}\n```\n\n**Line 34: Use `withTaskGroup` instead of creating tasks in a loop.**\n\n```swift\n// Before\nfor url in urls {\n Task { try await fetch(url) }\n}\n\n// After\ntry await withThrowingTaskGroup(of: Data.self) { group in\n for url in urls {\n group.addTask { try await fetch(url) }\n }\n\n for try await result in group {\n process(result)\n }\n}\n```\n\n### Summary\n\n1. **Correctness (high):** Actor reentrancy bug on line 18 may cause duplicate downloads and a force-unwrap crash.\n2. **Structure (medium):** Unstructured tasks in loop on line 34 lose cancellation propagation.\n\nEnd of example.\n\n\n## References\n\n- `references/hotspots.md` - Grep targets for code review: known-dangerous patterns and what to check for each.\n- `references/new-features.md` - Swift 6.2 changes that alter review advice: default actor isolation, isolated conformances, caller-actor async behavior, `@concurrent`, `Task.immediate`, task naming, and priority escalation.\n- `references/actors.md` - Actor reentrancy, shared-state annotations, global actor inference, and isolation patterns.\n- `references/structured.md` - Task groups over loops, discarding task groups, concurrency limits.\n- `references/unstructured.md` - Task vs Task.detached, when Task {} is a code smell.\n- `references/cancellation.md` - Cancellation propagation, cooperative checking, broken cancellation patterns.\n- `references/async-streams.md` - AsyncStream factory, continuation lifecycle, back-pressure.\n- `references/bridging.md` - Checked continuations, wrapping legacy APIs, `@unchecked Sendable`.\n- `references/interop.md` - Migrating from GCD, `Mutex`/locks, completion handlers, delegates, and Combine.\n- `references/bug-patterns.md` - Common concurrency failure modes and their fixes.\n- `references/diagnostics.md` - Strict-concurrency compiler errors, protocol conformance fixes, and likely remedies.\n- `references/testing.md` - Async test strategy with Swift Testing, race detection, avoiding timing-based tests.\n","doc/skills/swift-testing-pro/SKILL.md":"---\nname: swift-testing-pro\ndescription: Writes, reviews, and improves Swift Testing code using modern APIs and best practices. Use when reading, writing, or reviewing projects that use Swift Testing.\nlicense: MIT\nmetadata:\n author: Paul Hudson\n version: \"1.0\"\n---\n\nWrite and review Swift Testing code for correctness, modern API usage, and adherence to project conventions. Report only genuine problems - do not nitpick or invent issues.\n\nReview process:\n\n1. Ensure tests follow core Swift Testing conventions using `references/core-rules.md`.\n1. Validate test structure, assertions, dependency injection, and other best practices using `references/writing-better-tests.md`.\n1. Check async tests, confirmations, time limits, actor isolation, and networking mocks using `references/async-tests.md`.\n1. Ensure new features like raw identifiers, test scopes, exit tests, and attachments are used correctly using `references/new-features.md`.\n1. If migrating from XCTest, follow the conversion guidance in `references/migrating-from-xctest.md`.\n\nIf doing partial work, load only the relevant reference files.\n\n\n## Core Instructions\n\n- Target Swift 6.2 or later, using modern Swift concurrency.\n- As a Swift Testing developer, the user wants all new unit and integration tests to be written using Swift Testing, and they may ask for help migrating existing XCTest code to Swift Testing.\n- Swift Testing does *not* support UI tests β XCTest must be used there.\n- Use a consistent project structure, with folder layout determined by app features.\n\nSwift Testing evolves with each Swift release, so expect three to four releases each year, each introducing new features. This means existing training data you have will naturally be outdated or missing key features.\n\nThis skill specifically draws upon the very latest Swift and Swift Testing code, which means it will suggest things you are not aware of. Treat the userβs installed toolchain as authoritative, but there's a fairly high chance Apple's *documentation* about the APIs will be stale, so treat them carefully.\n\n\n## Output Format\n\nIf the user asks for a review, organize findings by file. For each issue:\n\n1. State the file and relevant line(s).\n2. Name the rule being violated.\n3. Show a brief before/after code fix.\n\nSkip files with no issues. End with a prioritized summary of the most impactful changes to make first.\n\nIf the user asks you to write or improve tests, follow the same rules above but make the changes directly instead of returning a findings report.\n\nExample output:\n\n### UserTests.swift\n\n**Line 5: Use struct, not class, for test suites.**\n\n```swift\n// Before\nclass UserTests: XCTestCase {\n\n// After\nstruct UserTests {\n```\n\n**Line 12: Use `#expect` instead of `XCTAssertEqual`.**\n\n```swift\n// Before\nXCTAssertEqual(user.name, \"Taylor\")\n\n// After\n#expect(user.name == \"Taylor\")\n```\n\n**Line 30: Use `#require` for preconditions, not `#expect`.**\n\n```swift\n// Before\n#expect(users.isEmpty == false)\nlet first = users.first!\n\n// After\nlet first = try #require(users.first)\n```\n\n### Summary\n\n1. **Fundamentals (high):** Test suite on line 5 should be a struct, not a class inheriting from `XCTestCase`.\n2. **Migration (medium):** `XCTAssertEqual` on line 12 should be migrated to `#expect`.\n3. **Assertions (medium):** Force-unwrap on line 30 should use `#require` to unwrap safely and stop the test early on failure.\n\nEnd of example.\n\n\n## References\n\n- `references/core-rules.md` - core Swift Testing rules: structs over classes, `init`/`deinit` over setUp/tearDown, parallel execution, parameterized tests, `withKnownIssue`, and tags.\n- `references/writing-better-tests.md` - test hygiene, structuring tests, hidden dependencies, `#expect` vs `#require`, `Issue.record()`, `#expect(throws:)`, and verification methods.\n- `references/async-tests.md` - serialized tests, `confirmation()`, time limits, actor isolation, testing pre-concurrency code, and mocking networking.\n- `references/new-features.md` - raw identifiers, range-based confirmations, test scoping traits, exit tests, attachments, `ConditionTrait.evaluate()`, and the updated `#expect(throws:)` return value.\n- `references/migrating-from-xctest.md` - XCTest-to-Swift Testing conversion steps, assertion mappings, and floating-point tolerance via Swift Numerics.\n","doc/skills/app-store-review/README.md":"# App Store Review Guidelines Skill\n\nAn AI agent skill that exhaustively evaluates iOS, macOS, tvOS, watchOS, and visionOS app code against **every point** in Apple's App Store Review Guidelines.\n\n**Supports:** Swift, Objective-C, **React Native**, and **Expo** apps\n\n**Current through:** Apple's official June 8, 2026 App Review Guidelines update\n\n## Installation\n\n### Codex\n\nAdd this repository as a Codex plugin marketplace:\n\n```bash\ncodex plugin marketplace add safaiyeh/app-store-review-skill\n```\n\nThen open Codex, run `/plugins`, choose the App Store Review marketplace, and install the `app-store-review` plugin. Start a new thread and invoke the skill with `$app-store-review` or ask for an App Store compliance review.\n\nCodex also discovers direct local skills from `~/.agents/skills`, but plugins are the recommended distribution path for reusable skills.\n\n### Claude Code Plugin Marketplace\n\n```bash\n/plugin marketplace add safaiyeh/app-store-review-skill\n/plugin install app-store-review@app-store-review\n```\n\n### skills.sh\n\n```bash\nnpx skills add safaiyeh/app-store-review-skill\n```\n\n## Setup\n\n### Supported AI Agents\n\nThis skill works with Codex and AI coding agents that support the skills.sh standard:\n\n- [Codex](https://openai.com/codex/)\n- [Claude Code](https://claude.ai/code)\n- [Cursor](https://cursor.sh)\n- [Windsurf](https://codeium.com/windsurf)\n- And other compatible agents\n\n### How It Works\n\n1. **Install the skill** in your project using the command above\n2. **Start your AI agent** in the project directory\n3. **Ask for an App Store review** - the agent will automatically load relevant guidelines\n4. **Review the findings** - the agent identifies potential rejection issues with code references\n\n### Example Prompts\n\n```\n\"Review this app for App Store compliance\"\n\"Check if my IAP implementation follows Apple's guidelines\"\n\"Audit the privacy and data collection in this React Native app\"\n\"What App Store issues might block my submission?\"\n```\n\n### Telemetry\n\nThe skills CLI collects anonymous usage telemetry. To opt out:\n\n```bash\nSKILLS_NO_TELEMETRY=1 npx skills add safaiyeh/app-store-review-skill\n```\n\n## Structure\n\n```\napp-store-review-skill/\nβββ .agents/\nβ βββ plugins/marketplace.json # Codex plugin marketplace\nβββ .claude-plugin/\nβ βββ marketplace.json # Claude Code plugin marketplace\nβ βββ plugin.json # Claude Code plugin manifest\nβββ .codex-plugin/\nβ βββ plugin.json # Codex plugin manifest\nβββ agents/\nβ βββ openai.yaml # Codex UI metadata\nβββ SKILL.md # Index with quick reference & checklist\nβββ rules/\n βββ 1-safety.md # Section 1: Safety guidelines\n βββ 2-performance.md # Section 2: Performance guidelines\n βββ 3-business.md # Section 3: Business guidelines\n βββ 4-design.md # Section 4: Design guidelines\n βββ 5-legal.md # Section 5: Legal guidelines\n```\n\n## Coverage\n\nThis skill covers **ALL 5 major sections** with **EVERY guideline point**:\n\n### [1. Safety](rules/1-safety.md)\n- 1.1 Objectionable Content (1.1.1-1.1.7)\n- 1.2 User-Generated Content & Creator Content\n- 1.3 Kids Category (parental gates, privacy, analytics)\n- 1.4 Physical Harm (medical apps, drug dosage, substances)\n- 1.5 Developer Information\n- 1.6 Data Security\n- 1.7 Reporting Criminal Activity\n\n### [2. Performance](rules/2-performance.md)\n- 2.1 App Completeness (final versions, IAP)\n- 2.2 Beta Testing\n- 2.3 Accurate Metadata (2.3.1-2.3.13)\n- 2.4 Hardware Compatibility (2.4.1-2.4.5)\n- 2.5 Software Requirements (2.5.1-2.5.18)\n\n### [3. Business](rules/3-business.md)\n- 3.1 Payments (IAP, subscriptions, external links, crypto)\n- 3.1.1-3.1.5 In-App Purchase rules\n- 3.2 Other Business Models (acceptable/unacceptable)\n\n### [4. Design](rules/4-design.md)\n- 4.1 Copycats\n- 4.2 Minimum Functionality\n- 4.3 Spam\n- 4.4 Extensions (keyboard, Safari)\n- 4.5 Apple Sites and Services\n- 4.7 Mini Apps, Chatbots, Game Emulators\n- 4.8 Login Services\n- 4.9 Apple Pay\n- 4.10 Monetizing Built-In Capabilities\n\n### [5. Legal](rules/5-legal.md)\n- 5.1 Privacy (data collection, use, sharing, health, kids, location)\n- 5.2 Intellectual Property\n- 5.3 Gaming, Gambling, Lotteries\n- 5.4 VPN Apps\n- 5.5 Mobile Device Management\n- 5.6 Developer Code of Conduct (reviews, developer identity, discovery fraud, app quality)\n\n## Features\n\n- **Modular structure** - Agent loads only relevant sections\n- **2000+ lines** of comprehensive guidelines\n- **Checklists** for every guideline point\n- **Code patterns** for Swift AND React Native/Expo\n- **Package references** for both Expo and bare React Native\n- **Quick reference** for high-risk rejection patterns\n- **Pre-submission checklist** in main SKILL.md\n\n## React Native / Expo Support\n\nEach rule file includes:\n- TypeScript/JavaScript code patterns to flag\n- Expo package recommendations (preferred)\n- Bare React Native package alternatives\n- React Native-specific checklists\n\nKey packages covered:\n- `react-native-purchases` (RevenueCat β recommended for IAP) / `react-native-iap`\n- `expo-tracking-transparency` / `react-native-tracking-transparency`\n- `expo-secure-store` / `react-native-keychain`\n- `expo-apple-authentication` / `@invertase/react-native-apple-authentication`\n- `expo-local-authentication` / `react-native-biometrics`\n\n## What It Checks\n\n### Critical Issues (Immediate Rejection)\n- Private API usage\n- Hardcoded secrets/credentials\n- External payment for digital goods\n- On-device cryptocurrency mining\n- Dynamic code execution\n\n### High-Risk Issues\n- Missing App Tracking Transparency\n- Account creation without deletion\n- IAP without restore purchases\n- UGC without moderation\n- UGC without removal workflows or a compliance improvement plan\n- Kids apps without parental gates\n- Live Activities or push notifications used for spam, phishing, or unsolicited messages\n\n### Medium-Risk Issues\n- Vague purpose strings\n- Over-requesting permissions\n- Unjustified background modes\n- References to other platforms\n- Custom review prompts instead of the system API\n\n## When It Triggers\n\nThe skill activates when working on:\n- App Store submission preparation\n- Code compliance review\n- Payment/StoreKit implementation\n- Privacy and data handling\n- User-generated content features\n- Kids Category apps\n- Health/medical apps\n- VPN/MDM apps\n- Gambling/lottery apps\n\n## License\n\nMIT\n","ARCHITECTURE.md":"# OnlySwitch Architecture\n\n## Purpose\n\nOnlySwitch is a macOS menu-bar utility that exposes system switches, widgets, an optional desktop pet, an AI assistant, and remote control capabilities. The repository also contains reusable Swift Package modules, a widget target, a remote app, persistence, networking, authentication, and OpenClaw integration.\n\n## Core constraints\n\n1. **Use The Composable Architecture (TCA).** Model user-facing features with state, actions, reducers, and effects using [pointfreeco/swift-composable-architecture](https://github.com/pointfreeco/swift-composable-architecture). OnlySwitch already uses TCA in multiple package features; extend that pattern consistently.\n2. **Use `swift-dependencies` for injection.** Runtime services and external effects should be accessed through `@Dependency` using [pointfreeco/swift-dependencies](https://github.com/pointfreeco/swift-dependencies), rather than being constructed directly inside views or reducers. When introducing or migrating a service, add the dependency at the appropriate module boundary.\n3. **Modularize with Swift packages.** Use the `Modules` Swift Package to separate independently buildable and testable functionality. Keep target dependencies intentional and acyclic.\n4. **Factor monolithic logic into focused modules.** Extract switch behavior, feature state, persistence, networking, remote protocol, authentication, AI provider integrations, and presentation concerns into focused modules as boundaries become clear.\n5. **Keep SwiftUI views free of business logic.** Views render state and send user intent. Business rules, validation, orchestration, permissions, shell/AppleScript effects, and state transitions belong in reducers, domain types, or injected clients.\n6. **Follow Swift 6 concurrency safety.** Preserve `Sendable` correctness, actor isolation, structured concurrency, cancellation, and safe crossing of process, networking, persistence, and app/extension boundaries.\n7. **Extract common logic for reuse.** Shared models, remote protocol types, switch descriptors, formatting, validation, persistence adapters, and permission policies should have one well-defined implementation and be reused by the app, widget, remote app, and package targets where appropriate.\n\n## Intended dependency direction\n\n```text\nApp / Widget / Remote app targets\n β\nFeature modules (TCA reducers, feature state, feature views)\n β\nDomain modules (switches, remote protocol, models, business rules)\n β\nInfrastructure modules (system effects, persistence, networking, AI providers, keychain)\n```\n\nInfrastructure details must not leak into SwiftUI views. Feature modules should depend on domain abstractions and access infrastructure through injected dependency clients. Shared protocol and model modules must remain safe for all targets that exchange their values.\n\n## Current repository boundaries\n\n- `Modules/` is the primary Swift Package boundary. It contains feature modules such as `OnlyControl`, `OnlyAgent`, `Authenticator`, `StickerView`, and `DesktopPet`, plus shared `Defines`, `Extensions`, `Utilities`, `Networking`, `RemoteCore`, and `RemoteTransport` modules.\n- `Modules/Sources/Aphrodite` owns the generated mini-app authoring domain, serialized library, TCA feature, and sandboxed renderer. `SettingsVM.shared` retains the Settings store for the app session so accepted work survives presentation changes, while Aphrodite's injected notification boundary requests permission and reports only persistence-confirmed completion; the app delegate owns foreground banner policy. Authoring prompts, conversation history, model selection, and other authoring configuration never cross the `RemoteCore` or `RemoteTransport` boundary; validated runtime HTML, optional validated SVG, and minimal display metadata may cross that boundary for OnlyRemote. Each app persists only its latest HTML and compact completed user prompts; optimistic replacement prevents a stale edit from restoring a deleted or newer app. Six bundled starter apps are merged into the local library once using stable IDs and a persisted seed version, preserving user edits and deletions. Codex reuses a runtime per model and purpose while mapping each Aphrodite conversation to its own thread. Optional icons come from the same model response as static SVG, are validated before storage and native rendering, and fall back to `star.hexagon` when unavailable. Existing libraries without icons or conversation metadata remain readable. The renderer's only native signals are bounded content-size reports from an isolated WebKit content world; the editor keeps an unscaled logical canvas and scales it to fit its preview, while launchers use the content-height signal. Generated page JavaScript cannot access the handler or any native capability.\n- `OnlySwitch/` contains the main macOS application, system integrations, Core Data persistence, audio/player functionality, and app-specific UI. Menu-bar hosts measure active content separately from persistent chrome, then apply the shared `Utilities.AdaptivePanelHeightPolicy` to the hosting screenβs `visibleFrame`. Only Control uses a fixed-size window and keeps overflow scrollable.\n- `OnlyWidget/` contains widget-facing code and must use extension-safe shared models and effects.\n- `OnlySwitchRemote/` contains the remote-control application and must share protocol contracts without importing main-app implementation details. Its root TCA feature owns the independent Aphrodite personal-tools tab and OnlyRemote Plus sheet. Aphrodite access is gated by verified subscription entitlement, with an embedded paywall for nonmembers. Entitlement refresh is independent of product loading and responds to foregrounding, transaction updates, purchases, restoration, and expiration. A Debug-only Settings submenu provides a persisted paywall bypass for development; Release builds ignore this preference. The injected StoreKit client loads and purchases only the one-month `jacklandrin.onlyremote.plus.monthly` auto-renewable product. Only eligible verified transactions unlock access; pending purchases await a later transaction update, and cancellation does not grant access. Recognized verified transactions are finished after processing, and purchase results update both embedded and Settings paywalls without depending on duplicate transaction notifications.\n- `RemoteCore` owns the lightweight, versioned Aphrodite transfer models and the shared HTML and SVG safety validators. Authenticated protocol 1.6 sessions automatically transfer the complete saved library as bounded manifests and 64 KiB chunks with SHA-256 integrity; the wire contract excludes Aphrodite authoring types and private authoring state. OnlyRemote validates each complete transfer before atomically replacing its per-Mac cache, and its WebKit runner uses the same isolated custom origin, content-security policy, and navigation restrictions as the shared sandbox primitives. OnlyRemote lists and runs cached tools but does not create or edit them.\n- Launch Campaign uses an injected TCA client to fetch a bounded manifest and dated HTML from the fixed repository origin. A nonpersistent, navigation-restricted WebKit renderer loads while hidden and acknowledges the date only after successful presentation. The page follows app language and native appearance; its OnlyRemote download link opens the existing native QR window. Both windows temporarily rise above menu-bar panels when presented and return to normal level on focus loss, app deactivation, or closing. Failed requests or rendering remain silent and unacknowledged. Debug builds bypass the previously shown date so the latest page appears on every app launch; forced previews do not modify the saved presentation date.\n- `OnlySwitchTests/`, `OnlySwitchRemoteTests/`, and `Modules/Tests/` contain unit, integration, feature, protocol, and end-to-end coverage.\n- `OpenClaw/skills/onlyswitch-deeplink/` contains the OpenClaw integration documentation and skill for invoking built-in switches through deeplinks.\n\nThe project already uses TCA in package features and Swift Package modularization. New work should extend existing reducer/dependency patterns rather than introduce a parallel state-management approach. `swift-dependencies` is an architectural requirement for new injectable services; existing direct constructions may be migrated incrementally at feature boundaries.\n\n## Feature structure guidance\n\nEach feature should aim to contain:\n\n- a `State` value representing renderable state;\n- an `Action` enum representing user, lifecycle, and dependency-driven events;\n- a reducer that owns transitions and effects;\n- a SwiftUI view that observes state and sends actions;\n- injected clients for clocks, system commands, permissions, persistence, networking, and AI providers;\n- focused tests for business rules, effect behavior, authorization failures, and important edge cases.\n\n## System and remote boundaries\n\nChanges to switches, shell commands, AppleScript, keychain data, Core Data, widgets, remote sessions, or deeplinks must account for:\n\n- macOS authorization and user-cancelled permission flows;\n- command failure, unavailable hardware, unsupported OS versions, and missing executables;\n- secure storage and migration of credentials, pairing data, and provider keys;\n- remote pairing, authentication, encryption, framing, ordering, replay protection, cancellation, and reconnect behavior;\n- widget refresh limits and stale state;\n- process isolation and extension-safe serialization;\n- localization, accessibility, and menu-bar interaction behavior.\n\n## Testing expectations\n\nPrefer deterministic reducer and domain tests with controlled dependencies. Add integration coverage for Core Data, system-effect adapters, remote transport, pairing, and cross-target behavior when reducer tests cannot prove correctness. New concurrency-sensitive code should include tests for cancellation, ordering, actor isolation assumptions, malformed frames, connection loss, and failure propagation where applicable.\n\n","doc/skills/writing-plans/plan-document-reviewer-prompt.md":"# Plan Document Reviewer Prompt Template\n\nUse this template when dispatching a plan document reviewer subagent.\n\n**Purpose:** Verify the plan is complete, matches the spec, and has proper task decomposition.\n\n**Dispatch after:** The complete plan is written.\n\n```\nSubagent (general-purpose):\n description: \"Review plan document\"\n prompt: |\n You are a plan document reviewer. Verify this plan is complete and ready for implementation.\n\n **Plan to review:** [PLAN_FILE_PATH]\n **Spec for reference:** [SPEC_FILE_PATH]\n\n ## What to Check\n\n | Category | What to Look For |\n |----------|------------------|\n | Completeness | TODOs, placeholders, incomplete tasks, missing steps |\n | Spec Alignment | Plan covers spec requirements, no major scope creep |\n | Task Decomposition | Tasks have clear boundaries, steps are actionable |\n | Buildability | Could an engineer follow this plan without getting stuck? |\n\n ## Calibration\n\n **Only flag issues that would cause real problems during implementation.**\n An implementer building the wrong thing or getting stuck is an issue.\n Minor wording, stylistic preferences, and \"nice to have\" suggestions are not.\n\n Approve unless there are serious gaps β missing requirements from the spec,\n contradictory steps, placeholder content, or tasks so vague they can't be acted on.\n\n ## Output Format\n\n ## Plan Review\n\n **Status:** Approved | Issues Found\n\n **Issues (if any):**\n - [Task X, Step Y]: [specific issue] - [why it matters for implementation]\n\n **Recommendations (advisory, do not block approval):**\n - [suggestions for improvement]\n```\n\n**Reviewer returns:** Status, Issues (if any), Recommendations\n","doc/skills/app-store-review/.codex-plugin/plugin.json":"{\n \"name\": \"app-store-review\",\n \"version\": \"1.1.0\",\n \"description\": \"Evaluates code against Apple's App Store Review Guidelines for iOS, macOS, tvOS, watchOS, and visionOS apps.\",\n \"author\": {\n \"name\": \"safaiyeh\",\n \"url\": \"https://github.com/safaiyeh\"\n },\n \"homepage\": \"https://github.com/safaiyeh/app-store-review-skill\",\n \"repository\": \"https://github.com/safaiyeh/app-store-review-skill\",\n \"license\": \"MIT\",\n \"keywords\": [\n \"apple\",\n \"app-store\",\n \"review\",\n \"guidelines\",\n \"ios\",\n \"macos\",\n \"swift\",\n \"react-native\",\n \"expo\"\n ],\n \"skills\": \"./\",\n \"interface\": {\n \"displayName\": \"App Store Review\",\n \"shortDescription\": \"Audit apps for App Store review risk\",\n \"longDescription\": \"Evaluate app code against Apple's App Store Review Guidelines before submission, with coverage for privacy, payments, safety, performance, design, and legal risks.\",\n \"developerName\": \"safaiyeh\",\n \"category\": \"Coding\",\n \"capabilities\": [\n \"Read\"\n ],\n \"websiteURL\": \"https://github.com/safaiyeh/app-store-review-skill\",\n \"defaultPrompt\": [\n \"Review this app for App Store compliance.\"\n ],\n \"brandColor\": \"#0A84FF\"\n }\n}\n","doc/skills/README.md":"# Project Skill Notes\n\nStore project-specific skill supplements, routing notes, and reusable instructions here.\n\nThese files are not loaded automatically. Load a file only when the task matches its stated scope, such as TCA feature design, Swift 6 concurrency, macOS system effects, remote transport, widget integration, App Store review, or test strategy. Each file should begin with a short `When to load` section and should avoid duplicating general guidance that is not needed for the relevant task.\n","doc/skills/app-store-review/.claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `doc/skills/app-store-review/.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/.claude-plugin/marketplace.json)","doc/skills/app-store-review/.claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `doc/skills/app-store-review/.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/.claude-plugin/plugin.json)","doc/skills/app-store-review/agents/openai.yaml":"# Agents Skill\n\nPath: `doc/skills/app-store-review/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/agents/openai.yaml)","doc/skills/app-store-review/rules/1-safety.md":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/1-safety.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/1-safety.md)","doc/skills/app-store-review/rules/2-performance.md":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/2-performance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/2-performance.md)","doc/skills/app-store-review/rules/3-business.md":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/3-business.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/3-business.md)","doc/skills/app-store-review/rules/4-design.md":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/4-design.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/4-design.md)","doc/skills/app-store-review/rules/5-legal.md":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/5-legal.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/5-legal.md)","doc/skills/swift-concurrency-pro/references/actors.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/actors.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/actors.md)","doc/skills/swift-concurrency-pro/references/async-streams.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/async-streams.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/async-streams.md)","doc/skills/swift-concurrency-pro/references/bridging.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/bridging.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/bridging.md)","doc/skills/swift-concurrency-pro/references/bug-patterns.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/bug-patterns.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/bug-patterns.md)","doc/skills/swift-concurrency-pro/references/cancellation.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/cancellation.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/cancellation.md)","doc/skills/swift-concurrency-pro/references/diagnostics.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/diagnostics.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/diagnostics.md)","doc/skills/swift-concurrency-pro/references/hotspots.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/hotspots.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/hotspots.md)","doc/skills/swift-concurrency-pro/references/interop.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/interop.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/interop.md)","doc/skills/swift-concurrency-pro/references/new-features.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/new-features.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/new-features.md)","doc/skills/swift-concurrency-pro/references/structured.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/structured.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/structured.md)","doc/skills/swift-concurrency-pro/references/testing.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/testing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/testing.md)","doc/skills/swift-concurrency-pro/references/unstructured.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/unstructured.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/unstructured.md)","doc/skills/swift-concurrency-pro/agents/openai.yaml":"# Agents Skill\n\nPath: `doc/skills/swift-concurrency-pro/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/agents/openai.yaml)","doc/skills/swift-testing-pro/references/async-tests.md":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/async-tests.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/async-tests.md)","doc/skills/swift-testing-pro/references/core-rules.md":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/core-rules.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/core-rules.md)","doc/skills/swift-testing-pro/references/migrating-from-xctest.md":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/migrating-from-xctest.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/migrating-from-xctest.md)","doc/skills/swift-testing-pro/references/new-features.md":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/new-features.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/new-features.md)","doc/skills/swift-testing-pro/references/writing-better-tests.md":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/writing-better-tests.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/writing-better-tests.md)","doc/skills/swift-testing-pro/agents/openai.yaml":"# Agents Skill\n\nPath: `doc/skills/swift-testing-pro/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/agents/openai.yaml)","doc/skills/swiftui-pro/references/accessibility.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/accessibility.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/accessibility.md)","doc/skills/swiftui-pro/references/api.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/api.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/api.md)","doc/skills/swiftui-pro/references/data.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/data.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/data.md)","doc/skills/swiftui-pro/references/design.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/design.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/design.md)","doc/skills/swiftui-pro/references/hygiene.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/hygiene.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/hygiene.md)","doc/skills/swiftui-pro/references/navigation.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/navigation.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/navigation.md)","doc/skills/swiftui-pro/references/performance.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/performance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/performance.md)","doc/skills/swiftui-pro/references/swift.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/swift.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/swift.md)","doc/skills/swiftui-pro/references/views.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/views.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/views.md)","doc/skills/swiftui-pro/agents/openai.yaml":"# Agents Skill\n\nPath: `doc/skills/swiftui-pro/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/agents/openai.yaml)","OpenClaw/skills/onlyswitch-deeplink/references/switch-ids.md":"# References Skill\n\nPath: `OpenClaw/skills/onlyswitch-deeplink/references/switch-ids.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/OpenClaw/skills/onlyswitch-deeplink/references/switch-ids.md)","doc/skills/app-store-review/.agents/plugins/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `doc/skills/app-store-review/.agents/plugins/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/.agents/plugins/marketplace.json)"},"files":{"doc/skills/app-store-review/SKILL.md":"---\nname: app-store-review\ndescription: Evaluates code against Apple's App Store Review Guidelines. Use this skill when reviewing iOS, macOS, tvOS, watchOS, or visionOS app code (Swift, Objective-C, React Native, or Expo) to identify potential App Store rejection issues before submission. Triggers on tasks involving app review preparation, compliance checking, or App Store submission readiness.\nlicense: MIT\nmetadata:\n author: safaiyeh\n version: \"1.1.0\"\n---\n\n# App Store Review Guidelines Checker\n\nComprehensive guide for evaluating iOS, macOS, tvOS, watchOS, and visionOS app code against Apple's App Store Review Guidelines. This skill covers EVERY guideline point to identify potential rejection issues before submission.\n\n**Supports:** Swift, Objective-C, React Native, and Expo apps\n\n**Guidelines current through:** Apple's June 8, 2026 App Review Guidelines update.\n\n## When to Apply\n\nUse this skill when:\n- Preparing an app for App Store submission\n- Reviewing code for compliance issues\n- Implementing features that may trigger review concerns\n- Auditing existing apps for guideline violations\n- Building features involving payments, user data, or sensitive content\n\n## Guideline Sections\n\nRead individual rule files for detailed explanations, checklists, and code examples:\n\n| Section | File | Key Topics |\n|---------|------|------------|\n| **1. Safety** | [rules/1-safety.md](rules/1-safety.md) | Objectionable content, UGC moderation, Kids Category, physical harm, data security |\n| **2. Performance** | [rules/2-performance.md](rules/2-performance.md) | App completeness, metadata accuracy, hardware compatibility, software requirements |\n| **3. Business** | [rules/3-business.md](rules/3-business.md) | In-app purchase, subscriptions, cryptocurrencies, other business models |\n| **4. Design** | [rules/4-design.md](rules/4-design.md) | Copycats, minimum functionality, spam, extensions, Apple services, login |\n| **5. Legal** | [rules/5-legal.md](rules/5-legal.md) | Privacy, data collection, intellectual property, gambling, VPN, MDM, developer code of conduct |\n\n## Risk Levels by Category\n\n| Risk Level | Category | Section | Common Rejection Reasons |\n|------------|----------|---------|--------------------------|\n| CRITICAL | Privacy & Data | 5.1 | Missing privacy policy, unauthorized data collection |\n| CRITICAL | Payments | 3.1 | Bypassing in-app purchase, unclear pricing |\n| HIGH | Safety | 1.x | Objectionable content, inadequate UGC moderation |\n| HIGH | Performance | 2.x | Crashes, incomplete features, deprecated APIs |\n| MEDIUM | Design | 4.x | Copycat apps, minimum functionality issues |\n| MEDIUM | Legal | 5.x | IP violations, gambling without license |\n\n---\n\n## Quick Reference: High-Risk Rejection Patterns\n\n### Critical Issues (Immediate Rejection)\n\n**Swift:**\n```swift\n// π΄ Private API usage\nlet selector = NSSelectorFromString(\"_privateMethod\")\n\n// π΄ Hardcoded secrets\nlet apiKey = \"sk_live_xxxxx\"\n\n// π΄ External payment for digital goods\nfunc purchaseDigitalContent() {\n openStripeCheckout() // Use StoreKit instead\n}\n```\n\n**React Native / Expo:**\n```typescript\n// π΄ Hardcoded secrets in JS bundle\nconst API_KEY = 'sk_live_xxxxx'; // REJECTION\n\n// π΄ External payment for digital goods\nLinking.openURL('https://stripe.com/checkout'); // Use react-native-iap\n\n// π΄ Dynamic code execution\neval(downloadedCode); // REJECTION\n\n// π΄ Major feature changes via CodePush/expo-updates\n// OTA updates for bug fixes only, not new features!\n```\n\n### High-Risk Issues\n\n**Swift:**\n```swift\n// π‘ Missing ATT when using ad SDKs\nimport FacebookAds // Without ATTrackingManager\n\n// π‘ Account creation without deletion\nfunc createAccount() { } // But no deleteAccount()\n```\n\n**React Native / Expo:**\n```typescript\n// π‘ Missing ATT (use expo-tracking-transparency)\nimport analytics from '@react-native-firebase/analytics';\nanalytics().logEvent('event'); // Without ATT prompt = REJECTION\n\n// π‘ Account deletion via website only\nLinking.openURL('https://example.com/delete'); // Must be in-app!\n\n// π‘ Social login without a privacy-preserving alternative (4.8)\n // Also offer a login meeting 4.8 criteria\n // (Sign in with Apple is the simplest option)\n\n// π‘ Custom review prompts (5.6.1)\nshowCustomAlert('Rate us 5 stars!'); // Use StoreReview.requestReview()\n```\n\n### Medium-Risk Issues\n\n```typescript\n// π Vague purpose strings in Info.plist\n\"This app needs camera access\" // Be specific!\n\n// π WebView-only app (insufficient native functionality)\nconst App = () => ;\n\n// π References to Android in iOS app\nconst text = \"Also available on Android\"; // REJECTION\n\n// π console.log in production\nconsole.log('debug'); // Remove or wrap in __DEV__\n```\n\n---\n\n## Pre-Submission Checklist\n\n### Privacy (Section 5.1)\n- [ ] Privacy policy link in App Store Connect\n- [ ] Privacy policy link accessible within app\n- [ ] All purpose strings are specific and accurate\n- [ ] App Privacy details completed in App Store Connect\n- [ ] ATT implemented if tracking users\n- [ ] Account deletion available if accounts exist\n- [ ] Data minimization - only requesting necessary permissions\n- [ ] User consent obtained before data collection\n\n### Payments (Section 3.1)\n- [ ] StoreKit used for all digital purchases\n- [ ] Restore purchases implemented\n- [ ] Subscription terms clearly displayed\n- [ ] Loot box odds disclosed if applicable\n- [ ] No external payment for digital goods (unless entitled)\n- [ ] Credits/currencies don't expire\n\n### Safety (Section 1.x)\n- [ ] No objectionable content\n- [ ] UGC moderation implemented (filter, report, block, contact)\n- [ ] UGC violations can be removed quickly and backed by a remediation plan\n- [ ] Kids and teens receive age-appropriate experiences inside the app\n- [ ] Parental gates for Kids Category apps\n- [ ] No false information or prank features\n- [ ] Medical disclaimers if applicable\n- [ ] No substance promotion\n\n### Performance (Section 2.x)\n- [ ] No crashes or bugs\n- [ ] All features complete and functional\n- [ ] No placeholder content\n- [ ] IPv6 tested and functional\n- [ ] Demo account provided if needed\n- [ ] Using only public APIs\n- [ ] No deprecated APIs\n- [ ] Proper background mode usage\n\n### Design (Section 4.x)\n- [ ] Sufficient native functionality (not just web wrapper)\n- [ ] No copycat concerns\n- [ ] Original app name and branding\n- [ ] No duplicate Bundle ID spam or low-effort saturated-category clones\n- [ ] Live Activities, push notifications, and Game Center are not used for spam, phishing, or unsolicited messages\n- [ ] Extensions comply with guidelines\n- [ ] Login alternatives if using social login\n- [ ] Not monetizing built-in capabilities\n\n### Legal (Section 5.x)\n- [ ] No unlicensed third-party content\n- [ ] Proper Apple trademark usage\n- [ ] Gambling license if applicable (with real location-based geo-restriction)\n- [ ] VPN uses NEVPNManager API\n- [ ] COPPA/GDPR compliance for kids\n- [ ] Review prompts use the system API only (no custom prompts)\n- [ ] No review, chart, search, or referral manipulation (5.6)\n\n---\n\n## References\n\n- [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)\n- [Apple Developer Program License Agreement](https://developer.apple.com/support/terms/apple-developer-program-license-agreement/)\n- [June 8, 2026 App Review Guidelines update](https://developer.apple.com/news/?id=a233fmpw)\n- [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/)\n- [App Store Connect Help](https://developer.apple.com/help/app-store-connect/)\n- [Apple Developer Documentation](https://developer.apple.com/documentation/)\n","OpenClaw/skills/onlyswitch-deeplink/SKILL.md":"---\nname: onlyswitch-deeplink\ndescription: Invoke OnlySwitch built-in switches or buttons via deeplink. Use when the user asks to toggle or trigger an OnlySwitch action (e.g. empty trash, keep awake, dark mode, mute, hide desktop, clear clipboard, eject discs, Xcode derived data, and any other built-in switch or button). Resolve the request to the correct switch id and open the onlyswitch deeplink.\nmetadata: {\"openclaw\":{\"os\":[\"darwin\"],\"homepage\":\"https://github.com/jacklandrin/OnlySwitch\"}}\n---\n\n# OnlySwitch Deeplink\n\nInvoke OnlySwitch built-in switches or one-shot buttons by opening its deeplink. OnlySwitch must be installed and allowed to handle the `onlyswitch://` URL scheme.\n\n## Workflow\n\n1. **Resolve intent to switch id** \n Map the user's request to a single built-in switch/button using [references/switch-ids.md](references/switch-ids.md). Match phrases like \"empty trash\", \"toggle keep awake\", \"mute mic\", \"clear xcode cache\" to the correct **id** (e.g. empty trash β 16384, keep awake β 16).\n\n2. **Open the deeplink** \n Run on the user's machine (macOS):\n\n ```bash\n open \"onlyswitch://run?type=builtIn&id=\"\n ```\n\n Replace `` with the numeric id from the reference table. Example for \"empty trash\":\n\n ```bash\n open \"onlyswitch://run?type=builtIn&id=16384\"\n ```\n\n3. **Confirm** \n Tell the user which action was triggered (e.g. \"Emptied trash via OnlySwitch\" or \"Toggled Keep Awake via OnlySwitch\").\n\n## Notes\n\n- One deeplink per request: resolve to exactly one switch id per user message.\n- If the request doesn't match any built-in (e.g. custom switch or unknown action), say that OnlySwitch deeplinks only support the built-in list and suggest checking the app or docs.\n- IDs are raw enum values from `SwitchType` in the OnlySwitch app (see project's `SwitchType.swift` for the source of truth; this skill's reference table is derived from it).\n","AGENTS.md":"# OnlySwitch Agent Guidance\n\nThis file defines the default workflow for changes to the OnlySwitch project. It applies to the macOS app, widgets, remote app, Swift Package modules, tests, OpenClaw integration, and project documentation.\n\n## Workflow\n\nFor every task, follow these steps in order. Each phase is delegated to the named subagent/model, and its output is handed to the next phase:\n\n1. **Identify the task β subagent: 5.6 Luna.** Restate the requested outcome, inspect the relevant project files, and analyze the primary use cases, failure modes, and edge cases. Include impacts on macOS permissions, menu-bar behavior, widgets, remote control, persistence, localization, accessibility, and security when relevant.\n2. **Write the implementation plan β subagent: 5.6 Terra.** Ask the user whether they want an implementation plan written first. When accepted, load the `writing-plans` skill, save the completed plan under `doc/plan/`, and use it as the source of truth while implementing. For small, self-contained changes, the user may choose to proceed without a saved plan.\n3. **Load relevant skills using Context Routing β subagent: 5.6 Luna.** Select only the skills whose routing conditions match the task. Do not load every skill or every skill markdown by default. See [Context Routing](#context-routing).\n4. **Summarize constraints β subagent: 5.6 Luna.** Before changing files, briefly summarize applicable architecture rules, platform/deployment constraints, compatibility requirements, existing conventions, and any assumptions.\n5. **Implement unit tests β subagent: 5.6 Terra.** Ask whether the user wants test-driven development for the task. If yes, write or update tests before production code where practical. If no, still add or update focused regression tests when the risk warrants them. Skip this phase only when tests are not meaningful for the requested change.\n6. **Implement the feature β subagent: 5.6 sol.** Make the smallest coherent change that satisfies the task, following the applicable Context Routing guidance and the saved plan when one exists.\n7. **Review the code β subagent: 5.6 Terra.** Review the implementation and tests for correctness, architecture compliance, edge cases, concurrency safety, permissions/privacy risks, and regressions. Apply or request fixes before reporting completion. Run the narrowest relevant checks, then broader checks when appropriate, and report what changed, what was verified, and any known limitations.\n\nWhen a task is explicitly urgent or the user has already answered one of the workflow questions in the current conversation, do not ask the same question again; carry that decision forward for the task.\n\n## Context Routing\n\nSkills are opt-in by task context. First inspect the task and repository; then load only the matching skill instructions. A skill is not loaded merely because it is available.\n\n| Context or trigger | Load skill guidance when | Do not load when |\n| --- | --- | --- |\n| `swiftui-pro` (`doc/skills/swiftui-pro/SKILL.md`) | Reviewing, designing, or implementing SwiftUI views, view state, navigation, accessibility, animations, or SwiftUI performance | The task does not inspect or change SwiftUI code |\n| `swift-concurrency-pro` (`doc/skills/swift-concurrency-pro/SKILL.md`) | Reviewing, designing, or implementing Swift concurrency, actors, `Sendable`, isolation, async streams, cancellation, or strict-concurrency fixes | The task does not inspect or change concurrency code |\n| `swift-testing-pro` (`doc/skills/swift-testing-pro/SKILL.md`) | Writing, migrating, reviewing, or improving Swift Testing/XCTest code or test strategy | No test code or test strategy is in scope |\n| `app-store-review` (`doc/skills/app-store-review/SKILL.md`) | The user explicitly requests an App Store submission-readiness review | Any macOS app task; App Store constraints are out of scope by default for this project |\n| `writing-plans` (`doc/skills/writing-plans/SKILL.md`) | The user requests a multi-step implementation plan, or the workflow's plan step is accepted | The user declines a plan or the task is small and self-contained |\n\nUse the narrowest applicable skill. If several conditions match, load the smallest set that covers the work and state the selection in the task update. Skill instructions may route to more specific references; follow only those references needed for the current task. For the project-local `writing-plans` skill, always save plans as `doc/plan/YYYY-MM-DD-.md`; this project location overrides any generic default path in the skill.\n\n## Project-specific working rules\n\n- Treat `ARCHITECTURE.md` as the source of truth for architectural constraints.\n- Keep implementation plans in `doc/plan/`. Keep reusable skill notes, routing supplements, and project-specific skill instructions in `doc/skills/`.\n- Keep business logic out of SwiftUI views. Move state transitions, validation, orchestration, and side effects into TCA reducers, domain types, or injected clients.\n- Preserve the boundaries between the macOS app, widget extension, remote app, and reusable Swift Package modules.\n- Prefer focused, composable modules and reusable abstractions over expanding monolithic files.\n- Maintain Swift 6 concurrency safety, including explicit sendability and actor isolation at networking, persistence, and process-boundary crossings.\n- Treat shell commands, Apple Events, keychain access, system settings, and user permissions as security-sensitive effects that require explicit dependencies and testable failure handling.\n- Do not evaluate macOS app changes against App Store constraints unless the user explicitly requests an App Store submission-readiness review.\n- Design new or substantially changed UI with modern platform styling, adopting Liquid Glass where supported, providing compatible fallbacks, supporting light and dark modes, and adapting layouts for macOS, iPhone, and iPad sizes as applicable.\n- Translate every new user-facing string into every language supported by OnlySwitch; do not ship newly added source-only strings.\n- Avoid unrelated formatting or refactoring. Update documentation when a change alters an architectural decision or workflow.\n","doc/skills/writing-plans/SKILL.md":"---\nname: writing-plans\ndescription: Use when you have a spec or requirements for a multi-step task, before touching code\n---\n\n# Writing Plans\n\n## Overview\n\nWrite comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.\n\nAssume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.\n\n**Announce at start:** \"I'm using the writing-plans skill to create the implementation plan.\"\n\n**Context:** If working in an isolated worktree, it should have been created via the `superpowers:using-git-worktrees` skill at execution time.\n\n**Save plans to:** `doc/plan/YYYY-MM-DD-.md`\n- This project path is mandatory for OnlySwitch implementation plans.\n\n## Scope Check\n\nIf the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans β one per subsystem. Each plan should produce working, testable software on its own.\n\n## File Structure\n\nBefore defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.\n\n- Design units with clear boundaries and well-defined interfaces. Each file should have one clear responsibility.\n- You reason best about code you can hold in context at once, and your edits are more reliable when files are focused. Prefer smaller, focused files over large ones that do too much.\n- Files that change together should live together. Split by responsibility, not by technical layer.\n- In existing codebases, follow established patterns. If the codebase uses large files, don't unilaterally restructure - but if a file you're modifying has grown unwieldy, including a split in the plan is reasonable.\n\nThis structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.\n\n## Task Right-Sizing\n\nA task is the smallest unit that carries its own test cycle and is worth a\nfresh reviewer's gate. When drawing task boundaries: fold setup,\nconfiguration, scaffolding, and documentation steps into the task whose\ndeliverable needs them; split only where a reviewer could meaningfully\nreject one task while approving its neighbor. Each task ends with an\nindependently testable deliverable.\n\n## Bite-Sized Task Granularity\n\n**Each step is one action (2-5 minutes):**\n- \"Write the failing test\" - step\n- \"Run it to make sure it fails\" - step\n- \"Implement the minimal code to make the test pass\" - step\n- \"Run the tests and make sure they pass\" - step\n- \"Commit\" - step\n\n## Plan Document Header\n\n**Every plan MUST start with this header:**\n\n```markdown\n# [Feature Name] Implementation Plan\n\n> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.\n\n**Goal:** [One sentence describing what this builds]\n\n**Architecture:** [2-3 sentences about approach]\n\n**Tech Stack:** [Key technologies/libraries]\n\n## Global Constraints\n\n[The spec's project-wide requirements β version floors, dependency limits,\nnaming and copy rules, platform requirements β one line each, with exact\nvalues copied verbatim from the spec. Every task's requirements implicitly\ninclude this section.]\n\n---\n```\n\n## Task Structure\n\n````markdown\n### Task N: [Component Name]\n\n**Files:**\n- Create: `exact/path/to/file.py`\n- Modify: `exact/path/to/existing.py:123-145`\n- Test: `tests/exact/path/to/test.py`\n\n**Interfaces:**\n- Consumes: [what this task uses from earlier tasks β exact signatures]\n- Produces: [what later tasks rely on β exact function names, parameter\n and return types. A task's implementer sees only their own task; this\n block is how they learn the names and types neighboring tasks use.]\n\n- [ ] **Step 1: Write the failing test**\n\n```python\ndef test_specific_behavior():\n result = function(input)\n assert result == expected\n```\n\n- [ ] **Step 2: Run test to verify it fails**\n\nRun: `pytest tests/path/test.py::test_name -v`\nExpected: FAIL with \"function not defined\"\n\n- [ ] **Step 3: Write minimal implementation**\n\n```python\ndef function(input):\n return expected\n```\n\n- [ ] **Step 4: Run test to verify it passes**\n\nRun: `pytest tests/path/test.py::test_name -v`\nExpected: PASS\n\n- [ ] **Step 5: Commit**\n\n```bash\ngit add tests/path/test.py src/path/file.py\ngit commit -m \"feat: add specific feature\"\n```\n````\n\n## No Placeholders\n\nEvery step must contain the actual content an engineer needs. These are **plan failures** β never write them:\n- \"TBD\", \"TODO\", \"implement later\", \"fill in details\"\n- \"Add appropriate error handling\" / \"add validation\" / \"handle edge cases\"\n- \"Write tests for the above\" (without actual test code)\n- \"Similar to Task N\" (repeat the code β the engineer may be reading tasks out of order)\n- Steps that describe what to do without showing how (code blocks required for code steps)\n- References to types, functions, or methods not defined in any task\n\n## Self-Review\n\nAfter writing the complete plan, look at the spec with fresh eyes and check the plan against it. This is a checklist you run yourself β not a subagent dispatch.\n\n**1. Spec coverage:** Skim each section/requirement in the spec. Can you point to a task that implements it? List any gaps.\n\n**2. Placeholder scan:** Search your plan for red flags β any of the patterns from the \"No Placeholders\" section above. Fix them.\n\n**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.\n\nIf you find issues, fix them inline. No need to re-review β just fix and move on. If you find a spec requirement with no task, add the task.\n\n## Execution Handoff\n\nAfter saving the plan, offer execution choice:\n\n**\"Plan complete and saved to `doc/plan/.md`. Two execution options:**\n\n**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration\n\n**2. Inline Execution** - Execute tasks in this session using executing-plans, batch execution with checkpoints\n\n**Which approach?\"**\n\n**If Subagent-Driven chosen:**\n- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development\n- Fresh subagent per task + two-stage review\n\n**If Inline Execution chosen:**\n- **REQUIRED SUB-SKILL:** Use superpowers:executing-plans\n- Batch execution with checkpoints for review\n","doc/skills/swiftui-pro/SKILL.md":"---\nname: swiftui-pro\ndescription: Comprehensively reviews SwiftUI code for best practices on modern APIs, maintainability, and performance. Use when reading, writing, or reviewing SwiftUI projects.\nlicense: MIT\nmetadata:\n author: Paul Hudson\n version: \"1.0\"\n---\n\nReview Swift and SwiftUI code for correctness, modern API usage, and adherence to project conventions. Report only genuine problems - do not nitpick or invent issues.\n\nReview process:\n\n1. Check for deprecated API using `references/api.md`.\n1. Check that views, modifiers, and animations have been written optimally using `references/views.md`.\n1. Validate that data flow is configured correctly using `references/data.md`.\n1. Ensure navigation is updated and performant using `references/navigation.md`.\n1. Ensure the code uses designs that are accessible and compliant with Appleβs Human Interface Guidelines using `references/design.md`.\n1. Validate accessibility compliance including Dynamic Type, VoiceOver, and Reduce Motion using `references/accessibility.md`.\n1. Ensure the code is able to run efficiently using `references/performance.md`.\n1. Quick validation of Swift code using `references/swift.md`.\n1. Final code hygiene check using `references/hygiene.md`.\n\nIf doing a partial review, load only the relevant reference files.\n\n\n## Core Instructions\n\n- iOS 26 exists, and is the default deployment target for new apps.\n- Target Swift 6.2 or later, using modern Swift concurrency.\n- As a SwiftUI developer, the user will want to avoid UIKit unless requested.\n- Do not introduce third-party frameworks without asking first.\n- Break different types up into different Swift files rather than placing multiple structs, classes, or enums into a single file.\n- Use a consistent project structure, with folder layout determined by app features.\n\n\n## Output Format\n\nOrganize findings by file. For each issue:\n\n1. State the file and relevant line(s).\n2. Name the rule being violated (e.g., \"Use `foregroundStyle()` instead of `foregroundColor()`\").\n3. Show a brief before/after code fix.\n\nSkip files with no issues. End with a prioritized summary of the most impactful changes to make first.\n\nExample output:\n\n### ContentView.swift\n\n**Line 12: Use `foregroundStyle()` instead of `foregroundColor()`.**\n\n```swift\n// Before\nText(\"Hello\").foregroundColor(.red)\n\n// After\nText(\"Hello\").foregroundStyle(.red)\n```\n\n**Line 24: Icon-only button is bad for VoiceOver - add a text label.**\n\n```swift\n// Before\nButton(action: addUser) {\n Image(systemName: \"plus\")\n}\n\n// After\nButton(\"Add User\", systemImage: \"plus\", action: addUser)\n```\n\n**Line 31: Avoid `Binding(get:set:)` in view body - use `@State` with `onChange()` instead.**\n\n```swift\n// Before\nTextField(\"Username\", text: Binding(\n get: { model.username },\n set: { model.username = $0; model.save() }\n))\n\n// After\nTextField(\"Username\", text: $model.username)\n .onChange(of: model.username) {\n model.save()\n }\n```\n\n### Summary\n\n1. **Accessibility (high):** The add button on line 24 is invisible to VoiceOver.\n2. **Deprecated API (medium):** `foregroundColor()` on line 12 should be `foregroundStyle()`.\n3. **Data flow (medium):** The manual binding on line 31 is fragile and harder to maintain.\n\nEnd of example.\n\n\n## References\n\n- `references/accessibility.md` - Dynamic Type, VoiceOver, Reduce Motion, and other accessibility requirements.\n- `references/api.md` - updating code for modern API, and the deprecated code it replaces.\n- `references/design.md` - guidance for building accessible apps that meet Appleβs Human Interface Guidelines.\n- `references/hygiene.md` - making code compile cleanly and be maintainable in the long term.\n- `references/navigation.md` - navigation using `NavigationStack`/`NavigationSplitView`, plus alerts, confirmation dialogs, and sheets.\n- `references/performance.md` - optimizing SwiftUI code for maximum performance.\n- `references/data.md` - data flow, shared state, and property wrappers.\n- `references/swift.md` - tips on writing modern Swift code, including using Swift Concurrency effectively.\n- `references/views.md` - view structure, composition, and animation.\n","doc/skills/swift-concurrency-pro/SKILL.md":"---\nname: swift-concurrency-pro\ndescription: Reviews Swift code for concurrency correctness, modern API usage, and common async/await pitfalls. Use when reading, writing, or reviewing Swift concurrency code.\nlicense: MIT\nmetadata:\n author: Paul Hudson\n version: \"1.0\"\n---\n\nReview Swift concurrency code for correctness, modern API usage, and adherence to project conventions. Report only genuine problems - do not nitpick or invent issues.\n\nReview process:\n\n1. Scan for known-dangerous patterns using `references/hotspots.md` to prioritize what to inspect.\n1. Check for recent Swift 6.2 concurrency behavior using `references/new-features.md`.\n1. Validate actor usage for reentrancy and isolation correctness using `references/actors.md`.\n1. Ensure structured concurrency is preferred over unstructured where appropriate using `references/structured.md`.\n1. Check unstructured task usage for correctness using `references/unstructured.md`.\n1. Verify cancellation is handled correctly using `references/cancellation.md`.\n1. Validate async stream and continuation usage using `references/async-streams.md`.\n1. Check bridging code between sync and async worlds using `references/bridging.md`.\n1. Review any legacy concurrency migrations using `references/interop.md`.\n1. Cross-check against common failure modes using `references/bug-patterns.md`.\n1. If the project has strict-concurrency errors, map diagnostics to fixes using `references/diagnostics.md`.\n1. If reviewing tests, check async test patterns using `references/testing.md`.\n\nIf doing a partial review, load only the relevant reference files.\n\n\n## Core Instructions\n\n- Target Swift 6.2 or later with strict concurrency checking.\n- If code spans multiple targets or packages, compare their concurrency build settings before assuming behavior should match.\n- Prefer structured concurrency (task groups) over unstructured (`Task {}`).\n- Prefer Swift concurrency over Grand Central Dispatch for new code. GCD is still acceptable in low-level code, framework interop, or performance-critical synchronous work where queues and locks are the right tool β don't flag these as errors.\n- If an API offers both `async`/`await` and closure-based variants, always prefer `async`/`await`.\n- Do not introduce third-party concurrency frameworks without asking first.\n- Do not suggest `@unchecked Sendable` to fix compiler errors. It silences the diagnostic without fixing the underlying race. Prefer actors, value types, or `sending` parameters instead. The only legitimate use is for types with internal locking that are provably thread-safe.\n\n\n## Output Format\n\nOrganize findings by file. For each issue:\n\n1. State the file and relevant line(s).\n2. Name the rule being violated.\n3. Show a brief before/after code fix.\n\nSkip files with no issues. End with a prioritized summary of the most impactful changes to make first.\n\nExample output:\n\n### DataLoader.swift\n\n**Line 18: Actor reentrancy β state may have changed across the `await`.**\n\n```swift\n// Before\nactor Cache {\n var items: [String: Data] = [:]\n\n func fetch(_ key: String) async throws -> Data {\n if items[key] == nil {\n items[key] = try await download(key)\n }\n return items[key]!\n }\n}\n\n// After\nactor Cache {\n var items: [String: Data] = [:]\n\n func fetch(_ key: String) async throws -> Data {\n if let existing = items[key] { return existing }\n let data = try await download(key)\n items[key] = data\n return data\n }\n}\n```\n\n**Line 34: Use `withTaskGroup` instead of creating tasks in a loop.**\n\n```swift\n// Before\nfor url in urls {\n Task { try await fetch(url) }\n}\n\n// After\ntry await withThrowingTaskGroup(of: Data.self) { group in\n for url in urls {\n group.addTask { try await fetch(url) }\n }\n\n for try await result in group {\n process(result)\n }\n}\n```\n\n### Summary\n\n1. **Correctness (high):** Actor reentrancy bug on line 18 may cause duplicate downloads and a force-unwrap crash.\n2. **Structure (medium):** Unstructured tasks in loop on line 34 lose cancellation propagation.\n\nEnd of example.\n\n\n## References\n\n- `references/hotspots.md` - Grep targets for code review: known-dangerous patterns and what to check for each.\n- `references/new-features.md` - Swift 6.2 changes that alter review advice: default actor isolation, isolated conformances, caller-actor async behavior, `@concurrent`, `Task.immediate`, task naming, and priority escalation.\n- `references/actors.md` - Actor reentrancy, shared-state annotations, global actor inference, and isolation patterns.\n- `references/structured.md` - Task groups over loops, discarding task groups, concurrency limits.\n- `references/unstructured.md` - Task vs Task.detached, when Task {} is a code smell.\n- `references/cancellation.md` - Cancellation propagation, cooperative checking, broken cancellation patterns.\n- `references/async-streams.md` - AsyncStream factory, continuation lifecycle, back-pressure.\n- `references/bridging.md` - Checked continuations, wrapping legacy APIs, `@unchecked Sendable`.\n- `references/interop.md` - Migrating from GCD, `Mutex`/locks, completion handlers, delegates, and Combine.\n- `references/bug-patterns.md` - Common concurrency failure modes and their fixes.\n- `references/diagnostics.md` - Strict-concurrency compiler errors, protocol conformance fixes, and likely remedies.\n- `references/testing.md` - Async test strategy with Swift Testing, race detection, avoiding timing-based tests.\n","doc/skills/swift-testing-pro/SKILL.md":"---\nname: swift-testing-pro\ndescription: Writes, reviews, and improves Swift Testing code using modern APIs and best practices. Use when reading, writing, or reviewing projects that use Swift Testing.\nlicense: MIT\nmetadata:\n author: Paul Hudson\n version: \"1.0\"\n---\n\nWrite and review Swift Testing code for correctness, modern API usage, and adherence to project conventions. Report only genuine problems - do not nitpick or invent issues.\n\nReview process:\n\n1. Ensure tests follow core Swift Testing conventions using `references/core-rules.md`.\n1. Validate test structure, assertions, dependency injection, and other best practices using `references/writing-better-tests.md`.\n1. Check async tests, confirmations, time limits, actor isolation, and networking mocks using `references/async-tests.md`.\n1. Ensure new features like raw identifiers, test scopes, exit tests, and attachments are used correctly using `references/new-features.md`.\n1. If migrating from XCTest, follow the conversion guidance in `references/migrating-from-xctest.md`.\n\nIf doing partial work, load only the relevant reference files.\n\n\n## Core Instructions\n\n- Target Swift 6.2 or later, using modern Swift concurrency.\n- As a Swift Testing developer, the user wants all new unit and integration tests to be written using Swift Testing, and they may ask for help migrating existing XCTest code to Swift Testing.\n- Swift Testing does *not* support UI tests β XCTest must be used there.\n- Use a consistent project structure, with folder layout determined by app features.\n\nSwift Testing evolves with each Swift release, so expect three to four releases each year, each introducing new features. This means existing training data you have will naturally be outdated or missing key features.\n\nThis skill specifically draws upon the very latest Swift and Swift Testing code, which means it will suggest things you are not aware of. Treat the userβs installed toolchain as authoritative, but there's a fairly high chance Apple's *documentation* about the APIs will be stale, so treat them carefully.\n\n\n## Output Format\n\nIf the user asks for a review, organize findings by file. For each issue:\n\n1. State the file and relevant line(s).\n2. Name the rule being violated.\n3. Show a brief before/after code fix.\n\nSkip files with no issues. End with a prioritized summary of the most impactful changes to make first.\n\nIf the user asks you to write or improve tests, follow the same rules above but make the changes directly instead of returning a findings report.\n\nExample output:\n\n### UserTests.swift\n\n**Line 5: Use struct, not class, for test suites.**\n\n```swift\n// Before\nclass UserTests: XCTestCase {\n\n// After\nstruct UserTests {\n```\n\n**Line 12: Use `#expect` instead of `XCTAssertEqual`.**\n\n```swift\n// Before\nXCTAssertEqual(user.name, \"Taylor\")\n\n// After\n#expect(user.name == \"Taylor\")\n```\n\n**Line 30: Use `#require` for preconditions, not `#expect`.**\n\n```swift\n// Before\n#expect(users.isEmpty == false)\nlet first = users.first!\n\n// After\nlet first = try #require(users.first)\n```\n\n### Summary\n\n1. **Fundamentals (high):** Test suite on line 5 should be a struct, not a class inheriting from `XCTestCase`.\n2. **Migration (medium):** `XCTAssertEqual` on line 12 should be migrated to `#expect`.\n3. **Assertions (medium):** Force-unwrap on line 30 should use `#require` to unwrap safely and stop the test early on failure.\n\nEnd of example.\n\n\n## References\n\n- `references/core-rules.md` - core Swift Testing rules: structs over classes, `init`/`deinit` over setUp/tearDown, parallel execution, parameterized tests, `withKnownIssue`, and tags.\n- `references/writing-better-tests.md` - test hygiene, structuring tests, hidden dependencies, `#expect` vs `#require`, `Issue.record()`, `#expect(throws:)`, and verification methods.\n- `references/async-tests.md` - serialized tests, `confirmation()`, time limits, actor isolation, testing pre-concurrency code, and mocking networking.\n- `references/new-features.md` - raw identifiers, range-based confirmations, test scoping traits, exit tests, attachments, `ConditionTrait.evaluate()`, and the updated `#expect(throws:)` return value.\n- `references/migrating-from-xctest.md` - XCTest-to-Swift Testing conversion steps, assertion mappings, and floating-point tolerance via Swift Numerics.\n","doc/skills/app-store-review/README.md":"# App Store Review Guidelines Skill\n\nAn AI agent skill that exhaustively evaluates iOS, macOS, tvOS, watchOS, and visionOS app code against **every point** in Apple's App Store Review Guidelines.\n\n**Supports:** Swift, Objective-C, **React Native**, and **Expo** apps\n\n**Current through:** Apple's official June 8, 2026 App Review Guidelines update\n\n## Installation\n\n### Codex\n\nAdd this repository as a Codex plugin marketplace:\n\n```bash\ncodex plugin marketplace add safaiyeh/app-store-review-skill\n```\n\nThen open Codex, run `/plugins`, choose the App Store Review marketplace, and install the `app-store-review` plugin. Start a new thread and invoke the skill with `$app-store-review` or ask for an App Store compliance review.\n\nCodex also discovers direct local skills from `~/.agents/skills`, but plugins are the recommended distribution path for reusable skills.\n\n### Claude Code Plugin Marketplace\n\n```bash\n/plugin marketplace add safaiyeh/app-store-review-skill\n/plugin install app-store-review@app-store-review\n```\n\n### skills.sh\n\n```bash\nnpx skills add safaiyeh/app-store-review-skill\n```\n\n## Setup\n\n### Supported AI Agents\n\nThis skill works with Codex and AI coding agents that support the skills.sh standard:\n\n- [Codex](https://openai.com/codex/)\n- [Claude Code](https://claude.ai/code)\n- [Cursor](https://cursor.sh)\n- [Windsurf](https://codeium.com/windsurf)\n- And other compatible agents\n\n### How It Works\n\n1. **Install the skill** in your project using the command above\n2. **Start your AI agent** in the project directory\n3. **Ask for an App Store review** - the agent will automatically load relevant guidelines\n4. **Review the findings** - the agent identifies potential rejection issues with code references\n\n### Example Prompts\n\n```\n\"Review this app for App Store compliance\"\n\"Check if my IAP implementation follows Apple's guidelines\"\n\"Audit the privacy and data collection in this React Native app\"\n\"What App Store issues might block my submission?\"\n```\n\n### Telemetry\n\nThe skills CLI collects anonymous usage telemetry. To opt out:\n\n```bash\nSKILLS_NO_TELEMETRY=1 npx skills add safaiyeh/app-store-review-skill\n```\n\n## Structure\n\n```\napp-store-review-skill/\nβββ .agents/\nβ βββ plugins/marketplace.json # Codex plugin marketplace\nβββ .claude-plugin/\nβ βββ marketplace.json # Claude Code plugin marketplace\nβ βββ plugin.json # Claude Code plugin manifest\nβββ .codex-plugin/\nβ βββ plugin.json # Codex plugin manifest\nβββ agents/\nβ βββ openai.yaml # Codex UI metadata\nβββ SKILL.md # Index with quick reference & checklist\nβββ rules/\n βββ 1-safety.md # Section 1: Safety guidelines\n βββ 2-performance.md # Section 2: Performance guidelines\n βββ 3-business.md # Section 3: Business guidelines\n βββ 4-design.md # Section 4: Design guidelines\n βββ 5-legal.md # Section 5: Legal guidelines\n```\n\n## Coverage\n\nThis skill covers **ALL 5 major sections** with **EVERY guideline point**:\n\n### [1. Safety](rules/1-safety.md)\n- 1.1 Objectionable Content (1.1.1-1.1.7)\n- 1.2 User-Generated Content & Creator Content\n- 1.3 Kids Category (parental gates, privacy, analytics)\n- 1.4 Physical Harm (medical apps, drug dosage, substances)\n- 1.5 Developer Information\n- 1.6 Data Security\n- 1.7 Reporting Criminal Activity\n\n### [2. Performance](rules/2-performance.md)\n- 2.1 App Completeness (final versions, IAP)\n- 2.2 Beta Testing\n- 2.3 Accurate Metadata (2.3.1-2.3.13)\n- 2.4 Hardware Compatibility (2.4.1-2.4.5)\n- 2.5 Software Requirements (2.5.1-2.5.18)\n\n### [3. Business](rules/3-business.md)\n- 3.1 Payments (IAP, subscriptions, external links, crypto)\n- 3.1.1-3.1.5 In-App Purchase rules\n- 3.2 Other Business Models (acceptable/unacceptable)\n\n### [4. Design](rules/4-design.md)\n- 4.1 Copycats\n- 4.2 Minimum Functionality\n- 4.3 Spam\n- 4.4 Extensions (keyboard, Safari)\n- 4.5 Apple Sites and Services\n- 4.7 Mini Apps, Chatbots, Game Emulators\n- 4.8 Login Services\n- 4.9 Apple Pay\n- 4.10 Monetizing Built-In Capabilities\n\n### [5. Legal](rules/5-legal.md)\n- 5.1 Privacy (data collection, use, sharing, health, kids, location)\n- 5.2 Intellectual Property\n- 5.3 Gaming, Gambling, Lotteries\n- 5.4 VPN Apps\n- 5.5 Mobile Device Management\n- 5.6 Developer Code of Conduct (reviews, developer identity, discovery fraud, app quality)\n\n## Features\n\n- **Modular structure** - Agent loads only relevant sections\n- **2000+ lines** of comprehensive guidelines\n- **Checklists** for every guideline point\n- **Code patterns** for Swift AND React Native/Expo\n- **Package references** for both Expo and bare React Native\n- **Quick reference** for high-risk rejection patterns\n- **Pre-submission checklist** in main SKILL.md\n\n## React Native / Expo Support\n\nEach rule file includes:\n- TypeScript/JavaScript code patterns to flag\n- Expo package recommendations (preferred)\n- Bare React Native package alternatives\n- React Native-specific checklists\n\nKey packages covered:\n- `react-native-purchases` (RevenueCat β recommended for IAP) / `react-native-iap`\n- `expo-tracking-transparency` / `react-native-tracking-transparency`\n- `expo-secure-store` / `react-native-keychain`\n- `expo-apple-authentication` / `@invertase/react-native-apple-authentication`\n- `expo-local-authentication` / `react-native-biometrics`\n\n## What It Checks\n\n### Critical Issues (Immediate Rejection)\n- Private API usage\n- Hardcoded secrets/credentials\n- External payment for digital goods\n- On-device cryptocurrency mining\n- Dynamic code execution\n\n### High-Risk Issues\n- Missing App Tracking Transparency\n- Account creation without deletion\n- IAP without restore purchases\n- UGC without moderation\n- UGC without removal workflows or a compliance improvement plan\n- Kids apps without parental gates\n- Live Activities or push notifications used for spam, phishing, or unsolicited messages\n\n### Medium-Risk Issues\n- Vague purpose strings\n- Over-requesting permissions\n- Unjustified background modes\n- References to other platforms\n- Custom review prompts instead of the system API\n\n## When It Triggers\n\nThe skill activates when working on:\n- App Store submission preparation\n- Code compliance review\n- Payment/StoreKit implementation\n- Privacy and data handling\n- User-generated content features\n- Kids Category apps\n- Health/medical apps\n- VPN/MDM apps\n- Gambling/lottery apps\n\n## License\n\nMIT\n","ARCHITECTURE.md":"# OnlySwitch Architecture\n\n## Purpose\n\nOnlySwitch is a macOS menu-bar utility that exposes system switches, widgets, an optional desktop pet, an AI assistant, and remote control capabilities. The repository also contains reusable Swift Package modules, a widget target, a remote app, persistence, networking, authentication, and OpenClaw integration.\n\n## Core constraints\n\n1. **Use The Composable Architecture (TCA).** Model user-facing features with state, actions, reducers, and effects using [pointfreeco/swift-composable-architecture](https://github.com/pointfreeco/swift-composable-architecture). OnlySwitch already uses TCA in multiple package features; extend that pattern consistently.\n2. **Use `swift-dependencies` for injection.** Runtime services and external effects should be accessed through `@Dependency` using [pointfreeco/swift-dependencies](https://github.com/pointfreeco/swift-dependencies), rather than being constructed directly inside views or reducers. When introducing or migrating a service, add the dependency at the appropriate module boundary.\n3. **Modularize with Swift packages.** Use the `Modules` Swift Package to separate independently buildable and testable functionality. Keep target dependencies intentional and acyclic.\n4. **Factor monolithic logic into focused modules.** Extract switch behavior, feature state, persistence, networking, remote protocol, authentication, AI provider integrations, and presentation concerns into focused modules as boundaries become clear.\n5. **Keep SwiftUI views free of business logic.** Views render state and send user intent. Business rules, validation, orchestration, permissions, shell/AppleScript effects, and state transitions belong in reducers, domain types, or injected clients.\n6. **Follow Swift 6 concurrency safety.** Preserve `Sendable` correctness, actor isolation, structured concurrency, cancellation, and safe crossing of process, networking, persistence, and app/extension boundaries.\n7. **Extract common logic for reuse.** Shared models, remote protocol types, switch descriptors, formatting, validation, persistence adapters, and permission policies should have one well-defined implementation and be reused by the app, widget, remote app, and package targets where appropriate.\n\n## Intended dependency direction\n\n```text\nApp / Widget / Remote app targets\n β\nFeature modules (TCA reducers, feature state, feature views)\n β\nDomain modules (switches, remote protocol, models, business rules)\n β\nInfrastructure modules (system effects, persistence, networking, AI providers, keychain)\n```\n\nInfrastructure details must not leak into SwiftUI views. Feature modules should depend on domain abstractions and access infrastructure through injected dependency clients. Shared protocol and model modules must remain safe for all targets that exchange their values.\n\n## Current repository boundaries\n\n- `Modules/` is the primary Swift Package boundary. It contains feature modules such as `OnlyControl`, `OnlyAgent`, `Authenticator`, `StickerView`, and `DesktopPet`, plus shared `Defines`, `Extensions`, `Utilities`, `Networking`, `RemoteCore`, and `RemoteTransport` modules.\n- `Modules/Sources/Aphrodite` owns the generated mini-app authoring domain, serialized library, TCA feature, and sandboxed renderer. `SettingsVM.shared` retains the Settings store for the app session so accepted work survives presentation changes, while Aphrodite's injected notification boundary requests permission and reports only persistence-confirmed completion; the app delegate owns foreground banner policy. Authoring prompts, conversation history, model selection, and other authoring configuration never cross the `RemoteCore` or `RemoteTransport` boundary; validated runtime HTML, optional validated SVG, and minimal display metadata may cross that boundary for OnlyRemote. Each app persists only its latest HTML and compact completed user prompts; optimistic replacement prevents a stale edit from restoring a deleted or newer app. Six bundled starter apps are merged into the local library once using stable IDs and a persisted seed version, preserving user edits and deletions. Codex reuses a runtime per model and purpose while mapping each Aphrodite conversation to its own thread. Optional icons come from the same model response as static SVG, are validated before storage and native rendering, and fall back to `star.hexagon` when unavailable. Existing libraries without icons or conversation metadata remain readable. The renderer's only native signals are bounded content-size reports from an isolated WebKit content world; the editor keeps an unscaled logical canvas and scales it to fit its preview, while launchers use the content-height signal. Generated page JavaScript cannot access the handler or any native capability.\n- `OnlySwitch/` contains the main macOS application, system integrations, Core Data persistence, audio/player functionality, and app-specific UI. Menu-bar hosts measure active content separately from persistent chrome, then apply the shared `Utilities.AdaptivePanelHeightPolicy` to the hosting screenβs `visibleFrame`. Only Control uses a fixed-size window and keeps overflow scrollable.\n- `OnlyWidget/` contains widget-facing code and must use extension-safe shared models and effects.\n- `OnlySwitchRemote/` contains the remote-control application and must share protocol contracts without importing main-app implementation details. Its root TCA feature owns the independent Aphrodite personal-tools tab and OnlyRemote Plus sheet. Aphrodite access is gated by verified subscription entitlement, with an embedded paywall for nonmembers. Entitlement refresh is independent of product loading and responds to foregrounding, transaction updates, purchases, restoration, and expiration. A Debug-only Settings submenu provides a persisted paywall bypass for development; Release builds ignore this preference. The injected StoreKit client loads and purchases only the one-month `jacklandrin.onlyremote.plus.monthly` auto-renewable product. Only eligible verified transactions unlock access; pending purchases await a later transaction update, and cancellation does not grant access. Recognized verified transactions are finished after processing, and purchase results update both embedded and Settings paywalls without depending on duplicate transaction notifications.\n- `RemoteCore` owns the lightweight, versioned Aphrodite transfer models and the shared HTML and SVG safety validators. Authenticated protocol 1.6 sessions automatically transfer the complete saved library as bounded manifests and 64 KiB chunks with SHA-256 integrity; the wire contract excludes Aphrodite authoring types and private authoring state. OnlyRemote validates each complete transfer before atomically replacing its per-Mac cache, and its WebKit runner uses the same isolated custom origin, content-security policy, and navigation restrictions as the shared sandbox primitives. OnlyRemote lists and runs cached tools but does not create or edit them.\n- Launch Campaign uses an injected TCA client to fetch a bounded manifest and dated HTML from the fixed repository origin. A nonpersistent, navigation-restricted WebKit renderer loads while hidden and acknowledges the date only after successful presentation. The page follows app language and native appearance; its OnlyRemote download link opens the existing native QR window. Both windows temporarily rise above menu-bar panels when presented and return to normal level on focus loss, app deactivation, or closing. Failed requests or rendering remain silent and unacknowledged. Debug builds bypass the previously shown date so the latest page appears on every app launch; forced previews do not modify the saved presentation date.\n- `OnlySwitchTests/`, `OnlySwitchRemoteTests/`, and `Modules/Tests/` contain unit, integration, feature, protocol, and end-to-end coverage.\n- `OpenClaw/skills/onlyswitch-deeplink/` contains the OpenClaw integration documentation and skill for invoking built-in switches through deeplinks.\n\nThe project already uses TCA in package features and Swift Package modularization. New work should extend existing reducer/dependency patterns rather than introduce a parallel state-management approach. `swift-dependencies` is an architectural requirement for new injectable services; existing direct constructions may be migrated incrementally at feature boundaries.\n\n## Feature structure guidance\n\nEach feature should aim to contain:\n\n- a `State` value representing renderable state;\n- an `Action` enum representing user, lifecycle, and dependency-driven events;\n- a reducer that owns transitions and effects;\n- a SwiftUI view that observes state and sends actions;\n- injected clients for clocks, system commands, permissions, persistence, networking, and AI providers;\n- focused tests for business rules, effect behavior, authorization failures, and important edge cases.\n\n## System and remote boundaries\n\nChanges to switches, shell commands, AppleScript, keychain data, Core Data, widgets, remote sessions, or deeplinks must account for:\n\n- macOS authorization and user-cancelled permission flows;\n- command failure, unavailable hardware, unsupported OS versions, and missing executables;\n- secure storage and migration of credentials, pairing data, and provider keys;\n- remote pairing, authentication, encryption, framing, ordering, replay protection, cancellation, and reconnect behavior;\n- widget refresh limits and stale state;\n- process isolation and extension-safe serialization;\n- localization, accessibility, and menu-bar interaction behavior.\n\n## Testing expectations\n\nPrefer deterministic reducer and domain tests with controlled dependencies. Add integration coverage for Core Data, system-effect adapters, remote transport, pairing, and cross-target behavior when reducer tests cannot prove correctness. New concurrency-sensitive code should include tests for cancellation, ordering, actor isolation assumptions, malformed frames, connection loss, and failure propagation where applicable.\n\n","doc/skills/writing-plans/plan-document-reviewer-prompt.md":"# Plan Document Reviewer Prompt Template\n\nUse this template when dispatching a plan document reviewer subagent.\n\n**Purpose:** Verify the plan is complete, matches the spec, and has proper task decomposition.\n\n**Dispatch after:** The complete plan is written.\n\n```\nSubagent (general-purpose):\n description: \"Review plan document\"\n prompt: |\n You are a plan document reviewer. Verify this plan is complete and ready for implementation.\n\n **Plan to review:** [PLAN_FILE_PATH]\n **Spec for reference:** [SPEC_FILE_PATH]\n\n ## What to Check\n\n | Category | What to Look For |\n |----------|------------------|\n | Completeness | TODOs, placeholders, incomplete tasks, missing steps |\n | Spec Alignment | Plan covers spec requirements, no major scope creep |\n | Task Decomposition | Tasks have clear boundaries, steps are actionable |\n | Buildability | Could an engineer follow this plan without getting stuck? |\n\n ## Calibration\n\n **Only flag issues that would cause real problems during implementation.**\n An implementer building the wrong thing or getting stuck is an issue.\n Minor wording, stylistic preferences, and \"nice to have\" suggestions are not.\n\n Approve unless there are serious gaps β missing requirements from the spec,\n contradictory steps, placeholder content, or tasks so vague they can't be acted on.\n\n ## Output Format\n\n ## Plan Review\n\n **Status:** Approved | Issues Found\n\n **Issues (if any):**\n - [Task X, Step Y]: [specific issue] - [why it matters for implementation]\n\n **Recommendations (advisory, do not block approval):**\n - [suggestions for improvement]\n```\n\n**Reviewer returns:** Status, Issues (if any), Recommendations\n","doc/skills/app-store-review/.codex-plugin/plugin.json":"{\n \"name\": \"app-store-review\",\n \"version\": \"1.1.0\",\n \"description\": \"Evaluates code against Apple's App Store Review Guidelines for iOS, macOS, tvOS, watchOS, and visionOS apps.\",\n \"author\": {\n \"name\": \"safaiyeh\",\n \"url\": \"https://github.com/safaiyeh\"\n },\n \"homepage\": \"https://github.com/safaiyeh/app-store-review-skill\",\n \"repository\": \"https://github.com/safaiyeh/app-store-review-skill\",\n \"license\": \"MIT\",\n \"keywords\": [\n \"apple\",\n \"app-store\",\n \"review\",\n \"guidelines\",\n \"ios\",\n \"macos\",\n \"swift\",\n \"react-native\",\n \"expo\"\n ],\n \"skills\": \"./\",\n \"interface\": {\n \"displayName\": \"App Store Review\",\n \"shortDescription\": \"Audit apps for App Store review risk\",\n \"longDescription\": \"Evaluate app code against Apple's App Store Review Guidelines before submission, with coverage for privacy, payments, safety, performance, design, and legal risks.\",\n \"developerName\": \"safaiyeh\",\n \"category\": \"Coding\",\n \"capabilities\": [\n \"Read\"\n ],\n \"websiteURL\": \"https://github.com/safaiyeh/app-store-review-skill\",\n \"defaultPrompt\": [\n \"Review this app for App Store compliance.\"\n ],\n \"brandColor\": \"#0A84FF\"\n }\n}\n","doc/skills/README.md":"# Project Skill Notes\n\nStore project-specific skill supplements, routing notes, and reusable instructions here.\n\nThese files are not loaded automatically. Load a file only when the task matches its stated scope, such as TCA feature design, Swift 6 concurrency, macOS system effects, remote transport, widget integration, App Store review, or test strategy. Each file should begin with a short `When to load` section and should avoid duplicating general guidance that is not needed for the relevant task.\n","doc/skills/app-store-review/.claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `doc/skills/app-store-review/.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/.claude-plugin/marketplace.json)","doc/skills/app-store-review/.claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `doc/skills/app-store-review/.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/.claude-plugin/plugin.json)","doc/skills/app-store-review/agents/openai.yaml":"# Agents Skill\n\nPath: `doc/skills/app-store-review/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/agents/openai.yaml)","doc/skills/app-store-review/rules/1-safety.md":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/1-safety.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/1-safety.md)","doc/skills/app-store-review/rules/2-performance.md":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/2-performance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/2-performance.md)","doc/skills/app-store-review/rules/3-business.md":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/3-business.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/3-business.md)","doc/skills/app-store-review/rules/4-design.md":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/4-design.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/4-design.md)","doc/skills/app-store-review/rules/5-legal.md":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/5-legal.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/5-legal.md)","doc/skills/swift-concurrency-pro/references/actors.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/actors.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/actors.md)","doc/skills/swift-concurrency-pro/references/async-streams.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/async-streams.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/async-streams.md)","doc/skills/swift-concurrency-pro/references/bridging.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/bridging.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/bridging.md)","doc/skills/swift-concurrency-pro/references/bug-patterns.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/bug-patterns.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/bug-patterns.md)","doc/skills/swift-concurrency-pro/references/cancellation.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/cancellation.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/cancellation.md)","doc/skills/swift-concurrency-pro/references/diagnostics.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/diagnostics.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/diagnostics.md)","doc/skills/swift-concurrency-pro/references/hotspots.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/hotspots.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/hotspots.md)","doc/skills/swift-concurrency-pro/references/interop.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/interop.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/interop.md)","doc/skills/swift-concurrency-pro/references/new-features.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/new-features.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/new-features.md)","doc/skills/swift-concurrency-pro/references/structured.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/structured.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/structured.md)","doc/skills/swift-concurrency-pro/references/testing.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/testing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/testing.md)","doc/skills/swift-concurrency-pro/references/unstructured.md":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/unstructured.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/unstructured.md)","doc/skills/swift-concurrency-pro/agents/openai.yaml":"# Agents Skill\n\nPath: `doc/skills/swift-concurrency-pro/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/agents/openai.yaml)","doc/skills/swift-testing-pro/references/async-tests.md":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/async-tests.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/async-tests.md)","doc/skills/swift-testing-pro/references/core-rules.md":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/core-rules.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/core-rules.md)","doc/skills/swift-testing-pro/references/migrating-from-xctest.md":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/migrating-from-xctest.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/migrating-from-xctest.md)","doc/skills/swift-testing-pro/references/new-features.md":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/new-features.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/new-features.md)","doc/skills/swift-testing-pro/references/writing-better-tests.md":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/writing-better-tests.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/writing-better-tests.md)","doc/skills/swift-testing-pro/agents/openai.yaml":"# Agents Skill\n\nPath: `doc/skills/swift-testing-pro/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/agents/openai.yaml)","doc/skills/swiftui-pro/references/accessibility.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/accessibility.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/accessibility.md)","doc/skills/swiftui-pro/references/api.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/api.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/api.md)","doc/skills/swiftui-pro/references/data.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/data.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/data.md)","doc/skills/swiftui-pro/references/design.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/design.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/design.md)","doc/skills/swiftui-pro/references/hygiene.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/hygiene.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/hygiene.md)","doc/skills/swiftui-pro/references/navigation.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/navigation.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/navigation.md)","doc/skills/swiftui-pro/references/performance.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/performance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/performance.md)","doc/skills/swiftui-pro/references/swift.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/swift.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/swift.md)","doc/skills/swiftui-pro/references/views.md":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/views.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/views.md)","doc/skills/swiftui-pro/agents/openai.yaml":"# Agents Skill\n\nPath: `doc/skills/swiftui-pro/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/agents/openai.yaml)","OpenClaw/skills/onlyswitch-deeplink/references/switch-ids.md":"# References Skill\n\nPath: `OpenClaw/skills/onlyswitch-deeplink/references/switch-ids.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/OpenClaw/skills/onlyswitch-deeplink/references/switch-ids.md)","doc/skills/app-store-review/.agents/plugins/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `doc/skills/app-store-review/.agents/plugins/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/.agents/plugins/marketplace.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# OnlySwitch Agent Guidance\n\nThis file defines the default workflow for changes to the OnlySwitch project. It applies to the macOS app, widgets, remote app, Swift Package modules, tests, OpenClaw integration, and project documentation.\n\n## Workflow\n\nFor every task, follow these steps in order. Each phase is delegated to the named subagent/model, and its output is handed to the next phase:\n\n1. **Identify the task β subagent: 5.6 Luna.** Restate the requested outcome, inspect the relevant project files, and analyze the primary use cases, failure modes, and edge cases. Include impacts on macOS permissions, menu-bar behavior, widgets, remote control, persistence, localization, accessibility, and security when relevant.\n2. **Write the implementation plan β subagent: 5.6 Terra.** Ask the user whether they want an implementation plan written first. When accepted, load the `writing-plans` skill, save the completed plan under `doc/plan/`, and use it as the source of truth while implementing. For small, self-contained changes, the user may choose to proceed without a saved plan.\n3. **Load relevant skills using Context Routing β subagent: 5.6 Luna.** Select only the skills whose routing conditions match the task. Do not load every skill or every skill markdown by default. See [Context Routing](#context-routing).\n4. **Summarize constraints β subagent: 5.6 Luna.** Before changing files, briefly summarize applicable architecture rules, platform/deployment constraints, compatibility requirements, existing conventions, and any assumptions.\n5. **Implement unit tests β subagent: 5.6 Terra.** Ask whether the user wants test-driven development for the task. If yes, write or update tests before production code where practical. If no, still add or update focused regression tests when the risk warrants them. Skip this phase only when tests are not meaningful for the requested change.\n6. **Implement the feature β subagent: 5.6 sol.** Make the smallest coherent change that satisfies the task, following the applicable Context Routing guidance and the saved plan when one exists.\n7. **Review the code β subagent: 5.6 Terra.** Review the implementation and tests for correctness, architecture compliance, edge cases, concurrency safety, permissions/privacy risks, and regressions. Apply or request fixes before reporting completion. Run the narrowest relevant checks, then broader checks when appropriate, and report what changed, what was verified, and any known limitations.\n\nWhen a task is explicitly urgent or the user has already answered one of the workflow questions in the current conversation, do not ask the same question again; carry that decision forward for the task.\n\n## Context Routing\n\nSkills are opt-in by task context. First inspect the task and repository; then load only the matching skill instructions. A skill is not loaded merely because it is available.\n\n| Context or trigger | Load skill guidance when | Do not load when |\n| --- | --- | --- |\n| `swiftui-pro` (`doc/skills/swiftui-pro/SKILL.md`) | Reviewing, designing, or implementing SwiftUI views, view state, navigation, accessibility, animations, or SwiftUI performance | The task does not inspect or change SwiftUI code |\n| `swift-concurrency-pro` (`doc/skills/swift-concurrency-pro/SKILL.md`) | Reviewing, designing, or implementing Swift concurrency, actors, `Sendable`, isolation, async streams, cancellation, or strict-concurrency fixes | The task does not inspect or change concurrency code |\n| `swift-testing-pro` (`doc/skills/swift-testing-pro/SKILL.md`) | Writing, migrating, reviewing, or improving Swift Testing/XCTest code or test strategy | No test code or test strategy is in scope |\n| `app-store-review` (`doc/skills/app-store-review/SKILL.md`) | The user explicitly requests an App Store submission-readiness review | Any macOS app task; App Store constraints are out of scope by default for this project |\n| `writing-plans` (`doc/skills/writing-plans/SKILL.md`) | The user requests a multi-step implementation plan, or the workflow's plan step is accepted | The user declines a plan or the task is small and self-contained |\n\nUse the narrowest applicable skill. If several conditions match, load the smallest set that covers the work and state the selection in the task update. Skill instructions may route to more specific references; follow only those references needed for the current task. For the project-local `writing-plans` skill, always save plans as `doc/plan/YYYY-MM-DD-.md`; this project location overrides any generic default path in the skill.\n\n## Project-specific working rules\n\n- Treat `ARCHITECTURE.md` as the source of truth for architectural constraints.\n- Keep implementation plans in `doc/plan/`. Keep reusable skill notes, routing supplements, and project-specific skill instructions in `doc/skills/`.\n- Keep business logic out of SwiftUI views. Move state transitions, validation, orchestration, and side effects into TCA reducers, domain types, or injected clients.\n- Preserve the boundaries between the macOS app, widget extension, remote app, and reusable Swift Package modules.\n- Prefer focused, composable modules and reusable abstractions over expanding monolithic files.\n- Maintain Swift 6 concurrency safety, including explicit sendability and actor isolation at networking, persistence, and process-boundary crossings.\n- Treat shell commands, Apple Events, keychain access, system settings, and user permissions as security-sensitive effects that require explicit dependencies and testable failure handling.\n- Do not evaluate macOS app changes against App Store constraints unless the user explicitly requests an App Store submission-readiness review.\n- Design new or substantially changed UI with modern platform styling, adopting Liquid Glass where supported, providing compatible fallbacks, supporting light and dark modes, and adapting layouts for macOS, iPhone, and iPad sizes as applicable.\n- Translate every new user-facing string into every language supported by OnlySwitch; do not ship newly added source-only strings.\n- Avoid unrelated formatting or refactoring. Update documentation when a change alters an architectural decision or workflow.\n","isInternal":false,"tokens":1263,"sizeBytes":6218},{"name":"ARCHITECTURE.md","path":"ARCHITECTURE.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/ARCHITECTURE.md","title":"System Architecture & Module Boundaries","category":"project-spec","format":"markdown","content":"# OnlySwitch Architecture\n\n## Purpose\n\nOnlySwitch is a macOS menu-bar utility that exposes system switches, widgets, an optional desktop pet, an AI assistant, and remote control capabilities. The repository also contains reusable Swift Package modules, a widget target, a remote app, persistence, networking, authentication, and OpenClaw integration.\n\n## Core constraints\n\n1. **Use The Composable Architecture (TCA).** Model user-facing features with state, actions, reducers, and effects using [pointfreeco/swift-composable-architecture](https://github.com/pointfreeco/swift-composable-architecture). OnlySwitch already uses TCA in multiple package features; extend that pattern consistently.\n2. **Use `swift-dependencies` for injection.** Runtime services and external effects should be accessed through `@Dependency` using [pointfreeco/swift-dependencies](https://github.com/pointfreeco/swift-dependencies), rather than being constructed directly inside views or reducers. When introducing or migrating a service, add the dependency at the appropriate module boundary.\n3. **Modularize with Swift packages.** Use the `Modules` Swift Package to separate independently buildable and testable functionality. Keep target dependencies intentional and acyclic.\n4. **Factor monolithic logic into focused modules.** Extract switch behavior, feature state, persistence, networking, remote protocol, authentication, AI provider integrations, and presentation concerns into focused modules as boundaries become clear.\n5. **Keep SwiftUI views free of business logic.** Views render state and send user intent. Business rules, validation, orchestration, permissions, shell/AppleScript effects, and state transitions belong in reducers, domain types, or injected clients.\n6. **Follow Swift 6 concurrency safety.** Preserve `Sendable` correctness, actor isolation, structured concurrency, cancellation, and safe crossing of process, networking, persistence, and app/extension boundaries.\n7. **Extract common logic for reuse.** Shared models, remote protocol types, switch descriptors, formatting, validation, persistence adapters, and permission policies should have one well-defined implementation and be reused by the app, widget, remote app, and package targets where appropriate.\n\n## Intended dependency direction\n\n```text\nApp / Widget / Remote app targets\n β\nFeature modules (TCA reducers, feature state, feature views)\n β\nDomain modules (switches, remote protocol, models, business rules)\n β\nInfrastructure modules (system effects, persistence, networking, AI providers, keychain)\n```\n\nInfrastructure details must not leak into SwiftUI views. Feature modules should depend on domain abstractions and access infrastructure through injected dependency clients. Shared protocol and model modules must remain safe for all targets that exchange their values.\n\n## Current repository boundaries\n\n- `Modules/` is the primary Swift Package boundary. It contains feature modules such as `OnlyControl`, `OnlyAgent`, `Authenticator`, `StickerView`, and `DesktopPet`, plus shared `Defines`, `Extensions`, `Utilities`, `Networking`, `RemoteCore`, and `RemoteTransport` modules.\n- `Modules/Sources/Aphrodite` owns the generated mini-app authoring domain, serialized library, TCA feature, and sandboxed renderer. `SettingsVM.shared` retains the Settings store for the app session so accepted work survives presentation changes, while Aphrodite's injected notification boundary requests permission and reports only persistence-confirmed completion; the app delegate owns foreground banner policy. Authoring prompts, conversation history, model selection, and other authoring configuration never cross the `RemoteCore` or `RemoteTransport` boundary; validated runtime HTML, optional validated SVG, and minimal display metadata may cross that boundary for OnlyRemote. Each app persists only its latest HTML and compact completed user prompts; optimistic replacement prevents a stale edit from restoring a deleted or newer app. Six bundled starter apps are merged into the local library once using stable IDs and a persisted seed version, preserving user edits and deletions. Codex reuses a runtime per model and purpose while mapping each Aphrodite conversation to its own thread. Optional icons come from the same model response as static SVG, are validated before storage and native rendering, and fall back to `star.hexagon` when unavailable. Existing libraries without icons or conversation metadata remain readable. The renderer's only native signals are bounded content-size reports from an isolated WebKit content world; the editor keeps an unscaled logical canvas and scales it to fit its preview, while launchers use the content-height signal. Generated page JavaScript cannot access the handler or any native capability.\n- `OnlySwitch/` contains the main macOS application, system integrations, Core Data persistence, audio/player functionality, and app-specific UI. Menu-bar hosts measure active content separately from persistent chrome, then apply the shared `Utilities.AdaptivePanelHeightPolicy` to the hosting screenβs `visibleFrame`. Only Control uses a fixed-size window and keeps overflow scrollable.\n- `OnlyWidget/` contains widget-facing code and must use extension-safe shared models and effects.\n- `OnlySwitchRemote/` contains the remote-control application and must share protocol contracts without importing main-app implementation details. Its root TCA feature owns the independent Aphrodite personal-tools tab and OnlyRemote Plus sheet. Aphrodite access is gated by verified subscription entitlement, with an embedded paywall for nonmembers. Entitlement refresh is independent of product loading and responds to foregrounding, transaction updates, purchases, restoration, and expiration. A Debug-only Settings submenu provides a persisted paywall bypass for development; Release builds ignore this preference. The injected StoreKit client loads and purchases only the one-month `jacklandrin.onlyremote.plus.monthly` auto-renewable product. Only eligible verified transactions unlock access; pending purchases await a later transaction update, and cancellation does not grant access. Recognized verified transactions are finished after processing, and purchase results update both embedded and Settings paywalls without depending on duplicate transaction notifications.\n- `RemoteCore` owns the lightweight, versioned Aphrodite transfer models and the shared HTML and SVG safety validators. Authenticated protocol 1.6 sessions automatically transfer the complete saved library as bounded manifests and 64 KiB chunks with SHA-256 integrity; the wire contract excludes Aphrodite authoring types and private authoring state. OnlyRemote validates each complete transfer before atomically replacing its per-Mac cache, and its WebKit runner uses the same isolated custom origin, content-security policy, and navigation restrictions as the shared sandbox primitives. OnlyRemote lists and runs cached tools but does not create or edit them.\n- Launch Campaign uses an injected TCA client to fetch a bounded manifest and dated HTML from the fixed repository origin. A nonpersistent, navigation-restricted WebKit renderer loads while hidden and acknowledges the date only after successful presentation. The page follows app language and native appearance; its OnlyRemote download link opens the existing native QR window. Both windows temporarily rise above menu-bar panels when presented and return to normal level on focus loss, app deactivation, or closing. Failed requests or rendering remain silent and unacknowledged. Debug builds bypass the previously shown date so the latest page appears on every app launch; forced previews do not modify the saved presentation date.\n- `OnlySwitchTests/`, `OnlySwitchRemoteTests/`, and `Modules/Tests/` contain unit, integration, feature, protocol, and end-to-end coverage.\n- `OpenClaw/skills/onlyswitch-deeplink/` contains the OpenClaw integration documentation and skill for invoking built-in switches through deeplinks.\n\nThe project already uses TCA in package features and Swift Package modularization. New work should extend existing reducer/dependency patterns rather than introduce a parallel state-management approach. `swift-dependencies` is an architectural requirement for new injectable services; existing direct constructions may be migrated incrementally at feature boundaries.\n\n## Feature structure guidance\n\nEach feature should aim to contain:\n\n- a `State` value representing renderable state;\n- an `Action` enum representing user, lifecycle, and dependency-driven events;\n- a reducer that owns transitions and effects;\n- a SwiftUI view that observes state and sends actions;\n- injected clients for clocks, system commands, permissions, persistence, networking, and AI providers;\n- focused tests for business rules, effect behavior, authorization failures, and important edge cases.\n\n## System and remote boundaries\n\nChanges to switches, shell commands, AppleScript, keychain data, Core Data, widgets, remote sessions, or deeplinks must account for:\n\n- macOS authorization and user-cancelled permission flows;\n- command failure, unavailable hardware, unsupported OS versions, and missing executables;\n- secure storage and migration of credentials, pairing data, and provider keys;\n- remote pairing, authentication, encryption, framing, ordering, replay protection, cancellation, and reconnect behavior;\n- widget refresh limits and stale state;\n- process isolation and extension-safe serialization;\n- localization, accessibility, and menu-bar interaction behavior.\n\n## Testing expectations\n\nPrefer deterministic reducer and domain tests with controlled dependencies. Add integration coverage for Core Data, system-effect adapters, remote transport, pairing, and cross-target behavior when reducer tests cannot prove correctness. New concurrency-sensitive code should include tests for cancellation, ordering, actor isolation assumptions, malformed frames, connection loss, and failure propagation where applicable.\n\n","isInternal":false,"tokens":1878,"sizeBytes":10090},{"name":"openai.yaml","path":"doc/skills/app-store-review/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `doc/skills/app-store-review/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/agents/openai.yaml)","tokens":300,"sizeBytes":210},{"name":"README.md","path":"doc/skills/app-store-review/README.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/README.md","title":"App-store-review Skill","category":"anthropic-skill","format":"markdown","content":"# App Store Review Guidelines Skill\n\nAn AI agent skill that exhaustively evaluates iOS, macOS, tvOS, watchOS, and visionOS app code against **every point** in Apple's App Store Review Guidelines.\n\n**Supports:** Swift, Objective-C, **React Native**, and **Expo** apps\n\n**Current through:** Apple's official June 8, 2026 App Review Guidelines update\n\n## Installation\n\n### Codex\n\nAdd this repository as a Codex plugin marketplace:\n\n```bash\ncodex plugin marketplace add safaiyeh/app-store-review-skill\n```\n\nThen open Codex, run `/plugins`, choose the App Store Review marketplace, and install the `app-store-review` plugin. Start a new thread and invoke the skill with `$app-store-review` or ask for an App Store compliance review.\n\nCodex also discovers direct local skills from `~/.agents/skills`, but plugins are the recommended distribution path for reusable skills.\n\n### Claude Code Plugin Marketplace\n\n```bash\n/plugin marketplace add safaiyeh/app-store-review-skill\n/plugin install app-store-review@app-store-review\n```\n\n### skills.sh\n\n```bash\nnpx skills add safaiyeh/app-store-review-skill\n```\n\n## Setup\n\n### Supported AI Agents\n\nThis skill works with Codex and AI coding agents that support the skills.sh standard:\n\n- [Codex](https://openai.com/codex/)\n- [Claude Code](https://claude.ai/code)\n- [Cursor](https://cursor.sh)\n- [Windsurf](https://codeium.com/windsurf)\n- And other compatible agents\n\n### How It Works\n\n1. **Install the skill** in your project using the command above\n2. **Start your AI agent** in the project directory\n3. **Ask for an App Store review** - the agent will automatically load relevant guidelines\n4. **Review the findings** - the agent identifies potential rejection issues with code references\n\n### Example Prompts\n\n```\n\"Review this app for App Store compliance\"\n\"Check if my IAP implementation follows Apple's guidelines\"\n\"Audit the privacy and data collection in this React Native app\"\n\"What App Store issues might block my submission?\"\n```\n\n### Telemetry\n\nThe skills CLI collects anonymous usage telemetry. To opt out:\n\n```bash\nSKILLS_NO_TELEMETRY=1 npx skills add safaiyeh/app-store-review-skill\n```\n\n## Structure\n\n```\napp-store-review-skill/\nβββ .agents/\nβ βββ plugins/marketplace.json # Codex plugin marketplace\nβββ .claude-plugin/\nβ βββ marketplace.json # Claude Code plugin marketplace\nβ βββ plugin.json # Claude Code plugin manifest\nβββ .codex-plugin/\nβ βββ plugin.json # Codex plugin manifest\nβββ agents/\nβ βββ openai.yaml # Codex UI metadata\nβββ SKILL.md # Index with quick reference & checklist\nβββ rules/\n βββ 1-safety.md # Section 1: Safety guidelines\n βββ 2-performance.md # Section 2: Performance guidelines\n βββ 3-business.md # Section 3: Business guidelines\n βββ 4-design.md # Section 4: Design guidelines\n βββ 5-legal.md # Section 5: Legal guidelines\n```\n\n## Coverage\n\nThis skill covers **ALL 5 major sections** with **EVERY guideline point**:\n\n### [1. Safety](rules/1-safety.md)\n- 1.1 Objectionable Content (1.1.1-1.1.7)\n- 1.2 User-Generated Content & Creator Content\n- 1.3 Kids Category (parental gates, privacy, analytics)\n- 1.4 Physical Harm (medical apps, drug dosage, substances)\n- 1.5 Developer Information\n- 1.6 Data Security\n- 1.7 Reporting Criminal Activity\n\n### [2. Performance](rules/2-performance.md)\n- 2.1 App Completeness (final versions, IAP)\n- 2.2 Beta Testing\n- 2.3 Accurate Metadata (2.3.1-2.3.13)\n- 2.4 Hardware Compatibility (2.4.1-2.4.5)\n- 2.5 Software Requirements (2.5.1-2.5.18)\n\n### [3. Business](rules/3-business.md)\n- 3.1 Payments (IAP, subscriptions, external links, crypto)\n- 3.1.1-3.1.5 In-App Purchase rules\n- 3.2 Other Business Models (acceptable/unacceptable)\n\n### [4. Design](rules/4-design.md)\n- 4.1 Copycats\n- 4.2 Minimum Functionality\n- 4.3 Spam\n- 4.4 Extensions (keyboard, Safari)\n- 4.5 Apple Sites and Services\n- 4.7 Mini Apps, Chatbots, Game Emulators\n- 4.8 Login Services\n- 4.9 Apple Pay\n- 4.10 Monetizing Built-In Capabilities\n\n### [5. Legal](rules/5-legal.md)\n- 5.1 Privacy (data collection, use, sharing, health, kids, location)\n- 5.2 Intellectual Property\n- 5.3 Gaming, Gambling, Lotteries\n- 5.4 VPN Apps\n- 5.5 Mobile Device Management\n- 5.6 Developer Code of Conduct (reviews, developer identity, discovery fraud, app quality)\n\n## Features\n\n- **Modular structure** - Agent loads only relevant sections\n- **2000+ lines** of comprehensive guidelines\n- **Checklists** for every guideline point\n- **Code patterns** for Swift AND React Native/Expo\n- **Package references** for both Expo and bare React Native\n- **Quick reference** for high-risk rejection patterns\n- **Pre-submission checklist** in main SKILL.md\n\n## React Native / Expo Support\n\nEach rule file includes:\n- TypeScript/JavaScript code patterns to flag\n- Expo package recommendations (preferred)\n- Bare React Native package alternatives\n- React Native-specific checklists\n\nKey packages covered:\n- `react-native-purchases` (RevenueCat β recommended for IAP) / `react-native-iap`\n- `expo-tracking-transparency` / `react-native-tracking-transparency`\n- `expo-secure-store` / `react-native-keychain`\n- `expo-apple-authentication` / `@invertase/react-native-apple-authentication`\n- `expo-local-authentication` / `react-native-biometrics`\n\n## What It Checks\n\n### Critical Issues (Immediate Rejection)\n- Private API usage\n- Hardcoded secrets/credentials\n- External payment for digital goods\n- On-device cryptocurrency mining\n- Dynamic code execution\n\n### High-Risk Issues\n- Missing App Tracking Transparency\n- Account creation without deletion\n- IAP without restore purchases\n- UGC without moderation\n- UGC without removal workflows or a compliance improvement plan\n- Kids apps without parental gates\n- Live Activities or push notifications used for spam, phishing, or unsolicited messages\n\n### Medium-Risk Issues\n- Vague purpose strings\n- Over-requesting permissions\n- Unjustified background modes\n- References to other platforms\n- Custom review prompts instead of the system API\n\n## When It Triggers\n\nThe skill activates when working on:\n- App Store submission preparation\n- Code compliance review\n- Payment/StoreKit implementation\n- Privacy and data handling\n- User-generated content features\n- Kids Category apps\n- Health/medical apps\n- VPN/MDM apps\n- Gambling/lottery apps\n\n## License\n\nMIT\n","isInternal":false,"tokens":1629,"sizeBytes":6491},{"name":"1-safety.md","path":"doc/skills/app-store-review/rules/1-safety.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/1-safety.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/1-safety.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/1-safety.md)","tokens":300,"sizeBytes":207},{"name":"2-performance.md","path":"doc/skills/app-store-review/rules/2-performance.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/2-performance.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/2-performance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/2-performance.md)","tokens":300,"sizeBytes":217},{"name":"3-business.md","path":"doc/skills/app-store-review/rules/3-business.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/3-business.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/3-business.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/3-business.md)","tokens":300,"sizeBytes":211},{"name":"4-design.md","path":"doc/skills/app-store-review/rules/4-design.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/4-design.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/4-design.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/4-design.md)","tokens":300,"sizeBytes":207},{"name":"5-legal.md","path":"doc/skills/app-store-review/rules/5-legal.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/5-legal.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/5-legal.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/5-legal.md)","tokens":300,"sizeBytes":205},{"name":"SKILL.md","path":"doc/skills/app-store-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/SKILL.md","title":"app-store-review","category":"anthropic-skill","format":"markdown","content":"---\nname: app-store-review\ndescription: Evaluates code against Apple's App Store Review Guidelines. Use this skill when reviewing iOS, macOS, tvOS, watchOS, or visionOS app code (Swift, Objective-C, React Native, or Expo) to identify potential App Store rejection issues before submission. Triggers on tasks involving app review preparation, compliance checking, or App Store submission readiness.\nlicense: MIT\nmetadata:\n author: safaiyeh\n version: \"1.1.0\"\n---\n\n# App Store Review Guidelines Checker\n\nComprehensive guide for evaluating iOS, macOS, tvOS, watchOS, and visionOS app code against Apple's App Store Review Guidelines. This skill covers EVERY guideline point to identify potential rejection issues before submission.\n\n**Supports:** Swift, Objective-C, React Native, and Expo apps\n\n**Guidelines current through:** Apple's June 8, 2026 App Review Guidelines update.\n\n## When to Apply\n\nUse this skill when:\n- Preparing an app for App Store submission\n- Reviewing code for compliance issues\n- Implementing features that may trigger review concerns\n- Auditing existing apps for guideline violations\n- Building features involving payments, user data, or sensitive content\n\n## Guideline Sections\n\nRead individual rule files for detailed explanations, checklists, and code examples:\n\n| Section | File | Key Topics |\n|---------|------|------------|\n| **1. Safety** | [rules/1-safety.md](rules/1-safety.md) | Objectionable content, UGC moderation, Kids Category, physical harm, data security |\n| **2. Performance** | [rules/2-performance.md](rules/2-performance.md) | App completeness, metadata accuracy, hardware compatibility, software requirements |\n| **3. Business** | [rules/3-business.md](rules/3-business.md) | In-app purchase, subscriptions, cryptocurrencies, other business models |\n| **4. Design** | [rules/4-design.md](rules/4-design.md) | Copycats, minimum functionality, spam, extensions, Apple services, login |\n| **5. Legal** | [rules/5-legal.md](rules/5-legal.md) | Privacy, data collection, intellectual property, gambling, VPN, MDM, developer code of conduct |\n\n## Risk Levels by Category\n\n| Risk Level | Category | Section | Common Rejection Reasons |\n|------------|----------|---------|--------------------------|\n| CRITICAL | Privacy & Data | 5.1 | Missing privacy policy, unauthorized data collection |\n| CRITICAL | Payments | 3.1 | Bypassing in-app purchase, unclear pricing |\n| HIGH | Safety | 1.x | Objectionable content, inadequate UGC moderation |\n| HIGH | Performance | 2.x | Crashes, incomplete features, deprecated APIs |\n| MEDIUM | Design | 4.x | Copycat apps, minimum functionality issues |\n| MEDIUM | Legal | 5.x | IP violations, gambling without license |\n\n---\n\n## Quick Reference: High-Risk Rejection Patterns\n\n### Critical Issues (Immediate Rejection)\n\n**Swift:**\n```swift\n// π΄ Private API usage\nlet selector = NSSelectorFromString(\"_privateMethod\")\n\n// π΄ Hardcoded secrets\nlet apiKey = \"sk_live_xxxxx\"\n\n// π΄ External payment for digital goods\nfunc purchaseDigitalContent() {\n openStripeCheckout() // Use StoreKit instead\n}\n```\n\n**React Native / Expo:**\n```typescript\n// π΄ Hardcoded secrets in JS bundle\nconst API_KEY = 'sk_live_xxxxx'; // REJECTION\n\n// π΄ External payment for digital goods\nLinking.openURL('https://stripe.com/checkout'); // Use react-native-iap\n\n// π΄ Dynamic code execution\neval(downloadedCode); // REJECTION\n\n// π΄ Major feature changes via CodePush/expo-updates\n// OTA updates for bug fixes only, not new features!\n```\n\n### High-Risk Issues\n\n**Swift:**\n```swift\n// π‘ Missing ATT when using ad SDKs\nimport FacebookAds // Without ATTrackingManager\n\n// π‘ Account creation without deletion\nfunc createAccount() { } // But no deleteAccount()\n```\n\n**React Native / Expo:**\n```typescript\n// π‘ Missing ATT (use expo-tracking-transparency)\nimport analytics from '@react-native-firebase/analytics';\nanalytics().logEvent('event'); // Without ATT prompt = REJECTION\n\n// π‘ Account deletion via website only\nLinking.openURL('https://example.com/delete'); // Must be in-app!\n\n// π‘ Social login without a privacy-preserving alternative (4.8)\n // Also offer a login meeting 4.8 criteria\n // (Sign in with Apple is the simplest option)\n\n// π‘ Custom review prompts (5.6.1)\nshowCustomAlert('Rate us 5 stars!'); // Use StoreReview.requestReview()\n```\n\n### Medium-Risk Issues\n\n```typescript\n// π Vague purpose strings in Info.plist\n\"This app needs camera access\" // Be specific!\n\n// π WebView-only app (insufficient native functionality)\nconst App = () => ;\n\n// π References to Android in iOS app\nconst text = \"Also available on Android\"; // REJECTION\n\n// π console.log in production\nconsole.log('debug'); // Remove or wrap in __DEV__\n```\n\n---\n\n## Pre-Submission Checklist\n\n### Privacy (Section 5.1)\n- [ ] Privacy policy link in App Store Connect\n- [ ] Privacy policy link accessible within app\n- [ ] All purpose strings are specific and accurate\n- [ ] App Privacy details completed in App Store Connect\n- [ ] ATT implemented if tracking users\n- [ ] Account deletion available if accounts exist\n- [ ] Data minimization - only requesting necessary permissions\n- [ ] User consent obtained before data collection\n\n### Payments (Section 3.1)\n- [ ] StoreKit used for all digital purchases\n- [ ] Restore purchases implemented\n- [ ] Subscription terms clearly displayed\n- [ ] Loot box odds disclosed if applicable\n- [ ] No external payment for digital goods (unless entitled)\n- [ ] Credits/currencies don't expire\n\n### Safety (Section 1.x)\n- [ ] No objectionable content\n- [ ] UGC moderation implemented (filter, report, block, contact)\n- [ ] UGC violations can be removed quickly and backed by a remediation plan\n- [ ] Kids and teens receive age-appropriate experiences inside the app\n- [ ] Parental gates for Kids Category apps\n- [ ] No false information or prank features\n- [ ] Medical disclaimers if applicable\n- [ ] No substance promotion\n\n### Performance (Section 2.x)\n- [ ] No crashes or bugs\n- [ ] All features complete and functional\n- [ ] No placeholder content\n- [ ] IPv6 tested and functional\n- [ ] Demo account provided if needed\n- [ ] Using only public APIs\n- [ ] No deprecated APIs\n- [ ] Proper background mode usage\n\n### Design (Section 4.x)\n- [ ] Sufficient native functionality (not just web wrapper)\n- [ ] No copycat concerns\n- [ ] Original app name and branding\n- [ ] No duplicate Bundle ID spam or low-effort saturated-category clones\n- [ ] Live Activities, push notifications, and Game Center are not used for spam, phishing, or unsolicited messages\n- [ ] Extensions comply with guidelines\n- [ ] Login alternatives if using social login\n- [ ] Not monetizing built-in capabilities\n\n### Legal (Section 5.x)\n- [ ] No unlicensed third-party content\n- [ ] Proper Apple trademark usage\n- [ ] Gambling license if applicable (with real location-based geo-restriction)\n- [ ] VPN uses NEVPNManager API\n- [ ] COPPA/GDPR compliance for kids\n- [ ] Review prompts use the system API only (no custom prompts)\n- [ ] No review, chart, search, or referral manipulation (5.6)\n\n---\n\n## References\n\n- [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)\n- [Apple Developer Program License Agreement](https://developer.apple.com/support/terms/apple-developer-program-license-agreement/)\n- [June 8, 2026 App Review Guidelines update](https://developer.apple.com/news/?id=a233fmpw)\n- [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/)\n- [App Store Connect Help](https://developer.apple.com/help/app-store-connect/)\n- [Apple Developer Documentation](https://developer.apple.com/documentation/)\n","frontmatter":{"name":"app-store-review","description":"Evaluates code against Apple's App Store Review Guidelines. Use this skill when reviewing iOS, macOS, tvOS, watchOS, or visionOS app code (Swift, Objective-C, React Native, or Expo) to identify potential App Store rejection issues before submission. Triggers on tasks involving app review preparation, compliance checking, or App Store submission readiness.","license":"MIT","metadata":{"author":"safaiyeh","version":"1.1.0"}},"isInternal":false,"tokens":1808,"sizeBytes":7743},{"name":"README.md","path":"doc/skills/README.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/README.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Project Skill Notes\n\nStore project-specific skill supplements, routing notes, and reusable instructions here.\n\nThese files are not loaded automatically. Load a file only when the task matches its stated scope, such as TCA feature design, Swift 6 concurrency, macOS system effects, remote transport, widget integration, App Store review, or test strategy. Each file should begin with a short `When to load` section and should avoid duplicating general guidance that is not needed for the relevant task.\n","isInternal":false,"tokens":97,"sizeBytes":504},{"name":"openai.yaml","path":"doc/skills/swift-concurrency-pro/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `doc/skills/swift-concurrency-pro/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/agents/openai.yaml)","tokens":300,"sizeBytes":220},{"name":"actors.md","path":"doc/skills/swift-concurrency-pro/references/actors.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/actors.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/actors.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/actors.md)","tokens":300,"sizeBytes":228},{"name":"async-streams.md","path":"doc/skills/swift-concurrency-pro/references/async-streams.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/async-streams.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/async-streams.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/async-streams.md)","tokens":300,"sizeBytes":242},{"name":"bridging.md","path":"doc/skills/swift-concurrency-pro/references/bridging.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/bridging.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/bridging.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/bridging.md)","tokens":300,"sizeBytes":232},{"name":"bug-patterns.md","path":"doc/skills/swift-concurrency-pro/references/bug-patterns.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/bug-patterns.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/bug-patterns.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/bug-patterns.md)","tokens":300,"sizeBytes":240},{"name":"cancellation.md","path":"doc/skills/swift-concurrency-pro/references/cancellation.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/cancellation.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/cancellation.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/cancellation.md)","tokens":300,"sizeBytes":240},{"name":"diagnostics.md","path":"doc/skills/swift-concurrency-pro/references/diagnostics.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/diagnostics.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/diagnostics.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/diagnostics.md)","tokens":300,"sizeBytes":238},{"name":"hotspots.md","path":"doc/skills/swift-concurrency-pro/references/hotspots.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/hotspots.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/hotspots.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/hotspots.md)","tokens":300,"sizeBytes":232},{"name":"interop.md","path":"doc/skills/swift-concurrency-pro/references/interop.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/interop.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/interop.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/interop.md)","tokens":300,"sizeBytes":230},{"name":"new-features.md","path":"doc/skills/swift-concurrency-pro/references/new-features.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/new-features.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/new-features.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/new-features.md)","tokens":300,"sizeBytes":240},{"name":"structured.md","path":"doc/skills/swift-concurrency-pro/references/structured.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/structured.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/structured.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/structured.md)","tokens":300,"sizeBytes":236},{"name":"testing.md","path":"doc/skills/swift-concurrency-pro/references/testing.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/testing.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/testing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/testing.md)","tokens":300,"sizeBytes":230},{"name":"unstructured.md","path":"doc/skills/swift-concurrency-pro/references/unstructured.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/unstructured.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/unstructured.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/unstructured.md)","tokens":300,"sizeBytes":240},{"name":"SKILL.md","path":"doc/skills/swift-concurrency-pro/SKILL.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/SKILL.md","title":"swift-concurrency-pro","category":"anthropic-skill","format":"markdown","content":"---\nname: swift-concurrency-pro\ndescription: Reviews Swift code for concurrency correctness, modern API usage, and common async/await pitfalls. Use when reading, writing, or reviewing Swift concurrency code.\nlicense: MIT\nmetadata:\n author: Paul Hudson\n version: \"1.0\"\n---\n\nReview Swift concurrency code for correctness, modern API usage, and adherence to project conventions. Report only genuine problems - do not nitpick or invent issues.\n\nReview process:\n\n1. Scan for known-dangerous patterns using `references/hotspots.md` to prioritize what to inspect.\n1. Check for recent Swift 6.2 concurrency behavior using `references/new-features.md`.\n1. Validate actor usage for reentrancy and isolation correctness using `references/actors.md`.\n1. Ensure structured concurrency is preferred over unstructured where appropriate using `references/structured.md`.\n1. Check unstructured task usage for correctness using `references/unstructured.md`.\n1. Verify cancellation is handled correctly using `references/cancellation.md`.\n1. Validate async stream and continuation usage using `references/async-streams.md`.\n1. Check bridging code between sync and async worlds using `references/bridging.md`.\n1. Review any legacy concurrency migrations using `references/interop.md`.\n1. Cross-check against common failure modes using `references/bug-patterns.md`.\n1. If the project has strict-concurrency errors, map diagnostics to fixes using `references/diagnostics.md`.\n1. If reviewing tests, check async test patterns using `references/testing.md`.\n\nIf doing a partial review, load only the relevant reference files.\n\n\n## Core Instructions\n\n- Target Swift 6.2 or later with strict concurrency checking.\n- If code spans multiple targets or packages, compare their concurrency build settings before assuming behavior should match.\n- Prefer structured concurrency (task groups) over unstructured (`Task {}`).\n- Prefer Swift concurrency over Grand Central Dispatch for new code. GCD is still acceptable in low-level code, framework interop, or performance-critical synchronous work where queues and locks are the right tool β don't flag these as errors.\n- If an API offers both `async`/`await` and closure-based variants, always prefer `async`/`await`.\n- Do not introduce third-party concurrency frameworks without asking first.\n- Do not suggest `@unchecked Sendable` to fix compiler errors. It silences the diagnostic without fixing the underlying race. Prefer actors, value types, or `sending` parameters instead. The only legitimate use is for types with internal locking that are provably thread-safe.\n\n\n## Output Format\n\nOrganize findings by file. For each issue:\n\n1. State the file and relevant line(s).\n2. Name the rule being violated.\n3. Show a brief before/after code fix.\n\nSkip files with no issues. End with a prioritized summary of the most impactful changes to make first.\n\nExample output:\n\n### DataLoader.swift\n\n**Line 18: Actor reentrancy β state may have changed across the `await`.**\n\n```swift\n// Before\nactor Cache {\n var items: [String: Data] = [:]\n\n func fetch(_ key: String) async throws -> Data {\n if items[key] == nil {\n items[key] = try await download(key)\n }\n return items[key]!\n }\n}\n\n// After\nactor Cache {\n var items: [String: Data] = [:]\n\n func fetch(_ key: String) async throws -> Data {\n if let existing = items[key] { return existing }\n let data = try await download(key)\n items[key] = data\n return data\n }\n}\n```\n\n**Line 34: Use `withTaskGroup` instead of creating tasks in a loop.**\n\n```swift\n// Before\nfor url in urls {\n Task { try await fetch(url) }\n}\n\n// After\ntry await withThrowingTaskGroup(of: Data.self) { group in\n for url in urls {\n group.addTask { try await fetch(url) }\n }\n\n for try await result in group {\n process(result)\n }\n}\n```\n\n### Summary\n\n1. **Correctness (high):** Actor reentrancy bug on line 18 may cause duplicate downloads and a force-unwrap crash.\n2. **Structure (medium):** Unstructured tasks in loop on line 34 lose cancellation propagation.\n\nEnd of example.\n\n\n## References\n\n- `references/hotspots.md` - Grep targets for code review: known-dangerous patterns and what to check for each.\n- `references/new-features.md` - Swift 6.2 changes that alter review advice: default actor isolation, isolated conformances, caller-actor async behavior, `@concurrent`, `Task.immediate`, task naming, and priority escalation.\n- `references/actors.md` - Actor reentrancy, shared-state annotations, global actor inference, and isolation patterns.\n- `references/structured.md` - Task groups over loops, discarding task groups, concurrency limits.\n- `references/unstructured.md` - Task vs Task.detached, when Task {} is a code smell.\n- `references/cancellation.md` - Cancellation propagation, cooperative checking, broken cancellation patterns.\n- `references/async-streams.md` - AsyncStream factory, continuation lifecycle, back-pressure.\n- `references/bridging.md` - Checked continuations, wrapping legacy APIs, `@unchecked Sendable`.\n- `references/interop.md` - Migrating from GCD, `Mutex`/locks, completion handlers, delegates, and Combine.\n- `references/bug-patterns.md` - Common concurrency failure modes and their fixes.\n- `references/diagnostics.md` - Strict-concurrency compiler errors, protocol conformance fixes, and likely remedies.\n- `references/testing.md` - Async test strategy with Swift Testing, race detection, avoiding timing-based tests.\n","frontmatter":{"name":"swift-concurrency-pro","description":"Reviews Swift code for concurrency correctness, modern API usage, and common async/await pitfalls. Use when reading, writing, or reviewing Swift concurrency code.","license":"MIT","metadata":{"author":"Paul Hudson","version":"1.0"}},"isInternal":false,"tokens":1197,"sizeBytes":5493},{"name":"openai.yaml","path":"doc/skills/swift-testing-pro/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `doc/skills/swift-testing-pro/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/agents/openai.yaml)","tokens":300,"sizeBytes":212},{"name":"async-tests.md","path":"doc/skills/swift-testing-pro/references/async-tests.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/async-tests.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/async-tests.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/async-tests.md)","tokens":300,"sizeBytes":230},{"name":"core-rules.md","path":"doc/skills/swift-testing-pro/references/core-rules.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/core-rules.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/core-rules.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/core-rules.md)","tokens":300,"sizeBytes":228},{"name":"migrating-from-xctest.md","path":"doc/skills/swift-testing-pro/references/migrating-from-xctest.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/migrating-from-xctest.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/migrating-from-xctest.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/migrating-from-xctest.md)","tokens":300,"sizeBytes":250},{"name":"new-features.md","path":"doc/skills/swift-testing-pro/references/new-features.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/new-features.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/new-features.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/new-features.md)","tokens":300,"sizeBytes":232},{"name":"writing-better-tests.md","path":"doc/skills/swift-testing-pro/references/writing-better-tests.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/writing-better-tests.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/writing-better-tests.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/writing-better-tests.md)","tokens":300,"sizeBytes":248},{"name":"SKILL.md","path":"doc/skills/swift-testing-pro/SKILL.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/SKILL.md","title":"swift-testing-pro","category":"anthropic-skill","format":"markdown","content":"---\nname: swift-testing-pro\ndescription: Writes, reviews, and improves Swift Testing code using modern APIs and best practices. Use when reading, writing, or reviewing projects that use Swift Testing.\nlicense: MIT\nmetadata:\n author: Paul Hudson\n version: \"1.0\"\n---\n\nWrite and review Swift Testing code for correctness, modern API usage, and adherence to project conventions. Report only genuine problems - do not nitpick or invent issues.\n\nReview process:\n\n1. Ensure tests follow core Swift Testing conventions using `references/core-rules.md`.\n1. Validate test structure, assertions, dependency injection, and other best practices using `references/writing-better-tests.md`.\n1. Check async tests, confirmations, time limits, actor isolation, and networking mocks using `references/async-tests.md`.\n1. Ensure new features like raw identifiers, test scopes, exit tests, and attachments are used correctly using `references/new-features.md`.\n1. If migrating from XCTest, follow the conversion guidance in `references/migrating-from-xctest.md`.\n\nIf doing partial work, load only the relevant reference files.\n\n\n## Core Instructions\n\n- Target Swift 6.2 or later, using modern Swift concurrency.\n- As a Swift Testing developer, the user wants all new unit and integration tests to be written using Swift Testing, and they may ask for help migrating existing XCTest code to Swift Testing.\n- Swift Testing does *not* support UI tests β XCTest must be used there.\n- Use a consistent project structure, with folder layout determined by app features.\n\nSwift Testing evolves with each Swift release, so expect three to four releases each year, each introducing new features. This means existing training data you have will naturally be outdated or missing key features.\n\nThis skill specifically draws upon the very latest Swift and Swift Testing code, which means it will suggest things you are not aware of. Treat the userβs installed toolchain as authoritative, but there's a fairly high chance Apple's *documentation* about the APIs will be stale, so treat them carefully.\n\n\n## Output Format\n\nIf the user asks for a review, organize findings by file. For each issue:\n\n1. State the file and relevant line(s).\n2. Name the rule being violated.\n3. Show a brief before/after code fix.\n\nSkip files with no issues. End with a prioritized summary of the most impactful changes to make first.\n\nIf the user asks you to write or improve tests, follow the same rules above but make the changes directly instead of returning a findings report.\n\nExample output:\n\n### UserTests.swift\n\n**Line 5: Use struct, not class, for test suites.**\n\n```swift\n// Before\nclass UserTests: XCTestCase {\n\n// After\nstruct UserTests {\n```\n\n**Line 12: Use `#expect` instead of `XCTAssertEqual`.**\n\n```swift\n// Before\nXCTAssertEqual(user.name, \"Taylor\")\n\n// After\n#expect(user.name == \"Taylor\")\n```\n\n**Line 30: Use `#require` for preconditions, not `#expect`.**\n\n```swift\n// Before\n#expect(users.isEmpty == false)\nlet first = users.first!\n\n// After\nlet first = try #require(users.first)\n```\n\n### Summary\n\n1. **Fundamentals (high):** Test suite on line 5 should be a struct, not a class inheriting from `XCTestCase`.\n2. **Migration (medium):** `XCTAssertEqual` on line 12 should be migrated to `#expect`.\n3. **Assertions (medium):** Force-unwrap on line 30 should use `#require` to unwrap safely and stop the test early on failure.\n\nEnd of example.\n\n\n## References\n\n- `references/core-rules.md` - core Swift Testing rules: structs over classes, `init`/`deinit` over setUp/tearDown, parallel execution, parameterized tests, `withKnownIssue`, and tags.\n- `references/writing-better-tests.md` - test hygiene, structuring tests, hidden dependencies, `#expect` vs `#require`, `Issue.record()`, `#expect(throws:)`, and verification methods.\n- `references/async-tests.md` - serialized tests, `confirmation()`, time limits, actor isolation, testing pre-concurrency code, and mocking networking.\n- `references/new-features.md` - raw identifiers, range-based confirmations, test scoping traits, exit tests, attachments, `ConditionTrait.evaluate()`, and the updated `#expect(throws:)` return value.\n- `references/migrating-from-xctest.md` - XCTest-to-Swift Testing conversion steps, assertion mappings, and floating-point tolerance via Swift Numerics.\n","frontmatter":{"name":"swift-testing-pro","description":"Writes, reviews, and improves Swift Testing code using modern APIs and best practices. Use when reading, writing, or reviewing projects that use Swift Testing.","license":"MIT","metadata":{"author":"Paul Hudson","version":"1.0"}},"isInternal":false,"tokens":958,"sizeBytes":4302},{"name":"openai.yaml","path":"doc/skills/swiftui-pro/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `doc/skills/swiftui-pro/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/agents/openai.yaml)","tokens":300,"sizeBytes":200},{"name":"accessibility.md","path":"doc/skills/swiftui-pro/references/accessibility.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/accessibility.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/accessibility.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/accessibility.md)","tokens":300,"sizeBytes":222},{"name":"api.md","path":"doc/skills/swiftui-pro/references/api.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/api.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/api.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/api.md)","tokens":300,"sizeBytes":202},{"name":"data.md","path":"doc/skills/swiftui-pro/references/data.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/data.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/data.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/data.md)","tokens":300,"sizeBytes":204},{"name":"design.md","path":"doc/skills/swiftui-pro/references/design.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/design.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/design.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/design.md)","tokens":300,"sizeBytes":208},{"name":"hygiene.md","path":"doc/skills/swiftui-pro/references/hygiene.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/hygiene.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/hygiene.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/hygiene.md)","tokens":300,"sizeBytes":210},{"name":"navigation.md","path":"doc/skills/swiftui-pro/references/navigation.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/navigation.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/navigation.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/navigation.md)","tokens":300,"sizeBytes":216},{"name":"performance.md","path":"doc/skills/swiftui-pro/references/performance.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/performance.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/performance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/performance.md)","tokens":300,"sizeBytes":218},{"name":"swift.md","path":"doc/skills/swiftui-pro/references/swift.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/swift.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/swift.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/swift.md)","tokens":300,"sizeBytes":206},{"name":"views.md","path":"doc/skills/swiftui-pro/references/views.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/views.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `doc/skills/swiftui-pro/references/views.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/references/views.md)","tokens":300,"sizeBytes":206},{"name":"SKILL.md","path":"doc/skills/swiftui-pro/SKILL.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swiftui-pro/SKILL.md","title":"swiftui-pro","category":"anthropic-skill","format":"markdown","content":"---\nname: swiftui-pro\ndescription: Comprehensively reviews SwiftUI code for best practices on modern APIs, maintainability, and performance. Use when reading, writing, or reviewing SwiftUI projects.\nlicense: MIT\nmetadata:\n author: Paul Hudson\n version: \"1.0\"\n---\n\nReview Swift and SwiftUI code for correctness, modern API usage, and adherence to project conventions. Report only genuine problems - do not nitpick or invent issues.\n\nReview process:\n\n1. Check for deprecated API using `references/api.md`.\n1. Check that views, modifiers, and animations have been written optimally using `references/views.md`.\n1. Validate that data flow is configured correctly using `references/data.md`.\n1. Ensure navigation is updated and performant using `references/navigation.md`.\n1. Ensure the code uses designs that are accessible and compliant with Appleβs Human Interface Guidelines using `references/design.md`.\n1. Validate accessibility compliance including Dynamic Type, VoiceOver, and Reduce Motion using `references/accessibility.md`.\n1. Ensure the code is able to run efficiently using `references/performance.md`.\n1. Quick validation of Swift code using `references/swift.md`.\n1. Final code hygiene check using `references/hygiene.md`.\n\nIf doing a partial review, load only the relevant reference files.\n\n\n## Core Instructions\n\n- iOS 26 exists, and is the default deployment target for new apps.\n- Target Swift 6.2 or later, using modern Swift concurrency.\n- As a SwiftUI developer, the user will want to avoid UIKit unless requested.\n- Do not introduce third-party frameworks without asking first.\n- Break different types up into different Swift files rather than placing multiple structs, classes, or enums into a single file.\n- Use a consistent project structure, with folder layout determined by app features.\n\n\n## Output Format\n\nOrganize findings by file. For each issue:\n\n1. State the file and relevant line(s).\n2. Name the rule being violated (e.g., \"Use `foregroundStyle()` instead of `foregroundColor()`\").\n3. Show a brief before/after code fix.\n\nSkip files with no issues. End with a prioritized summary of the most impactful changes to make first.\n\nExample output:\n\n### ContentView.swift\n\n**Line 12: Use `foregroundStyle()` instead of `foregroundColor()`.**\n\n```swift\n// Before\nText(\"Hello\").foregroundColor(.red)\n\n// After\nText(\"Hello\").foregroundStyle(.red)\n```\n\n**Line 24: Icon-only button is bad for VoiceOver - add a text label.**\n\n```swift\n// Before\nButton(action: addUser) {\n Image(systemName: \"plus\")\n}\n\n// After\nButton(\"Add User\", systemImage: \"plus\", action: addUser)\n```\n\n**Line 31: Avoid `Binding(get:set:)` in view body - use `@State` with `onChange()` instead.**\n\n```swift\n// Before\nTextField(\"Username\", text: Binding(\n get: { model.username },\n set: { model.username = $0; model.save() }\n))\n\n// After\nTextField(\"Username\", text: $model.username)\n .onChange(of: model.username) {\n model.save()\n }\n```\n\n### Summary\n\n1. **Accessibility (high):** The add button on line 24 is invisible to VoiceOver.\n2. **Deprecated API (medium):** `foregroundColor()` on line 12 should be `foregroundStyle()`.\n3. **Data flow (medium):** The manual binding on line 31 is fragile and harder to maintain.\n\nEnd of example.\n\n\n## References\n\n- `references/accessibility.md` - Dynamic Type, VoiceOver, Reduce Motion, and other accessibility requirements.\n- `references/api.md` - updating code for modern API, and the deprecated code it replaces.\n- `references/design.md` - guidance for building accessible apps that meet Appleβs Human Interface Guidelines.\n- `references/hygiene.md` - making code compile cleanly and be maintainable in the long term.\n- `references/navigation.md` - navigation using `NavigationStack`/`NavigationSplitView`, plus alerts, confirmation dialogs, and sheets.\n- `references/performance.md` - optimizing SwiftUI code for maximum performance.\n- `references/data.md` - data flow, shared state, and property wrappers.\n- `references/swift.md` - tips on writing modern Swift code, including using Swift Concurrency effectively.\n- `references/views.md` - view structure, composition, and animation.\n","frontmatter":{"name":"swiftui-pro","description":"Comprehensively reviews SwiftUI code for best practices on modern APIs, maintainability, and performance. Use when reading, writing, or reviewing SwiftUI projects.","license":"MIT","metadata":{"author":"Paul Hudson","version":"1.0"}},"isInternal":false,"tokens":906,"sizeBytes":4145},{"name":"plan-document-reviewer-prompt.md","path":"doc/skills/writing-plans/plan-document-reviewer-prompt.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/writing-plans/plan-document-reviewer-prompt.md","title":"Writing-plans Skill","category":"anthropic-skill","format":"markdown","content":"# Plan Document Reviewer Prompt Template\n\nUse this template when dispatching a plan document reviewer subagent.\n\n**Purpose:** Verify the plan is complete, matches the spec, and has proper task decomposition.\n\n**Dispatch after:** The complete plan is written.\n\n```\nSubagent (general-purpose):\n description: \"Review plan document\"\n prompt: |\n You are a plan document reviewer. Verify this plan is complete and ready for implementation.\n\n **Plan to review:** [PLAN_FILE_PATH]\n **Spec for reference:** [SPEC_FILE_PATH]\n\n ## What to Check\n\n | Category | What to Look For |\n |----------|------------------|\n | Completeness | TODOs, placeholders, incomplete tasks, missing steps |\n | Spec Alignment | Plan covers spec requirements, no major scope creep |\n | Task Decomposition | Tasks have clear boundaries, steps are actionable |\n | Buildability | Could an engineer follow this plan without getting stuck? |\n\n ## Calibration\n\n **Only flag issues that would cause real problems during implementation.**\n An implementer building the wrong thing or getting stuck is an issue.\n Minor wording, stylistic preferences, and \"nice to have\" suggestions are not.\n\n Approve unless there are serious gaps β missing requirements from the spec,\n contradictory steps, placeholder content, or tasks so vague they can't be acted on.\n\n ## Output Format\n\n ## Plan Review\n\n **Status:** Approved | Issues Found\n\n **Issues (if any):**\n - [Task X, Step Y]: [specific issue] - [why it matters for implementation]\n\n **Recommendations (advisory, do not block approval):**\n - [suggestions for improvement]\n```\n\n**Reviewer returns:** Status, Issues (if any), Recommendations\n","isInternal":false,"tokens":364,"sizeBytes":1713},{"name":"SKILL.md","path":"doc/skills/writing-plans/SKILL.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/writing-plans/SKILL.md","title":"writing-plans","category":"anthropic-skill","format":"markdown","content":"---\nname: writing-plans\ndescription: Use when you have a spec or requirements for a multi-step task, before touching code\n---\n\n# Writing Plans\n\n## Overview\n\nWrite comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.\n\nAssume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.\n\n**Announce at start:** \"I'm using the writing-plans skill to create the implementation plan.\"\n\n**Context:** If working in an isolated worktree, it should have been created via the `superpowers:using-git-worktrees` skill at execution time.\n\n**Save plans to:** `doc/plan/YYYY-MM-DD-.md`\n- This project path is mandatory for OnlySwitch implementation plans.\n\n## Scope Check\n\nIf the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans β one per subsystem. Each plan should produce working, testable software on its own.\n\n## File Structure\n\nBefore defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.\n\n- Design units with clear boundaries and well-defined interfaces. Each file should have one clear responsibility.\n- You reason best about code you can hold in context at once, and your edits are more reliable when files are focused. Prefer smaller, focused files over large ones that do too much.\n- Files that change together should live together. Split by responsibility, not by technical layer.\n- In existing codebases, follow established patterns. If the codebase uses large files, don't unilaterally restructure - but if a file you're modifying has grown unwieldy, including a split in the plan is reasonable.\n\nThis structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.\n\n## Task Right-Sizing\n\nA task is the smallest unit that carries its own test cycle and is worth a\nfresh reviewer's gate. When drawing task boundaries: fold setup,\nconfiguration, scaffolding, and documentation steps into the task whose\ndeliverable needs them; split only where a reviewer could meaningfully\nreject one task while approving its neighbor. Each task ends with an\nindependently testable deliverable.\n\n## Bite-Sized Task Granularity\n\n**Each step is one action (2-5 minutes):**\n- \"Write the failing test\" - step\n- \"Run it to make sure it fails\" - step\n- \"Implement the minimal code to make the test pass\" - step\n- \"Run the tests and make sure they pass\" - step\n- \"Commit\" - step\n\n## Plan Document Header\n\n**Every plan MUST start with this header:**\n\n```markdown\n# [Feature Name] Implementation Plan\n\n> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.\n\n**Goal:** [One sentence describing what this builds]\n\n**Architecture:** [2-3 sentences about approach]\n\n**Tech Stack:** [Key technologies/libraries]\n\n## Global Constraints\n\n[The spec's project-wide requirements β version floors, dependency limits,\nnaming and copy rules, platform requirements β one line each, with exact\nvalues copied verbatim from the spec. Every task's requirements implicitly\ninclude this section.]\n\n---\n```\n\n## Task Structure\n\n````markdown\n### Task N: [Component Name]\n\n**Files:**\n- Create: `exact/path/to/file.py`\n- Modify: `exact/path/to/existing.py:123-145`\n- Test: `tests/exact/path/to/test.py`\n\n**Interfaces:**\n- Consumes: [what this task uses from earlier tasks β exact signatures]\n- Produces: [what later tasks rely on β exact function names, parameter\n and return types. A task's implementer sees only their own task; this\n block is how they learn the names and types neighboring tasks use.]\n\n- [ ] **Step 1: Write the failing test**\n\n```python\ndef test_specific_behavior():\n result = function(input)\n assert result == expected\n```\n\n- [ ] **Step 2: Run test to verify it fails**\n\nRun: `pytest tests/path/test.py::test_name -v`\nExpected: FAIL with \"function not defined\"\n\n- [ ] **Step 3: Write minimal implementation**\n\n```python\ndef function(input):\n return expected\n```\n\n- [ ] **Step 4: Run test to verify it passes**\n\nRun: `pytest tests/path/test.py::test_name -v`\nExpected: PASS\n\n- [ ] **Step 5: Commit**\n\n```bash\ngit add tests/path/test.py src/path/file.py\ngit commit -m \"feat: add specific feature\"\n```\n````\n\n## No Placeholders\n\nEvery step must contain the actual content an engineer needs. These are **plan failures** β never write them:\n- \"TBD\", \"TODO\", \"implement later\", \"fill in details\"\n- \"Add appropriate error handling\" / \"add validation\" / \"handle edge cases\"\n- \"Write tests for the above\" (without actual test code)\n- \"Similar to Task N\" (repeat the code β the engineer may be reading tasks out of order)\n- Steps that describe what to do without showing how (code blocks required for code steps)\n- References to types, functions, or methods not defined in any task\n\n## Self-Review\n\nAfter writing the complete plan, look at the spec with fresh eyes and check the plan against it. This is a checklist you run yourself β not a subagent dispatch.\n\n**1. Spec coverage:** Skim each section/requirement in the spec. Can you point to a task that implements it? List any gaps.\n\n**2. Placeholder scan:** Search your plan for red flags β any of the patterns from the \"No Placeholders\" section above. Fix them.\n\n**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.\n\nIf you find issues, fix them inline. No need to re-review β just fix and move on. If you find a spec requirement with no task, add the task.\n\n## Execution Handoff\n\nAfter saving the plan, offer execution choice:\n\n**\"Plan complete and saved to `doc/plan/.md`. Two execution options:**\n\n**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration\n\n**2. Inline Execution** - Execute tasks in this session using executing-plans, batch execution with checkpoints\n\n**Which approach?\"**\n\n**If Subagent-Driven chosen:**\n- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development\n- Fresh subagent per task + two-stage review\n\n**If Inline Execution chosen:**\n- **REQUIRED SUB-SKILL:** Use superpowers:executing-plans\n- Batch execution with checkpoints for review\n","frontmatter":{"name":"writing-plans","description":"Use when you have a spec or requirements for a multi-step task, before touching code"},"isInternal":false,"tokens":1559,"sizeBytes":6888},{"name":"switch-ids.md","path":"OpenClaw/skills/onlyswitch-deeplink/references/switch-ids.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/OpenClaw/skills/onlyswitch-deeplink/references/switch-ids.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `OpenClaw/skills/onlyswitch-deeplink/references/switch-ids.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/OpenClaw/skills/onlyswitch-deeplink/references/switch-ids.md)","tokens":300,"sizeBytes":242},{"name":"SKILL.md","path":"OpenClaw/skills/onlyswitch-deeplink/SKILL.md","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/OpenClaw/skills/onlyswitch-deeplink/SKILL.md","title":"onlyswitch-deeplink","category":"anthropic-skill","format":"markdown","content":"---\nname: onlyswitch-deeplink\ndescription: Invoke OnlySwitch built-in switches or buttons via deeplink. Use when the user asks to toggle or trigger an OnlySwitch action (e.g. empty trash, keep awake, dark mode, mute, hide desktop, clear clipboard, eject discs, Xcode derived data, and any other built-in switch or button). Resolve the request to the correct switch id and open the onlyswitch deeplink.\nmetadata: {\"openclaw\":{\"os\":[\"darwin\"],\"homepage\":\"https://github.com/jacklandrin/OnlySwitch\"}}\n---\n\n# OnlySwitch Deeplink\n\nInvoke OnlySwitch built-in switches or one-shot buttons by opening its deeplink. OnlySwitch must be installed and allowed to handle the `onlyswitch://` URL scheme.\n\n## Workflow\n\n1. **Resolve intent to switch id** \n Map the user's request to a single built-in switch/button using [references/switch-ids.md](references/switch-ids.md). Match phrases like \"empty trash\", \"toggle keep awake\", \"mute mic\", \"clear xcode cache\" to the correct **id** (e.g. empty trash β 16384, keep awake β 16).\n\n2. **Open the deeplink** \n Run on the user's machine (macOS):\n\n ```bash\n open \"onlyswitch://run?type=builtIn&id=\"\n ```\n\n Replace `` with the numeric id from the reference table. Example for \"empty trash\":\n\n ```bash\n open \"onlyswitch://run?type=builtIn&id=16384\"\n ```\n\n3. **Confirm** \n Tell the user which action was triggered (e.g. \"Emptied trash via OnlySwitch\" or \"Toggled Keep Awake via OnlySwitch\").\n\n## Notes\n\n- One deeplink per request: resolve to exactly one switch id per user message.\n- If the request doesn't match any built-in (e.g. custom switch or unknown action), say that OnlySwitch deeplinks only support the built-in list and suggest checking the app or docs.\n- IDs are raw enum values from `SwitchType` in the OnlySwitch app (see project's `SwitchType.swift` for the source of truth; this skill's reference table is derived from it).\n","frontmatter":{"name":"onlyswitch-deeplink","description":"Invoke OnlySwitch built-in switches or buttons via deeplink. Use when the user asks to toggle or trigger an OnlySwitch action (e.g. empty trash, keep awake, dark mode, mute, hide desktop, clear clipboard, eject discs, Xcode derived data, and any other built-in switch or button). Resolve the request to the correct switch id and open the onlyswitch deeplink.","metadata":{"openclaw":{"os":["darwin"],"homepage":"https://github.com/jacklandrin/OnlySwitch"}}},"isInternal":false,"tokens":474,"sizeBytes":1901},{"name":"marketplace.json","path":"doc/skills/app-store-review/.agents/plugins/marketplace.json","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/.agents/plugins/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `doc/skills/app-store-review/.agents/plugins/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/.agents/plugins/marketplace.json)","tokens":300,"sizeBytes":259},{"name":"marketplace.json","path":"doc/skills/app-store-review/.claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `doc/skills/app-store-review/.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":257},{"name":"plugin.json","path":"doc/skills/app-store-review/.claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `doc/skills/app-store-review/.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":243},{"name":"plugin.json","path":"doc/skills/app-store-review/.codex-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/.codex-plugin/plugin.json","title":"app-store-review","category":"plugin-manifest","format":"json","content":"{\n \"name\": \"app-store-review\",\n \"version\": \"1.1.0\",\n \"description\": \"Evaluates code against Apple's App Store Review Guidelines for iOS, macOS, tvOS, watchOS, and visionOS apps.\",\n \"author\": {\n \"name\": \"safaiyeh\",\n \"url\": \"https://github.com/safaiyeh\"\n },\n \"homepage\": \"https://github.com/safaiyeh/app-store-review-skill\",\n \"repository\": \"https://github.com/safaiyeh/app-store-review-skill\",\n \"license\": \"MIT\",\n \"keywords\": [\n \"apple\",\n \"app-store\",\n \"review\",\n \"guidelines\",\n \"ios\",\n \"macos\",\n \"swift\",\n \"react-native\",\n \"expo\"\n ],\n \"skills\": \"./\",\n \"interface\": {\n \"displayName\": \"App Store Review\",\n \"shortDescription\": \"Audit apps for App Store review risk\",\n \"longDescription\": \"Evaluate app code against Apple's App Store Review Guidelines before submission, with coverage for privacy, payments, safety, performance, design, and legal risks.\",\n \"developerName\": \"safaiyeh\",\n \"category\": \"Coding\",\n \"capabilities\": [\n \"Read\"\n ],\n \"websiteURL\": \"https://github.com/safaiyeh/app-store-review-skill\",\n \"defaultPrompt\": [\n \"Review this app for App Store compliance.\"\n ],\n \"brandColor\": \"#0A84FF\"\n }\n}\n","frontmatter":{"name":"app-store-review","version":"1.1.0","description":"Evaluates code against Apple's App Store Review Guidelines for iOS, macOS, tvOS, watchOS, and visionOS apps.","author":{"name":"safaiyeh","url":"https://github.com/safaiyeh"},"homepage":"https://github.com/safaiyeh/app-store-review-skill","repository":"https://github.com/safaiyeh/app-store-review-skill","license":"MIT","keywords":["apple","app-store","review","guidelines","ios","macos","swift","react-native","expo"],"skills":"./","interface":{"displayName":"App Store Review","shortDescription":"Audit apps for App Store review risk","longDescription":"Evaluate app code against Apple's App Store Review Guidelines before submission, with coverage for privacy, payments, safety, performance, design, and legal risks.","developerName":"safaiyeh","category":"Coding","capabilities":["Read"],"websiteURL":"https://github.com/safaiyeh/app-store-review-skill","defaultPrompt":["Review this app for App Store compliance."],"brandColor":"#0A84FF"}},"isInternal":false,"tokens":333,"sizeBytes":1191}],"systemPromptSnippet":"\n\n# OnlySwitch Agent Guidance\n\nThis file defines the default workflow for changes to the OnlySwitch project. It applies to the macOS app, widgets, remote app, Swift Package modules, tests, OpenClaw integration, and project documentation.\n\n## Workflow\n\nFor every task, follow these steps in order. Each phase is delegated to the named subagent/model, and its output is handed to the next phase:\n\n1. **Identify the task β subagent: 5.6 Luna.** Restate the requested outcome, inspect the relevant project files, and analyze the primary use cases, failure modes, and edge cases. Include impacts on macOS permissions, menu-bar behavior, widgets, remote control, persistence, localization, accessibility, and security when relevant.\n2. **Write the implementation plan β subagent: 5.6 Terra.** Ask the user whether they want an implementation plan written first. When accepted, load the `writing-plans` skill, save the completed plan under `doc/plan/`, and use it as the source of truth while implementing. For small, self-contained changes, the user may choose to proceed without a saved plan.\n3. **Load relevant skills using Context Routing β subagent: 5.6 Luna.** Select only the skills whose routing conditions match the task. Do not load every skill or every skill markdown by default. See [Context Routing](#context-routing).\n4. **Summarize constraints β subagent: 5.6 Luna.** Before changing files, briefly summarize applicable architecture rules, platform/deployment constraints, compatibility requirements, existing conventions, and any assumptions.\n5. **Implement unit tests β subagent: 5.6 Terra.** Ask whether the user wants test-driven development for the task. If yes, write or update tests before production code where practical. If no, still add or update focused regression tests when the risk warrants them. Skip this phase only when tests are not meaningful for the requested change.\n6. **Implement the feature β subagent: 5.6 sol.** Make the smallest coherent change that satisfies the task, following the applicable Context Routing guidance and the saved plan when one exists.\n7. **Review the code β subagent: 5.6 Terra.** Review the implementation and tests for correctness, architecture compliance, edge cases, concurrency safety, permissions/privacy risks, and regressions. Apply or request fixes before reporting completion. Run the narrowest relevant checks, then broader checks when appropriate, and report what changed, what was verified, and any known limitations.\n\nWhen a task is explicitly urgent or the user has already answered one of the workflow questions in the current conversation, do not ask the same question again; carry that decision forward for the task.\n\n## Context Routing\n\nSkills are opt-in by task context. First inspect the task and repository; then load only the matching skill instructions. A skill is not loaded merely because it is available.\n\n| Context or trigger | Load skill guidance when | Do not load when |\n| --- | --- | --- |\n| `swiftui-pro` (`doc/skills/swiftui-pro/SKILL.md`) | Reviewing, designing, or implementing SwiftUI views, view state, navigation, accessibility, animations, or SwiftUI performance | The task does not inspect or change SwiftUI code |\n| `swift-concurrency-pro` (`doc/skills/swift-concurrency-pro/SKILL.md`) | Reviewing, designing, or implementing Swift concurrency, actors, `Sendable`, isolation, async streams, cancellation, or strict-concurrency fixes | The task does not inspect or change concurrency code |\n| `swift-testing-pro` (`doc/skills/swift-testing-pro/SKILL.md`) | Writing, migrating, reviewing, or improving Swift Testing/XCTest code or test strategy | No test code or test strategy is in scope |\n| `app-store-review` (`doc/skills/app-store-review/SKILL.md`) | The user explicitly requests an App Store submission-readiness review | Any macOS app task; App Store constraints are out of scope by default for this project |\n| `writing-plans` (`doc/skills/writing-plans/SKILL.md`) | The user requests a multi-step implementation plan, or the workflow's plan step is accepted | The user declines a plan or the task is small and self-contained |\n\nUse the narrowest applicable skill. If several conditions match, load the smallest set that covers the work and state the selection in the task update. Skill instructions may route to more specific references; follow only those references needed for the current task. For the project-local `writing-plans` skill, always save plans as `doc/plan/YYYY-MM-DD-.md`; this project location overrides any generic default path in the skill.\n\n## Project-specific working rules\n\n- Treat `ARCHITECTURE.md` as the source of truth for architectural constraints.\n- Keep implementation plans in `doc/plan/`. Keep reusable skill notes, routing supplements, and project-specific skill instructions in `doc/skills/`.\n- Keep business logic out of SwiftUI views. Move state transitions, validation, orchestration, and side effects into TCA reducers, domain types, or injected clients.\n- Preserve the boundaries between the macOS app, widget extension, remote app, and reusable Swift Package modules.\n- Prefer focused, composable modules and reusable abstractions over expanding monolithic files.\n- Maintain Swift 6 concurrency safety, including explicit sendability and actor isolation at networking, persistence, and process-boundary crossings.\n- Treat shell commands, Apple Events, keychain access, system settings, and user permissions as security-sensitive effects that require explicit dependencies and testable failure handling.\n- Do not evaluate macOS app changes against App Store constraints unless the user explicitly requests an App Store submission-readiness review.\n- Design new or substantially changed UI with modern platform styling, adopting Liquid Glass where supported, providing compatible fallbacks, supporting light and dark modes, and adapting layouts for macOS, iPhone, and iPad sizes as applicable.\n- Translate every new user-facing string into every language supported by OnlySwitch; do not ship newly added source-only strings.\n- Avoid unrelated formatting or refactoring. Update documentation when a change alters an architectural decision or workflow.\n\n\n# OnlySwitch Architecture\n\n## Purpose\n\nOnlySwitch is a macOS menu-bar utility that exposes system switches, widgets, an optional desktop pet, an AI assistant, and remote control capabilities. The repository also contains reusable Swift Package modules, a widget target, a remote app, persistence, networking, authentication, and OpenClaw integration.\n\n## Core constraints\n\n1. **Use The Composable Architecture (TCA).** Model user-facing features with state, actions, reducers, and effects using [pointfreeco/swift-composable-architecture](https://github.com/pointfreeco/swift-composable-architecture). OnlySwitch already uses TCA in multiple package features; extend that pattern consistently.\n2. **Use `swift-dependencies` for injection.** Runtime services and external effects should be accessed through `@Dependency` using [pointfreeco/swift-dependencies](https://github.com/pointfreeco/swift-dependencies), rather than being constructed directly inside views or reducers. When introducing or migrating a service, add the dependency at the appropriate module boundary.\n3. **Modularize with Swift packages.** Use the `Modules` Swift Package to separate independently buildable and testable functionality. Keep target dependencies intentional and acyclic.\n4. **Factor monolithic logic into focused modules.** Extract switch behavior, feature state, persistence, networking, remote protocol, authentication, AI provider integrations, and presentation concerns into focused modules as boundaries become clear.\n5. **Keep SwiftUI views free of business logic.** Views render state and send user intent. Business rules, validation, orchestration, permissions, shell/AppleScript effects, and state transitions belong in reducers, domain types, or injected clients.\n6. **Follow Swift 6 concurrency safety.** Preserve `Sendable` correctness, actor isolation, structured concurrency, cancellation, and safe crossing of process, networking, persistence, and app/extension boundaries.\n7. **Extract common logic for reuse.** Shared models, remote protocol types, switch descriptors, formatting, validation, persistence adapters, and permission policies should have one well-defined implementation and be reused by the app, widget, remote app, and package targets where appropriate.\n\n## Intended dependency direction\n\n```text\nApp / Widget / Remote app targets\n β\nFeature modules (TCA reducers, feature state, feature views)\n β\nDomain modules (switches, remote protocol, models, business rules)\n β\nInfrastructure modules (system effects, persistence, networking, AI providers, keychain)\n```\n\nInfrastructure details must not leak into SwiftUI views. Feature modules should depend on domain abstractions and access infrastructure through injected dependency clients. Shared protocol and model modules must remain safe for all targets that exchange their values.\n\n## Current repository boundaries\n\n- `Modules/` is the primary Swift Package boundary. It contains feature modules such as `OnlyControl`, `OnlyAgent`, `Authenticator`, `StickerView`, and `DesktopPet`, plus shared `Defines`, `Extensions`, `Utilities`, `Networking`, `RemoteCore`, and `RemoteTransport` modules.\n- `Modules/Sources/Aphrodite` owns the generated mini-app authoring domain, serialized library, TCA feature, and sandboxed renderer. `SettingsVM.shared` retains the Settings store for the app session so accepted work survives presentation changes, while Aphrodite's injected notification boundary requests permission and reports only persistence-confirmed completion; the app delegate owns foreground banner policy. Authoring prompts, conversation history, model selection, and other authoring configuration never cross the `RemoteCore` or `RemoteTransport` boundary; validated runtime HTML, optional validated SVG, and minimal display metadata may cross that boundary for OnlyRemote. Each app persists only its latest HTML and compact completed user prompts; optimistic replacement prevents a stale edit from restoring a deleted or newer app. Six bundled starter apps are merged into the local library once using stable IDs and a persisted seed version, preserving user edits and deletions. Codex reuses a runtime per model and purpose while mapping each Aphrodite conversation to its own thread. Optional icons come from the same model response as static SVG, are validated before storage and native rendering, and fall back to `star.hexagon` when unavailable. Existing libraries without icons or conversation metadata remain readable. The renderer's only native signals are bounded content-size reports from an isolated WebKit content world; the editor keeps an unscaled logical canvas and scales it to fit its preview, while launchers use the content-height signal. Generated page JavaScript cannot access the handler or any native capability.\n- `OnlySwitch/` contains the main macOS application, system integrations, Core Data persistence, audio/player functionality, and app-specific UI. Menu-bar hosts measure active content separately from persistent chrome, then apply the shared `Utilities.AdaptivePanelHeightPolicy` to the hosting screenβs `visibleFrame`. Only Control uses a fixed-size window and keeps overflow scrollable.\n- `OnlyWidget/` contains widget-facing code and must use extension-safe shared models and effects.\n- `OnlySwitchRemote/` contains the remote-control application and must share protocol contracts without importing main-app implementation details. Its root TCA feature owns the independent Aphrodite personal-tools tab and OnlyRemote Plus sheet. Aphrodite access is gated by verified subscription entitlement, with an embedded paywall for nonmembers. Entitlement refresh is independent of product loading and responds to foregrounding, transaction updates, purchases, restoration, and expiration. A Debug-only Settings submenu provides a persisted paywall bypass for development; Release builds ignore this preference. The injected StoreKit client loads and purchases only the one-month `jacklandrin.onlyremote.plus.monthly` auto-renewable product. Only eligible verified transactions unlock access; pending purchases await a later transaction update, and cancellation does not grant access. Recognized verified transactions are finished after processing, and purchase results update both embedded and Settings paywalls without depending on duplicate transaction notifications.\n- `RemoteCore` owns the lightweight, versioned Aphrodite transfer models and the shared HTML and SVG safety validators. Authenticated protocol 1.6 sessions automatically transfer the complete saved library as bounded manifests and 64 KiB chunks with SHA-256 integrity; the wire contract excludes Aphrodite authoring types and private authoring state. OnlyRemote validates each complete transfer before atomically replacing its per-Mac cache, and its WebKit runner uses the same isolated custom origin, content-security policy, and navigation restrictions as the shared sandbox primitives. OnlyRemote lists and runs cached tools but does not create or edit them.\n- Launch Campaign uses an injected TCA client to fetch a bounded manifest and dated HTML from the fixed repository origin. A nonpersistent, navigation-restricted WebKit renderer loads while hidden and acknowledges the date only after successful presentation. The page follows app language and native appearance; its OnlyRemote download link opens the existing native QR window. Both windows temporarily rise above menu-bar panels when presented and return to normal level on focus loss, app deactivation, or closing. Failed requests or rendering remain silent and unacknowledged. Debug builds bypass the previously shown date so the latest page appears on every app launch; forced previews do not modify the saved presentation date.\n- `OnlySwitchTests/`, `OnlySwitchRemoteTests/`, and `Modules/Tests/` contain unit, integration, feature, protocol, and end-to-end coverage.\n- `OpenClaw/skills/onlyswitch-deeplink/` contains the OpenClaw integration documentation and skill for invoking built-in switches through deeplinks.\n\nThe project already uses TCA in package features and Swift Package modularization. New work should extend existing reducer/dependency patterns rather than introduce a parallel state-management approach. `swift-dependencies` is an architectural requirement for new injectable services; existing direct constructions may be migrated incrementally at feature boundaries.\n\n## Feature structure guidance\n\nEach feature should aim to contain:\n\n- a `State` value representing renderable state;\n- an `Action` enum representing user, lifecycle, and dependency-driven events;\n- a reducer that owns transitions and effects;\n- a SwiftUI view that observes state and sends actions;\n- injected clients for clocks, system commands, permissions, persistence, networking, and AI providers;\n- focused tests for business rules, effect behavior, authorization failures, and important edge cases.\n\n## System and remote boundaries\n\nChanges to switches, shell commands, AppleScript, keychain data, Core Data, widgets, remote sessions, or deeplinks must account for:\n\n- macOS authorization and user-cancelled permission flows;\n- command failure, unavailable hardware, unsupported OS versions, and missing executables;\n- secure storage and migration of credentials, pairing data, and provider keys;\n- remote pairing, authentication, encryption, framing, ordering, replay protection, cancellation, and reconnect behavior;\n- widget refresh limits and stale state;\n- process isolation and extension-safe serialization;\n- localization, accessibility, and menu-bar interaction behavior.\n\n## Testing expectations\n\nPrefer deterministic reducer and domain tests with controlled dependencies. Add integration coverage for Core Data, system-effect adapters, remote transport, pairing, and cross-target behavior when reducer tests cannot prove correctness. New concurrency-sensitive code should include tests for cancellation, ordering, actor isolation assumptions, malformed frames, connection loss, and failure propagation where applicable.\n\n\n# Agents Skill\n\nPath: `doc/skills/app-store-review/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/agents/openai.yaml)\n\n\n# App Store Review Guidelines Skill\n\nAn AI agent skill that exhaustively evaluates iOS, macOS, tvOS, watchOS, and visionOS app code against **every point** in Apple's App Store Review Guidelines.\n\n**Supports:** Swift, Objective-C, **React Native**, and **Expo** apps\n\n**Current through:** Apple's official June 8, 2026 App Review Guidelines update\n\n## Installation\n\n### Codex\n\nAdd this repository as a Codex plugin marketplace:\n\n```bash\ncodex plugin marketplace add safaiyeh/app-store-review-skill\n```\n\nThen open Codex, run `/plugins`, choose the App Store Review marketplace, and install the `app-store-review` plugin. Start a new thread and invoke the skill with `$app-store-review` or ask for an App Store compliance review.\n\nCodex also discovers direct local skills from `~/.agents/skills`, but plugins are the recommended distribution path for reusable skills.\n\n### Claude Code Plugin Marketplace\n\n```bash\n/plugin marketplace add safaiyeh/app-store-review-skill\n/plugin install app-store-review@app-store-review\n```\n\n### skills.sh\n\n```bash\nnpx skills add safaiyeh/app-store-review-skill\n```\n\n## Setup\n\n### Supported AI Agents\n\nThis skill works with Codex and AI coding agents that support the skills.sh standard:\n\n- [Codex](https://openai.com/codex/)\n- [Claude Code](https://claude.ai/code)\n- [Cursor](https://cursor.sh)\n- [Windsurf](https://codeium.com/windsurf)\n- And other compatible agents\n\n### How It Works\n\n1. **Install the skill** in your project using the command above\n2. **Start your AI agent** in the project directory\n3. **Ask for an App Store review** - the agent will automatically load relevant guidelines\n4. **Review the findings** - the agent identifies potential rejection issues with code references\n\n### Example Prompts\n\n```\n\"Review this app for App Store compliance\"\n\"Check if my IAP implementation follows Apple's guidelines\"\n\"Audit the privacy and data collection in this React Native app\"\n\"What App Store issues might block my submission?\"\n```\n\n### Telemetry\n\nThe skills CLI collects anonymous usage telemetry. To opt out:\n\n```bash\nSKILLS_NO_TELEMETRY=1 npx skills add safaiyeh/app-store-review-skill\n```\n\n## Structure\n\n```\napp-store-review-skill/\nβββ .agents/\nβ βββ plugins/marketplace.json # Codex plugin marketplace\nβββ .claude-plugin/\nβ βββ marketplace.json # Claude Code plugin marketplace\nβ βββ plugin.json # Claude Code plugin manifest\nβββ .codex-plugin/\nβ βββ plugin.json # Codex plugin manifest\nβββ agents/\nβ βββ openai.yaml # Codex UI metadata\nβββ SKILL.md # Index with quick reference & checklist\nβββ rules/\n βββ 1-safety.md # Section 1: Safety guidelines\n βββ 2-performance.md # Section 2: Performance guidelines\n βββ 3-business.md # Section 3: Business guidelines\n βββ 4-design.md # Section 4: Design guidelines\n βββ 5-legal.md # Section 5: Legal guidelines\n```\n\n## Coverage\n\nThis skill covers **ALL 5 major sections** with **EVERY guideline point**:\n\n### [1. Safety](rules/1-safety.md)\n- 1.1 Objectionable Content (1.1.1-1.1.7)\n- 1.2 User-Generated Content & Creator Content\n- 1.3 Kids Category (parental gates, privacy, analytics)\n- 1.4 Physical Harm (medical apps, drug dosage, substances)\n- 1.5 Developer Information\n- 1.6 Data Security\n- 1.7 Reporting Criminal Activity\n\n### [2. Performance](rules/2-performance.md)\n- 2.1 App Completeness (final versions, IAP)\n- 2.2 Beta Testing\n- 2.3 Accurate Metadata (2.3.1-2.3.13)\n- 2.4 Hardware Compatibility (2.4.1-2.4.5)\n- 2.5 Software Requirements (2.5.1-2.5.18)\n\n### [3. Business](rules/3-business.md)\n- 3.1 Payments (IAP, subscriptions, external links, crypto)\n- 3.1.1-3.1.5 In-App Purchase rules\n- 3.2 Other Business Models (acceptable/unacceptable)\n\n### [4. Design](rules/4-design.md)\n- 4.1 Copycats\n- 4.2 Minimum Functionality\n- 4.3 Spam\n- 4.4 Extensions (keyboard, Safari)\n- 4.5 Apple Sites and Services\n- 4.7 Mini Apps, Chatbots, Game Emulators\n- 4.8 Login Services\n- 4.9 Apple Pay\n- 4.10 Monetizing Built-In Capabilities\n\n### [5. Legal](rules/5-legal.md)\n- 5.1 Privacy (data collection, use, sharing, health, kids, location)\n- 5.2 Intellectual Property\n- 5.3 Gaming, Gambling, Lotteries\n- 5.4 VPN Apps\n- 5.5 Mobile Device Management\n- 5.6 Developer Code of Conduct (reviews, developer identity, discovery fraud, app quality)\n\n## Features\n\n- **Modular structure** - Agent loads only relevant sections\n- **2000+ lines** of comprehensive guidelines\n- **Checklists** for every guideline point\n- **Code patterns** for Swift AND React Native/Expo\n- **Package references** for both Expo and bare React Native\n- **Quick reference** for high-risk rejection patterns\n- **Pre-submission checklist** in main SKILL.md\n\n## React Native / Expo Support\n\nEach rule file includes:\n- TypeScript/JavaScript code patterns to flag\n- Expo package recommendations (preferred)\n- Bare React Native package alternatives\n- React Native-specific checklists\n\nKey packages covered:\n- `react-native-purchases` (RevenueCat β recommended for IAP) / `react-native-iap`\n- `expo-tracking-transparency` / `react-native-tracking-transparency`\n- `expo-secure-store` / `react-native-keychain`\n- `expo-apple-authentication` / `@invertase/react-native-apple-authentication`\n- `expo-local-authentication` / `react-native-biometrics`\n\n## What It Checks\n\n### Critical Issues (Immediate Rejection)\n- Private API usage\n- Hardcoded secrets/credentials\n- External payment for digital goods\n- On-device cryptocurrency mining\n- Dynamic code execution\n\n### High-Risk Issues\n- Missing App Tracking Transparency\n- Account creation without deletion\n- IAP without restore purchases\n- UGC without moderation\n- UGC without removal workflows or a compliance improvement plan\n- Kids apps without parental gates\n- Live Activities or push notifications used for spam, phishing, or unsolicited messages\n\n### Medium-Risk Issues\n- Vague purpose strings\n- Over-requesting permissions\n- Unjustified background modes\n- References to other platforms\n- Custom review prompts instead of the system API\n\n## When It Triggers\n\nThe skill activates when working on:\n- App Store submission preparation\n- Code compliance review\n- Payment/StoreKit implementation\n- Privacy and data handling\n- User-generated content features\n- Kids Category apps\n- Health/medical apps\n- VPN/MDM apps\n- Gambling/lottery apps\n\n## License\n\nMIT\n\n\n# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/1-safety.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/1-safety.md)\n\n\n# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/2-performance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/2-performance.md)\n\n\n# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/3-business.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/3-business.md)\n\n\n# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/4-design.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/4-design.md)\n\n\n# Rules Skill\n\nPath: `doc/skills/app-store-review/rules/5-legal.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/app-store-review/rules/5-legal.md)\n\n\n---\nname: app-store-review\ndescription: Evaluates code against Apple's App Store Review Guidelines. Use this skill when reviewing iOS, macOS, tvOS, watchOS, or visionOS app code (Swift, Objective-C, React Native, or Expo) to identify potential App Store rejection issues before submission. Triggers on tasks involving app review preparation, compliance checking, or App Store submission readiness.\nlicense: MIT\nmetadata:\n author: safaiyeh\n version: \"1.1.0\"\n---\n\n# App Store Review Guidelines Checker\n\nComprehensive guide for evaluating iOS, macOS, tvOS, watchOS, and visionOS app code against Apple's App Store Review Guidelines. This skill covers EVERY guideline point to identify potential rejection issues before submission.\n\n**Supports:** Swift, Objective-C, React Native, and Expo apps\n\n**Guidelines current through:** Apple's June 8, 2026 App Review Guidelines update.\n\n## When to Apply\n\nUse this skill when:\n- Preparing an app for App Store submission\n- Reviewing code for compliance issues\n- Implementing features that may trigger review concerns\n- Auditing existing apps for guideline violations\n- Building features involving payments, user data, or sensitive content\n\n## Guideline Sections\n\nRead individual rule files for detailed explanations, checklists, and code examples:\n\n| Section | File | Key Topics |\n|---------|------|------------|\n| **1. Safety** | [rules/1-safety.md](rules/1-safety.md) | Objectionable content, UGC moderation, Kids Category, physical harm, data security |\n| **2. Performance** | [rules/2-performance.md](rules/2-performance.md) | App completeness, metadata accuracy, hardware compatibility, software requirements |\n| **3. Business** | [rules/3-business.md](rules/3-business.md) | In-app purchase, subscriptions, cryptocurrencies, other business models |\n| **4. Design** | [rules/4-design.md](rules/4-design.md) | Copycats, minimum functionality, spam, extensions, Apple services, login |\n| **5. Legal** | [rules/5-legal.md](rules/5-legal.md) | Privacy, data collection, intellectual property, gambling, VPN, MDM, developer code of conduct |\n\n## Risk Levels by Category\n\n| Risk Level | Category | Section | Common Rejection Reasons |\n|------------|----------|---------|--------------------------|\n| CRITICAL | Privacy & Data | 5.1 | Missing privacy policy, unauthorized data collection |\n| CRITICAL | Payments | 3.1 | Bypassing in-app purchase, unclear pricing |\n| HIGH | Safety | 1.x | Objectionable content, inadequate UGC moderation |\n| HIGH | Performance | 2.x | Crashes, incomplete features, deprecated APIs |\n| MEDIUM | Design | 4.x | Copycat apps, minimum functionality issues |\n| MEDIUM | Legal | 5.x | IP violations, gambling without license |\n\n---\n\n## Quick Reference: High-Risk Rejection Patterns\n\n### Critical Issues (Immediate Rejection)\n\n**Swift:**\n```swift\n// π΄ Private API usage\nlet selector = NSSelectorFromString(\"_privateMethod\")\n\n// π΄ Hardcoded secrets\nlet apiKey = \"sk_live_xxxxx\"\n\n// π΄ External payment for digital goods\nfunc purchaseDigitalContent() {\n openStripeCheckout() // Use StoreKit instead\n}\n```\n\n**React Native / Expo:**\n```typescript\n// π΄ Hardcoded secrets in JS bundle\nconst API_KEY = 'sk_live_xxxxx'; // REJECTION\n\n// π΄ External payment for digital goods\nLinking.openURL('https://stripe.com/checkout'); // Use react-native-iap\n\n// π΄ Dynamic code execution\neval(downloadedCode); // REJECTION\n\n// π΄ Major feature changes via CodePush/expo-updates\n// OTA updates for bug fixes only, not new features!\n```\n\n### High-Risk Issues\n\n**Swift:**\n```swift\n// π‘ Missing ATT when using ad SDKs\nimport FacebookAds // Without ATTrackingManager\n\n// π‘ Account creation without deletion\nfunc createAccount() { } // But no deleteAccount()\n```\n\n**React Native / Expo:**\n```typescript\n// π‘ Missing ATT (use expo-tracking-transparency)\nimport analytics from '@react-native-firebase/analytics';\nanalytics().logEvent('event'); // Without ATT prompt = REJECTION\n\n// π‘ Account deletion via website only\nLinking.openURL('https://example.com/delete'); // Must be in-app!\n\n// π‘ Social login without a privacy-preserving alternative (4.8)\n // Also offer a login meeting 4.8 criteria\n // (Sign in with Apple is the simplest option)\n\n// π‘ Custom review prompts (5.6.1)\nshowCustomAlert('Rate us 5 stars!'); // Use StoreReview.requestReview()\n```\n\n### Medium-Risk Issues\n\n```typescript\n// π Vague purpose strings in Info.plist\n\"This app needs camera access\" // Be specific!\n\n// π WebView-only app (insufficient native functionality)\nconst App = () => ;\n\n// π References to Android in iOS app\nconst text = \"Also available on Android\"; // REJECTION\n\n// π console.log in production\nconsole.log('debug'); // Remove or wrap in __DEV__\n```\n\n---\n\n## Pre-Submission Checklist\n\n### Privacy (Section 5.1)\n- [ ] Privacy policy link in App Store Connect\n- [ ] Privacy policy link accessible within app\n- [ ] All purpose strings are specific and accurate\n- [ ] App Privacy details completed in App Store Connect\n- [ ] ATT implemented if tracking users\n- [ ] Account deletion available if accounts exist\n- [ ] Data minimization - only requesting necessary permissions\n- [ ] User consent obtained before data collection\n\n### Payments (Section 3.1)\n- [ ] StoreKit used for all digital purchases\n- [ ] Restore purchases implemented\n- [ ] Subscription terms clearly displayed\n- [ ] Loot box odds disclosed if applicable\n- [ ] No external payment for digital goods (unless entitled)\n- [ ] Credits/currencies don't expire\n\n### Safety (Section 1.x)\n- [ ] No objectionable content\n- [ ] UGC moderation implemented (filter, report, block, contact)\n- [ ] UGC violations can be removed quickly and backed by a remediation plan\n- [ ] Kids and teens receive age-appropriate experiences inside the app\n- [ ] Parental gates for Kids Category apps\n- [ ] No false information or prank features\n- [ ] Medical disclaimers if applicable\n- [ ] No substance promotion\n\n### Performance (Section 2.x)\n- [ ] No crashes or bugs\n- [ ] All features complete and functional\n- [ ] No placeholder content\n- [ ] IPv6 tested and functional\n- [ ] Demo account provided if needed\n- [ ] Using only public APIs\n- [ ] No deprecated APIs\n- [ ] Proper background mode usage\n\n### Design (Section 4.x)\n- [ ] Sufficient native functionality (not just web wrapper)\n- [ ] No copycat concerns\n- [ ] Original app name and branding\n- [ ] No duplicate Bundle ID spam or low-effort saturated-category clones\n- [ ] Live Activities, push notifications, and Game Center are not used for spam, phishing, or unsolicited messages\n- [ ] Extensions comply with guidelines\n- [ ] Login alternatives if using social login\n- [ ] Not monetizing built-in capabilities\n\n### Legal (Section 5.x)\n- [ ] No unlicensed third-party content\n- [ ] Proper Apple trademark usage\n- [ ] Gambling license if applicable (with real location-based geo-restriction)\n- [ ] VPN uses NEVPNManager API\n- [ ] COPPA/GDPR compliance for kids\n- [ ] Review prompts use the system API only (no custom prompts)\n- [ ] No review, chart, search, or referral manipulation (5.6)\n\n---\n\n## References\n\n- [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)\n- [Apple Developer Program License Agreement](https://developer.apple.com/support/terms/apple-developer-program-license-agreement/)\n- [June 8, 2026 App Review Guidelines update](https://developer.apple.com/news/?id=a233fmpw)\n- [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/)\n- [App Store Connect Help](https://developer.apple.com/help/app-store-connect/)\n- [Apple Developer Documentation](https://developer.apple.com/documentation/)\n\n\n# Project Skill Notes\n\nStore project-specific skill supplements, routing notes, and reusable instructions here.\n\nThese files are not loaded automatically. Load a file only when the task matches its stated scope, such as TCA feature design, Swift 6 concurrency, macOS system effects, remote transport, widget integration, App Store review, or test strategy. Each file should begin with a short `When to load` section and should avoid duplicating general guidance that is not needed for the relevant task.\n\n\n# Agents Skill\n\nPath: `doc/skills/swift-concurrency-pro/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/agents/openai.yaml)\n\n\n# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/actors.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/actors.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/async-streams.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/async-streams.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/bridging.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/bridging.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/bug-patterns.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/bug-patterns.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/cancellation.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/cancellation.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/diagnostics.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/diagnostics.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/hotspots.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/hotspots.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/interop.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/interop.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/new-features.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/new-features.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/structured.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/structured.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/testing.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/testing.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-concurrency-pro/references/unstructured.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-concurrency-pro/references/unstructured.md)\n\n\n---\nname: swift-concurrency-pro\ndescription: Reviews Swift code for concurrency correctness, modern API usage, and common async/await pitfalls. Use when reading, writing, or reviewing Swift concurrency code.\nlicense: MIT\nmetadata:\n author: Paul Hudson\n version: \"1.0\"\n---\n\nReview Swift concurrency code for correctness, modern API usage, and adherence to project conventions. Report only genuine problems - do not nitpick or invent issues.\n\nReview process:\n\n1. Scan for known-dangerous patterns using `references/hotspots.md` to prioritize what to inspect.\n1. Check for recent Swift 6.2 concurrency behavior using `references/new-features.md`.\n1. Validate actor usage for reentrancy and isolation correctness using `references/actors.md`.\n1. Ensure structured concurrency is preferred over unstructured where appropriate using `references/structured.md`.\n1. Check unstructured task usage for correctness using `references/unstructured.md`.\n1. Verify cancellation is handled correctly using `references/cancellation.md`.\n1. Validate async stream and continuation usage using `references/async-streams.md`.\n1. Check bridging code between sync and async worlds using `references/bridging.md`.\n1. Review any legacy concurrency migrations using `references/interop.md`.\n1. Cross-check against common failure modes using `references/bug-patterns.md`.\n1. If the project has strict-concurrency errors, map diagnostics to fixes using `references/diagnostics.md`.\n1. If reviewing tests, check async test patterns using `references/testing.md`.\n\nIf doing a partial review, load only the relevant reference files.\n\n\n## Core Instructions\n\n- Target Swift 6.2 or later with strict concurrency checking.\n- If code spans multiple targets or packages, compare their concurrency build settings before assuming behavior should match.\n- Prefer structured concurrency (task groups) over unstructured (`Task {}`).\n- Prefer Swift concurrency over Grand Central Dispatch for new code. GCD is still acceptable in low-level code, framework interop, or performance-critical synchronous work where queues and locks are the right tool β don't flag these as errors.\n- If an API offers both `async`/`await` and closure-based variants, always prefer `async`/`await`.\n- Do not introduce third-party concurrency frameworks without asking first.\n- Do not suggest `@unchecked Sendable` to fix compiler errors. It silences the diagnostic without fixing the underlying race. Prefer actors, value types, or `sending` parameters instead. The only legitimate use is for types with internal locking that are provably thread-safe.\n\n\n## Output Format\n\nOrganize findings by file. For each issue:\n\n1. State the file and relevant line(s).\n2. Name the rule being violated.\n3. Show a brief before/after code fix.\n\nSkip files with no issues. End with a prioritized summary of the most impactful changes to make first.\n\nExample output:\n\n### DataLoader.swift\n\n**Line 18: Actor reentrancy β state may have changed across the `await`.**\n\n```swift\n// Before\nactor Cache {\n var items: [String: Data] = [:]\n\n func fetch(_ key: String) async throws -> Data {\n if items[key] == nil {\n items[key] = try await download(key)\n }\n return items[key]!\n }\n}\n\n// After\nactor Cache {\n var items: [String: Data] = [:]\n\n func fetch(_ key: String) async throws -> Data {\n if let existing = items[key] { return existing }\n let data = try await download(key)\n items[key] = data\n return data\n }\n}\n```\n\n**Line 34: Use `withTaskGroup` instead of creating tasks in a loop.**\n\n```swift\n// Before\nfor url in urls {\n Task { try await fetch(url) }\n}\n\n// After\ntry await withThrowingTaskGroup(of: Data.self) { group in\n for url in urls {\n group.addTask { try await fetch(url) }\n }\n\n for try await result in group {\n process(result)\n }\n}\n```\n\n### Summary\n\n1. **Correctness (high):** Actor reentrancy bug on line 18 may cause duplicate downloads and a force-unwrap crash.\n2. **Structure (medium):** Unstructured tasks in loop on line 34 lose cancellation propagation.\n\nEnd of example.\n\n\n## References\n\n- `references/hotspots.md` - Grep targets for code review: known-dangerous patterns and what to check for each.\n- `references/new-features.md` - Swift 6.2 changes that alter review advice: default actor isolation, isolated conformances, caller-actor async behavior, `@concurrent`, `Task.immediate`, task naming, and priority escalation.\n- `references/actors.md` - Actor reentrancy, shared-state annotations, global actor inference, and isolation patterns.\n- `references/structured.md` - Task groups over loops, discarding task groups, concurrency limits.\n- `references/unstructured.md` - Task vs Task.detached, when Task {} is a code smell.\n- `references/cancellation.md` - Cancellation propagation, cooperative checking, broken cancellation patterns.\n- `references/async-streams.md` - AsyncStream factory, continuation lifecycle, back-pressure.\n- `references/bridging.md` - Checked continuations, wrapping legacy APIs, `@unchecked Sendable`.\n- `references/interop.md` - Migrating from GCD, `Mutex`/locks, completion handlers, delegates, and Combine.\n- `references/bug-patterns.md` - Common concurrency failure modes and their fixes.\n- `references/diagnostics.md` - Strict-concurrency compiler errors, protocol conformance fixes, and likely remedies.\n- `references/testing.md` - Async test strategy with Swift Testing, race detection, avoiding timing-based tests.\n\n\n# Agents Skill\n\nPath: `doc/skills/swift-testing-pro/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/agents/openai.yaml)\n\n\n# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/async-tests.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/async-tests.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/core-rules.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/core-rules.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/migrating-from-xctest.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/migrating-from-xctest.md)\n\n\n# References Skill\n\nPath: `doc/skills/swift-testing-pro/references/new-features.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/jacklandrin/OnlySwitch/HEAD/doc/skills/swift-testing-pro/references/new-features.md)\n\n\n"}