Update to Expo

{
  "name": "expo-module",
  "description": "Framework (OSS). Guide for creating and writing Expo native modules and views using the Expo Modules API (Swift, Kotlin, TypeScript). Covers module definition DSL, native views, shared objects, config plugins, lifecycle hooks, autolinking, and type system. Use when building or modifying native modules for Expo. Not for migrating an existing Swift module from the definition DSL to the Expo Modules API 2.0 macros; use expo-migrate-module (from the expo-experiments plugin) for that.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 367
    },
    {
      "relative_path": "references/config-plugin.md",
      "size_in_bytes": 2040
    },
    {
      "relative_path": "references/create-expo-module.md",
      "size_in_bytes": 10075
    },
    {
      "relative_path": "references/lifecycle.md",
      "size_in_bytes": 3763
    },
    {
      "relative_path": "references/module-config.md",
      "size_in_bytes": 1762
    },
    {
      "relative_path": "references/native-module.md",
      "size_in_bytes": 5869
    },
    {
      "relative_path": "references/native-view.md",
      "size_in_bytes": 3590
    }
  ],
  "skill_md_contents": "---\nname: expo-module\ndescription: Framework (OSS). Guide for creating and writing Expo native modules and views using the Expo Modules API (Swift, Kotlin, TypeScript). Covers module definition DSL, native views, shared objects, config plugins, lifecycle hooks, autolinking, and type system. Use when building or modifying native modules for Expo. Not for migrating an existing Swift module from the definition DSL to the Expo Modules API 2.0 macros; use expo-migrate-module (from the expo-experiments plugin) for that.\nversion: 1.0.0\nlicense: MIT\n---\n\n# Writing Expo Modules\n\nComplete reference for building native modules and views using the Expo Modules API. Covers Swift (iOS), Kotlin (Android), and TypeScript.\n\n## When to Use\n\n- Creating a new Expo native module or native view\n- Adding native functionality (camera, sensors, system APIs) to an Expo app\n- Wrapping platform SDKs for React Native consumption\n- Building config plugins that modify native project files\n- Adding Android, Apple, or web support to an existing Expo module\n- Editing `expo-module.config.json`, config plugins, or lifecycle hooks\n\nTo migrate an existing Swift module from the definition DSL to the Expo Modules API 2.0 macros (`@ExpoModule`, `@JS`, `@Event`), use the `expo-migrate-module` skill (from the `expo-experiments` plugin) instead.\n\n## References\n\nConsult these resources as needed:\n\n```\nreferences/\n  create-expo-module.md      Scaffolding and add-platform-support workflow, defaults, and quirks\n  native-module.md           Module definition DSL: Name, Function, AsyncFunction, Property, Constant, Events, type system, shared objects\n  native-view.md             Native view components: View, Prop, EventDispatcher, view lifecycle, ref-based functions\n  lifecycle.md               Lifecycle hooks: module, iOS app/AppDelegate, Android activity/application listeners\n  config-plugin.md           Config plugins: modifying Info.plist, AndroidManifest.xml, reading values in native code\n  module-config.md           expo-module.config.json fields, file placement, and autolinking behavior\n```\n\n## Quick Start\n\nPrefer `create-expo-module` over manually creating native module files and directories. In practice, the best path is usually to create the scaffold first and then build on top of it. The scaffold sets up the expected layout, `expo-module.config.json`, podspec or Gradle files, TypeScript bindings, and the standalone example app flow.\n\nIf an existing Expo module only needs another platform, use `create-expo-module add-platform-support` instead of manually copying native directories.\n\nSee [references/create-expo-module.md](references/create-expo-module.md) before scaffolding or extending a module. It covers:\n\n- local vs standalone modules\n- `--platform`, `--features`, `--barrel`, `--package-manager`, and non-interactive mode\n- `expo.autolinking.nativeModulesDir`\n- `add-platform-support` behavior and quirks\n\n## Recommended Workflow\n\n1. Choose the scaffold type first:\n   - **Local module** for one app\n   - **Standalone module** for reuse, monorepos, or publishing\n2. Determine native `expo-module` features that you will need.\n   - Based on the user's instructions determine which feature scaffolding will be useful.\n   - Available features: `Constant`, `Function`, `AsyncFunction`, `Event`, `View`, `ViewEvent`, `SharedObject`\n3. Scaffold deliberately:\n   - pass an explicit slug or path\n   - choose `--platform` intentionally instead of relying on defaults\n   - use `--features` to choose code samples which you will modify in the next step to match the real implementation.\n4. Replace generated example code with the real implementation.\n5. If you add a new platform later, prefer `add-platform-support` over manual file copying.\n\n## Practical Scaffolding Rules\n\n- Feature examples are **opt-in**. A newly scaffolded module may be minimal if no features were selected.\n- `ViewEvent` implies `View`.\n- Local modules do **not** generate an `index.ts` barrel by default. Use `--barrel` only if you want one.\n- In non-interactive local scaffolding, pass the positional slug or path explicitly. `--name` changes the native class name, not the folder name.\n- Local modules live in `expo.autolinking.nativeModulesDir` when configured, otherwise in `modules/`.\n- Standalone modules have their own package metadata, scripts, and usually an example app. Local modules use the host app's tooling instead.\n\n## Core File Shapes\n\nThe Swift and Kotlin DSL share the same structure. Swift is usually the clearest primary example; consult the references for feature-specific details.\n\n## Module Structure Reference\n\nThe Swift and Kotlin DSL share the same structure. Both platforms are shown here for reference — in other reference files, Swift is shown as the primary language unless the Kotlin pattern meaningfully differs.\n\n**Swift (iOS):**\n\n```swift\nimport ExpoModulesCore\n\npublic class MyModule: Module {\n  public func definition() -> ModuleDefinition {\n    Name(\"MyModule\")\n\n    Function(\"hello\") { (name: String) -> String in\n      return \"Hello \\(name)!\"\n    }\n  }\n}\n```\n\n**Kotlin (Android):**\n\n```kotlin\npackage expo.modules.mymodule\n\nimport expo.modules.kotlin.modules.Module\nimport expo.modules.kotlin.modules.ModuleDefinition\n\nclass MyModule : Module() {\n  override fun definition() = ModuleDefinition {\n    Name(\"MyModule\")\n\n    Function(\"hello\") { name: String ->\n      \"Hello $name!\"\n    }\n  }\n}\n```\n\n**TypeScript:**\n\n```typescript\nimport { requireNativeModule } from \"expo\";\n\nconst MyModule = requireNativeModule(\"MyModule\");\n\nexport function hello(name: string): string {\n  return MyModule.hello(name);\n}\n```\n\n### expo-module.config.json\n\n```json\n{\n  \"platforms\": [\"android\", \"apple\"],\n  \"apple\": {\n    \"modules\": [\"MyModule\"]\n  },\n  \"android\": {\n    \"modules\": [\"expo.modules.mymodule.MyModule\"]\n  }\n}\n```\n\nNote: iOS uses just the class name; Android uses the fully-qualified class name (package + class). See `references/module-config.md` for all fields.\n\n## Submitting Feedback\nIf you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:\n```bash\nnpx --yes submit-expo-feedback@latest --category skills --subject \"expo-module\" \"<actionable feedback>\"\n```\nOnly submit when you have something specific and actionable to report. Include as much relevant context as possible.\nIf an AI agent repeatedly failed or the user had to take over an Expo task, load the expo-skill-feedback skill and follow its eval-candidate flow instead of reusing the command above.\n"
}