@namch/agent-assistant 1.0.0

package/skills/mobile-development/references/mobile-mindset.md

@@ -0,0 +1,544 @@
+# Mobile Development Mindset & Thinking Patterns
+
+Essential thinking patterns and decision-making frameworks for successful mobile development.
+
+## The 10 Commandments of Mobile Development
+
+### 1. Performance is Foundation, Not Feature
+- **Reality**: 70% users abandon apps >3s load time
+- **Mindset**: Optimize from day one, not "later"
+- **Action**: Set performance budgets before writing code
+
+### 2. Every Kilobyte, Every Millisecond Matters
+- **Reality**: Mobile = constrained environment (battery, memory, network)
+- **Mindset**: Desktop assumptions don't apply
+- **Action**: Profile real devices, not simulators
+
+### 3. Offline-First by Default
+- **Reality**: Network is unreliable (elevators, tunnels, airplanes, poor signal)
+- **Mindset**: Design for offline, sync when online
+- **Action**: Local persistence first, cloud sync second
+
+### 4. User Context > Developer Environment
+- **Reality**: Users on trains, walking, one-handed, bright sunlight
+- **Mindset**: Test in real-world scenarios
+- **Action**: Real device testing mandatory
+
+### 5. Platform Awareness Without Platform Lock-In
+- **Reality**: iOS and Android users expect different patterns
+- **Mindset**: Respect conventions, but keep logic portable
+- **Action**: Platform-specific UI, shared business logic
+
+### 6. Iterate, Don't Perfect (2024-2025 Survival Strategy)
+- **Reality**: Mobile landscape changes rapidly
+- **Mindset**: Ship, measure, improve cycle
+- **Action**: MVP → User feedback → Iterate
+
+### 7. Security and Accessibility by Design
+- **Reality**: Not afterthoughts, but core requirements
+- **Mindset**: Build trust and inclusivity from start
+- **Action**: Security audit + accessibility testing in every sprint
+
+### 8. Test on Real Devices
+- **Reality**: Simulators lie about performance, battery, network
+- **Mindset**: Simulators for speed, devices for truth
+- **Action**: CI/CD with real device farms
+
+### 9. Architecture Scales with Complexity
+- **Reality**: Over-engineering kills simple apps
+- **Mindset**: Start simple, refactor when needed
+- **Action**: MVVM for small apps, Clean Architecture when complexity demands
+
+### 10. Continuous Learning is Survival
+- **Reality**: 85% developers use AI tools (2024), frameworks evolve constantly
+- **Mindset**: Embrace change, allocate learning time
+- **Action**: 1+ hour weekly for new tech/patterns
+
+## Mobile-Specific Constraints & Thinking
+
+### Small Screens (Constraint → Design Parameter)
+
+**Constraint:**
+- 5-7 inch screens, thumb-reach zones, fat finger problem
+
+**Thinking Shift:**
+- Embrace minimalism: "What can we remove?"
+- Priority-based hierarchy: Most important action front and center
+- Progressive disclosure: Hide complexity behind layers
+
+**Practical Targets:**
+- 44x44px minimum touch targets (iOS)
+- 48x48px minimum touch targets (Android)
+- Primary actions within thumb reach (bottom 1/3)
+- Maximum 3-4 items in bottom navigation
+
+**Example Decision:**
+```
+❌ Bad: 8-column data table on mobile
+✅ Good: Card view with 3 key metrics, "View more" for details
+```
+
+### Limited Resources (Every KB/ms Matters)
+
+**Constraint:**
+- Battery drain, memory pressure, thermal throttling
+
+**Thinking Shift:**
+- Resource consciousness in every decision
+- Measure before optimizing (don't guess)
+- Graceful degradation on low-end devices
+
+**Practical Targets:**
+- <100MB memory for typical screens
+- <5% battery drain per hour active use
+- <50MB initial download, <200MB total
+- 60 FPS (16.67ms per frame)
+
+**Example Decision:**
+```
+❌ Bad: Load all 1000 items in list
+✅ Good: Virtualized list (10 items visible + buffer)
+```
+
+### Intermittent Connectivity (Offline-First)
+
+**Constraint:**
+- Network unreliable: elevators, tunnels, poor signal, airplane mode
+
+**Thinking Shift:**
+- Local-first data architecture
+- Optimistic UI updates
+- Sync conflict resolution strategy
+
+**Practical Approaches:**
+- **Write-through cache**: Write local, sync background
+- **Hybrid sync**: Push (realtime) + Pull (periodic)
+- **Conflict resolution**: Last-write-wins with timestamps or CRDT
+
+**Example Decision:**
+```
+❌ Bad: Show spinner while posting comment
+✅ Good: Show comment immediately (optimistic), sync background, handle conflicts
+```
+
+## Platform-Specific Thinking
+
+### iOS Mental Model
+
+**Philosophy**: Consistent, polished, opinionated
+- Users expect iOS patterns (tab bar, navigation bar, swipe back)
+- Design reviews reject non-standard UIs
+- "It just works" expectation = zero tolerance for crashes
+
+**Fragmentation**: LOW
+- 90%+ on iOS 16+ (2024)
+- Only ~50 device models to test
+- Predictable hardware specs
+
+**Design Thinking**:
+- Follow Human Interface Guidelines religiously
+- Native navigation patterns non-negotiable
+- Haptic feedback for important actions
+- Respect safe areas (notch, Dynamic Island)
+
+**When to Go Native iOS:**
+- App Store is primary revenue channel
+- Need latest Apple features (WidgetKit, Live Activities)
+- Target affluent user base (iOS users spend 2.5x more)
+
+### Android Mental Model
+
+**Philosophy**: Flexible, customizable, democratic
+- Users expect Material Design but tolerate variations
+- Extreme fragmentation = defensive programming
+- "Back button" = fundamental navigation expectation
+
+**Fragmentation**: HIGH
+- 24,000+ device models
+- Android 6-14 in active use (8 years of OS versions)
+- Wide range of hardware specs (512MB to 12GB RAM)
+
+**Design Thinking**:
+- Material Design 3 as baseline
+- Test on low-end devices (1GB RAM minimum)
+- Respect system navigation (gesture vs 3-button)
+- Handle back button properly
+
+**When to Go Native Android:**
+- Global market focus (72% market share)
+- Emerging markets (Android dominates)
+- Enterprise/B2B (customization needs)
+
+## Performance Mindset (Every Millisecond Matters)
+
+### Critical Metrics (User Perception)
+
+| Metric | Threshold | User Perception |
+|--------|-----------|-----------------|
+| **Launch time** | <2s | Acceptable |
+| **Launch time** | 2-3s | Noticeable delay |
+| **Launch time** | >3s | 70% abandon |
+| **Screen load** | <1s | Instant (cached) |
+| **Screen load** | 1-3s | Acceptable (network) |
+| **Screen load** | >3s | Frustrating |
+| **Animation** | 60 FPS | Smooth |
+| **Animation** | 30-60 FPS | Noticeable jank |
+| **Animation** | <30 FPS | Unusable |
+
+### Performance Budget Example
+
+**Mobile App Performance Budget:**
+```
+Launch Time
+├─ Cold start: <2s (target 1.5s)
+├─ Warm start: <1s
+└─ Hot start: <0.5s
+
+Screen Load
+├─ Cached data: <500ms
+├─ Network data: <2s
+└─ Heavy computation: <3s
+
+Memory
+├─ Typical screen: <100MB
+├─ Heavy screen (images): <150MB
+└─ Peak usage: <200MB
+
+Network
+├─ Initial bundle: <2MB
+├─ Per screen: <500KB
+└─ Images: <200KB each
+
+Battery
+├─ Active use: <5% per hour
+├─ Background: <1% per hour
+└─ Idle: <0.1% per hour
+```
+
+### Optimization Decision Tree
+
+**Is it slow?**
+1. **Measure first** (Xcode Instruments, Android Profiler)
+2. **Find bottleneck** (CPU, memory, network, disk I/O)
+3. **Fix biggest impact** (80/20 rule)
+4. **Measure again** (verify improvement)
+
+**Common Culprits:**
+- Synchronous main thread operations
+- Unoptimized images (too large, wrong format)
+- N+1 query problem (fetch in loop)
+- Memory leaks (retain cycles, listeners)
+- Re-renders without memoization
+
+## Mobile Development Workflow
+
+### Iterative Development Cycle (Agile)
+
+**Sprint Structure (2 weeks):**
+```
+Week 1: Build + Test
+├─ Day 1-2: Design + plan
+├─ Day 3-4: Implement core
+└─ Day 5: Code review + tests
+
+Week 2: Polish + Ship
+├─ Day 6-7: Bug fixes + polish
+├─ Day 8: QA testing
+├─ Day 9: Staging deployment
+└─ Day 10: Production release (staged)
+```
+
+**Daily Workflow:**
+1. Pull latest code
+2. Run tests locally
+3. Develop feature/fix
+4. Write/update tests
+5. Local testing on device
+6. Code review
+7. CI/CD validation
+8. Merge to develop
+
+**CI/CD Impact:**
+- 20% reduction in development time
+- 50% fewer production bugs
+- 3x faster deployment
+
+### Common Pitfalls & Avoidance
+
+#### 1. Testing Only on Simulators
+**Problem**: Simulators don't show real performance (battery, memory, network)
+**Solution**: Real device testing mandatory before every release
+**Impact**: 40% of bugs only appear on real devices
+
+#### 2. Ignoring Platform Conventions
+**Problem**: Custom navigation confuses users
+**Solution**: Follow iOS HIG and Material Design
+**Impact**: 30% lower engagement with non-standard UIs
+
+#### 3. No Offline Handling
+**Problem**: Network failures = blank screens, errors
+**Solution**: Offline-first architecture, cached data
+**Impact**: 50% of users experience network issues daily
+
+#### 4. Poor Memory Management
+**Problem**: Memory leaks → crashes, poor performance
+**Solution**: ARC/GC understanding, profile regularly
+**Impact**: Memory issues = #1 crash cause (35%)
+
+#### 5. Hardcoded Credentials
+**Problem**: Security vulnerability, API key exposure
+**Solution**: Environment variables, secure storage
+**Impact**: 23% of apps leak sensitive data (OWASP)
+
+#### 6. No Accessibility
+**Problem**: Excludes 15%+ of users (disability, situational)
+**Solution**: VoiceOver/TalkBack testing, semantic labels
+**Impact**: Accessibility = 1.3B global market
+
+#### 7. Premature Optimization
+**Problem**: Wasted time optimizing non-bottlenecks
+**Solution**: Measure first, optimize biggest impact
+**Impact**: 80% of performance issues = 20% of code
+
+#### 8. Over-Engineering
+**Problem**: Complex architecture for simple apps
+**Solution**: Start simple, scale when needed
+**Impact**: 3x longer development for no user benefit
+
+#### 9. Skipping Real Device Testing
+**Problem**: Missed battery drain, thermal issues
+**Solution**: Device farm in CI/CD, manual testing
+**Impact**: 25% of performance issues device-specific
+
+#### 10. Not Respecting Battery
+**Problem**: Background processing drains battery
+**Solution**: Batch operations, respect Doze Mode
+**Impact**: Battery drain = #1 uninstall reason
+
+## Debugging Strategies & Tools (2024-2025)
+
+### iOS Debugging (Xcode 16)
+
+**Tools:**
+- **Instruments**: Profiling (Time, Allocations, Leaks, Network)
+- **Memory Graph**: Visual retain cycles
+- **View Hierarchy**: UI debugging
+- **Network Link Conditioner**: Simulate poor network
+- **Console**: System logs, os_log
+
+**AI-Driven:**
+- Xcode 16 AI crash analysis
+- Automatic memory leak detection
+- Performance suggestions
+
+**Process:**
+1. Reproduce bug on device
+2. Attach debugger / capture crash log
+3. Symbolicate crash report
+4. Fix root cause (not symptom)
+5. Add test to prevent regression
+
+### Android Debugging (Android Studio Giraffe+)
+
+**Tools:**
+- **Profiler**: CPU, Memory, Network, Energy
+- **Layout Inspector**: 3D view hierarchy
+- **Database Inspector**: SQLite/Room debugging
+- **Network Inspector**: API call monitoring
+- **Logcat**: System logs with filters
+
+**AI-Driven:**
+- Android Vitals: Crash clustering, ANR analysis
+- Firebase Crashlytics: AI-powered issue grouping
+- Play Console insights: User-reported bugs
+
+**Process:**
+1. Reproduce on emulator/device
+2. Check Logcat for stack traces
+3. Use Android Profiler for performance
+4. Fix and verify with instrumented tests
+5. Monitor Play Console vitals post-release
+
+### Cross-Platform Debugging
+
+**React Native:**
+- Chrome DevTools / Safari Web Inspector
+- Flipper (meta debugger: network, layout, logs)
+- Reactotron (state inspection)
+
+**Flutter:**
+- Flutter DevTools (Inspector, Timeline, Memory, Network)
+- Dart Observatory (VM debugging)
+- Widget Inspector (UI debugging)
+
+## Progressive Enhancement & Graceful Degradation
+
+### Progressive Enhancement (Build Up)
+
+**Strategy**: Start with baseline, enhance for capable devices
+
+**Example: Image Loading**
+```
+Baseline (all devices):
+├─ Show placeholder immediately
+├─ Load low-res image (10KB)
+└─ Display with smooth fade-in
+
+Enhancement (modern devices):
+├─ Check network (fast = high-res)
+├─ Check memory (ample = cache)
+└─ Progressive JPEG rendering
+```
+
+**Benefits:**
+- Works on all devices
+- Optimal experience on modern devices
+- No user left behind
+
+### Graceful Degradation (Strip Down)
+
+**Strategy**: Build for best, degrade for constraints
+
+**Example: Animation**
+```
+Best (flagship devices):
+├─ Complex particle effects
+├─ 120 FPS animations
+└─ Parallax scrolling
+
+Degraded (budget devices):
+├─ Simple fade transitions
+├─ 60 FPS target
+└─ Disable parallax (GPU load)
+```
+
+**Detection:**
+```javascript
+// React Native
+const isLowEndDevice =
+  DeviceInfo.getTotalMemory() < 2000000000; // <2GB
+
+if (isLowEndDevice) {
+  // Disable heavy animations
+  // Reduce concurrent operations
+  // Lower image quality
+}
+```
+
+**Benefits:**
+- Optimized for all hardware tiers
+- Prevents crashes on low-end devices
+- Better user experience across spectrum
+
+## Native vs Cross-Platform Decision Framework
+
+### Decision Tree
+
+**Q1: Do you need 100% native performance?**
+- **Yes** → Native (Swift/Kotlin)
+- **No** → Continue
+
+**Q2: Is team comfortable with JavaScript?**
+- **Yes** → React Native
+- **No** → Continue
+
+**Q3: Need desktop or web versions too?**
+- **Yes** → Flutter
+- **No** → Continue
+
+**Q4: Complex animations or custom UI?**
+- **Yes** → Flutter
+- **No** → React Native (easier for standard UIs)
+
+**Q5: Existing codebase to share?**
+- **React web app** → React Native
+- **No existing code** → Flutter (cleaner slate)
+
+### Hybrid Approach (Best of Both Worlds)
+
+**Strategy**: Cross-platform for most features, native for critical paths
+
+**Example Architecture:**
+```
+React Native / Flutter (90%)
+├─ UI and business logic
+├─ Standard features
+└─ API integration
+
+Native Modules (10%)
+├─ Performance-critical (video processing)
+├─ Platform-specific (HealthKit, Android Auto)
+└─ Third-party SDKs (payment, analytics)
+```
+
+**When to Use:**
+- Best: Leverage cross-platform speed + native power
+- Complexity: Maintain native module knowledge
+- Team: Need both cross-platform and native developers
+
+## Architecture Decision-Making
+
+### Complexity-Based Architecture Selection
+
+**Simple App (1-5 screens, basic CRUD)**
+- **Architecture**: MVVM (no Clean Architecture)
+- **State**: Local state (useState, setState)
+- **Reasoning**: Over-engineering adds complexity without benefit
+
+**Medium App (5-20 screens, moderate logic)**
+- **Architecture**: MVVM with clear separation
+- **State**: Global state management (Zustand, Riverpod)
+- **Reasoning**: Scalability without over-engineering
+
+**Complex App (20+ screens, enterprise logic)**
+- **Architecture**: Clean Architecture (domain, data, presentation)
+- **State**: Advanced state management + dependency injection
+- **Reasoning**: Maintainability and testability critical
+
+### Architecture Evolution
+
+**Start Simple:**
+```
+v1.0: MVVM, local state, single module
+└─ Focus: Ship fast, validate idea
+
+v2.0: Add global state when needed
+└─ Trigger: Props drilling becomes painful
+
+v3.0: Add Clean Architecture when scaling
+└─ Trigger: Team grows, features multiply
+
+v4.0: Extract microservices if justified
+└─ Trigger: Independent deployment needs
+```
+
+**Key Principle:** Refactor when pain > refactoring cost, not before
+
+## Resources & Continuous Learning
+
+**Weekly Learning Targets (2024-2025):**
+- 1 hour: New framework features
+- 30 min: Performance optimization techniques
+- 30 min: Security updates (CVEs, OWASP)
+- 30 min: Community articles/videos
+
+**Top Resources:**
+- iOS: Apple WWDC videos, Swift by Sundell
+- Android: Android Dev Summit, Medium Android Dev
+- React Native: React Native Blog, Expo Blog
+- Flutter: Flutter Engage, Medium Flutter
+- Mobile DevOps: Bitrise Blog, Fastlane guides
+
+**Communities:**
+- Stack Overflow (mobile tags)
+- Reddit (r/iOSProgramming, r/androiddev, r/reactnative, r/FlutterDev)
+- Discord (React Native, Flutter official)
+- Twitter: Follow framework creators and contributors
+
+**AI Tools (85% adoption in 2024):**
+- GitHub Copilot: Code completion, boilerplate
+- ChatGPT/Claude: Architecture questions, debugging
+- Tabnine: Context-aware suggestions
+- Average time saved: 1+ hour weekly
+
+**Key Mindset:** Continuous learning is not optional, it's survival in mobile development

package/skills/monitoring-expert/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: monitoring-expert
+description: Use when setting up monitoring systems, logging, metrics, tracing, or alerting. Invoke for dashboards, Prometheus/Grafana, load testing, profiling, capacity planning.
+triggers:
+  - monitoring
+  - observability
+  - logging
+  - metrics
+  - tracing
+  - alerting
+  - Prometheus
+  - Grafana
+  - DataDog
+  - APM
+  - performance testing
+  - load testing
+  - profiling
+  - capacity planning
+  - bottleneck
+role: specialist
+scope: implementation
+output-format: code
+---
+
+# Monitoring Expert
+
+Observability and performance specialist implementing comprehensive monitoring, alerting, tracing, and performance testing systems.
+
+## Role Definition
+
+You are a senior SRE with 10+ years of experience in production systems. You specialize in the three pillars of observability: logs, metrics, and traces. You build monitoring systems that enable quick incident response, proactive issue detection, and performance optimization.
+
+## When to Use This Skill
+
+- Setting up application monitoring
+- Implementing structured logging
+- Creating metrics and dashboards
+- Configuring alerting rules
+- Implementing distributed tracing
+- Debugging production issues with observability
+- Performance testing and load testing
+- Application profiling and bottleneck analysis
+- Capacity planning and resource forecasting
+
+## Core Workflow
+
+1. **Assess** - Identify what needs monitoring
+2. **Instrument** - Add logging, metrics, traces
+3. **Collect** - Set up aggregation and storage
+4. **Visualize** - Create dashboards
+5. **Alert** - Configure meaningful alerts
+
+## Reference Guide
+
+Load detailed guidance based on context:
+
+| Topic | Reference | Load When |
+|-------|-----------|-----------|
+| Logging | `references/structured-logging.md` | Pino, JSON logging |
+| Metrics | `references/prometheus-metrics.md` | Counter, Histogram, Gauge |
+| Tracing | `references/opentelemetry.md` | OpenTelemetry, spans |
+| Alerting | `references/alerting-rules.md` | Prometheus alerts |
+| Dashboards | `references/dashboards.md` | RED/USE method, Grafana |
+| Performance Testing | `references/performance-testing.md` | Load testing, k6, Artillery, benchmarks |
+| Profiling | `references/application-profiling.md` | CPU/memory profiling, bottlenecks |
+| Capacity Planning | `references/capacity-planning.md` | Scaling, forecasting, budgets |
+
+## Constraints
+
+### MUST DO
+- Use structured logging (JSON)
+- Include request IDs for correlation
+- Set up alerts for critical paths
+- Monitor business metrics, not just technical
+- Use appropriate metric types (counter/gauge/histogram)
+- Implement health check endpoints
+
+### MUST NOT DO
+- Log sensitive data (passwords, tokens, PII)
+- Alert on every error (alert fatigue)
+- Use string interpolation in logs (use structured fields)
+- Skip correlation IDs in distributed systems
+
+## Knowledge Reference
+
+Prometheus, Grafana, ELK Stack, Loki, Jaeger, OpenTelemetry, DataDog, New Relic, CloudWatch, structured logging, RED metrics, USE method, k6, Artillery, Locust, JMeter, clinic.js, pprof, py-spy, async-profiler, capacity planning
+
+## Related Skills
+
+- **DevOps Engineer** - Infrastructure monitoring
+- **Debugging Wizard** - Using observability for debugging
+- **Architecture Designer** - Observability architecture