{userName}

{streakCount}

{lastWorkoutType}

{dailyGoalProgress}

{nextScheduledEvent}

• If the user provides all the details upfront in their first message (app name, journeys, variables, etc.), don't re-ask what you already know. Confirm your understanding and fill any gaps with targeted follow-ups.
• If the user gives vague answers ("it's a fitness app"), probe deeper — what kind of fitness? Gym workouts, running, yoga, general wellness?
• If they mention user properties, ask about the data type and where it lives in their code
• Don't ask all questions at once. Start with app basics, then drill into journeys and variables naturally
• 2–3 rounds of questions is usually enough. Don't over-interview.

1. A gentle nudge 2 hours after signup if the user hasn't started
2. A motivational message the next morning
3. A "your plan is waiting" reminder 48 hours after signup
4. A final "we miss you" message at day 5 if they still haven't engaged

• Respect existing notifications: If the app already has local push notifications (from Phase 1), weave them into your campaigns. Don't create duplicates. If an existing notification fits naturally into a campaign, include it as-is (or suggest improvements, noting the change).
• Vary the approaches: Don't make all campaigns about the same thing. Spread across different parts of the user lifecycle — onboarding, habit formation, re-engagement, milestone celebration, etc.
• Be specific about timing: Don't say "send after some time." Say "send 2 hours after the user completes signup, between 9am–9pm local time." Timing should account for the user's timezone and reasonable hours.
• Personalize aggressively: Use personalization variables in as many messages as possible — the more personal, the better. Prefer

  "Hey {userName}, ready for {nextWorkoutName}?"

  over generic copy. Weave in user preferences, progress data, streaks, and recent activity wherever it feels natural. A notification that feels written for the user gets tapped; a generic one gets ignored.
• Titles must be glanceable: Users scan notification titles in under a second. Keep titles short enough to display fully without truncation on any device — aim for under 35 characters. No ellipsis, ever. If you can't say it in 35 characters, simplify.
• Bodies should be compact: The body supports the title with one clear, punchy sentence. Stay under 90 characters. Don't pad with filler words. Every word should earn its place.
• Never repeat content across messages: Every message in a campaign — and across campaigns — must say something different. Different angle, different emotion, different variable, different call to action. If two messages could be confused for each other, rewrite one. Users notice repetition and it signals laziness, which erodes trust in the app.
• Each campaign should have 2–5 messages: Fewer than 2 isn't a "campaign," more than 5 risks notification fatigue.

references/json-schemas.md

campaigns

• A clear campaign name and purpose
• The target audience (who should receive this campaign and under what conditions)
• Each message with: title, body, trigger condition, timing, delay from previous message or trigger event, delivery window (time of day), and which personalization variables it uses
• Cancel conditions — when should the campaign stop (e.g., user completed the target action)

.clix-campaigns/app-profile.json

Here are the campaigns I've designed. Which would you like me to implement?

1. ✅ First Workout Onboarding — nudge new users toward their first workout
2. ✅ Streak Protection — remind users who are about to lose a streak
3. ✅ Weekly Progress — celebrate weekly achievements
4. ✅ Re-engagement — bring back users who've been away 3+ days

Let me know if you want to remove any, or if you'd like changes before I implement.

.clix-campaigns/app-profile.json

1. Identify the platform from the app profile (iOS/Android/Flutter/React Native)
2. Ask the user to share their project if they haven't already. You need access to the actual codebase to make direct edits.
3. Explore the project structure — find existing notification code, app delegate / main activity, and where scheduling logic should live
4. Check for existing notification setup — is the notification permission already requested? Is there a notification manager/service class? Build on what exists.

1. Notification Manager/Service: A central class that handles all campaign scheduling, cancellation, and tracking. This is the brain of the system.
2. Campaign definitions: The campaign data — messages, timing, triggers — structured so they're easy to update without touching scheduling logic.
3. Trigger integration: Hook into the appropriate places in the app to start/cancel campaigns (e.g., after signup, after completing an action, when the app opens).
4. Permission handling: Ensure notification permission is requested at the right moment (not on first launch — after the user understands the app's value).

• Don't break existing code. Read the codebase carefully before making changes. Integrate with existing patterns and architecture.
• Keep campaign data separate from scheduling logic. This makes it easy to add/modify campaigns later without touching core logic.
• Handle edge cases: What if the user completes the target action between messages? The campaign should cancel gracefully. What if the app is reinstalled? Don't re-send already-seen messages.
• Respect quiet hours: Only deliver between 9am–9pm local time unless the user specifies otherwise.
• Include clear code comments explaining what each part does, especially the timing logic.

1. Summarize what files were created or modified
2. Explain how to test the notifications (platform-specific testing tips)
3. Note any additional setup needed (e.g., adding a package dependency, enabling a capability in Xcode, updating AndroidManifest.xml)
4. Suggest how to verify the campaigns are working correctly