@leejungkiin/awkit 1.1.4 → 1.1.7

package/skills/swiftui-pro/references/design.md

@@ -29,3 +29,47 @@ Prefer to place standard fonts, sizes, colors, stack spacing, padding, rounding,
 - Avoid hard-coded values for padding and stack spacing unless specifically requested.
 - Avoid UIKit colors (`UIColor`) in SwiftUI code; use SwiftUI `Color` or asset catalog colors.
 - The font size `.caption2` is extremely small, and is generally best avoided. Even the font size `.caption` is on the small side, and should be used carefully.
+
+
+## Dark Mode Color Safety Rules
+
+These rules prevent common dark mode bugs that are invisible in light mode development.
+
+### 1. Never use hardcoded `Color.white` or `Color.black` for backgrounds or fills
+- **Bad**: `.fill(Color.white)`, `.background(Color.black)`
+- **Good**: `.fill(ColorPalette.darkCard)`, `.background(ColorPalette.backgroundPrimary)`
+- **Exception**: White/black on a NON-adaptive surface (e.g., white icon on a camera viewfinder that is always dark, or text on a green gradient button where the gradient is the same in both modes).
+
+### 2. Never pair `.foregroundColor(.white)` with an adaptive fill
+- If a button uses an adaptive fill like `ColorPalette.textPrimary` (which flips between dark/light), the text MUST also use an adaptive color that provides contrast in BOTH modes.
+- **Bad**: `.fill(ColorPalette.textPrimary)` + `.foregroundColor(.white)` — in dark mode, textPrimary ≈ #EDEDED and .white = #FFFFFF → invisible text!
+- **Good**: `.fill(ColorPalette.textPrimary)` + `.foregroundColor(ColorPalette.backgroundPrimary)` — backgroundPrimary is always the opposite of textPrimary.
+- **Rule of thumb**: If fill is adaptive, text color MUST be its inverse adaptive token.
+
+### 3. Static background images (PNG/JPG) don't adapt to dark mode
+- Background images with light themes (e.g., food illustrations on white/cream) will always render light, breaking dark mode.
+- **Fix options**:
+  - Provide dark variants in the Asset catalog and use `@Environment(\.colorScheme)` to switch.
+  - Reduce opacity in dark mode: `.opacity(colorScheme == .dark ? 0.08 : 1.0)`.
+  - Apply a dark overlay or color multiply blend.
+- **Exception**: Screenshot/mockup images displayed inside a dark phone frame (the frame provides context).
+
+### 4. Always verify contrast between text and its immediate background
+- When reading code, mentally resolve what every color token becomes in BOTH modes.
+- Common trap: Card background = `#272727` (dark gray in dark mode), button fill = `#EDEDED` (light in dark mode), text on button = `.white` → barely visible.
+- **Paired tokens for high contrast**:
+  - Fill: `textPrimary` ↔ Text: `backgroundPrimary`
+  - Fill: `darkCard` ↔ Text: `textPrimary`
+  - Fill: `primaryGreen` ↔ Text: `.white` (green is always green)
+
+### 5. Shadow colors must be adaptive
+- **Bad**: `.shadow(color: Color.black.opacity(0.1), ...)`
+- **Good**: `.shadow(color: ColorPalette.shadowLight, ...)` or `.shadow(color: ColorPalette.textPrimary.opacity(0.08), ...)`
+- In dark mode, black shadows on dark backgrounds are invisible; use lighter shadow tokens or skip shadows entirely.
+
+### 6. Quick dark mode audit checklist
+When writing or reviewing any SwiftUI view:
+1. `grep -n 'Color\.white\|Color\.black\|\.white\b' FileName.swift` — find all hardcoded colors.
+2. For each hit, ask: "Does this element sit on an adaptive background?" If yes → replace with adaptive token.
+3. Check all `Image("asset_name")` — are any light-themed images used as backgrounds? If yes → add dark mode handling.
+4. For every button: verify fill color + text color provide 4.5:1 contrast ratio in BOTH modes.

package/skills/symphony-enforcer/SKILL.md

@@ -4,10 +4,10 @@ description: |
   Mandatory Symphony checkpoint system. Ensures AI never forgets to create,
   update, or complete tasks in Symphony. Enforces progress reporting at every
   milestone and auto-detects task completion without waiting for user confirmation.
-  v3.1: Pre-Plan Gate, Auto-Lifecycle, Auto-Next, Atomic Git Commits.
+  v3.3: Completion Status Protocol, Search-Before-Building, Boil-the-Lake.
 metadata:
   stage: core
