@leejungkiin/awkit 1.1.6 → 1.1.9

package/skills/seasonal-aso/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: seasonal-aso
+description: When the user wants to optimize their App Store listing for seasonal events, holidays, or trending moments — including keyword opportunities, metadata updates, screenshot theming, and timing strategy. Use when the user mentions "seasonal", "holiday", "Christmas", "New Year", "Valentine's Day", "summer", "back to school", "seasonal keywords", "trending now", "limited time", or wants to capitalize on a calendar event. For general keyword research, see keyword-research. For full metadata rewrites, see metadata-optimization.
+metadata:
+  version: 1.0.0
+---
+
+# Seasonal ASO
+
+You help the user identify and act on seasonal keyword opportunities and listing optimizations tied to calendar events, holidays, and trending moments.
+
+## Key Principle
+
+**Seasonal rankings are competitive and time-sensitive.** Metadata takes 1–3 days to index. Plan changes 2 weeks before the event; revert 3–5 days after peak.
+
+## Seasonal Calendar (iOS — US)
+
+| Event | Peak Window | Keywords to target |
+|-------|-------------|-------------------|
+| New Year | Dec 26 – Jan 7 | "new year", "resolution", "goals", "habit", "fresh start" |
+| Valentine's Day | Feb 1–14 | "valentine", "love", "couples", "romantic", "gift" |
+| Spring / Easter | Mar–Apr | "spring", "easter", "refresh", "clean", "declutter" |
+| Mother's Day | May 1–12 | "mom", "mother", "family", "gift for mom" |
+| Summer | Jun–Aug | "summer", "vacation", "travel", "outdoor", "beach" |
+| Back to School | Jul 15 – Sep 10 | "school", "study", "student", "homework", "planner" |
+| Halloween | Oct 1–31 | "halloween", "scary", "spooky", "costume", "trick" |
+| Black Friday | Nov 20–30 | "deal", "sale", "discount", "shopping", "gift" |
+| Christmas | Dec 1–26 | "christmas", "gift", "holiday", "santa", "family" |
+| End of Year | Dec 27–31 | "year review", "recap", "goals 2026", "new year" |
+
+## Workflow
+
+### Step 1 — Identify Relevant Event
+
+1. Check for `app-marketing-context.md`
+2. Ask: **Which event or season are you targeting?**
+3. Ask: **What does your app do?** (to assess keyword relevance)
+4. Determine if the event is a good fit — not every seasonal moment applies
+
+### Step 2 — Research Seasonal Keywords
+
+Use Appeeky to find volume on seasonal terms:
+
+```bash
+GET /v1/keywords/metrics?keywords=christmas+planner,holiday+tracker
+GET /v1/keywords/suggestions?term=christmas&country=us
+GET /v1/keywords/trending?country=us&days=7
+```
+
+**Filter by:**
+- Volume spike (compare to baseline 30 days prior)
+- Difficulty < 60 preferred (seasonal keywords are crowded)
+- Relevance to your app's core function
+
+### Step 3 — Plan Metadata Changes
+
+**Keyword field (100 chars, iOS):**
+- Swap out low-performing keywords for seasonal terms
+- Add 2–4 seasonal keywords while preserving your best evergreen terms
+- Remove seasonal terms that are irrelevant to your core use case
+
+**Subtitle (30 chars):**
+- Consider a seasonal hook if it fits: "Your Holiday Planner" or "New Year Goal Tracker"
+- Only change if the original subtitle is not keyword-critical
+
+**Promotional text (170 chars — no review required):**
+- Always update for seasonal events — instant, no review
+- Use for: seasonal call-to-action, limited-time feature highlights, event tie-ins
+
+**Screenshots:**
+- Add a seasonal frame or theme to the first 2 screenshots
+- Use `screenshot-optimization` skill for creative guidance
+
+### Step 4 — Timing Checklist
+
+```
+Timeline (count back from event date):
+- [ ] T-14 days: Research keywords, brief creative
+- [ ] T-10 days: Write new metadata + promotional text
+- [ ] T-7 days: Submit screenshot updates (no review needed)
+- [ ] T-5 days: Submit keyword/subtitle update (review time buffer)
+- [ ] T-0: Event peak — monitor rankings daily
+- [ ] T+3 days: Revert metadata to evergreen version
+- [ ] T+5 days: Revert promotional text
+```
+
+## Output Format
+
+### Seasonal Opportunity Brief
+
+```
+🎄 Seasonal Opportunity: [Event Name]
+   Peak window: [dates]
+   Lead time needed: [X days]
+
+Keyword Opportunities:
+  High priority (volume spike, <60 difficulty):
+  - "[keyword]" — vol [N], diff [N]
+  - "[keyword]" — vol [N], diff [N]
+
+  Secondary (relevant but competitive):
+  - "[keyword]" — vol [N], diff [N]
+
+Metadata Recommendations:
+  Keyword field: [current] → [proposed — 100 chars]
+  Subtitle: [keep / change to: "..."]
+  Promo text: "[seasonal copy — 170 chars]"
+
+Screenshots: [suggest seasonal theme or keep as-is]
+
+Timeline:
+  - Submit metadata by: [date]
+  - Submit promo text by: [date]
+  - Revert by: [date]
+```
+
+## Seasonal vs Evergreen Trade-offs
+
+| Factor | Seasonal | Evergreen |
+|--------|----------|-----------|
+| Volume | Temporarily very high | Stable |
+| Competition | Very high at peak | Moderate |
+| Risk | Rankings drop after peak | Consistent |
+| Reward | Spike in installs | Sustained growth |
+
+**Rule:** Only swap evergreen keywords that are already underperforming. Never sacrifice a high-ranking keyword for seasonal speculation.
+
+## Trending Moments (Non-Calendar)
+
+For viral/trending moments (news events, viral content, app store trends):
+1. Use `GET /v1/keywords/trending?country=us&days=3` to spot emerging terms
+2. Act within 24–48 hours (trending windows are short)
+3. Only update promotional text (instant, no review)
+4. Revert after the trend fades (typically 3–7 days)
+
+## Related Skills
+
+- `keyword-research` — Deep keyword analysis for seasonal candidates
+- `metadata-optimization` — Rewrite full metadata with seasonal terms
+- `screenshot-optimization` — Design seasonal screenshot themes
+- `market-pulse` — Spot trending keywords and market movements in real time

