agy-superpowers 5.0.7 → 5.0.9

package/template/agent/skills/game-design/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: game-design
+description: Use when designing game mechanics, core loops, progression systems, monetization for games, difficulty curves, tutorial design, or player psychology
+---
+
+# Game Design Lens
+
+> **Philosophy:** Game design is the art of making decisions fun. Every system should answer: "Is this engaging?"
+> The best games feel instantly playable and endlessly deep.
+
+---
+
+## Core Instincts
+
+- **Core loop first** — if the core action isn't fun by itself, no meta-game will save it
+- **Feel before balance** — a perfectly balanced but bad-feeling game fails; great feel forgives imbalance
+- **Teach through play** — tutorials are a design failure if players need to read them
+- **Intrinsic over extrinsic motivation** — players who play for rewards quit when rewards stop
+- **Every system must serve the fantasy** — if a mechanic doesn't reinforce the core fantasy, cut it
+
+---
+
+## Game Loop Hierarchy
+
+```
+Core Loop (seconds):   The primary action (shoot, match, tap, build)
+Meta Loop (minutes):   Progression within a session (upgrade, complete level)
+Outer Loop (days):     Long-term progression (unlock, prestige, story)
+
+Addiction comes from nested loops where each satisfies before feeding into the next.
+
+Example: Clash Royale
+  Core:  Battle (3 min)
+  Meta:  Earn chest, open chest, get cards
+  Outer: Climb trophies, unlock arenas, seasonal ladder
+```
+
+---
+
+## Player Motivation (Bartle Types)
+
+| Type | Motivation | Engage with |
+|------|-----------|-------------|
+| **Achiever** | Goals, completion, rewards | Achievements, leaderboards, progress bars |
+| **Explorer** | Discovery, secrets, lore | Hidden content, procedural worlds, narrative |
+| **Socializer** | Connection, competition, cooperation | Guilds, co-op, chat, gifting |
+| **Killer** | Competition, dominance | PvP, rankings, bragging rights |
+
+**Indie hacker tip:** Mobile casual games are mostly Achievers. Design clear goals and visible progress.
+
+---
+
+## Difficulty Curve Design
+
+```
+Flow State (Csikszentmihalyi):
+  Too hard → frustration → quit
+  Too easy → boredom → quit
+  Balanced → flow → engagement
+
+Difficulty progression rule:
+  Introduce mechanic (easy) → test mechanic (medium) → combine mechanics (hard)
+  Never introduce two new mechanics simultaneously
+
+Rubber-band difficulty:
+  Dynamic difficulty adjustment (DDA): losing players get slight boost
+  Winning players face slight increase
+  Keeps sessions competitive without feeling rigged
+```
+
+---
+
+## Monetization Design for Games
+
+| Model | Player experience | Retention impact | Revenue potential |
+|-------|------------------|-----------------|------------------|
+| **Premium** (one-time) | ✅ No friction | ✅ High | 🔴 Capped |
+| **IAP — cosmetics only** | ✅ No frustration | ✅ Good | 🟡 Medium |
+| **IAP — progression** | ⚠️ Pay-to-win risk | ⚠️ Can harm f2p | 🟡 Medium |
+| **Rewarded ads** | ✅ Player-initiated | ✅ Good if not forced | 🟡 Medium |
+| **Battle pass** | ✅ FOMO + value | ✅ High (retention driver) | 🟢 High |
+| **Subscriptions** | ✅ Predictable | ✅ Good | 🟢 High |
+| **Gacha / loot boxes** | ⚠️ Controversy | ⚠️ Can be predatory | 🟢 High |
+
+**Indie hacker safe defaults:** Rewarded ads + battle pass + cosmetic IAP.
+**Avoid:** Pay-to-win IAP — destroys community trust and long-term retention.
+
+---
+
+## Onboarding / Tutorial Design Rules
+
+```
+Rule 1: Show, don't tell — demonstrate mechanics, don't explain them
+Rule 2: Force the action — don't ask "do you want a tutorial?"; just do it
+Rule 3: Reward immediately — first tutorial action must give satisfying feedback
+Rule 4: FTUE (First-Time User Experience) must complete in < 3 minutes
+Rule 5: Every tutorial step has exactly ONE objective
+Rule 6: Remove all failure states during tutorial — frustration at minute 1 = uninstall
+Rule 7: No text walls — max 2 lines of instruction; ideally zero
+```
+
+---
+
+## Game Balance Framework
+
+```
+Dominant strategy = game is solved → players get bored
+No viable strategy = game is frustrating → players quit
+
+Balanced game: multiple viable strategies, each with clear strengths and weaknesses
+
+Rock-Paper-Scissors model:
+  A beats B, B beats C, C beats A
+  No single dominant option; strategy matters
+
+Formulas:
+  DPS = Damage / Attack Speed
+  TTK (Time to Kill) = Target HP / DPS
+  Win rate = (Wins) / (Wins + Losses) — target ~50% ± 5% for PvP balance
+```
+
+---
+
+## Game Metrics (KPIs)
+
+| Metric | Definition | Target |
+|--------|-----------|--------|
+| D1 Retention | % players returning on day 1 | > 35% |
+| D7 Retention | % players returning on day 7 | > 15% |
+| D28 Retention | % players returning on day 28 | > 7% |
+| Session length | Average time per session | 5–15 min (casual), 20–60 min (core) |
+| Sessions per DAU | Average sessions per daily user | > 2 |
+| ARPDAU | Revenue per daily active user | Varies; $0.05–$0.20 mobile casual |
+| IPM (Installs per Mille) | Ad creative installs / 1K impressions | > 3 for performance |
+| Day 0 tutorial completion | % who finish tutorial | > 70% |
+
+---
+
+## ❌ Anti-Patterns to Avoid
+
+| ❌ NEVER DO | Why | ✅ DO INSTEAD |
+|------------|-----|--------------|
+| Skip the core loop to build meta first | Meta can't save a bad core loop | Fun core loop in < 2 weeks prototype |
+| Pay-to-win IAP | Destroys PvP balance, harms f2p players | Cosmetics, convenience (not power) |
+| Energy/timer gates early in FTUE | Players quit before experiencing value | First gate after player is hooked (> D3) |
+| Tutorial that can be failed | Guaranteed failure = guaranteed uninstall | Guided, railroaded tutorial with no lose state |
+| Random difficulty spikes | Perceived unfairness = rage quit | Smooth curve with intentional "boss" moments |
+| Introducing 2 mechanics at once | Cognitive overload | One mechanic per level/screen |
+| Rewarded ads forced (not voluntary) | Players hate interruption | Rewarded only — player initiates |
+
+---
+
+## Questions You Always Ask
+
+**When designing a new mechanic:**
+- Is this fun by itself? (Test with just the mechanic, no rewards)
+- Does it reinforce the core fantasy of the game?
+- How does a new player encounter this for the first time?
+
+**When reviewing a level/system:**
+- Does the difficulty curve make sense? No sudden spikes?
+- What's the win rate data? (If PvP or competitive)
+- What's the tutorial completion rate for this flow?
+
+---
+
+## Red Flags
+
+**Must fix:**
+- [ ] Tutorial can be failed or skipped with no guidance
+- [ ] First session longer than 5 minutes before first reward
+- [ ] Pay-to-win mechanics that affect PvP balance
+- [ ] No distinct core loop (what does the player DO every 30 seconds?)
+
+**Should fix:**
+- [ ] No audio/haptic feedback on primary action
+- [ ] Difficulty spikes without escalation curve
+- [ ] Monetization gating content needed to progress (not convenience)
+
+---
+
+## Who to Pair With
+- `game-developer` — for technical implementation of mechanics
+- `mobile-developer` — for mobile UX and platform guidelines
+- `monetization-strategist` — for IAP pricing and revenue modeling
+- `retention-specialist` — for D1/D7/D28 funnel analysis
+
+---
+
+## Reference Frameworks
+- **MDA Framework** (Mechanics → Dynamics → Aesthetics) — Hunicke, LeBlanc, Zubek
+- **Bartle's Player Types** — motivation segmentation for multiplayer
+- **Flow State** — Csikszentmihalyi's challenge/skill balance
+- **Octalysis** — Yu-kai Chou's gamification framework (8 core drives)

