@agentskillkit/agent-skills 1.0.1 → 3.2.1

package/.agent/workflows/monitor.md

@@ -0,0 +1,283 @@
+---
+description: Production observability with OpenTelemetry, Prometheus/Grafana dashboards, and PagerDuty alerting
+---
+
+# Monitoring Setup Workflow
+
+Comprehensive production monitoring with observability, observability, observability collection, distributed observability, and incident response.
+
+## 🎯 Purpose
+
+This workflow uses the **monitoring-production** chain to setup:
+
+- OpenTelemetry observability foundation
+- Structured observability with cloud aggregation
+- Prometheus observability and dashboards
+- Distributed observability (APM)
+- Alerting and incident response
+
+## 🤖 Meta-Agents Integration
+
+| Phase | Agent | Action |
+| ----- | ----- | ------ |
+| **Pre-Setup** | `assessor` | Evaluate monitoring scope and complexity |
+| **Configuration** | `orchestrator` | Coordinate multi-skill setup |
+| **Post-Setup** | `learner` | Log monitoring patterns for future setups |
+
+---
+
+## 🔗 Chain: monitoring-production
+
+**Skills Loaded (5):**
+
+- `observability` - OpenTelemetry SDK, provider integration (Datadog, Sentry, New Relic)
+- `observability` - Structured observability (Pino/Winston), PII masking, log aggregation
+- `observability` - Prometheus observability, Golden Signals (latency, traffic, errors, saturation)
+- `observability` - Distributed observability, custom spans, context propagation
+- `observability` - Alert rules, Slack/PagerDuty integration, runbooks
+
+## 📖 Usage
+
+```bash
+/monitor <description>
+```
+
+### Examples
+
+```bash
+# Basic monitoring setup
+/monitor my-production-app
+
+# With specific provider
+/monitor production app with Datadog
+
+# With custom requirements
+/monitor e-commerce API
+Requirements:
+- Datadog APM
+- Error rate alerts
+- Slack notifications
+- Custom business observability
+```
+
+## 🔄 Workflow Steps
+
+This workflow automatically:
+
+1. **Observability Foundation**
+   - Install OpenTelemetry SDK
+   - Configure providers (Datadog/Sentry/New Relic)
+   - Setup auto-instrumentation
+   - Configure resource attributes
+
+2. **Structured observability**
+   - Setup Pino/Winston logger
+   - JSON-formatted logs
+   - PII redaction (email, phone, SSN)
+   - Cloud aggregation (Datadog Logs, CloudWatch, Loki)
+   - Correlation IDs for request observability
+
+3. **observability Collection**
+   - Expose Prometheus `/observability` endpoint
+   - Golden Signals (latency, traffic, errors, saturation)
+   - Custom business observability
+   - Create Grafana/Datadog dashboards
+
+4. **Distributed observability** (Optional)
+   - Enable auto-instrumentation (HTTP, DB, Redis)
+   - Custom span creation
+   - Trace context propagation (W3C)
+   - APM integration (Datadog APM, Sentry)
+   - Sampling strategy (10% production, 100% dev)
+
+5. **Incident Response**
+   - Configure alert rules (error rate, latency, downtime)
+   - Setup Slack webhook integration
+   - PagerDuty on-call routing
+   - Generate runbooks for common issues
+   - Post-mortem templates
+
+## 🎨 Supported Platforms
+
+### Observability Providers
+
+- **Datadog** - Full-stack monitoring
+- **New Relic** - APM and infrastructure
+- **Sentry** - Error tracking and performance
+- **Grafana Cloud** - Open-source stack
+- **Self-hosted** - Prometheus + Jaeger + Loki
+
+### Log Aggregation
+
+- **Datadog Logs**
+- **AWS CloudWatch**
+- **Grafana Loki**
+- **Elasticsearch**
+
+### observability Platforms
+
+- **Prometheus** + Grafana
+- **Datadog observability**
+- **New Relic observability**
+- **CloudWatch observability**
+
+## ✅ Success Criteria
+
+After running `/monitor`, you will have:
+
+✓ **Observability SDK** - OpenTelemetry initialized
+✓ **Structured Logs** - JSON logs with PII masking
+✓ **observability Endpoint** - `/observability` exposing Prometheus format
+✓ **Dashboards** - Pre-configured with Golden Signals
+✓ **Alerts** - At least 3 critical alerts (error rate, latency, health check)
+✓ **Notifications** - Slack/PagerDuty integration working
+✓ **Runbooks** - Documentation for incident response
+
+## 📊 What Gets Monitored
+
+### Application observability
+
+- HTTP request rate (requests/sec)
+- Response time (p50, p95, p99)
+- Error rate (%)
+- Active connections
+- Database query performance
+- Cache hit rate
+
+### Infrastructure observability
+
+- CPU usage
+- Memory usage
+- Disk usage
+- Network I/O
+
+### Business observability
+
+- User signups
+- Orders processed
+- Revenue (if applicable)
+- Custom KPIs
+
+## 🔍 Related Workflows
+
+- `/optimize` - Performance profiling and optimization
+- `/alert` - Configure additional alert rules
+- `/launch` - Deploy with monitoring pre-configured
+- `/diagnose` - Debug issues using monitoring data
+
+## 💡 Tips
+
+**When to use `/monitor`:**
+
+- After deploying to production
+- When setting up new services
+- After incidents (to prevent recurrence)
+- Regulatory compliance (audit observability)
+
+**Golden Signals are mandatory:**
+
+- **Latency** - How long requests take
+- **Traffic** - How many requests
+- **Errors** - How many fail
+- **Saturation** - Resource usage
+
+**Best practices:**
+
+- Set up monitoring BEFORE going to production
+- Test alerts in staging first
+- Keep runbooks up-to-date
+- Use PII masking for GDPR/CCPA compliance
+- Sample traces in production (10%) to save costs
+
+## 📚 Example Output
+
+```bash
+You: "/monitor my-production-app"
+
+Agent: Loading monitoring-production chain
+       ↓
+Skills: observability, observability, observability, observability, observability
+       ↓
+
+[1/5] 🔧 Observability Setup
+   ✅ OpenTelemetry SDK initialized
+   ✅ Service: my-production-app
+   ✅ Environment: production
+   ✅ Datadog exporter configured
+   ✅ Auto-instrumentation: HTTP, Prisma, Redis
+
+[2/5] 📝 observability
+   ✅ Structured observability with Pino
+   ✅ Log levels: error, warn, info, debug
+   ✅ PII redaction: password, creditCard, ssn, email, phone
+   ✅ Logs aggregated to Datadog
+   ✅ Correlation IDs enabled
+
+[3/5] 📊 observability
+   ✅ Prometheus observability exposed at /observability
+   ✅ Golden Signals configured:
+      - Latency: p50, p95, p99
+      - Traffic: requests/sec
+      - Errors: error rate
+      - Saturation: CPU, memory
+   ✅ Custom observability: 12 configured
+   ✅ Dashboard created in Datadog
+
+[4/5] 🔍 Distributed observability (optional)
+   ✅ Automatic instrumentation: HTTP, Prisma, Redis
+   ✅ Sampling rate: 10% (production)
+   ✅ Trace context propagation enabled
+   ✅ Traces visible in Datadog APM
+
+[5/5] 🚨 Incident Response
+   ✅ Alert rules configured: 5 critical, 8 high
+   ✅ Slack webhook: #oncall
+   ✅ PagerDuty integration: production-alerts
+   ✅ Runbooks generated: 5 playbooks
+   ✅ Post-mortem template created
+
+✅ Monitoring Complete!
+
+📊 Dashboard: https://app.datadoghq.com/dashboard/my-app
+📝 Logs: https://app.datadoghq.com/logs?service=my-app
+🔍 Traces: https://app.datadoghq.com/apm/services/my-app
+🚨 Alerts: https://app.datadoghq.com/monitors
+
+Created:
+✓ lib/observability/setup.ts
+✓ lib/logger.ts
+✓ lib/observability.ts
+✓ .env (with required variables)
+✓ docs/runbooks/ (5 playbooks)
+✓ alerts.yml (13 alert rules)
+✓ README-MONITORING.md
+```
+
+## 🚨 Alert Examples
+
+The workflow configures these critical alerts by default:
+
+| Alert               | Threshold     | Severity | Notification      |
+| ------------------- | ------------- | -------- | ----------------- |
+| High Error Rate     | >1% for 5min  | Critical | Slack + PagerDuty |
+| High Latency        | p95 >500ms    | High     | Slack             |
+| Health Check Failed | <100% success | Critical | Slack + PagerDuty |
+| Memory Usage        | >90%          | High     | Slack             |
+| Database Timeout    | >3 in 5min    | High     | Slack             |
+
+## 📖 Runbooks Generated
+
+The workflow creates runbooks for:
+
+- High error rate investigation
+- High latency debugging
+- Health check failure response
+- Database timeout resolution
+- Memory leak investigation
+
+---
+
+**Version:** 1.0.0  
+**Chain:** monitoring-production  
+**Added:** v3.4.0 (FAANG upgrade)
+

