generate-ppmplugin

# /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.

```text
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 offer "Both" or "iOS only" — just confirm "Android-only" (one option is still worth confirming so the user can cancel).

**On Mac-only constraint:** if the user picks Both or iOS-only on a non-Mac, surface a one-line warning (`/build-ios-binary` is Mac-only and will halt the orchestrator when reached). Offer to fall back to Android-only or stop.

Record the chosen target set; it's the contract every downstream sub-skill sees.

---

## Step 4 — Run the stages in sequence (with gates)

Invoke each stage via the `Skill` tool. After each step, check its result; on `DONE` continue, on `BLOCKED` / `NEEDS_CONTEXT` halt the orchestrator with a