package/skills/spec-gate/SKILL.md

@@ -0,0 +1,312 @@
+---
+name: spec-gate
+description: >-
+  Gate 2 — Architecture & Data Design Gate. Chốt thiết kế kỹ thuật (DB Schema,
+  API Contract, State Machine) TRƯỚC KHI cho phép code. Bắt buộc user approve
+  thiết kế để tránh "vừa làm vừa sửa database". Auto-triggered bởi orchestrator
+  khi Gate 2 chưa thỏa mãn.
+metadata:
+  stage: core
+  version: "1.0"
+  tags: [gate, architecture, database, design, spec-first, core]
+  requires: orchestrator
+agent: Architect
+trigger: conditional
+invocation-type: auto
+priority: 2
+activation_keywords:
+  - "thiết kế database"
+  - "schema design"
+  - "data model"
+  - "API design"
+  - "architect"
+---
+
+# Spec Gate v1.0 — Architecture & Data Design Gate
+
+> **Purpose:** Chốt thiết kế kỹ thuật (DB Schema, API Contract, State Machine) 
+> TRƯỚC KHI viết code. Đảm bảo tất cả persistence changes đã được suy nghĩ kỹ
+> và user đã approve trước khi AI bắt tay implement.
+>
+> **Problem it solves:** "Vừa làm vừa sửa database dẫn tới lung tung"
+
+---
+
+## ⚠️ SCOPE CLARITY
+
+| Skill này LÀM | Skill này KHÔNG làm |
+|---------------|---------------------|
+| Phác thảo Data Model (tables, fields, indexes) | Viết code |
+| Thiết kế API Contract (endpoints, request/response) | Tạo BRIEF/spec (việc của brainstorm-agent) |
+| Vẽ State Machine diagram (nếu cần) | Track tasks (việc của symphony-enforcer) |
+| Checklist tự kiểm tra thiết kế | Deploy |
+| Yêu cầu user approve design | Sửa lỗi |
+
+---
+
+## 🚀 ACTIVATION
+
+Skill này được kích hoạt bởi:
+1. **Orchestrator auto-trigger:** Khi Gate 2 check FAIL (không tìm thấy design doc đã approved)
+2. **Explicit command:** `/architect` hoặc `/design-db`
+3. **Keyword trigger:** "thiết kế database", "schema design", "data model"
+
+---
+
+## 📋 INPUT REQUIREMENTS
+
+Trước khi chạy, PHẢI có:
+
+```
+REQUIRED:
+  → docs/specs/<feature>.md HOẶC BRIEF.md (output từ Gate 1)
+  → .project-identity (projectId, techStack)
+
+OPTIONAL:
+  → docs/specs/TECH-SPEC.md (project-level constraints)
+  → Existing DB schema (nếu project đã có database)
+  → NeuralMemory context (decisions trước đó về architecture)
+```
+
+---
+
+## 🔄 PROCESS
+
+### Phase 1: Context Gathering (Silent)
+
+```
+1. Đọc BRIEF.md / spec document → Extract:
+   - Core entities (Users, Orders, Products...)
+   - Relationships (1-N, N-N)
+   - Business rules (unique constraints, validation rules)
+   - Flows requiring state tracking
+
+2. Đọc .project-identity → Extract:
+   - Tech stack (SQL? NoSQL? ORM?)
+   - Coding standards
+   - Existing patterns
+
+3. Đọc TECH-SPEC.md nếu có → Extract constraints:
+   - Database choice (PostgreSQL, Firestore, GRDB, Realm...)
+   - Performance requirements
+   - Offline-first requirements
+   - Migration strategy
+
+4. NeuralMemory recall → Previous architecture decisions
+```
+
+### Phase 2: Data Model Design
+
+```
+Cho MỖI entity phát hiện từ spec:
+
+TABLE/COLLECTION: <name>
+├── Fields:
+│   ├── id: <type> (PK)
+│   ├── field_1: <type> [NOT NULL | OPTIONAL]
+│   ├── field_2: <type> [DEFAULT: <value>]
+│   └── ...
+├── Indexes:
+│   ├── idx_<name>_<field> (purpose)
+│   └── ...
+├── Relationships:
+│   ├── belongs_to: <table> (FK: <field>)
+│   └── has_many: <table>
+└── Constraints:
+    ├── UNIQUE: <fields>
+    └── CHECK: <condition>
+```
+
+### Phase 3: API Contract Design (nếu có API)
+
+```
+Cho MỖI endpoint cần thiết:
+
+ENDPOINT: [METHOD] /api/<path>
+├── Purpose: <mô tả ngắn>
+├── Auth: <required | optional | public>
+├── Request:
+│   ├── Headers: <required headers>
+│   ├── Params: <path/query params>
+│   └── Body: { field: type, ... }
+├── Response:
+│   ├── 200: { field: type, ... }
+│   ├── 400: { error: "validation message" }
+│   └── 500: { error: "server error" }
+└── Notes: <edge cases, rate limiting, etc.>
+```
+
+### Phase 4: State Machine (nếu có stateful flows)
+
+```
+Cho flows có trạng thái chuyển đổi (order lifecycle, booking flow...):
+
+STATE MACHINE: <name>
+  [initial] → [state_1] → [state_2] → [final]
+       ↓           ↓
+    [error]    [cancelled]
+
+Transitions:
+  initial → state_1: trigger=<event>, guard=<condition>
+  state_1 → state_2: trigger=<event>
+  any → cancelled: trigger=user_cancel
+```
+
+### Phase 5: Self-Review Checklist
+
+**TRƯỚC KHI present cho user, AI PHẢI tự kiểm tra:**
+
+```yaml
+checklist:
+  data_integrity:
+    - [ ] Mọi entity có Primary Key?
+    - [ ] Foreign Keys đúng direction?
+    - [ ] Không có circular dependencies?
+    - [ ] Cascade delete rules đã define?
+
+  performance:
+    - [ ] Indexes cho frequent queries?
+    - [ ] N+1 query potential identified?
+    - [ ] Pagination strategy cho list endpoints?
+    - [ ] Caching strategy nếu cần?
+
+  consistency:
+    - [ ] Chuẩn với .project-identity tech stack?
+    - [ ] Chuẩn với TECH-SPEC.md constraints?
+    - [ ] Naming convention thống nhất?
+    - [ ] Date/time format thống nhất?
+
+  edge_cases:
+    - [ ] Concurrent access handling?
+    - [ ] Null/empty value handling?
+    - [ ] Soft delete vs hard delete?
+    - [ ] Offline-first sync strategy (nếu mobile)?
+
+  security:
+    - [ ] PII data identified + encrypted?
+    - [ ] Auth rules per endpoint?
+    - [ ] Input validation cho mọi user input?
+```
+
+### Phase 6: Present & Approval
+
+```
+Present cho user với format:
+
+───────────────────────────────────
+📐 ARCHITECTURE DESIGN: <Feature Name>
+───────────────────────────────────
+
+## Data Model
+[Phase 2 output]
+
+## API Endpoints  
+[Phase 3 output — nếu có]
+
+## State Machine
+[Phase 4 output — nếu có]
+
+## Self-Review ✅
+[Phase 5 checklist results]
+
+## Concerns & Trade-offs
+- [Concern 1]: [Mô tả + recommendation]
+- [Concern 2]: [Mô tả + recommendation]
+
+───────────────────────────────────
+⏳ Chờ anh approve thiết kế này trước khi code nhé.
+   Sửa gì cứ nói, tôi update lại.
+───────────────────────────────────
+```
+
+### Phase 7: Write Design Doc
+
+Sau khi user approve:
+
+```
+1. Tạo folder nếu chưa có: docs/architecture/
+2. Write file: docs/architecture/<feature>_design.md
+3. Nội dung = Phase 6 output + approval marker:
+   
+   ## Status: Approved
+   **Approved by:** User
+   **Approved at:** <ISO date>
+   **Conversation:** <conversation-id>
+
+4. Lưu vào NeuralMemory:
+   nmem_remember(
+     content="Architecture design for <feature> approved. Schema: <summary>",
+     type="decision",
+     tags=["architecture", "<projectId>", "<feature>"]
+   )
+
+5. Proceed → orchestrator re-checks Gate 2 → PASS → Gate 3
+```
+
+---
+
+## 🔙 DESIGN DEVIATION PROTOCOL
+
+Khi AI đang code (Gate 4) và phát hiện cần sửa schema khác approved design:
+
+```
+1. ⛔ DỪNG CODE NGAY LẬP TỨC
+2. Thông báo user:
+   "Phát hiện cần thêm/sửa [field/table] ngoài thiết kế đã duyệt.
+    Để tôi quay lại update design doc trước nhé."
+3. Mở lại design doc
+4. Highlight phần cần thay đổi + lý do
+5. Yêu cầu user re-approve
+6. Update marker: "## Status: Approved (Revision 2)"
+7. Tiếp tục code
+```
+
+---
+
+## 🗣️ Communication Style
+
+```
+❌ "Architecture document required. Please provide data model specification."
+✅ "Đã hiểu yêu cầu! Giờ để tôi phác thảo cấu trúc database cho anh xem 
+    trước — kinh nghiệm cho thấy nếu chốt DB sớm sẽ tiết kiệm rất nhiều 
+    thời gian sửa lại sau."
+
+❌ "Design review requires your explicit approval."
+✅ "Anh xem thiết kế này có ổn không? Sửa gì cứ nói, tôi update lại. 
+    Chốt xong là bắt tay code luôn."
+```
+
+---
+
+## 🚫 Anti-Patterns
+
+```yaml
+never_do:
+  - Tự approve design (user PHẢI approve)
+  - Skip self-review checklist
+  - Design quá chi tiết cho trivial features (orchestrator đã filter)
+  - Bắt đầu code trước khi có approval marker
+  - Phớt lờ TECH-SPEC.md constraints
+
+always_do:
+  - Đọc ALL input sources trước khi design
+  - Chạy self-review checklist 100%
+  - Highlight trade-offs và concerns
+  - Ghi lại decisions vào NeuralMemory
+  - Kiểm tra consistency với existing schema
+```
+
+---
+
+## 🧩 Skill Relationships
+
+```
+TRIGGERED BY: orchestrator (Gate 2 check fail)
+DEPENDS ON: brainstorm-agent output (Gate 1 must pass first)
+FEEDS INTO: symphony-enforcer (Gate 3 reads design doc to create tasks)
+WORKS WITH: nm-memory-sync (store architectural decisions)
+```
+
+---
+
+*spec-gate v1.0 — Architecture & Data Design Gate for AWKit*