package/.agent/workflows/optimize.md

@@ -0,0 +1,220 @@
+---
+description: Performance optimizer with bundle analysis, N+1 query fixes, Redis caching, and k6 load testing
+---
+
+# Performance Optimization Workflow
+
+Systematic performance optimization: profile, tune database, add caching, validate with load testing.
+
+## 🎯 Purpose
+
+This workflow uses the **performance-audit** chain to:
+
+- Profile application performance (Lighthouse, bundle size, API latency)
+- Optimize database queries (indexes, N+1 fixes)
+- Implement caching layers (Redis, CDN)
+- Validate improvements with load testing
+
+## 🤖 Meta-Agents Integration
+
+| Phase | Agent | Action |
+| ----- | ----- | ------ |
+| **Pre-Optimize** | `recovery` | Save current state before changes |
+| **Optimization** | `orchestrator` | Coordinate parallel optimization tasks |
+| **Post-Optimize** | `learner` | Log optimization patterns for reuse |
+| **Failure** | `recovery` | Rollback if optimization degrades performance |
+
+```
+Flow:
+recovery.save() → orchestrator.run(optimizations)
+       ↓
+benchmark → worse? → recovery.restore()
+       ↓
+better → learner.log(optimization_patterns)
+```
+
+---
+
+## 🔗 Chain: performance-audit
+
+**Skills Loaded (4):**
+
+- `perf-optimizer` - Performance profiling (Core Web Vitals, bundle analysis)
+- `data-modeler` - Query optimization, index recommendations
+- `perf-optimizer` - Redis caching, CDN configuration
+- `perf-optimizer` - k6/Artillery load testing, scalability validation
+
+## 📖 Usage
+
+```bash
+/optimize <description>
+```
+
+### Examples
+
+```bash
+# Basic optimization
+/optimize my-slow-api
+
+# With specific target
+/optimize checkout flow (target: p95 <200ms)
+
+# Production optimization
+/optimize production app (10K+ users)
+```
+
+## 🔄 Workflow Steps
+
+This workflow automatically:
+
+1. **Performance Profiling**
+   - Run Lighthouse audit (Core Web Vitals)
+   - Analyze bundle size
+   - Profile API response times
+   - Identify slow database queries
+
+2. **Database Optimization**
+   - Detect N+1 queries
+   - Add missing indexes
+   - Optimize slow queries
+   - Tune connection pool
+
+3. **Cache Implementation**
+   - Setup Redis cache
+   - Configure CDN (Cloudflare/Vercel)
+   - Set HTTP caching headers
+   - Implement cache-aside pattern
+
+4. **Load Testing**
+   - Run realistic user scenarios
+   - Test at target scale (10K+ users)
+   - Measure p95 latency, error rate
+   - Identify remaining bottlenecks
+
+## ✅ Success Criteria
+
+After running `/optimize`, you will have:
+
+✓ **Bottlenecks Identified** - Slow queries, large bundles
+✓ **Performance Improved** - 50%+ latency reduction
+✓ **Caching Implemented** - >80% cache hit rate
+✓ **Load Test Passed** - Supports target concurrent users
+
+## 📊 What Gets Optimized
+
+### Frontend
+
+- Bundle size reduction (code splitting)
+- Image optimization (WebP, lazy loading)
+- Core Web Vitals (LCP <2.5s, CLS <0.1)
+
+### Backend
+
+- Database query optimization (indexes, N+1 fixes)
+- Redis caching (80%+ hit rate)
+- API response time (p95 <200ms)
+- Connection pool tuning
+
+### Infrastructure
+
+- CDN configuration
+- HTTP caching headers
+- Horizontal scaling recommendations
+
+## 🎨 Performance Targets
+
+| Metric               | Target  | Critical |
+| -------------------- | ------- | -------- |
+| **p95 Latency**      | <200ms  | <500ms   |
+| **Error Rate**       | <0.5%   | <1%      |
+| **Cache Hit Rate**   | >80%    | >70%     |
+| **Concurrent Users** | 10,000+ | 5,000+   |
+
+## 🔍 Related Workflows
+
+- `/benchmark` - Run load tests only (no optimization)
+- `/monitor` - Setup monitoring after optimization
+- `/launch` - Deploy optimized version
+
+## 💡 Tips
+
+**When to use `/optimize`:**
+
+- API response times >500ms
+- High database load
+- Poor Lighthouse scores
+- Before launch to production
+
+**Best practices:**
+
+- Profile BEFORE optimizing
+- Fix database issues first (biggest impact)
+- Add caching second
+- Validate with load tests
+- Monitor after deployment
+
+## 📚 Example Output
+
+```bash
+You: "/optimize my-slow-api"
+
+Agent: Loading performance-audit chain
+       ↓
+Skills: perf-optimizer, data-modeler, perf-optimizer, perf-optimizer
+       ↓
+
+[1/4] 🔍 Performance Profiling
+   ⚠️ API p95 latency: 850ms (target: <200ms)
+   ❌ Database queries: 15 per request
+   ❌ Slow query: users.findMany (2.5s)
+   ⚠️ No caching detected
+
+[2/4] 🗄️ Database Tuning
+   ✅ Added index: idx_users_email
+   ✅ Fixed N+1: user posts (15 queries → 1)
+   ✅ Connection pool: 10 → 20
+   ✅ Query time: 2.5s → 50ms (98% faster)
+
+[3/4] âš¡ Cache Optimization
+   ✅ Redis configured
+   ✅ Cache-aside pattern implemented
+   ✅ CDN configured for static assets
+   ✅ Cache hit rate: 85%
+   ✅ Database load: 1000 qps → 150 qps
+
+[4/4] 🧪 Load Testing
+   Testing: 5,000 concurrent users
+   ✅ p95 latency: 180ms (target: <200ms ✓)
+   ✅ Error rate: 0.2% (target: <1% ✓)
+   ✅ Throughput: 4,150 rps
+   ✅ PASS
+
+📊 Performance Improvement:
+   - Latency: 850ms → 180ms (79% faster)
+   - Database load: 85% reduction
+   - Supports: 5,000+ users ✅
+
+✅ Optimization complete!
+
+Files modified:
+   ✓ Add indexes to schema
+   ✓ Redis cache setup (lib/cache/)
+   ✓ CDN config (next.config.js)
+   ✓ Load test script (tests/load/)
+```
+
+## 🚨 Common Bottlenecks Fixed
+
+| Issue                 | Solution                    | Impact                |
+| --------------------- | --------------------------- | --------------------- |
+| N+1 queries           | Use `include` or JOINs      | 90%+ faster           |
+| Missing indexes       | Add indexes on foreign keys | 95%+ faster           |
+| No caching            | Redis + CDN                 | 70% DB load reduction |
+| Small connection pool | Increase to 20-50           | Eliminates timeouts   |
+
+---
+
+**Version:** 1.0.0  
+**Chain:** performance-audit  
+**Added:** v3.5.0 (FAANG upgrade - Phase 2)
+