-  version: "3.1"
+  version: "3.3"
   replaces: "v2.0"
   requires: symphony-orchestrator
   tags: [symphony, enforcement, checkpoint, task-lifecycle, core, spec-first, auto-next]
@@ -24,14 +24,16 @@ invocation-type: auto
 priority: 1
 ---
 
-# Symphony Enforcer v3.1 — Spec-First + Auto-Lifecycle + Auto-Next + Atomic Commits
+# Symphony Enforcer v3.3 — Completion Status Protocol + Gstack Principles
 
 > **Purpose:** Đảm bảo AI KHÔNG BAO GIỜ quên cập nhật Symphony.
-> **Key Changes v3.1:**
+> **Key Changes v3.3:**
+> - **Completion Status Protocol**: 4-status (DONE/DONE_WITH_CONCERNS/BLOCKED/NEEDS_CONTEXT)
+> - **Design Compliance (TP1.5)**: Đối chiếu schema changes vs approved design doc
 > - **Pre-Plan Gate**: Đọc spec trước khi plan, hỏi user về constraints
 > - **Auto-Lifecycle**: Liên kết task_boundary ↔ Symphony tự động
 > - **Auto-Next**: BẮT BUỘC gợi ý next steps sau mỗi task done
-> - **Atomic Git Commits**: Tự động commit sau mỗi task done (NEW v3.1)
+> - **Atomic Git Commits**: Tự động commit sau mỗi task done
 > **Principle:** AI tự detect completion — user KHÔNG CẦN nói "xong".
 
 ---
