@patricio0312rev/skillset 0.1.0

package/templates/architecture/migration-planner/ SKILL.md

@@ -0,0 +1,376 @@
+---
+name: migration-planner
+description: Builds phased data and system migrations using feature flags, dual writes, backfills, and validation. Includes rollback plans and risk mitigation. Use for "data migration", "system migration", "database migration", or "platform migration".
+---
+
+# Migration Planner
+
+Execute safe, zero-downtime migrations with validation and rollback plans.
+
+## Migration Patterns
+
+### 1. Feature Flag Migration (Safest)
+
+```
+Phase 1: Deploy new code (disabled)
+Phase 2: Enable for 1% traffic
+Phase 3: Ramp to 10%, 50%, 100%
+Phase 4: Remove old code
+```
+
+### 2. Dual Write Migration
+
+```
+Phase 1: Write to both old and new
+Phase 2: Backfill old → new
+Phase 3: Read from new (write both)
+Phase 4: Stop writing to old
+Phase 5: Decommission old
+```
+
+### 3. Blue-Green Deployment
+
+```
+Blue (current) → Green (new)
+Switch traffic: Blue → Green
+Rollback available: Green → Blue
+```
+
+## Complete Migration Plan Template
+
+````markdown
+# Migration Plan: MySQL → PostgreSQL
+
+## Overview
+
+**What:** Migrate user database from MySQL to PostgreSQL
+**Why:** Better JSON support, improved performance
+**When:** Q1 2024
+**Owner:** Database Team
+**Risk Level:** HIGH
+
+## Current State
+
+- MySQL 8.0
+- 500GB data
+- 100K users
+- 1000 writes/min
+- 10,000 reads/min
+
+## Target State
+
+- PostgreSQL 15
+- Same data model
+- No downtime
+- Data validation 100% match
+
+## Phases
+
+### Phase 1: Dual Write (Week 1-2)
+
+**Goal:** Write to both databases
+
+**Steps:**
+
+1. Deploy PostgreSQL cluster
+2. Create schema in PostgreSQL
+3. Deploy dual-write code
+4. Enable dual writes (MySQL primary, PostgreSQL secondary)
+
+**Code:**
+
+```typescript
+async function createUser(data: CreateUserDto) {
+  // Write to MySQL (primary)
+  const mysqlUser = await mysql.users.create(data);
+
+  // Write to PostgreSQL (secondary, fire and forget)
+  postgres.users.create(data).catch((err) => {
+    logger.error("PostgreSQL write failed", err);
+  });
+
+  return mysqlUser; // Still trust MySQL
+}
+```
+````
+
+**Validation:**
+
+- Monitor PostgreSQL write success rate
+- Compare row counts daily
+- Alert if drift >0.1%
+
+**Rollback:** Disable PostgreSQL writes
+
+### Phase 2: Backfill (Week 3-4)
+
+**Goal:** Copy historical data
+
+**Steps:**
+
+1. Take MySQL snapshot
+2. Run backfill script in batches
+3. Validate data integrity
+4. Resume from failure automatically
+
+**Script:**
+
+```python
+def backfill():
+    last_id = get_last_migrated_id()
+    batch_size = 1000
+
+    while True:
+        users = mysql.query(
+            "SELECT * FROM users WHERE id > %s LIMIT %s",
+            [last_id, batch_size]
+        )
+
+        if not users:
+            break
+
+        postgres.bulk_insert(users)
+        last_id = users[-1]['id']
+        save_checkpoint(last_id)
+
+        time.sleep(0.1)  # Rate limit
+```
+
+**Validation:**
+
+- Row count match
+- Random sample comparison (1000 rows)
+- Checksum comparison
+
+**Rollback:** Delete PostgreSQL data
+
+### Phase 3: Dual Read (Week 5)
+
+**Goal:** Validate PostgreSQL reads
+
+**Steps:**
+
+1. Deploy shadow read code
+2. Read from both (MySQL primary)
+3. Compare results
+4. Log mismatches
+
+**Code:**
+
+```typescript
+async function getUser(id: string) {
+  const mysqlUser = await mysql.users.findById(id);
+
+  // Shadow read from PostgreSQL
+  postgres.users.findById(id).then((pgUser) => {
+    if (!deepEqual(mysqlUser, pgUser)) {
+      logger.warn("Data mismatch", { id, mysqlUser, pgUser });
+      metrics.increment("migration.mismatch");
+    }
+  });
+
+  return mysqlUser; // Still trust MySQL
+}
+```
+
+**Validation:**
+
+- Mismatch rate <0.01%
+- PostgreSQL query performance acceptable
+
+**Rollback:** Remove shadow reads
+
+### Phase 4: Flip Read Traffic (Week 6)
+
+**Goal:** Read from PostgreSQL
+
+**Steps:**
+
+1. Feature flag: read from PostgreSQL (1% traffic)
+2. Monitor errors, latency
+3. Ramp: 1% → 10% → 50% → 100%
+4. Still writing to both
+
+**Code:**
+
+```typescript
+async function getUser(id: string) {
+  if (featureFlags.readFromPostgres) {
+    return postgres.users.findById(id);
+  }
+  return mysql.users.findById(id);
+}
+```
+
+**Validation:**
+
+- Error rate unchanged
+- Latency p95 <500ms
+- No user complaints
+
+**Rollback:** Flip feature flag off
+
+### Phase 5: Stop MySQL Writes (Week 7)
+
+**Goal:** PostgreSQL is now primary
+
+**Steps:**
+
+1. Stop writing to MySQL
+2. Keep MySQL running (read-only)
+3. Monitor for issues
+
+**Code:**
+
+```typescript
+async function createUser(data: CreateUserDto) {
+  return postgres.users.create(data);
+  // No longer writing to MySQL
+}
+```
+
+**Validation:**
+
+- All operations working
+- MySQL not receiving writes
+
+**Rollback:** Re-enable MySQL writes
+
+### Phase 6: Decommission (Week 8)
+
+**Goal:** Remove MySQL
+
+**Steps:**
+
+1. Archive MySQL data
+2. Shutdown MySQL cluster
+3. Remove MySQL client code
+
+**Rollback:** Not available (point of no return)
+
+## Validation Strategy
+
+### Data Integrity Checks
+
+```python
+def validate_migration():
+    # Row counts
+    mysql_count = mysql.query("SELECT COUNT(*) FROM users")[0]
+    pg_count = postgres.query("SELECT COUNT(*) FROM users")[0]
+    assert mysql_count == pg_count
+
+    # Random sampling
+    sample = mysql.query("SELECT * FROM users ORDER BY RAND() LIMIT 1000")
+    for row in sample:
+        pg_row = postgres.query("SELECT * FROM users WHERE id = %s", [row['id']])
+        assert row == pg_row
+
+    # Checksums
+    mysql_checksum = mysql.query("SELECT MD5(GROUP_CONCAT(id, email)) FROM users")
+    pg_checksum = postgres.query("SELECT MD5(STRING_AGG(id::text || email, '')) FROM users")
+    assert mysql_checksum == pg_checksum
+```
+
+## Rollback Plans
+
+### Phase 1-3 Rollback (Easy)
+
+- Disable PostgreSQL writes
+- No impact to users
+- Data in MySQL still valid
+
+### Phase 4 Rollback (Medium)
+
+- Flip feature flag
+- Route reads back to MySQL
+- Minor user impact (seconds)
+
+### Phase 5+ Rollback (Hard)
+
+- Must re-enable MySQL writes
+- Potential data loss (writes since phase 5)
+- Requires dual-write resumption
+
+## Risk Mitigation
+
+### Risk 1: Data Loss
+
+**Mitigation:**
+
+- Dual writes until validated
+- Transaction logs captured
+- Continuous backups
+
+### Risk 2: Performance Degradation
+
+**Mitigation:**
+
+- Load test PostgreSQL
+- Query optimization
+- Connection pooling
+
+### Risk 3: Schema Differences
+
+**Mitigation:**
+
+- Schema validation script
+- Test migrations in staging
+- Document data type differences
+
+## Communication Plan
+
+### Stakeholder Updates
+
+```markdown
+**Week 0:** Migration announced
+**Week 2:** Phase 1 complete (dual writes)
+**Week 4:** Backfill complete
+**Week 6:** Traffic shifted to PostgreSQL
+**Week 8:** Migration complete
+```
+
+### Status Dashboard
+
+- Current phase
+- Data sync status (%)
+- Validation results
+- Error rates
+
+## Testing Plan
+
+### Pre-Migration Testing
+
+1. Test in development
+2. Full migration in staging
+3. Load test PostgreSQL
+4. Validate rollback procedures
+
+### During Migration
+
+1. Continuous monitoring
+2. Automated validation
+3. Manual spot checks
+4. User acceptance testing
+
+## Best Practices
+
+1. **Small batches**: Migrate incrementally
+2. **Dual write**: Keep both systems synchronized
+3. **Feature flags**: Control rollout
+4. **Validate continuously**: Don't trust, verify
+5. **Rollback ready**: Plan for worst case
+6. **Monitor closely**: Track metrics
+7. **Communicate often**: Keep stakeholders informed
+
+## Output Checklist
+
+- [ ] Migration phases defined (5-7 phases)
+- [ ] Dual write implementation
+- [ ] Backfill script ready
+- [ ] Validation strategy
+- [ ] Feature flags configured
+- [ ] Rollback plans per phase
+- [ ] Risk mitigation strategies
+- [ ] Communication plan
+- [ ] Monitoring dashboard
+- [ ] Testing checklist

