# Pushengage

> Use when integrating, debugging, asking about, or auditing PushEngage push notifications in any mobile app (iOS, Android, Flutter, React Native). Detects the customer's platform and hands off to the matching platform spoke.

- Skill: `awesomemotive/pushengage` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add awesomemotive/pushengage`
- Raw SKILL.md: https://api.skillmd.com/api/skills/awesomemotive/pushengage/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- License: MIT
- Author: awesomemotive (https://skillmd.com/u/awesomemotive)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/awesomemotive/pushengage

---


# PushEngage — Entry Skill

This skill is the entry point for any PushEngage-related task. Its job is small and mechanical:

1. Detect which platform the customer's repo is.
2. Hand off to the matching platform spoke skill.
3. If multiple platforms are present (monorepo), ask the customer which one to work on this session.

**You don't answer PushEngage questions from here. You route.**

## Step 1 — Detect platform

Run these detection checks against the current working directory. Use a file-glob or shell `find` — do not read file contents yet.

| Platform | Detection markers (any one is sufficient) |
|---|---|
| **Flutter** (check FIRST) | `pubspec.yaml` containing a `flutter:` SDK block |
| **React Native** (check SECOND) | `package.json` containing a dependency on `react-native` or `expo` |
| **iOS** | `Podfile` · `Package.swift` · `**/*.xcodeproj` · `**/*.xcworkspace` |
| **Android** | `build.gradle` or `build.gradle.kts` at root AND `app/src/main/AndroidManifest.xml` |

**Precedence note:** Flutter and React Native projects also contain `ios/` and `android/` subfolders with their own Podfile / build.gradle. **Always check for Flutter and React Native FIRST.** A Flutter repo gets routed to `pushengage-flutter`, NOT to `pushengage-ios` or `pushengage-android`, even though those native markers exist. Same for React Native — route to `pushengage-react-native`.

Implementation hint:

```bash
# iOS
find . -maxdepth 4 \( -name "Podfile" -o -name "Package.swift" -o -name "*.xcodeproj" -o -name "*.xcworkspace" \) -print -quit
# Android
find . -maxdepth 4 \( -name "build.gradle" -o -name "build.gradle.kts" \) -print -quit
# Flutter
find . -maxdepth 4 -name "pubspec.yaml" -print -quit  # then grep -q "^  sdk: flutter" inside
# React Native
find . -maxdepth 4 -name "package.json" -print -quit  # then grep -q "react-native\|expo" inside
```

## Step 2 — Decide and hand off

| Detected | Action |
|---|---|
| Exactly **one** platform | Activate that platform's skill (below) and follow it. Use whatever mechanism your agent uses to load a skill by name; if your agent auto-activates skills by description, the matching `pushengage-<platform>` skill will already qualify — switch to it. Done. |
| **Multiple** platforms | Ask: "I see iOS and Android folders in this repo. Which platform are we working on this session?" Then activate that platform's skill. |
| **No** platforms detected | Ask: "I don't see iOS / Android / Flutter / React Native markers in this directory. Are you running this from the right folder?" Don't guess. |
| Platform whose skill isn't shipped yet | Tell the customer plainly: "This skill set currently covers iOS, Android, Flutter, and React Native. Your stack isn't supported." Don't fake it. |

Currently available platform skills:

- iOS → `pushengage-ios`
- Android → `pushengage-android`
- Flutter → `pushengage-flutter`
- React Native → `pushengage-react-native`

## Step 3 — Don't invent

Even after handing off, do not generate PushEngage API surface from training data. PushEngage is small enough that base-model recall is sparse or wrong. If the spoke doesn't cover what the customer is asking, say so and direct them to PushEngage support — don't fabricate.

## Cross-platform best practices

For best practices that apply regardless of platform (API key handling, permission timing, etc.), see `best-practices.md` in this skill folder. Spokes are encouraged to reference these rule IDs (`XP-BP-NN`) in their own audit findings.

## Dashboard-side tasks: the PushEngage MCP server

These skills cover **SDK integration and debugging in the customer's codebase**. Account-side operations — sending or scheduling notifications, creating segments, reading analytics, changing site settings — are handled by the official PushEngage MCP server (`@pushengage/mcp`), whose tools appear with names like `mcp__pushengage__*` when it is connected (the Claude Code plugin configures it automatically; other agents can add it from `https://github.com/awesomemotive/pushengage-mcp`).

- If the customer asks for a dashboard-side task and the MCP tools are available, use them.
- During debugging, the MCP tools can verify account-side state (site config, campaign payloads) that the code alone can't show — prefer that over asking the customer to screenshot the dashboard.
- If the MCP tools are not available, do NOT fabricate dashboard state. Tell the customer the steps to do it in the dashboard UI, or point them at the MCP server.
- First MCP use triggers a browser login to the customer's PushEngage account — that prompt is expected, not an error.

## Concepts

If you are not sure what a PushEngage term means (site, subscriber, profile ID, segment, App ID vs App Push Id, integration key, hash), read `concepts.md` in this skill folder. Don't guess.