package/template/agent/skills/game-developer/SKILL.md

@@ -0,0 +1,175 @@
+---
+name: game-developer
+description: Use when working on mobile app features, reviewing mobile code, or making architecture decisions — regardless of platform (React Native, Flutter, iOS, Android)
+---
+
+# Game Developer Lens
+
+> **Philosophy:** Games are real-time, frame-budget-constrained simulations. Every millisecond counts.
+> Fun is the product. Performance is the enabler. Both must ship together.
+
+---
+
+## ⚠️ ASK BEFORE ASSUMING
+
+| What | Why it matters |
+|------|----------------|
+| **Platform?** Mobile / PC / Console / Web | Frame budget, input model, distribution channel all differ |
+| **Engine?** Unity / Unreal / Godot / custom | Determines every technical pattern |
+| **Genre?** Puzzle / RPG / Action / Idle | Core loop architecture differs fundamentally |
+| **Online?** Singleplayer / Multiplayer / MMO | Networking complexity changes everything |
+
+When unspecified, assume Unity + C# + mobile (iOS + Android).
+
+---
+
+## Frame Budget
+
+```
+Target frame rate → frame budget → time per frame
+60 FPS  =  16.67ms per frame  (mobile standard)
+30 FPS  =  33.33ms per frame  (minimum acceptable mobile)
+120 FPS =   8.33ms per frame  (high-refresh displays)
+
+Budget allocation guideline (16.67ms total):
+  CPU (game logic + physics): ~6ms
+  CPU (rendering commands):   ~4ms
+  GPU (draw calls + shaders): ~6ms
+  Headroom (OS, audio, GC):  ~0.67ms
+
+If any system consistently exceeds budget → frame drops → player frustration
+```
+
+---
+
+## Engine Decision Tree
+
+```
+What engine?
+├── AAA budget + PC/Console + team → Unreal Engine (C++)
+├── Mobile + fast iteration + mid-size → Unity (C#)
+├── Indie + open source + 2D/3D → Godot (GDScript or C#)
+├── Browser target → Phaser.js / Babylon.js / Three.js
+└── Existing engine in codebase → match codebase
+```
+
+---
+
+## Core Instincts
+
+- **The game loop is sacred** — Input → Update → Render, every frame, on time
+- **Object pooling over instantiation** — `Instantiate()` at runtime = GC spike = frame drop
+- **Draw calls are the enemy** — batch sprites, use atlases, instanced rendering
+- **Physics runs on a fixed timestep** — decouple physics from render frame rate
+- **GC pauses kill games** — allocate in `Start()`/`Awake()`, never in `Update()`
+- **Profiler first, optimize second** — never guess what's slow
+
+---
+
+## Performance Thresholds (Mobile)
+
+| Metric | Good | Investigate |
+|--------|------|-------------|
+| Frame rate (gameplay) | 60 FPS sustained | < 45 FPS |
+| Frame rate (menus/UI) | 60 FPS | < 30 FPS |
+| Draw calls per frame | < 100 | > 200 |
+| Texture memory | < 256MB | > 512MB |
+| APK / IPA size | < 100MB | > 200MB (impacts conversion) |
+| RAM usage (mid-range device) | < 300MB | > 500MB (OS kills app) |
+| Load time (initial) | < 5s | > 10s |
+| GC allocation per frame | 0B | > 0B (any = risk) |
+
+---
+
+## ❌ Anti-Patterns to Avoid
+
+| ❌ NEVER DO | Why | ✅ DO INSTEAD |
+|------------|-----|--------------|
+| `Instantiate()`/`Destroy()` in `Update()` | GC spike = frame drop | Object pooling |
+| `GameObject.Find()` in `Update()` | Expensive search every frame | Cache reference in `Start()` |
+| Non-atlased sprites | 1 draw call per sprite = explosion | Sprite Atlas / texture packing |
+| `string` concatenation in `Update()` | String allocation = GC | `StringBuilder` or avoid |
+| Unnecessary `GetComponent<>()` per frame | Expensive reflection | Cache in `Awake()/Start()` |
+| Physics on non-fixed timestep | Non-deterministic simulation | Use `FixedUpdate()` for physics |
+| Uncompressed audio | Large bundle, high memory | OGG for music, WAV for short SFX only |
+| `Debug.Log()` in build | CPU overhead, even in release | Strip with `#if UNITY_EDITOR` or Conditional |
+
+---
+
+## Platform Considerations
+
+| Concern | iOS | Android |
+|---------|-----|---------|
+| Max texture size | 4096×4096 | 4096×4096 |
+| Graphics API | Metal | Vulkan / OpenGL ES 3.0 |
+| Target FPS API | `Application.targetFrameRate = 60` | Same |
+| Memory kill threshold | ~1.5GB | Varies by device (256MB–4GB) |
+| App size limit (OTA) | 200MB cellular cap | No cap (varies by store) |
+| Haptic feedback | `UnityEngine.iOS.Device.SetNoBackupFlag` / Core Haptics | Vibration API |
+
+---
+
+## Multi-Scene / Asset Loading Pattern
+
+```csharp
+// Async scene loading (never use sync — it freezes)
+async void LoadScene(string sceneName) {
+  var op = SceneManager.LoadSceneAsync(sceneName, LoadSceneMode.Additive);
+  op.allowSceneActivation = false;
+  while (op.progress < 0.9f) {
+    loadingBar.value = op.progress;
+    await Task.Yield();
+  }
+  op.allowSceneActivation = true;
+}
+
+// Addressables for asset streaming (don't include everything in build)
+var handle = Addressables.LoadAssetAsync<GameObject>("enemies/boss");
+await handle.Task;
+```
+
+---
+
+## Questions You Always Ask
+
+**When designing a system:**
+- Does any allocation happen inside `Update()`? (GC risk)
+- Is this system tested on a low-end Android device (Qualcomm 450-class)?
+- What's the draw call count before and after this change?
+- Does this work at 30 FPS? (Not just 60 FPS in editor)
+
+**When reviewing code:**
+- Are expensive operations cached?
+- Is physics logic in `FixedUpdate()`, not `Update()`?
+- Are textures atlased and compressed?
+
+---
+
+## Red Flags in Code Review
+
+**Must fix:**
+- [ ] Allocations happening inside `Update()` loop
+- [ ] `Find()` or `GetComponent<>()` called per frame without caching
+- [ ] Unatlased sprite renderers (high draw call count)
+- [ ] Synchronous scene loading
+
+**Should fix:**
+- [ ] No object pooling for frequently spawned objects
+- [ ] Uncompressed audio assets
+- [ ] Debug.Log calls in production build paths
+
+---
+
+## Who to Pair With
+- `game-design` — for game loop, balance, and player psychology
+- `mobile-developer` — for mobile platform constraints and store distribution
+- `monetization-strategist` — for IAP and ad monetization strategy
+- `app-store-optimizer` — for App Store/Google Play listing
+
+---
+
+## Tools
+**Engines:** Unity · Unreal Engine · Godot  
+**Profiling:** Unity Profiler · Xcode Instruments · Android GPU Inspector · RenderDoc  
+**Asset pipeline:** TexturePacker (atlasing) · Addressables (Unity) · FMOD / Wwise (audio)  
+**Analytics:** Unity Analytics · GameAnalytics · Firebase (games)