package/templates/architecture/performance-budget-setter/ SKILL.md

@@ -0,0 +1,318 @@
+---
+name: performance-budget-setter
+description: Defines measurable performance budgets for bundle size, API latency, database queries, and render times. Provides enforcement strategies and monitoring plans. Use for "performance budgets", "performance monitoring", "web vitals", or "optimization targets".
+---
+
+# Performance Budget Setter
+
+Set and enforce performance budgets to maintain fast user experiences.
+
+## Performance Budget Template
+
+```markdown
+# Performance Budget: E-Commerce Website
+
+## Bundle Size Budget
+
+| Asset Type             | Budget     | Current    | Status |
+| ---------------------- | ---------- | ---------- | ------ |
+| Initial JS             | 200 KB     | 185 KB     | ✅     |
+| Initial CSS            | 50 KB      | 48 KB      | ✅     |
+| Vendor JS              | 150 KB     | 145 KB     | ✅     |
+| Fonts                  | 100 KB     | 95 KB      | ✅     |
+| Images (above fold)    | 300 KB     | 320 KB     | ❌     |
+| **Total Initial Load** | **800 KB** | **793 KB** | ✅     |
+
+## API Latency Budget
+
+| Endpoint       | p50    | p95    | p99     |
+| -------------- | ------ | ------ | ------- |
+| GET /products  | <100ms | <300ms | <500ms  |
+| POST /checkout | <200ms | <500ms | <1000ms |
+| GET /search    | <150ms | <400ms | <800ms  |
+
+## Database Query Budget
+
+| Query Type       | Budget | Current |
+| ---------------- | ------ | ------- |
+| Simple reads     | <50ms  | 42ms    |
+| Complex joins    | <200ms | 185ms   |
+| Aggregations     | <500ms | 450ms   |
+| Queries per page | <20    | 18      |
+
+## Core Web Vitals
+
+| Metric                         | Good   | Poor   | Target |
+| ------------------------------ | ------ | ------ | ------ |
+| LCP (Largest Contentful Paint) | <2.5s  | >4.0s  | <2.0s  |
+| FID (First Input Delay)        | <100ms | >300ms | <50ms  |
+| CLS (Cumulative Layout Shift)  | <0.1   | >0.25  | <0.05  |
+
+## Page-Specific Budgets
+
+### Homepage
+
+- Time to Interactive: <3s
+- Total Blocking Time: <300ms
+- Speed Index: <3s
+
+### Product Page
+
+- Time to Interactive: <4s
+- Images loaded: <2s
+- Reviews section: <1s
+
+### Checkout
+
+- Time to Interactive: <3s
+- Payment processing: <2s
+- Zero layout shifts
+
+## Third-Party Scripts
+
+| Service     | Budget     | Purpose          |
+| ----------- | ---------- | ---------------- |
+| Analytics   | 30 KB      | Google Analytics |
+| Chat Widget | 50 KB      | Customer support |
+| Payment     | 100 KB     | Stripe           |
+| **Total**   | **180 KB** |                  |
+```
+
+## Enforcement Strategy
+
+### 1. CI/CD Integration
+
+```yaml
+# .github/workflows/performance-budget.yml
+name: Performance Budget Check
+
+on: [pull_request]
+
+jobs:
+  budget-check:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+
+      - name: Build production bundle
+        run: npm run build
+
+      - name: Check bundle size
+        run: |
+          npx bundlesize
+
+      - name: Lighthouse CI
+        run: |
+          npm install -g @lhci/cli
+          lhci autorun
+```
+
+### 2. Webpack Bundle Analyzer
+
+```javascript
+// webpack.config.js
+const BundleAnalyzerPlugin =
+  require("webpack-bundle-analyzer").BundleAnalyzerPlugin;
+
+module.exports = {
+  plugins: [
+    new BundleAnalyzerPlugin({
+      analyzerMode: process.env.ANALYZE ? "server" : "disabled",
+    }),
+  ],
+  performance: {
+    hints: "error",
+    maxAssetSize: 200000, // 200 KB
+    maxEntrypointSize: 400000, // 400 KB
+  },
+};
+```
+
+### 3. package.json Configuration
+
+```json
+{
+  "bundlesize": [
+    {
+      "path": "./dist/js/main.*.js",
+      "maxSize": "200 KB"
+    },
+    {
+      "path": "./dist/css/main.*.css",
+      "maxSize": "50 KB"
+    },
+    {
+      "path": "./dist/js/vendor.*.js",
+      "maxSize": "150 KB"
+    }
+  ]
+}
+```
+
+## Monitoring Plan
+
+### Real User Monitoring (RUM)
+
+```typescript
+// Track Core Web Vitals
+import { getCLS, getFID, getFCP, getLCP, getTTFB } from "web-vitals";
+
+function sendToAnalytics(metric) {
+  const body = JSON.stringify(metric);
+
+  if (navigator.sendBeacon) {
+    navigator.sendBeacon("/analytics", body);
+  } else {
+    fetch("/analytics", { body, method: "POST", keepalive: true });
+  }
+}
+
+getCLS(sendToAnalytics);
+getFID(sendToAnalytics);
+getLCP(sendToAnalytics);
+```
+
+### Synthetic Monitoring
+
+```bash
+# Lighthouse CI
+lhci autorun --config=.lighthouserc.json
+
+# WebPageTest API
+curl "https://www.webpagetest.org/runtest.php?url=https://example.com&k=API_KEY"
+```
+
+### Performance Dashboard
+
+```markdown
+**Daily Metrics:**
+
+- Bundle size trend
+- API latency percentiles
+- Core Web Vitals scores
+- Page load times
+
+**Alerts:**
+
+- Bundle size exceeds budget by 10%
+- LCP >2.5s for >5% of users
+- API p95 >500ms
+- Any metric exceeds budget
+```
+
+## Optimization Strategies
+
+### Reduce Bundle Size
+
+```typescript
+// Code splitting
+const ProductPage = lazy(() => import("./ProductPage"));
+
+// Tree shaking
+import { specific } from "library"; // ✅
+import * as library from "library"; // ❌
+
+// Dynamic imports
+if (featureFlag) {
+  const module = await import("./feature");
+}
+```
+
+### Optimize API Calls
+
+```typescript
+// Parallel requests
+const [user, orders] = await Promise.all([fetchUser(id), fetchOrders(id)]);
+
+// Caching
+const cachedData = await redis.get(key);
+if (cachedData) return cachedData;
+
+// Pagination
+const products = await db.products
+  .find()
+  .limit(20)
+  .skip((page - 1) * 20);
+```
+
+### Optimize Database Queries
+
+```sql
+-- Add indexes
+CREATE INDEX idx_orders_user_created ON orders(user_id, created_at);
+
+-- Limit columns
+SELECT id, name FROM products; -- ✅
+SELECT * FROM products;        -- ❌
+
+-- Use EXPLAIN
+EXPLAIN ANALYZE SELECT ...;
+```
+
+## Budget Violation Response
+
+### When Budget Exceeded
+
+1. **Immediate:**
+
+   - Block PR from merging
+   - Notify team in Slack
+   - Create ticket
+
+2. **Within 24 hours:**
+
+   - Investigate cause
+   - Identify optimization opportunities
+   - Propose fix or budget increase
+
+3. **Decision:**
+   - Fix code (preferred)
+   - Increase budget (requires justification)
+
+### Budget Increase Request Template
+
+```markdown
+## Budget Increase Request
+
+**Component:** Main JS bundle
+**Current Budget:** 200 KB
+**Requested Budget:** 250 KB
+**Reason:** Added critical feature X
+
+**Impact Analysis:**
+
+- Load time increase: +0.5s
+- User impact: Medium
+- Revenue impact: Unknown
+
+**Alternatives Considered:**
+
+1. Code splitting: Reduces to 210 KB (preferred)
+2. Remove feature Y: Reduces to 195 KB (rejected)
+3. Lazy loading: Complex, 3 weeks effort
+
+**Recommendation:** Implement code splitting
+```
+
+## Best Practices
+
+1. **Set realistic budgets**: Based on user data
+2. **Enforce in CI**: Automated checks
+3. **Monitor continuously**: RUM + synthetic
+4. **Review quarterly**: Adjust as needed
+5. **Prioritize UX**: User-centric metrics
+6. **Document exceptions**: Why budget increased
+7. **Celebrate wins**: When under budget
+
+## Output Checklist
+
+- [ ] Bundle size budgets defined
+- [ ] API latency targets set
+- [ ] Database query budgets
+- [ ] Core Web Vitals targets
+- [ ] Page-specific budgets
+- [ ] CI/CD enforcement configured
+- [ ] Monitoring dashboard
+- [ ] Alert thresholds set
+- [ ] Violation response process
+- [ ] Regular review schedule