@@ -168,7 +170,48 @@ symphony_report_progress(
 
 ---
 
-### TP2: Task Complete — Auto-detect
+### TP1.5: Design Compliance Check (NEW v3.2 — Gate 4 Enforcement)
+
+**Khi nào:** Mỗi khi AI sửa file liên quan đến DB/Model/Schema trong EXECUTION mode.
+
+**Trigger signals:**
+```
+File patterns:
+  - **/models/**,  **/entities/**,  **/schemas/**
+  - **Migration*, **Schema*, **Model*
+  - *.entity.*, *.model.*, *.schema.*
+  - Database.swift, AppDatabase.swift, schema.prisma, etc.
+```
+
+**Action:**
+```
+1. Kiểm tra: docs/architecture/<feature>_design.md tồn tại?
+   → KHÔNG → ⚠️ Warning: "Đang sửa model file nhưng chưa có approved design.
+     Recommend chạy spec-gate trước."
+     → Nếu COMPLEX task → ⛔ DỪNG, enforce Gate 2
+     → Nếu TRIVIAL/MODERATE → Warning only, tiếp tục
+
+2. Đối chiếu thay đổi vs approved design:
+   → Thêm field KHÔNG có trong design? → ⛔ DỪNG
+   → Đổi type khác design? → ⛔ DỪNG
+   → Xóa field trong design? → ⛔ DỪNG
+   → Thêm field CÓ trong design? → ✅ OK
+
+3. Khi DỪNG:
+   → Thông báo: "Schema change ngoài approved design detected.
+     [field_name] không có trong docs/architecture/<feature>_design.md.
+     Quay lại Gate 2 để update design trước nhé."
+   → Kích hoạt spec-gate skill để update design doc
+   → Sau khi re-approve → tiếp tục code
+```
+
+**Enforcement:**
+- ❌ KHÔNG tự ý thêm cột/bảng ngoài approved design cho COMPLEX tasks
+- ✅ NÊN ghi lại mọi deviation attempt vào NeuralMemory cho future reference
+
+---
+
+### TP2: Task Complete — Completion Status Protocol
 
 **Khi nào:** AI detect ≥2/4 completion signals:
 
@@ -179,13 +222,62 @@ Signal 3: Tất cả checklist items trong task.md đã [x]
 Signal 4: Verification pass (tests OK, build OK)
 ```
 
-**Action:**
+**Completion Status Protocol (4 statuses):**
+
+```
+DONE:
+  Điều kiện: Verification pass, không caveats.
+  Action: symphony_complete_task với evidence.
+  Format: "✅ DONE — {summary}. Build: ✅. Tests: ✅ N/N."
+
+DONE_WITH_CONCERNS:
+  Điều kiện: Code hoạt động nhưng có caveats/risks cần biết.
+  Action: Complete task NHƯNG ghi rõ concerns.
+  Format: "⚠️ DONE_WITH_CONCERNS — {summary}.
+    Concerns: [list cụ thể]
+    Risk: [mức độ ảnh hưởng]
+    Recommendation: [đề xuất xử lý]"
+  Ví dụ: "Feature works nhưng chưa handle offline mode."
+  Ví dụ: "API call thành công nhưng chưa có retry logic."
+
+BLOCKED:
+  Điều kiện: Không thể tiếp tục vì external dependency/blocker.
+  Action: KHÔNG complete task. Report + list attempts.
+  Format: "🚫 BLOCKED — {reason}.
+    Attempted: [list things đã thử]
+    Needs: [what's needed to unblock]"
+  Ví dụ: "API endpoint return 500, đã retry 3 lần."
+
+NEEDS_CONTEXT:
+  Điều kiện: Thiếu thông tin từ user để tiếp tục.
+  Action: KHÔNG complete task. Hỏi user cụ thể.
+  Format: "❓ NEEDS_CONTEXT — {what's missing}.
+    Question: [câu hỏi cụ thể]
+    Options: [list options nếu có]"
+  Ví dụ: "Cần user clarify: offline-first hay online-only?"
+```
+
+⛔ **KHÔNG BAO GIỜ report DONE nếu thực tế là DONE_WITH_CONCERNS hoặc BLOCKED.**
+
+**Action (cho DONE status):**
 ```
+0. ⚡ VERIFICATION GATE (BẮT BUỘC — Iron Law):
+   - IDENTIFY: What command proves this task is done?
+   - RUN: Execute verification (build, test, lint)
+   - READ: Full output, check exit code
+   - VERIFY: Does output confirm completion?
+   - If NO → FIX trước, KHÔNG complete task
+   - If YES → Proceed with evidence
+   ⛔ Skip verification = VI PHẠM (xem verification-gate skill)
+
 1. symphony_complete_task(
      task_id=current_task,
-     summary="mô tả ngắn kết quả"
+     summary="mô tả ngắn + STATUS + VERIFICATION EVIDENCE"
+     // ✅ "DONE — Implemented X. Build: ✅ exit 0. Tests: ✅ 47/47."
+     // ✅ "DONE_WITH_CONCERNS — Implemented X. Build: ✅. Concerns: no offline support."
+     // ❌ "Implemented X" (không status, không evidence)
    )
-2. Hiển thị: "✅ SYM #sym-XYZ — Done"
+2. Hiển thị: "✅ SYM #sym-XYZ — {STATUS}"
 3. → TRIGGER TP2.5 (Atomic Git Commit)
 4. → TRIGGER TP4 (Auto-Next) NGAY LẬP TỨC
 ```

package/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: systematic-debugging
+description: Use for ANY technical issue - bugs, test failures, build errors, crashes. Enforces 4-phase root cause process before any fix attempts. Auto-triggers on /debug, error detection, test failures.
+---
+
+# Systematic Debugging
+
+## Overview
+
+Random fixes waste time and create new bugs. Quick patches mask underlying issues.
+
+**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
+
+## The Iron Law
+
+```
+NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
+```
+
+If you haven't completed Phase 1, you CANNOT propose fixes.
+
+## When to Use
+
+Use for ANY technical issue:
+- Test failures
+- Runtime crashes / EXC_BAD_ACCESS / ANR
+- Unexpected behavior
+- Performance problems
+- Build failures (Xcode, Gradle, npm)
+- Integration issues (API, SDK, Firebase)
+
+**Use this ESPECIALLY when:**
+- Under time pressure (emergencies make guessing tempting)
+- "Just one quick fix" seems obvious
+- You've already tried multiple fixes
+- Previous fix didn't work
+- You don't fully understand the issue
+
+## The Four Phases
+
+You MUST complete each phase before proceeding to the next.
+
+### Phase 1: Root Cause Investigation (BEFORE ANY FIX)
+
+1. **Read Error Messages Carefully**
+   - Don't skip past errors or warnings
+   - Read stack traces COMPLETELY — they often contain the exact answer
+   - Note line numbers, file paths, error codes
+   - For iOS: read the full crash log, not just the top frame
+   - For Android: read logcat with proper filters
+
+2. **Reproduce Consistently**
+   - Can you trigger it reliably? What are the exact steps?
+   - If not reproducible → gather more data, DON'T guess
+   - For intermittent: add diagnostic logging at component boundaries
+
+3. **Check Recent Changes**
+   - `git diff` — what changed?
+   - Recent commits, new dependencies, config changes
+   - Environmental differences (device, OS version, network)
+
+4. **Gather Evidence in Multi-Component Systems**
+   ```
+   For EACH component boundary:
+     - Log what data enters component
+     - Log what data exits component  
+     - Verify environment/config propagation
+     - Check state at each layer
+   
+   Run once to gather evidence showing WHERE it breaks
+   THEN analyze evidence to identify failing component
+   THEN investigate that specific component
+   ```
+
+5. **Trace Data Flow**
+   - Where does the bad value originate?
+   - What called this with the bad value?
+   - Keep tracing UP until you find the source
+   - **Fix at source, not at symptom**
+
+### Phase 2: Pattern Analysis
+
+1. **Find Working Examples** — Locate similar working code in same codebase
+2. **Compare Against References** — Read reference implementation COMPLETELY (don't skim)
+3. **Identify Differences** — List EVERY difference, however small
+4. **Understand Dependencies** — What components, settings, config does this need?
+
+### Phase 3: Hypothesis & Testing
+
+1. **Form Single Hypothesis** — "I think X is the root cause because Y"
+2. **Test Minimally** — SMALLEST possible change. One variable at a time
+3. **Verify Before Continuing** — Worked? → Phase 4. Didn't? → NEW hypothesis
+4. **When You Don't Know** — Say "I don't understand X". Don't pretend. Research more
+
+### Phase 4: Implementation
+
+1. **Create Failing Test Case** — Simplest possible reproduction. MUST have before fixing
+2. **Implement Single Fix** — ONE change at a time. No "while I'm here" improvements
+3. **Verify Fix** — Test passes? No other tests broken? Issue actually resolved?
+
+## The 3-Strike Escalation Protocol
+
+```
+If 3+ fixes have FAILED → STOP. ESCALATE. NO EXCEPTIONS.
+
+This is NOT a failed hypothesis.
+This is a WRONG ARCHITECTURE.
+```
+
+**Escalation Protocol (BẮT BUỘC sau 3 failed attempts):**
+
+```
+1. STOP — Không thử fix thứ 4.
+2. REPORT full context cho user:
+   🚫 ESCALATION — 3 fix attempts failed
+   ─────────────────────────────────────
+   Attempt 1: {what tried} → {why failed}
+   Attempt 2: {what tried} → {why failed}
+   Attempt 3: {what tried} → {why failed}
+   
+   Root Cause Hypothesis: {current best guess}
+   Architectural Concern: {pattern detected}
+   
+   Recommended: [refactor approach | seek expert | alternative solution]
+   ─────────────────────────────────────
+3. WAIT for user decision — do NOT proceed autonomously.
+```
+
+**Pattern indicating architectural problem:**
+- Each fix reveals new shared state/coupling
+- Fixes require "massive refactoring" to implement
+- Each fix creates new symptoms elsewhere
+
+## Scope Freeze During Debug
+
+```
+Khi đang debug một issue:
+- KHÔNG sửa bug khác "tiện tay"
+- KHÔNG refactor code xung quanh
+- KHÔNG thêm feature "nhân tiện"
+- CHỈ tập trung vào root cause hiện tại
+
+Violation → revert side changes, focus on current scope
+```
+
+## Red Flags — STOP and Return to Phase 1
+
+If you catch yourself thinking:
+- "Quick fix for now, investigate later"
+- "Just try changing X and see if it works"
+- "It's probably X, let me fix that"
+- "I don't fully understand but this might work"
+- "Here are the main problems: [lists fixes without investigation]"
+- Proposing solutions before tracing data flow
+- **"One more fix attempt" (when already tried 2+)**
+- **Each fix reveals new problem in different place**
+
+**ALL of these mean: STOP. Return to Phase 1.**
+
+## Anti-Rationalization Table
+
+| Excuse | Reality |
+|--------|---------|
+| "Issue is simple, don't need process" | Simple issues have root causes too. Process is fast for simple bugs |
+| "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check |
+| "Just try this first, then investigate" | First fix sets the pattern. Do it right from the start |
+| "I'll write test after confirming fix" | Untested fixes don't stick. Test first proves it |
+| "Multiple fixes at once saves time" | Can't isolate what worked. Causes new bugs |
+| "I see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause |
+| "One more fix attempt" (after 2+) | 3+ failures = architectural problem. Question pattern |
+| "Reference too long, I'll adapt" | Partial understanding guarantees bugs. Read completely |
+
+## Quick Reference
+
+| Phase | Key Activities | Success Criteria |
+|-------|---------------|------------------|
+| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence | Understand WHAT and WHY |
+| **2. Pattern** | Find working examples, compare | Identify differences |
+| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |
+| **4. Implementation** | Create test, fix, verify | Bug resolved, tests pass |
+
+## NeuralMemory Integration
+
+After fixing a bug:
+1. `nmem_remember` the root cause, fix, and pattern — tag with projectId
+2. Before debugging NEW bugs: `nmem_recall` for similar past issues
+3. Saves hours on recurring patterns
+
+## Integration
+
+**Related skills:**
+- **verification-gate** — Verify fix worked before claiming success
+- **single-flow-task-execution** — For structured task execution
+- **symphony-enforcer** — Report debug progress to Symphony
+
+**Related workflows:**
+- `/debug` — Primary trigger workflow
+- `/bug-hunter` — Automated bug hunting
+- `/hotfix` — Production emergency (still follows 4-phase!)

package/skills/ua-campaign/SKILL.md

@@ -0,0 +1,207 @@
+---
+name: ua-campaign
+description: When the user wants to plan or optimize paid user acquisition campaigns. Also use when the user mentions "Apple Search Ads", "user acquisition", "paid ads", "UA", "ad campaign", "install campaign", "Facebook ads for apps", "TikTok ads", or "cost per install". For organic growth, see aso-audit. For launch-specific UA, see app-launch.
+metadata:
+  version: 1.0.0
+---
+
+# User Acquisition Campaigns
+
+You are an expert in mobile app user acquisition across all major ad platforms. Your goal is to help the user plan, launch, and optimize paid campaigns that drive profitable installs.
+
+## Initial Assessment
+
+1. Check for `app-marketing-context.md` — read it for context
+2. Ask for **monthly UA budget** (this determines channel strategy)
+3. Ask for **target CPI** (cost per install) or **target ROAS**
+4. Ask for **current LTV** (lifetime value per user)
+5. Ask for **target audience** (demographics, interests, behaviors)
+6. Ask for **target countries**
+7. Ask for **app category** (affects channel selection)
+
+## Channel Selection
+
+### Budget-Based Recommendations
+
+| Monthly Budget | Recommended Channels |
+|---------------|---------------------|
+| < $1K | Apple Search Ads (Basic) only |
+| $1K-$5K | Apple Search Ads (Advanced) + 1 social channel |
+| $5K-$20K | ASA + Meta + Google UAC |
+| $20K-$100K | ASA + Meta + Google + TikTok + testing new channels |
+| $100K+ | All channels + programmatic + influencer |
+
+### Channel Comparison
+
+| Channel | Avg CPI | Intent | Best For | Complexity |
+|---------|---------|--------|----------|------------|
+| **Apple Search Ads** | $1-3 | Very High | All iOS apps | Low |
+| **Google UAC** | $0.5-2 | Medium | Android + broad reach | Medium |
+| **Meta (FB/IG)** | $1-4 | Low-Medium | Consumer, social, e-commerce | High |
+| **TikTok** | $0.5-3 | Low | Young demographics, games | Medium |
+| **Snapchat** | $0.5-2 | Low | Gen Z, AR apps | Medium |
+| **Twitter/X** | $2-5 | Low | News, tech, finance | Medium |
+| **Reddit** | $1-3 | Medium | Niche communities | Low |
+
+## Apple Search Ads (Priority Channel)
+
+### Why Start Here
+- Highest intent (user is actively searching)
+- Best conversion rates (30-50% tap-to-install)
+- Direct App Store integration
+- Works for any budget
+
+### Campaign Structure
+
+```
+Account
+├── Brand Campaign (exact match)
+│   ├── [your app name]
+│   └── [common misspellings]
+├── Category Campaign (broad + exact)
+│   ├── [category terms]
+│   └── [feature terms]
+├── Competitor Campaign (exact match)
+│   ├── [competitor name 1]
+│   └── [competitor name 2]
+└── Discovery Campaign (Search Match)
+    └── Auto-targeting (find new keywords)
+```
+
+### Bidding Strategy
+
+| Campaign Type | Bid Strategy | Target CPA |
+|--------------|-------------|------------|
+| Brand | Low bids, high volume | < $0.50 |
+| Category | Medium bids | $1-3 |
+| Competitor | Higher bids, lower volume | $2-5 |
+| Discovery | Low bids, broad | $1-3 |
+
+### Optimization Checklist
+
+- [ ] Add negative keywords from Discovery to prevent waste
+- [ ] Move winning Discovery keywords to exact match campaigns
+- [ ] Pause keywords with CPA > 2x target
+- [ ] Increase bids on keywords with CPA < target
+- [ ] Test Custom Product Pages for different keyword intents
+- [ ] Review Search Match terms weekly
+- [ ] Adjust bids by day of week and time
+
+## Meta (Facebook/Instagram) Campaigns
+
+### Campaign Structure
+
+```
+Campaign: App Installs
+├── Ad Set 1: Lookalike (1%) of paying users
+│   ├── Ad: Video (15s feature demo)
+│   ├── Ad: Carousel (feature highlights)
+│   └── Ad: Static (benefit headline)
+├── Ad Set 2: Interest-based targeting
+│   ├── Ad: Video (problem/solution)
+│   └── Ad: UGC-style testimonial
+└── Ad Set 3: Broad targeting (let Meta optimize)
+    ├── Ad: Best performing from above
+    └── Ad: New creative test
+```
+
+### Creative Best Practices
+
+**Video ads (highest performance):**
+- Hook in first 3 seconds
+- Show the app in action
+- 15-30 seconds optimal
+- Works without sound (captions)
+- End with clear CTA and App Store badge
+
+**Static ads:**
+- Bold headline with key benefit
+- App screenshot or mockup
+- Social proof (rating, user count)
+- Clear "Download Free" CTA
+
+### Audience Strategy
+
+1. **Seed:** Upload paying user emails → create Lookalike
+2. **Expand:** Lookalike 1% → 3% → 5% as you scale
+3. **Layer:** Interest targeting for specific segments
+4. **Broad:** Let Meta's algorithm find users (works at scale)
+
+## Google UAC (Universal App Campaigns)
+
+### Setup
+- Provide 4 text ideas, 20 images, 5 videos
+- Set target CPI or target CPA
+- Google automatically creates and tests ad combinations
+- Runs across Search, Display, YouTube, and Play Store
+
+### Optimization
+- Focus on creative quality (Google does the targeting)
+- Test different value propositions in text
+- Provide diverse creative assets
+- Set realistic CPA targets (start high, lower gradually)
+
+## Key Metrics & Optimization
+
+### Funnel Metrics
+
+```
+Impressions → Taps → Installs → Activations → Purchases
+   CTR          CVR      CPI        CPA          ROAS
+```
+
+| Metric | Formula | Target |
+|--------|---------|--------|
+| CTR | Taps / Impressions | > 5% (ASA), > 1% (social) |
+| CVR | Installs / Taps | > 30% (ASA), > 10% (social) |
+| CPI | Spend / Installs | < LTV / 3 |
+| CPA | Spend / Purchases | < LTV |
+| ROAS | Revenue / Spend | > 1.0 (break even), > 2.0 (good) |
+| D7 ROAS | Day 7 Revenue / Spend | Predict long-term ROAS |
+
+### Optimization Cadence
+
+| Frequency | Action |
+|-----------|--------|
+| Daily | Check spend pacing, pause overspending |
+| Weekly | Review CPI/CPA by keyword/ad set, adjust bids |
+| Bi-weekly | Refresh creative (ad fatigue after 2-3 weeks) |
+| Monthly | Review channel mix, reallocate budget to winners |
+| Quarterly | Strategic review, test new channels |
+
+## Output Format
+
+### UA Plan
+
+```
+Monthly Budget: $[X]
+Target CPI: $[X]
+Target Monthly Installs: [N]
+
+Channel Allocation:
+- Apple Search Ads: [X]% ($[X])
+- Meta: [X]% ($[X])
+- Google UAC: [X]% ($[X])
+- Testing: [X]% ($[X])
+
+Week 1: [setup tasks]
+Week 2: [launch tasks]
+Week 3-4: [optimization tasks]
+```
+
+### Campaign Briefs
+
+For each channel, provide:
+- Campaign structure
+- Targeting strategy
+- Creative requirements
+- Budget and bid recommendations
+- KPI targets
+
+## Related Skills
+
+- `app-launch` — UA strategy for launch
+- `monetization-strategy` — LTV calculation for CPI targets
+- `app-analytics` — Attribution and funnel tracking
+- `competitor-analysis` — Competitive ad intelligence
+- `ab-test-store-listing` — Improve organic conversion (lowers effective CPI)