/generate-ppmplugin

name: generate-ppmplugin
description: Build and verify a third-party `.ppmplugin` end to end. This recommended entry point detects Android and iOS source, confirms target platforms, then invokes the manifest, platform build, assemble, and audit stages in order. Advanced users can invoke a stage directly for focused reruns or debugging. Produces a native-only bundle (`manifest.json` plus an Android DEX and/or iOS framework) and stops on any failed stage rather than emitting an unverified partial build. Run after the native module exists.
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, Skill
model: sonnet

/generate-ppmplugin

**The recommended entry point** for the third-party-control build track. In the normal flow, the user invokes `/generate-ppmplugin` and it drives the five stage skills (`/generate-ppmplugin-manifest`, `/build-android-binary`, `/build-ios-binary`, `/assemble-ppmplugin`, `/audit-ppmplugin`) in order. Advanced users may invoke a stage directly to rerun or debug only that stage. Inspect the repo, pick the right target set, run manifest → build skill(s) → assemble → audit in sequence, and produce a *verified* `.ppmplugin` on disk (or a clear stop with the failing stage).

Read [`shared/ppmplugin-format.md`](../../shared/ppmplugin-format.md) §1 — the bundle layout this orchestrator produces.

What this skill does NOT do

• Does not author the manifest, build the DEX, build the framework, zip the bundle, or run the audit itself — those are the stage skills. This skill **invokes** them in the right order, with the right inputs, and gates between them.
• Does not skip any stage's confirmations / mismatch gates / replace-existing prompts — those still surface to the user. The orchestrator just removes the "which stage next?" decision so the user never has to invoke a stage directly.
• Does not upload to Dataverse or wire into a canvas app (Stage 3 — deferred).
• Does not edit source code under `src/`, `ios/`, `android/` — every stage builds from a staged copy. The repo is read-only from the build's perspective.

---

Step 1 — Read shared docs + prereq summary

1. Read [`shared/shared-instructions.md`](../../shared/shared-instructions.md) and [`shared/ppmplugin-format.md`](../../shared/ppmplugin-format.md). 2. Confirm the working directory is a third-party-control repo: a `package.json` (dev-only `<kebab>-control` name — **not** a published `@powerapps/extension-*` scope; this track ships a binary, not an npm package) and either `android/` or `ios/` (or both). If missing, STOP with `NEEDS_CONTEXT: not a third-party-control-ready repo — missing <list>` and point at [`shared/repo-layout.md`](../../shared/repo-layout.md). 3. Print the orchestrator prereq block (sub-skills each re-run their own prereq check when invoked — this is the summary the user sees up front so they know what's required end-to-end):

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Prereqs — /generate-ppmplugin (end-to-end)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 /generate-ppmplugin-manifest  — no toolchain (pure read + validate + write)
 /build-android-binary         — JDK 17, Android SDK Build-Tools 35 (d8), Gradle
 /build-ios-binary             — Xcode 16+ (26.2+ recommended; CocoaPods optional — header-only path)  (Mac-only)
 /assemble-ppmplugin           — jar (JDK)
 /audit-ppmplugin              — jar (JDK); dexdump or strings (DEX scan)

Each stage will surface its own prereq failure when reached (don't pre-fail the orchestrator on a missing tool the user may have on a different machine).

---

Step 2 — Detect available targets

Look at the repo to see which native platforms could actually build. **Detection is structural, not aspirational** — the user can't ship a platform whose source doesn't exist.

| Target | Detection signal | |---|---| | Android | `android/build.gradle` exists AND `android/src/main/java/**/*.kt` contains a `ReactContextBaseJavaModule` subclass | | iOS | `ios/RCT*Module.h` declaring `<RCTBridgeModule>` AND a `.m` with `+ (NSString *)moduleName` (**NOT** `RCT_EXPORT_MODULE`) (podspec **optional** — only declares extra iOS system frameworks; `/build-ios-binary` builds from the `.h/.m` source + the `react-native` devDep headers, not the podspec) |

Print a visible ✓/✗ block:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Targets available in this repo
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 🟢 ✓ Android — android/build.gradle + PenInputModule.kt found
 🟢 ✓ iOS     — ios/RCTPenInputModule.h (+ .m with +moduleName) found

(If a signal is present but malformed — e.g. `android/` exists but no Kotlin module — list it as ✗ with the specific gap. `/generate-ppmplugin-manifest` will run the deeper structure preflight; this orchestrator just sees if there's enough to consider the platform a viable target.)

If neither target is viable → STOP with `NEEDS_CONTEXT: no native target available — repo has neither a buildable android/ nor ios/ module`. The `.ppmplugin` format requires at least one native entrypoint; a manifest-only bundle is not shippable.

---

Step 3 — Recommend + confirm the target set

Use the detection from Step 2 to pre-mark the recommended option, then confirm with `AskUserQuestion`:

• **Both available** → recommend **Both**. Reasoning: the whole pipeline runs in one shot; the user gets a bundle that works on every mobile platform.
• **Android only available** → recommend **Android-only**. No iOS source to build.
• **iOS only available** → recommend **iOS-only**. No Android source to build.

Question: Which target(s) should this .ppmplugin ship?
- Both (Recommended)           — runs /build-android-binary AND /build-ios-binary
- Android only                  — skips iOS even though the source is here
- iOS only                      — skips Android even though the source is here

Only show options whose target is viable. If only Android is viable, do not offe