package/template/agent/skills/growth-hacker/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: growth-hacker
+description: Use when planning user acquisition, building viral loops, designing activation funnels, or running growth experiments — for any product type
+---
+
+# Growth Hacker Lens
+
+> **Philosophy:** Growth is a system, not a campaign. Build loops, not one-time spikes.
+> Optimize activation before acquisition. A leaky bucket can't be filled by pouring more water.
+
+---
+
+## Core Instincts
+
+- **Fix the funnel before filling it** — acquisition without retention is burning money
+- **North Star first** — all growth work should connect to one metric that captures delivered value
+- **Build loops, not funnels** — sustainable growth is self-reinforcing (referral, content, product virality)
+- **Kill ideas fast** — run the simplest possible test before investing in a full build
+- **Pre-PMF: qualitative; post-PMF: quantitative**
+
+---
+
+## AARRR Framework (Pirate Metrics)
+
+| Stage | Key Question | Metric |
+|-------|-------------|--------|
+| **Acquisition** | Where do users come from? | CAC, channel attribution |
+| **Activation** | Do users experience value quickly? | % hitting "aha moment" in session 1 |
+| **Retention** | Do users come back? | D1/D7/D30 retention rates |
+| **Revenue** | Do users pay? | Conversion rate, ARPU, MRR |
+| **Referral** | Do users tell others? | Viral coefficient K, NPS |
+
+**Indie hacker priority order: Retention → Activation → Revenue → Acquisition → Referral**
+(Fix retention first — everything else is downstream.)
+
+---
+
+## Viral Coefficient
+
+```
+K = i × c
+  i = average invites sent per user
+  c = conversion rate of those invites (0–1)
+
+K > 1 = viral (exponential growth)
+K = 0.5 + strong acquisition = sustainable growth
+K < 0.1 = product-led growth isn't working; use other channels
+```
+
+---
+
+## Activation Benchmarks
+
+| Metric | Good | Great |
+|--------|------|-------|
+| Day 1 retention (mobile) | > 30% | > 45% |
+| Activation rate (hit aha moment) | > 40% | > 60% |
+| Time to first value | < 5 min | < 2 min |
+| Onboarding completion | > 60% | > 80% |
+
+**Aha moment** = the specific action that most correlates with long-term retention. Find it via cohort analysis: what do retained users do that churned users don't?
+
+---
+
+## ❌ Anti-Patterns to Avoid
+
+| ❌ NEVER DO | Why | ✅ DO INSTEAD |
+|------------|-----|--------------|
+| Scale acquisition pre-PMF | Filling a leaky bucket | Get to K=0.5+ / 40% D30 retention first |
+| Run experiments without hypothesis | Results are uninterpretable | Document hypothesis before every experiment |
+| Celebrate signup numbers | Signups are vanity; activation and retention are sanity | Track activated users, not total signups |
+| One-time launch spike as "growth" | Not repeatable, not a system | Build channels with compounding returns |
+| Change multiple variables in one test | Can't attribute the result | One variable at a time |
+| Scale a channel before unit economics work | CAC > LTV = faster bankruptcy | LTV:CAC ≥ 3:1 before scaling spend |
+
+---
+
+## Questions You Always Ask
+
+**When diagnosing growth:**
+- Where is the biggest drop in the AARRR funnel right now?
+- What does the aha moment look like, and how fast do users get there?
+- Is this a retention problem (fix product) or an acquisition problem (optimize funnel)?
+
+**When planning experiments:**
+- What's the hypothesis? What would prove it wrong?
+- What's the minimum sample size for statistical significance?
+- How long does the experiment need to run? (Avoid stopping early)
+
+---
+
+## Red Flags
+
+**Must address:**
+- [ ] D30 retention < 10% and team is focused on acquisition
+- [ ] No defined aha moment / activation event
+- [ ] Growth experiments running without documented hypothesis
+- [ ] CAC > LTV (actively destroying value)
+
+**Should address:**
+- [ ] No referral mechanism in product
+- [ ] Acquisition fully dependent on paid (no organic loop)
+- [ ] Onboarding completion < 50%
+
+---
+
+## Who to Pair With
+- `product-manager` — for activation and aha moment definition
+- `data-analyst` — for cohort analysis and experiment significance
+- `retention-specialist` — for fixing the funnel before scaling
+
+---
+
+## Key Formulas
+
+```
+CAC     = total acquisition spend / new customers acquired
+LTV     = ARPU × (1 / monthly_churn_rate)
+LTV:CAC = should be ≥ 3:1 (ideally > 5:1)
+Payback = CAC / monthly_gross_margin_per_customer (target < 12 months)
+K       = invites_per_user × invite_conversion_rate
+```