package/skills/subscription-lifecycle/SKILL.md

@@ -0,0 +1,206 @@
+---
+name: subscription-lifecycle
+description: When the user wants to optimize their subscription business end-to-end — from trial start through renewal, cancellation, and win-back. Use when the user mentions "subscription lifecycle", "trial conversion", "churn", "cancellation", "win-back", "lapsed subscribers", "dunning", "billing retry", "grace period", "renewal rate", "subscriber LTV", or "resubscribe". For paywall design and pricing strategy, see monetization-strategy. For subscription analytics dashboards, see app-analytics.
+metadata:
+  version: 1.0.0
+---
+
+# Subscription Lifecycle
+
+You optimize every stage of the subscription journey: trial → paid → renewal → cancellation recovery → win-back.
+
+## The Subscription Lifecycle
+
+```
+Install → Trial start → [Trial period] → Conversion → Renewal → ... → Cancel → Win-back
+            ↓                               ↓              ↓           ↓
+         No convert                    Voluntary       Involuntary   Lapsed
+         (nurture)                     (exit survey)   (dunning)     (campaign)
+```
+
+## Key Metrics at Each Stage
+
+| Stage | Metric | Formula | Benchmark |
+|-------|--------|---------|-----------|
+| Trial | Trial start rate | Trials / Downloads | > 20% |
+| Trial | Trial-to-paid | Conversions / Trials | 25–40% strong |
+| Retention | Month 1 renewal | M1 renewals / Subscribers | > 70% |
+| Retention | Month 6 renewal | M6 renewals / Subscribers | > 50% |
+| Churn | Monthly churn | Lost subs / Start subs | < 5% good; < 2% excellent |
+| Revenue | MRR | Active subs × monthly price | — |
+| Revenue | LTV | ARPU / Monthly churn rate | — |
+| Recovery | Dunning recovery | Recovered / Failed payments | > 30% |
+| Win-back | Resubscribe rate | Returns / Lapsed | 5–15% |
+
+## Stage 1 — Trial Optimization
+
+### Trial Length
+
+| App Type | Recommended trial | Notes |
+|----------|------------------|-------|
+| Simple utility | 3–7 days | Value obvious quickly |
+| Health/fitness | 7–14 days | Habit formation needs time |
+| Productivity | 7–14 days | Workflow integration |
+| Education | 7–14 days | First lesson completion |
+| Entertainment | 7 days | Binge behavior |
+
+**Test:** Monthly apps with a 7-day trial vs. 14-day trial — conversion rate may drop slightly but LTV often increases.
+
+### Trial Nurture Sequence
+
+Send in-app (or push) messages during the trial to drive activation:
+
+```
+Day 0: Welcome — "Your trial has started. Here's how to get the most from it."
+Day 1: Core feature highlight — "Try [key feature] today"
+Day 3: Progress / social proof — "Users who do X get 3× better results"
+Day 5 (7-day trial): Urgency — "2 days left in your trial"
+Day 6: Value recap — "Here's what you've done / could do with premium"
+Day 7: Last day — "Your trial ends today"
+```
+
+**Rule:** Messages should show value, not just create pressure.
+
+### Trial End — Conversion Moment
+
+At trial end, show a paywall that:
+- Recaps what the user achieved during the trial
+- Shows the most-used premium features
+- Offers 3 plan options (monthly / annual / lifetime if applicable)
+- Highlights savings on annual ("Save 40%")
+
+See `monetization-strategy` for paywall design details.
+
+## Stage 2 — Reducing Voluntary Churn
+
+### Why Users Cancel (and How to Fix It)
+
+| Reason | Signal | Fix |
+|--------|--------|-----|
+| Forgot they subscribed | Low sessions, no activation | Improve onboarding + notification strategy |
+| Not enough value | Low feature usage | Push underused high-value features |
+| Too expensive | Price sensitivity | Introduce lower-tier or pause option |
+| Problem with app | 1-star reviews | Fix the bug, reply to reviews |
+| Found alternative | — | Monitor competitor installs |
+| Seasonal use | Churns at same time yearly | Offer a pause option |
+
+### The Cancellation Flow
+
+When a user initiates cancellation (iOS — `ManagedSubscriptionGroup`):
+
+1. **Offer a pause** before full cancel: "Pause for 1–3 months instead of cancelling"
+2. **Show value recap**: "You've used [feature] X times this month"
+3. **Offer a discount**: Only as last resort — 20–30% off for 3 months
+4. **Exit survey**: Always ask "Why are you cancelling?" (1 tap, not an essay)
+
+**Cancellation exit survey options:**
+- Too expensive
+- Not using it enough
+- Missing a feature I need
+- Switching to a competitor
+- Technical issues
+- Just taking a break
+
+### Engagement Signals to Watch
+
+Users at high churn risk:
+- Sessions < 1 per week (down from higher baseline)
+- Core feature not used in 14+ days
+- Push notifications disabled
+- Last session > 7 days ago
+
+Trigger a re-engagement push or in-app message before they cancel.
+
+## Stage 3 — Involuntary Churn (Failed Payments)
+
+Involuntary churn accounts for **20–40%** of all subscription cancellations.
+
+### Dunning Strategy
+
+| Day | Action |
+|-----|--------|
+| 0 | Payment fails silently — Apple/Google retry |
+| 3 | Apple/Google retry #2 |
+| 7 | Apple/Google retry #3 — show in-app "Update payment method" banner |
+| 10 | Send push: "Your subscription couldn't be renewed — tap to update" |
+| 14 | Grace period ends — subscription suspended |
+| 15 | Final in-app message: "Reactivate to keep access" |
+
+**Grace period:**
+- iOS: 6 days (configurable up to 16 in App Store Connect)
+- Android: 3 days (configurable)
+
+Maximize grace period length — every extra day recovers more subscribers.
+
+### RevenueCat Integration
+
+RevenueCat handles dunning automatically. Key settings:
+- Enable Billing Retry (iOS) / Account Hold (Android)
+- Configure grace period to maximum allowed
+- Use RevenueCat webhooks to trigger in-app messaging at each failure event
+
+See `revenuecat.md` integration guide.
+
+## Stage 4 — Win-Back Campaigns
+
+Target lapsed subscribers (cancelled or expired in last 30–90 days).
+
+### Win-Back Offer Ladder
+
+Start with the softest offer; escalate only if no response:
+
+```
+Week 1 after lapse:  "We miss you" — highlight new features added since they left
+Week 3:              "Come back for 30% off your first month back"
+Week 6:              "3 months at 50% off — best offer we'll make"
+Week 12+:            Archive — low conversion probability
+```
+
+### Win-Back Channels
+
+| Channel | How |
+|---------|-----|
+| Push notification | In-app if app still installed |
+| Email | If email was collected |
+| Apple Win-Back Offer | Native iOS win-back offer in StoreKit 2 |
+| Paid retargeting | Meta/Google retargeting to lapsed subscriber list |
+
+### StoreKit 2 Win-Back Offers (iOS 18+)
+
+Apple natively supports win-back subscription offers for lapsed subscribers:
+- Set up in App Store Connect → Subscriptions → Win-Back Offers
+- Presented automatically in the App Store to eligible lapsed users
+- No additional code needed beyond StoreKit 2 integration
+
+## Output Format
+
+### Subscription Health Report
+
+```
+Lifecycle Metrics ([period]):
+
+Trial start rate:    [X]%  (benchmark: >20%)
+Trial conversion:    [X]%  (benchmark: 25-40%)
+M1 renewal:          [X]%  (benchmark: >70%)
+Monthly churn:       [X]%  (benchmark: <5%)
+Dunning recovery:    [X]%  (benchmark: >30%)
+Win-back rate:       [X]%  (benchmark: 5-15%)
+
+LTV (estimated):    $[N]
+MRR:                $[N]
+
+Top issues:
+1. [Stage] — [metric] is [X]% vs benchmark [Y]% — [recommended fix]
+2. [Stage] — [metric] is [X]% vs benchmark [Y]% — [recommended fix]
+
+Priority action:
+[Single highest-leverage change to implement this week]
+```
+
+## Related Skills
+
+- `monetization-strategy` — Paywall design, pricing tiers, trial setup
+- `retention-optimization` — Engagement strategy to reduce voluntary churn
+- `app-analytics` — Track the metrics above with Firebase + RevenueCat
+- `onboarding-optimization` — Fix early-stage drop-off that prevents trial starts
+- `rating-prompt-strategy` — Satisfied subscribers are your best raters