package/template/agent/skills/i18n-localization/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: i18n-localization
+description: Use when planning internationalization (i18n) architecture, localizing an app for new markets, managing translations, or optimizing for non-English app store listings
+---
+
+# i18n / Localization Lens
+
+> **Philosophy:** Localization is not translation. It's redesigning the experience for a different culture.
+> A poorly localized app signals "we don't really care about your market."
+
+---
+
+## Core Instincts
+
+- **i18n first, l10n second** — build the architecture for internationalization before translating
+- **Never hardcode strings** — every user-visible string lives in an external translation file
+- **RTL is a layout problem, not a text problem** — Hebrew, Arabic require mirrored layouts
+- **Local market ≠ translated market** — date formats, numbers, currencies, cultural norms all differ
+- **App Store localization = free ASO** — localized store listings rank in local search without app changes
+
+---
+
+## i18n vs l10n
+
+| Term | Definition |
+|------|-----------|
+| **i18n** (internationalization) | Engineering — building support for multiple locales |
+| **l10n** (localization) | Content — adapting content for a specific locale |
+| **t9n** (translation) | Linguistic — converting text between languages |
+
+---
+
+## Technical Requirements
+
+### Strings
+- Never concatenate user-visible strings: `"Hello " + name` → use named placeholders: `"Hello {name}"`
+- Pluralization rules differ by language (Russian has 4 plural forms; English has 2)
+- Use ICU message format for complex strings: `{count, plural, one {# item} other {# items}}`
+
+### Date / Time / Numbers
+| Category | Example variance |
+|----------|-----------------|
+| Date format | US: 12/31/2024, EU: 31/12/2024, ISO: 2024-12-31 |
+| Time format | 12h (US) vs 24h (EU/Asia) |
+| Number format | 1,234.56 (US) vs 1.234,56 (EU) vs 1 234,56 (FR) |
+| Currency | Symbol position varies; decimal precision varies by currency |
+| Calendar | Gregorian default; some markets use Islamic, Hebrew, Chinese calendars |
+
+**Always use:** `Intl.DateTimeFormat`, `Intl.NumberFormat` (JS) or locale-aware libraries — never manually format.
+
+### Right-to-Left (RTL) Languages
+Arabic, Hebrew, Persian, Urdu — require:
+- Mirrored layout (left → right becomes right → left)
+- Text alignment: `start` / `end` instead of `left` / `right`
+- Icons that indicate direction must be flipped
+- Test with: RTL pseudo-localization before translating
+
+---
+
+## App Store Localization Priority
+
+Localize store listings first — no code changes needed, immediate revenue impact.
+
+| Market | Language | Potential uplift |
+|--------|----------|-----------------|
+| China | Simplified Chinese | 🔴 High (largest iOS market) |
+| Japan | Japanese | 🔴 High (highest ARPU per user) |
+| Germany | German | 🟠 Medium-high |
+| Brazil | Portuguese (BR) | 🟠 Medium-high |
+| France | French | 🟡 Medium |
+| South Korea | Korean | 🟡 Medium |
+
+**Rule:** Localize App Store listing → measure download increase → justify full app localization.
+
+---
+
+## ❌ Anti-Patterns to Avoid
+
+| ❌ NEVER DO | Why | ✅ DO INSTEAD |
+|------------|-----|--------------|
+| Hardcode strings in UI components | Impossible to translate in future | All strings in `i18n/en.json` from day one |
+| Use string concatenation for sentences | Word order differs by language | Named placeholders in translation keys |
+| Assume text length = English length | German is ~35% longer; Chinese is ~50% shorter | Design UI for 150% of English text length |
+| Use machine translation (Google Translate) for store listing | Quality signals carelessness | Professional translation for app store copy |
+| Translate only UI — not error messages, emails, notifications | Inconsistent experience | All user-visible text in translation files |
+| Design with only LTR in mind | RTL markets are large (Arabic = 400M speakers) | Use logical CSS properties (`inset-inline-start`) from start |
+
+---
+
+## Questions You Always Ask
+
+**When architecting i18n:**
+- Are all strings externalized into translation files (zero hardcoded UI text)?
+- Does the date/number/currency formatting use locale-aware APIs?
+- Is the layout system using logical properties (`start`/`end`) for RTL readiness?
+
+**When planning a new market:**
+- What's the current revenue from that country without localization?
+- What's the expected uplift from App Store listing localization vs full app localization?
+- Are there cultural norms that affect UX? (e.g., messaging apps are primary in some markets)
+
+---
+
+## Red Flags
+
+**Must fix:**
+- [ ] Hardcoded strings in UI code
+- [ ] String concatenation for user-visible sentences
+- [ ] Manual date/number formatting (not using `Intl.*` or locale library)
+
+**Should fix:**
+- [ ] App Store listing not localized for top 3 download markets
+- [ ] Layout uses `left`/`right` instead of `start`/`end` (RTL-incompatible)
+- [ ] No pseudo-localization test (catches text overflow and layout issues before real translation)
+
+---
+
+## Who to Pair With
+- `app-store-optimizer` — for App Store listing localization strategy
+- `mobile-developer` — for React Native / Flutter i18n implementation
+- `frontend-developer` — for web i18n and RTL CSS
+
+---
+
+## Tools
+**React:** `react-i18next` / `next-intl` · **Flutter:** `flutter_localizations` + ARB files · **iOS native:** `NSLocalizedString` + `.xcstrings` · **Translation management:** Lokalise · Phrase · Crowdin · **Quality:** Pseudo-localization testing → Appium