@brainforge/core 3.1.3 → 3.1.5

package/dist/index.js

@@ -3300,6 +3300,1573 @@ Systems fail. This post-mortem focuses on fixing systems, not assigning blame. T
     ],
     tags: ["incident", "postmortem", "sre", "general"],
     version: "1.0.0"
+  },
+  // ── Backend (continued) ───────────────────────────────────────────────────
+  {
+    id: "backend/graphql-api",
+    name: "GraphQL API",
+    category: "backend",
+    description: "Design a GraphQL schema with resolvers and authentication",
+    template: `Design a GraphQL API for {{project.name}} in {{project.language}}{{#if project.framework}} using {{project.framework}}{{/if}}.
+
+Domain: {{domain}}
+Types: {{types}}
+
+Produce:
+1. Schema definition (SDL) \u2014 type definitions, queries, mutations{{#if subscriptions}}, subscriptions{{/if}}
+2. Resolver implementations \u2014 with DataLoader batching for N+1 prevention
+3. Authentication: directive-based (@auth(role: "admin")) applied to protected fields/mutations
+4. Input validation: use input types, validate in resolvers, return UserError union
+5. Error handling: distinguish client errors (UserError) from server errors
+
+Pagination: use Relay-style cursor connections for all list fields.
+{{#if (eq project.type "student")}}- Add comments explaining resolver execution and the N+1 problem{{/if}}`,
+    contextSchema: [
+      { key: "domain", label: "Domain (what it manages)", type: "text", placeholder: "E-commerce: products, orders, customers" },
+      { key: "types", label: "Main types", type: "text", placeholder: "User, Product, Order, LineItem" },
+      { key: "subscriptions", label: "Include subscriptions?", type: "boolean", default: false }
+    ],
+    tags: ["graphql", "api", "backend"],
+    version: "1.0.0"
+  },
+  {
+    id: "backend/microservice-scaffold",
+    name: "Microservice Scaffold",
+    category: "backend",
+    description: "Scaffold a production-ready microservice with standard cross-cutting concerns",
+    template: `Scaffold a microservice named "{{serviceName}}" in {{project.language}}{{#if project.framework}} using {{project.framework}}{{/if}}.
+
+Responsibility: {{responsibility}}
+Communication: {{communication}}
+
+Include:
+1. Project structure: src/{routes,services,repositories,events,config,middleware}
+2. Configuration: env-var driven, validated on startup (fail fast if required vars missing)
+3. Health endpoints: GET /health (liveness) and GET /ready (readiness with dependency checks)
+4. Structured logging: JSON logs with correlation ID propagated from incoming headers
+5. Graceful shutdown: drain in-flight requests, close DB connections, deregister from service registry
+6. {{communication}} integration \u2014 consuming and publishing events/calls to other services
+7. Dockerfile with multi-stage build (build \u2192 runtime, non-root user, minimal image)
+
+Cross-cutting: request ID middleware, error handler, timeout middleware ({{timeout}} default).`,
+    contextSchema: [
+      { key: "serviceName", label: "Service name", type: "text", placeholder: "payment-service" },
+      { key: "responsibility", label: "What this service owns", type: "text", placeholder: "Payment processing, refunds, and transaction history" },
+      { key: "communication", label: "Communication style", type: "select", options: ["REST (sync)", "gRPC (sync)", "Message queue (async)", "Mixed"], default: "REST (sync)" },
+      { key: "timeout", label: "Default request timeout", type: "text", default: "30s" }
+    ],
+    tags: ["microservice", "architecture", "backend", "devops"],
+    version: "1.0.0"
+  },
+  {
+    id: "backend/webhook-handler",
+    name: "Webhook Handler",
+    category: "backend",
+    description: "Implement an incoming webhook endpoint with HMAC signature verification",
+    template: `Implement an incoming webhook handler for {{provider}} in {{project.language}}{{#if project.framework}} / {{project.framework}}{{/if}}.
+
+Events to handle: {{events}}
+
+Requirements:
+1. Signature verification \u2014 validate HMAC-SHA256 signature from {{signatureHeader}} header before any processing
+2. Idempotency \u2014 use the event ID from the payload; skip duplicate events (store processed IDs for {{idempotencyWindow}})
+3. Immediate 200 response \u2014 acknowledge within 5 seconds; do real work asynchronously via a job queue
+4. Retry safety \u2014 all handlers must be idempotent (safe to call multiple times with same payload)
+5. Event routing \u2014 dispatch to the correct handler based on event type field
+6. Dead letter handling \u2014 after 3 failed processing attempts, move to dead letter queue and alert
+
+Payload parsing: validate against expected schema before processing; reject malformed events with 400 (but return 200 to provider to stop retries on schema mismatches \u2014 log for manual review).`,
+    contextSchema: [
+      { key: "provider", label: "Webhook provider", type: "text", placeholder: "Stripe, GitHub, Twilio" },
+      { key: "events", label: "Events to handle", type: "text", placeholder: "payment.succeeded, payment.failed, subscription.updated" },
+      { key: "signatureHeader", label: "Signature header name", type: "text", placeholder: "Stripe-Signature", default: "X-Hub-Signature-256" },
+      { key: "idempotencyWindow", label: "Idempotency window", type: "text", default: "24 hours" }
+    ],
+    tags: ["webhook", "integration", "security", "backend"],
+    version: "1.0.0"
+  },
+  {
+    id: "backend/background-job",
+    name: "Background Job Worker",
+    category: "backend",
+    description: "Implement a background job queue with retry, concurrency, and monitoring",
+    template: `Implement a background job system for {{project.name}} in {{project.language}}{{#if project.framework}} / {{project.framework}}{{/if}}.
+
+Queue backend: {{queueBackend}}
+Jobs to implement: {{jobs}}
+Concurrency: {{concurrency}} workers
+
+For each job:
+1. Job definition: typed payload interface, validate on enqueue
+2. Handler: process logic, idempotent, return success or throw to trigger retry
+3. Retry policy: exponential backoff (1s \u2192 5s \u2192 30s \u2192 2m \u2192 10m), max {{maxRetries}} attempts
+4. Dead letter queue: after max retries, move to DLQ with full context for manual inspection
+5. Progress tracking: update job status (pending/running/done/failed) in the queue store
+
+Worker process:
+- Graceful shutdown: finish current job, stop polling, exit
+- Concurrency: process up to {{concurrency}} jobs in parallel
+- Observability: log job start/end with duration and job ID
+
+Also provide: an enqueue helper, a job status query endpoint, and a DLQ viewer.`,
+    contextSchema: [
+      { key: "queueBackend", label: "Queue backend", type: "select", options: ["BullMQ (Redis)", "pg-boss (PostgreSQL)", "RabbitMQ", "AWS SQS"], default: "BullMQ (Redis)" },
+      { key: "jobs", label: "Jobs to implement", type: "text", placeholder: "send-email, resize-image, generate-report, sync-crm" },
+      { key: "concurrency", label: "Worker concurrency", type: "text", default: "5" },
+      { key: "maxRetries", label: "Max retry attempts", type: "text", default: "5" }
+    ],
+    tags: ["queue", "jobs", "async", "backend"],
+    version: "1.0.0"
+  },
+  {
+    id: "backend/health-check",
+    name: "Health Check Endpoints",
+    category: "backend",
+    description: "Implement liveness and readiness health check endpoints",
+    template: `Implement health check endpoints for {{project.name}} in {{project.language}}{{#if project.framework}} / {{project.framework}}{{/if}}.
+
+Dependencies to check: {{dependencies}}
+
+Endpoints:
+1. GET /health \u2014 liveness probe (is the process alive?)
+   - Always returns 200 if the process is running
+   - Response: { status: "ok", uptime: number, version: string }
+
+2. GET /ready \u2014 readiness probe (is the service ready to accept traffic?)
+   - Checks each dependency: {{dependencies}}
+   - Returns 200 if ALL checks pass, 503 if any fail
+   - Response: { status: "ready"|"degraded", checks: { [dep]: { status, latencyMs } } }
+
+3. GET /metrics \u2014 Prometheus-compatible metrics (optional)
+   - Expose: request count, error rate, response time histogram, queue depth
+
+Design rules:
+- Health checks must complete within 1 second
+- DB check: run a cheap query (SELECT 1), not a full table scan
+- Cache check: SET then GET a test key
+- Never expose sensitive config or internal error details in responses`,
+    contextSchema: [
+      { key: "dependencies", label: "Dependencies to check", type: "text", placeholder: "PostgreSQL database, Redis cache, external payment API" }
+    ],
+    tags: ["health", "monitoring", "kubernetes", "backend"],
+    version: "1.0.0"
+  },
+  // ── Frontend (continued) ──────────────────────────────────────────────────
+  {
+    id: "frontend/dark-mode",
+    name: "Dark Mode Toggle",
+    category: "frontend",
+    description: "Implement dark mode with system preference detection and persistence",
+    template: `Implement dark mode for {{project.name}} in {{project.language}}{{#if project.framework}} using {{project.framework}}{{/if}}.
+
+Styling system: {{stylingSystem}}
+
+Requirements:
+1. System preference detection: respect prefers-color-scheme on first visit
+2. User override: toggle button that overrides system preference
+3. Persistence: store user's choice in localStorage (key: "color-scheme")
+4. No flash: inject theme class on <html> before React hydrates (add a small blocking script)
+5. Smooth transition: CSS transition on background-color and color (200ms ease)
+
+Implementation:
+- useColorScheme() hook \u2014 returns { scheme, toggle, setScheme }
+- ThemeProvider component \u2014 reads from localStorage, applies class to document root
+- Toggle button component with sun/moon icon and accessible aria-label
+- CSS custom properties for all theme tokens (--bg-primary, --text-primary, etc.)
+
+{{#if (eq stylingSystem "Tailwind")}}- Use Tailwind's \`dark:\` variant with class strategy (darkMode: 'class' in config){{/if}}`,
+    contextSchema: [
+      { key: "stylingSystem", label: "Styling system", type: "select", options: ["Tailwind", "CSS Modules", "Styled Components", "Plain CSS"], default: "Tailwind" }
+    ],
+    tags: ["dark-mode", "theme", "accessibility", "frontend"],
+    version: "1.0.0"
+  },
+  {
+    id: "frontend/search-ui",
+    name: "Search UI",
+    category: "frontend",
+    description: "Build a search input with debouncing, loading states, and result display",
+    template: `Build a search UI component for {{project.name}} in {{project.language}}{{#if project.framework}} using {{project.framework}}{{/if}}.
+
+What is being searched: {{searchTarget}}
+Search mode: {{searchMode}}
+
+Component features:
+1. Input with debounce ({{debounceMs}}ms) \u2014 don't fire on every keystroke
+2. Loading indicator while fetching results
+3. Result list: display {{resultShape}} with keyboard navigation (\u2191\u2193 arrows, Enter to select, Escape to close)
+4. Empty state: "No results for '{{query}}'" with helpful suggestion
+5. Error state: network failure message with retry button
+6. Highlight matched terms in results using mark tags
+7. Accessible: role="combobox", aria-expanded, aria-autocomplete, aria-activedescendant
+
+{{#if (eq searchMode "client-side")}}- Load all data once, filter in-memory using fuzzy matching{{/if}}
+{{#if (eq searchMode "server-side")}}- Call GET /search?q= on each debounced input change; cancel previous request (AbortController){{/if}}
+
+Include useSearch() hook that encapsulates state, debounce, and fetch logic.`,
+    contextSchema: [
+      { key: "searchTarget", label: "What to search", type: "text", placeholder: "Products, users, or documentation articles" },
+      { key: "searchMode", label: "Search mode", type: "select", options: ["server-side", "client-side"], default: "server-side" },
+      { key: "debounceMs", label: "Debounce delay (ms)", type: "text", default: "300" },
+      { key: "resultShape", label: "Result display shape", type: "text", placeholder: "title + description + category badge" }
+    ],
+    tags: ["search", "debounce", "ux", "frontend"],
+    version: "1.0.0"
+  },
+  {
+    id: "frontend/modal-dialog",
+    name: "Modal / Dialog",
+    category: "frontend",
+    description: "Build an accessible modal dialog with focus trap and keyboard support",
+    template: `Build a modal/dialog component for {{project.name}} in {{project.language}}{{#if project.framework}} using {{project.framework}}{{/if}}.
+
+Modal type: {{modalType}}
+
+Accessibility requirements (WAI-ARIA Dialog pattern):
+1. role="dialog" with aria-modal="true" and aria-labelledby pointing to title
+2. Focus trap: Tab cycles only within modal; Shift+Tab in reverse
+3. Initial focus: first focusable element or close button on open
+4. Escape key closes; clicking overlay closes (configurable)
+5. Return focus to trigger element on close
+6. Prevent body scroll when open (add overflow: hidden to body)
+
+Component API:
+- <Modal open={bool} onClose={() => void} title="...">children</Modal>
+- useModal() hook \u2014 returns { open, close, isOpen } for programmatic control
+- Render in a Portal (document.body) to avoid z-index issues
+
+Animation: fade in (150ms) + scale up from 95% on open; reverse on close.
+
+Variants: {{modalType}} \u2014 provide appropriate default size and layout.`,
+    contextSchema: [
+      { key: "modalType", label: "Modal type", type: "select", options: ["confirmation dialog", "form dialog", "image/media viewer", "full-screen overlay"], default: "confirmation dialog" }
+    ],
+    tags: ["modal", "dialog", "accessibility", "frontend"],
+    version: "1.0.0"
+  },
+  {
+    id: "frontend/dashboard-widget",
+    name: "Dashboard Widget",
+    category: "frontend",
+    description: "Build a reusable dashboard widget with loading, error, and empty states",
+    template: `Build a reusable dashboard widget for {{project.name}} in {{project.language}}{{#if project.framework}} using {{project.framework}}{{/if}}.
+
+Widget purpose: {{purpose}}
+Data source: {{dataSource}}
+
+Widget structure:
+1. Widget shell: title, subtitle, optional action button (top-right), border/shadow
+2. Loading state: skeleton loader matching the content shape (not a spinner)
+3. Error state: friendly message + retry button; log error details to console only
+4. Empty state: illustration + clear call-to-action
+5. Content area: {{purpose}}
+
+Data fetching:
+- useWidget(endpoint) hook \u2014 handles fetch, polling (every {{pollInterval}}), and error state
+- SWR or React Query pattern: stale-while-revalidate for instant UI on revisit
+- Optimistic updates for any write actions within the widget
+
+Responsiveness: widget collapses gracefully on small screens; configurable width (1/3, 1/2, full).`,
+    contextSchema: [
+      { key: "purpose", label: "What the widget shows", type: "text", placeholder: "Revenue chart, recent orders table, user activity feed" },
+      { key: "dataSource", label: "Data endpoint", type: "text", placeholder: "GET /api/stats/revenue" },
+      { key: "pollInterval", label: "Auto-refresh interval", type: "text", default: "60 seconds" }
+    ],
+    tags: ["dashboard", "widget", "data-fetching", "frontend"],
+    version: "1.0.0"
+  },
+  {
+    id: "frontend/notifications",
+    name: "Notifications Center",
+    category: "frontend",
+    description: "Build an in-app notification system with a bell icon and notification list",
+    template: `Build a notifications center for {{project.name}} in {{project.language}}{{#if project.framework}} using {{project.framework}}{{/if}}.
+
+Notification types: {{types}}
+Delivery: {{delivery}}
+
+Components:
+1. NotificationBell \u2014 icon with unread count badge; count caps at 99+
+2. NotificationDropdown \u2014 opens below bell, lists recent {{maxVisible}} notifications
+3. NotificationItem \u2014 icon/avatar, title, body (truncated at 2 lines), relative timestamp ("2 min ago"), mark-read on click
+
+State management (useNotifications hook):
+- Fetch initial list from {{delivery}} on mount
+- Mark as read (single or all)
+- Unread count derived from list state
+- Optimistic mark-read (update UI immediately, revert on API error)
+
+{{#if (eq delivery "WebSocket")}}- Subscribe to WebSocket channel; prepend new notifications as they arrive; cap list at 50{{/if}}
+{{#if (eq delivery "polling")}}- Poll GET /notifications?unread=true every 30 seconds{{/if}}
+
+Accessibility: role="region" aria-label="Notifications", focus management in dropdown.`,
+    contextSchema: [
+      { key: "types", label: "Notification types", type: "text", placeholder: "system alert, user mention, task assigned, payment received" },
+      { key: "delivery", label: "Delivery mechanism", type: "select", options: ["WebSocket", "polling", "Server-Sent Events"], default: "WebSocket" },
+      { key: "maxVisible", label: "Max visible in dropdown", type: "text", default: "10" }
+    ],
+    tags: ["notifications", "real-time", "ux", "frontend"],
+    version: "1.0.0"
+  },
+  // ── Database (continued) ──────────────────────────────────────────────────
+  {
+    id: "database/transaction",
+    name: "Database Transaction",
+    category: "database",
+    description: "Implement a multi-step database transaction with rollback and savepoints",
+    template: `Implement a database transaction for {{project.name}} in {{project.language}}.
+
+Operation: {{operation}}
+Steps: {{steps}}
+Database: {{database}}
+
+Design:
+1. Wrap all steps in a single transaction \u2014 all succeed or all roll back
+2. Use savepoints for partial rollback within the transaction if {{useSavepoints}}
+3. Isolation level: {{isolationLevel}} \u2014 explain why this level is appropriate
+4. Optimistic locking: add version column to detect concurrent updates; throw ConflictError on mismatch
+5. Retry logic: on serialization failure (deadlock/conflict), retry up to 3 times with jitter
+
+Transaction helper:
+\`\`\`
+withTransaction(async (tx) => {
+  // all DB calls use tx, not the global pool
+  const result = await step1(tx);
+  await step2(tx, result);
+  return finalResult;
+});
+\`\`\`
+
+Provide the transaction wrapper, each step as a separate function, and a test that verifies rollback behavior.`,
+    contextSchema: [
+      { key: "operation", label: "What this transaction does", type: "text", placeholder: "Transfer funds between two accounts" },
+      { key: "steps", label: "Steps in the transaction", type: "text", placeholder: "1. Debit source, 2. Credit destination, 3. Insert audit log" },
+      { key: "database", label: "Database", type: "select", options: ["PostgreSQL", "MySQL", "SQLite", "MongoDB"], default: "PostgreSQL" },
+      { key: "isolationLevel", label: "Isolation level", type: "select", options: ["READ COMMITTED", "REPEATABLE READ", "SERIALIZABLE"], default: "READ COMMITTED" },
+      { key: "useSavepoints", label: "Use savepoints?", type: "boolean", default: false }
+    ],
+    tags: ["transaction", "database", "consistency", "backend"],
+    version: "1.0.0"
+  },
+  {
+    id: "database/full-text-search",
+    name: "Full-Text Search",
+    category: "database",
+    description: "Implement full-text search with ranking and filtering",
+    template: `Implement full-text search for {{entity}} in {{project.language}}.
+
+Fields to search: {{fields}}
+Database / search engine: {{engine}}
+Filters: {{filters}}
+
+Implementation:
+1. Index setup: create a full-text index on {{fields}}
+{{#if (eq engine "PostgreSQL")}}- Use tsvector columns + GIN index; trgm extension for fuzzy matching{{/if}}
+{{#if (eq engine "Elasticsearch")}}- Define mapping with text fields, analyzers, and custom tokenizers{{/if}}
+{{#if (eq engine "Meilisearch")}}- Configure searchable attributes, ranking rules, and stop words{{/if}}
+
+2. Search function:
+   - Accept: query string, filters ({{filters}}), pagination (page/limit), sort
+   - Return: { hits: Entity[], total: number, took: number }
+   - Highlight matched terms in results
+
+3. Ranking: boost results where query matches title > body > tags
+4. Stemming/synonyms: handle plural forms and common synonyms
+5. Typo tolerance: fuzzy match for queries > 4 characters
+
+Provide index migration/setup script and a search service class.`,
+    contextSchema: [
+      { key: "entity", label: "Entity to search", type: "text", placeholder: "Articles, products, or users" },
+      { key: "fields", label: "Searchable fields", type: "text", placeholder: "title, description, tags, author" },
+      { key: "engine", label: "Search engine", type: "select", options: ["PostgreSQL", "Elasticsearch", "Meilisearch", "Typesense"], default: "PostgreSQL" },
+      { key: "filters", label: "Filterable attributes", type: "text", placeholder: "category, status, dateRange, authorId" }
+    ],
+    tags: ["search", "database", "full-text", "backend"],
+    version: "1.0.0"
+  },
+  {
+    id: "database/indexing-strategy",
+    name: "Index Strategy",
+    category: "database",
+    description: "Design a database indexing strategy for a table with query pattern analysis",
+    template: `Design an indexing strategy for the {{tableName}} table in {{project.language}}.
+
+Columns: {{columns}}
+Common queries: {{queries}}
+Database: {{database}}
+
+Analyze each query pattern and recommend indexes:
+
+1. For each query, identify:
+   - Which columns appear in WHERE, ORDER BY, JOIN ON, and GROUP BY
+   - Selectivity of each filter column (high = good index candidate)
+   - Read vs write ratio (more writes \u2192 fewer indexes)
+
+2. Index recommendations:
+   - Single-column indexes for high-selectivity equality filters
+   - Composite indexes: column order = equality first, then range, then ORDER BY
+   - Covering indexes for read-heavy queries (include all SELECT columns)
+   - Partial indexes for filtered subsets (WHERE deleted_at IS NULL)
+
+3. Anti-patterns to avoid:
+   - Duplicate indexes
+   - Indexes on low-cardinality columns (boolean, status with 3 values)
+   - Over-indexing write-heavy tables
+
+Provide CREATE INDEX statements with comments explaining each decision, and EXPLAIN ANALYZE examples.`,
+    contextSchema: [
+      { key: "tableName", label: "Table name", type: "text", placeholder: "orders" },
+      { key: "columns", label: "Table columns", type: "text", placeholder: "id, user_id, status, created_at, total, deleted_at" },
+      { key: "queries", label: "Common query patterns", type: "text", placeholder: "Get orders by user (sorted by date), filter by status, sum totals by month" },
+      { key: "database", label: "Database", type: "select", options: ["PostgreSQL", "MySQL", "SQLite"], default: "PostgreSQL" }
+    ],
+    tags: ["indexing", "database", "performance", "sql"],
+    version: "1.0.0"
+  },
+  {
+    id: "database/backup-restore",
+    name: "Backup & Restore",
+    category: "database",
+    description: "Design and implement a database backup and restore procedure",
+    template: `Design a backup and restore procedure for {{project.name}}.
+
+Database: {{database}}
+Environment: {{environment}}
+Recovery objectives: RPO = {{rpo}}, RTO = {{rto}}
+
+Backup strategy:
+1. Full backup: schedule and retention (how many to keep)
+2. Incremental/WAL archiving: continuous capture of changes between full backups
+3. Storage: {{storage}} \u2014 encrypted at rest, versioned, cross-region copy
+4. Verification: after each backup, run a restore test to a throwaway instance and verify row counts
+
+Restore procedure (step-by-step runbook):
+1. Stop application traffic (maintenance mode)
+2. Identify target backup (point-in-time or specific snapshot)
+3. Restore to staging first \u2014 verify data integrity
+4. Promote to production
+5. Run smoke tests before re-enabling traffic
+
+Automation:
+- Backup script with notifications on failure (email/Slack)
+- Restore script with dry-run mode
+- Scheduled job (cron or cloud scheduler)
+- Alert: backup not received in > 25 hours
+
+RPO of {{rpo}} means: maximum {{rpo}} of data loss is acceptable.
+RTO of {{rto}} means: service must be restored within {{rto}}.`,
+    contextSchema: [
+      { key: "database", label: "Database", type: "select", options: ["PostgreSQL", "MySQL", "MongoDB", "SQLite"], default: "PostgreSQL" },
+      { key: "environment", label: "Environment", type: "select", options: ["AWS RDS", "GCP Cloud SQL", "self-hosted VPS", "Supabase"], default: "AWS RDS" },
+      { key: "rpo", label: "Recovery Point Objective", type: "text", default: "1 hour" },
+      { key: "rto", label: "Recovery Time Objective", type: "text", default: "4 hours" },
+      { key: "storage", label: "Backup storage", type: "select", options: ["AWS S3", "GCS", "Azure Blob", "local disk"], default: "AWS S3" }
+    ],
+    tags: ["backup", "disaster-recovery", "database", "devops"],
+    version: "1.0.0"
+  },
+  // ── Testing (continued) ───────────────────────────────────────────────────
+  {
+    id: "testing/snapshot-test",
+    name: "Snapshot Testing",
+    category: "testing",
+    description: "Set up snapshot testing for UI components or API responses",
+    template: `Set up snapshot testing for {{project.name}} in {{project.language}}{{#if project.framework}} using {{project.framework}}{{/if}}.
+
+Snapshot target: {{target}}
+Framework: {{testFramework}}
+
+Strategy:
+1. What to snapshot: stable, deterministic output \u2014 component render trees, API response shapes, serialized objects
+2. What NOT to snapshot: timestamps, UUIDs, random values \u2014 use matchers (expect.any(String)) for these
+3. Snapshot size: keep snapshots small and focused; large snapshots become meaningless noise
+
+For UI components ({{target}}):
+- Render with representative props (default, loading, error, empty states)
+- Use inline snapshots for small outputs (< 20 lines)
+- Use external .snap files for larger renders
+
+For API responses:
+- Snapshot the shape, not the values \u2014 use asymmetric matchers
+- Test: response has correct keys and value types
+
+Maintenance rules:
+- Update snapshots intentionally: \`--updateSnapshot\` flag with a review of the diff
+- Delete obsolete snapshots immediately
+- CI fails on unintentional snapshot changes`,
+    contextSchema: [
+      { key: "target", label: "What to snapshot", type: "select", options: ["React/Vue components", "API response shapes", "serialized objects", "CLI output"], default: "React/Vue components" },
+      { key: "testFramework", label: "Test framework", type: "select", options: ["Jest", "Vitest", "pytest", "Go testing"], default: "Vitest" }
+    ],
+    tags: ["snapshot", "testing", "regression"],
+    version: "1.0.0"
+  },
+  {
+    id: "testing/performance-test",
+    name: "Performance Test Plan",
+    category: "testing",
+    description: "Design a performance and load testing strategy with target thresholds",
+    template: `Design a performance test plan for {{project.name}}.
+
+Target endpoint/flow: {{target}}
+Expected load: {{expectedLoad}}
+Tool: {{tool}}
+
+Test types:
+1. **Baseline test** \u2014 single user, measure raw response time and resource usage
+2. **Load test** \u2014 ramp to {{expectedLoad}} over 5 minutes, hold for 10 minutes, ramp down
+3. **Stress test** \u2014 push to 2x {{expectedLoad}} to find the breaking point
+4. **Soak test** \u2014 run at 70% capacity for 1 hour to detect memory leaks
+
+Pass/fail thresholds:
+- p50 response time \u2264 {{p50Target}}
+- p95 response time \u2264 {{p95Target}}
+- p99 response time \u2264 {{p99Target}}
+- Error rate < 0.1%
+- CPU usage < 80% at target load
+- Memory growth < 5% per hour (soak test)
+
+Monitoring during test:
+- Application metrics: request rate, error rate, response time histogram
+- Infrastructure: CPU, memory, disk I/O, network throughput
+- Database: query time, connection pool usage, slow query log
+
+Provide k6/Locust/JMeter script and a results analysis template.`,
+    contextSchema: [
+      { key: "target", label: "What to test", type: "text", placeholder: "POST /api/checkout flow" },
+      { key: "expectedLoad", label: "Expected peak load", type: "text", placeholder: "500 concurrent users" },
+      { key: "tool", label: "Load testing tool", type: "select", options: ["k6", "Locust", "Artillery", "JMeter", "Apache Bench"], default: "k6" },
+      { key: "p50Target", label: "p50 target", type: "text", default: "200ms" },
+      { key: "p95Target", label: "p95 target", type: "text", default: "500ms" },
+      { key: "p99Target", label: "p99 target", type: "text", default: "1s" }
+    ],
+    tags: ["performance", "load-testing", "testing", "sre"],
+    version: "1.0.0"
+  },
+  {
+    id: "testing/contract-test",
+    name: "Contract Test",
+    category: "testing",
+    description: "Write consumer-driven contract tests between two services",
+    template: `Write consumer-driven contract tests between {{consumer}} and {{provider}} in {{project.language}}.
+
+Integration point: {{integrationPoint}}
+Tool: {{tool}}
+
+Consumer side ({{consumer}}):
+1. Define the contract: what the consumer expects from the provider (request + response shape)
+2. Write consumer test: mock the provider using the contract, verify consumer handles responses correctly
+3. Publish contract to a pact broker or shared file
+
+Provider side ({{provider}}):
+1. Load the consumer contract
+2. Run provider verification: replay each consumer interaction against the real provider
+3. Verify provider meets every expectation in the contract
+4. Publish verification result to the pact broker
+
+Contract includes:
+- Request: method, path, headers, body schema
+- Response: status code, headers, body schema (use type matchers, not exact values)
+
+CI integration:
+- Consumer: generate and publish pact on PR
+- Provider: verify pacts on PR (can-i-deploy check before merge)
+- Break the build if a provider change violates a consumer contract`,
+    contextSchema: [
+      { key: "consumer", label: "Consumer service", type: "text", placeholder: "frontend-app or order-service" },
+      { key: "provider", label: "Provider service", type: "text", placeholder: "user-api or payment-service" },
+      { key: "integrationPoint", label: "What they integrate on", type: "text", placeholder: "GET /users/:id and POST /payments" },
+      { key: "tool", label: "Contract testing tool", type: "select", options: ["Pact", "Spring Cloud Contract", "Dredd", "manual JSON schema"], default: "Pact" }
+    ],
+    tags: ["contract-testing", "microservices", "testing", "integration"],
+    version: "1.0.0"
+  },
+  {
+    id: "testing/mutation-test",
+    name: "Mutation Testing",
+    category: "testing",
+    description: "Set up mutation testing to measure the true quality of your test suite",
+    template: `Set up mutation testing for {{project.name}} in {{project.language}}.
+
+Target: {{target}}
+Tool: {{tool}}
+
+What mutation testing reveals:
+- Tests that pass even when code is broken (weak assertions)
+- Lines with no meaningful coverage (tests that don't assert)
+- Logic faults that your tests can't detect
+
+Setup:
+1. Install and configure {{tool}} for the target source files
+2. Run baseline: all tests must pass before mutating
+3. Set a minimum mutation score threshold: {{threshold}}% \u2014 fail CI if score drops below
+
+Interpreting results:
+- **Killed mutant**: your tests detected the code change \u2192 good
+- **Survived mutant**: the code changed but all tests still passed \u2192 weak test
+- **Timeout mutant**: mutant caused infinite loop \u2192 mark as killed
+
+For each survived mutant, write a new assertion that kills it. Focus on:
+- Boundary conditions (off-by-one errors)
+- Boolean operators (AND vs OR, negation)
+- Arithmetic operators (+ vs -, * vs /)
+- Return value mutations (returning null, empty string, 0)
+
+Exclude from mutation: generated code, type definitions, constants, logging.`,
+    contextSchema: [
+      { key: "target", label: "Source to mutate", type: "text", placeholder: "src/services/ and src/utils/" },
+      { key: "tool", label: "Mutation testing tool", type: "select", options: ["Stryker (JS/TS)", "mutmut (Python)", "pitest (Java)", "go-mutesting (Go)"], default: "Stryker (JS/TS)" },
+      { key: "threshold", label: "Minimum mutation score (%)", type: "text", default: "80" }
+    ],
+    tags: ["mutation-testing", "test-quality", "testing"],
+    version: "1.0.0"
+  },
+  // ── DevOps (continued) ────────────────────────────────────────────────────
+  {
+    id: "devops/kubernetes",
+    name: "Kubernetes Manifest",
+    category: "devops",
+    description: "Generate production-ready Kubernetes deployment manifests",
+    template: `Generate Kubernetes manifests for {{project.name}}.
+
+Service type: {{serviceType}}
+Replicas: {{replicas}}
+Resources: CPU {{cpuRequest}}/{{cpuLimit}}, Memory {{memRequest}}/{{memLimit}}
+
+Manifests to produce:
+1. **Namespace** \u2014 isolate the application
+2. **Deployment** \u2014 {{replicas}} replicas, rolling update strategy (maxSurge: 1, maxUnavailable: 0)
+3. **Service** \u2014 {{serviceType}} to expose the deployment
+4. **ConfigMap** \u2014 non-sensitive configuration
+5. **Secret** \u2014 sensitive values (base64 encoded, reference env vars from here)
+6. **HorizontalPodAutoscaler** \u2014 scale on CPU > 70%, min {{replicas}} / max {{maxReplicas}} pods
+7. **PodDisruptionBudget** \u2014 minAvailable: {{minAvailable}} during cluster maintenance
+
+Pod spec requirements:
+- Liveness probe: GET /health, initialDelaySeconds: 30, periodSeconds: 10
+- Readiness probe: GET /ready, initialDelaySeconds: 10, periodSeconds: 5
+- Resource requests and limits (always set both)
+- Security context: runAsNonRoot: true, readOnlyRootFilesystem: true
+- Image pull policy: Always (for mutable tags like :latest)
+
+Provide all manifests in a single YAML file separated by ---`,
+    contextSchema: [
+      { key: "serviceType", label: "Kubernetes service type", type: "select", options: ["ClusterIP", "LoadBalancer", "NodePort"], default: "ClusterIP" },
+      { key: "replicas", label: "Initial replica count", type: "text", default: "2" },
+      { key: "maxReplicas", label: "Max replicas (HPA)", type: "text", default: "10" },
+      { key: "minAvailable", label: "Min available (PDB)", type: "text", default: "1" },
+      { key: "cpuRequest", label: "CPU request", type: "text", default: "100m" },
+      { key: "cpuLimit", label: "CPU limit", type: "text", default: "500m" },
+      { key: "memRequest", label: "Memory request", type: "text", default: "128Mi" },
+      { key: "memLimit", label: "Memory limit", type: "text", default: "512Mi" }
+    ],
+    tags: ["kubernetes", "k8s", "devops", "infrastructure"],
+    version: "1.0.0"
+  },
+  {
+    id: "devops/terraform",
+    name: "Terraform Module",
+    category: "devops",
+    description: "Write a reusable Terraform module for cloud infrastructure",
+    template: `Write a Terraform module for {{resource}} on {{cloud}}.
+
+Module purpose: {{purpose}}
+Environment: {{environment}}
+
+Module structure:
+\`\`\`
+modules/{{moduleName}}/
+  main.tf       \u2014 resource definitions
+  variables.tf  \u2014 input variables with types, descriptions, and defaults
+  outputs.tf    \u2014 output values consumed by other modules
+  versions.tf   \u2014 required_providers with version constraints
+  README.md     \u2014 usage example with all variables documented
+\`\`\`
+
+Requirements:
+1. All resource names include var.environment for env isolation (dev/staging/prod)
+2. Tags on every resource: Environment, Project, ManagedBy=terraform
+3. No hardcoded values \u2014 everything configurable via variables
+4. Use data sources to look up existing resources (VPCs, AMIs) by tag/name, not ID
+5. Remote state: provide example backend config (S3 + DynamoDB lock)
+6. Sensitive outputs: mark sensitive = true; never output secrets as plain text
+
+Provide: the module files, a usage example in a root module, and a terraform.tfvars.example.`,
+    contextSchema: [
+      { key: "resource", label: "Resource to create", type: "text", placeholder: "RDS PostgreSQL instance, ECS service, S3 + CloudFront CDN" },
+      { key: "cloud", label: "Cloud provider", type: "select", options: ["AWS", "GCP", "Azure", "DigitalOcean"], default: "AWS" },
+      { key: "purpose", label: "Module purpose", type: "text", placeholder: "Managed PostgreSQL database with automated backups and read replica" },
+      { key: "environment", label: "Target environment", type: "text", default: "staging" },
+      { key: "moduleName", label: "Module name", type: "text", placeholder: "rds-postgres" }
+    ],
+    tags: ["terraform", "iac", "infrastructure", "devops"],
+    version: "1.0.0"
+  },
+  {
+    id: "devops/secrets-management",
+    name: "Secrets Management",
+    category: "devops",
+    description: "Design a secrets management strategy for a multi-environment application",
+    template: `Design a secrets management strategy for {{project.name}}.
+
+Environments: {{environments}}
+Secrets to manage: {{secrets}}
+Secrets store: {{store}}
+
+Strategy:
+1. **Secret classification**
+   - Tier 1 (critical): database passwords, JWT signing keys, payment API keys \u2192 {{store}}
+   - Tier 2 (sensitive): third-party API keys, webhook secrets \u2192 {{store}} or env vars
+   - Tier 3 (config): feature flags, URLs, timeouts \u2192 environment variables or config files
+
+2. **Rotation**
+   - Automated rotation for DB credentials ({{store}} + DB user rotation)
+   - Rotation schedule: every 90 days; zero-downtime via dual-secret pattern
+   - Alert on secrets within 14 days of expiry
+
+3. **Access control**
+   - Each service gets its own IAM role/service account \u2014 least privilege
+   - Developers never see production secrets; use separate dev secrets
+   - Audit log: every secret access logged with caller identity and timestamp
+
+4. **CI/CD integration**
+   - Reference secrets by name in CI config, never copy values into CI env vars
+   - Dynamic secrets for CI builds (short-lived, scoped to the build)
+
+5. **Emergency procedures**
+   - Runbook: how to rotate a compromised secret in < 15 minutes
+   - Break-glass access with full audit trail
+
+Never commit secrets to git. Scan with truffleHog or gitleaks in pre-commit hooks.`,
+    contextSchema: [
+      { key: "environments", label: "Environments", type: "text", default: "development, staging, production" },
+      { key: "secrets", label: "Secrets to manage", type: "text", placeholder: "DB password, JWT secret, Stripe key, SendGrid API key" },
+      { key: "store", label: "Secrets store", type: "select", options: ["AWS Secrets Manager", "HashiCorp Vault", "GCP Secret Manager", "Azure Key Vault", "Doppler"], default: "AWS Secrets Manager" }
+    ],
+    tags: ["secrets", "security", "devops", "infrastructure"],
+    version: "1.0.0"
+  },
+  {
+    id: "devops/blue-green-deploy",
+    name: "Blue-Green Deployment",
+    category: "devops",
+    description: "Design a blue-green deployment strategy for zero-downtime releases",
+    template: `Design a blue-green deployment strategy for {{project.name}}.
+
+Infrastructure: {{infrastructure}}
+Traffic routing: {{router}}
+
+Setup:
+- **Blue** environment: current production (receives 100% traffic)
+- **Green** environment: new version (receives 0% traffic during preparation)
+
+Deployment procedure:
+1. Deploy new version to **green** (parallel to live blue)
+2. Run smoke tests against green (health check, critical paths)
+3. Warm up green: pre-load caches, warm JIT
+4. Switch traffic: {{router}} routes 100% to green \u2192 blue goes idle
+5. Monitor green for 15 minutes (error rate, latency, business metrics)
+6. **Rollback path**: switch router back to blue \u2014 instant, no re-deploy
+7. Decommission blue after 24-hour hold period
+
+Database migrations:
+- Must be backward-compatible (blue and green run simultaneously during switch)
+- Use expand-contract pattern: add new column \u2192 deploy \u2192 backfill \u2192 remove old column
+- Never rename or drop columns in the same deploy as the app change
+
+Monitoring gates (auto-rollback if triggered):
+- Error rate > 1% for 2 consecutive minutes
+- p99 latency > 2\xD7 baseline
+- Failed health checks on > 1 instance
+
+Provide: infrastructure-as-code snippets for {{infrastructure}} and a deployment runbook.`,
+    contextSchema: [
+      { key: "infrastructure", label: "Infrastructure", type: "select", options: ["AWS ECS", "Kubernetes", "AWS Elastic Beanstalk", "Heroku", "bare VMs"], default: "Kubernetes" },
+      { key: "router", label: "Traffic router", type: "select", options: ["AWS ALB", "NGINX", "Kubernetes Ingress", "Cloudflare"], default: "Kubernetes Ingress" }
+    ],
+    tags: ["deployment", "blue-green", "zero-downtime", "devops"],
+    version: "1.0.0"
+  },
+  {
+    id: "devops/ci-pipeline",
+    name: "CI/CD Pipeline",
+    category: "devops",
+    description: "Design a full CI/CD pipeline from commit to production",
+    template: `Design a CI/CD pipeline for {{project.name}} using {{ciTool}}.
+
+Language: {{project.language}}
+Deploy target: {{deployTarget}}
+
+Pipeline stages:
+1. **Lint & Format** \u2014 fail fast on style issues (< 1 min)
+2. **Build** \u2014 compile, bundle, generate artifacts
+3. **Unit tests** \u2014 isolated, mocked, fast (< 3 min)
+4. **Integration tests** \u2014 real DB + services (Docker Compose in CI)
+5. **Security scan** \u2014 SAST (Semgrep/SonarQube), dependency audit (npm audit/pip-audit), secret scan (gitleaks)
+6. **Build image** \u2014 Docker multi-stage, tag with git SHA
+7. **Push to registry** \u2014 push image, update image tag in IaC repo
+8. **Deploy to staging** \u2014 automatic on main branch merge
+9. **Smoke test** \u2014 hit critical endpoints on staging
+10. **Deploy to production** \u2014 manual approval gate (or auto if smoke tests pass)
+11. **Post-deploy verification** \u2014 run synthetic monitors for 5 minutes
+
+Branch strategy:
+- Feature branches: run stages 1-5
+- Main branch: run all stages through staging deploy
+- Tags (v*): deploy to production after manual approval
+
+Provide the full {{ciTool}} configuration file with all stages.`,
+    contextSchema: [
+      { key: "ciTool", label: "CI/CD tool", type: "select", options: ["GitHub Actions", "GitLab CI", "CircleCI", "Jenkins", "Bitbucket Pipelines"], default: "GitHub Actions" },
+      { key: "deployTarget", label: "Deploy target", type: "select", options: ["Kubernetes (kubectl)", "AWS ECS", "Heroku", "Fly.io", "VPS (SSH)"], default: "Kubernetes (kubectl)" }
+    ],
+    tags: ["ci-cd", "pipeline", "devops", "automation"],
+    version: "1.0.0"
+  },
+  // ── Academic (continued) ──────────────────────────────────────────────────
+  {
+    id: "academic/graph-traversal",
+    name: "Graph Traversal",
+    category: "academic",
+    description: "Implement and explain BFS and DFS graph traversal algorithms",
+    template: `Implement BFS and DFS graph traversal for {{project.name}} in {{project.language}}.
+
+Graph type: {{graphType}}
+Application: {{application}}
+
+Implement both algorithms:
+
+**Breadth-First Search (BFS):**
+- Use a queue (FIFO) \u2014 process nodes level by level
+- Time: O(V+E), Space: O(V)
+- Use when: shortest path in unweighted graph, level-order traversal
+
+**Depth-First Search (DFS):**
+- Use a stack (explicit or call stack for recursion)
+- Time: O(V+E), Space: O(V) \u2014 but recursion risks stack overflow on deep graphs
+- Use when: cycle detection, topological sort, connected components
+
+Applications for {{application}}:
+- Explain which algorithm is more appropriate and why
+- Implement the specialized variant (shortest path BFS / topological sort DFS)
+
+Include:
+- Graph representation: adjacency list (space-efficient for sparse graphs)
+- Visited set to handle cycles in undirected graphs
+- Traced path reconstruction (parent map)
+- Unit tests with: disconnected graph, cyclic graph, single-node graph, empty graph
+
+{{#if (eq project.type "student")}}- Add detailed comments explaining queue/stack state at each step{{/if}}`,
+    contextSchema: [
+      { key: "graphType", label: "Graph type", type: "select", options: ["undirected unweighted", "directed unweighted", "directed weighted", "DAG"], default: "undirected unweighted" },
+      { key: "application", label: "Real-world application", type: "text", placeholder: "Social network friend suggestions, file system traversal, dependency resolution" }
+    ],
+    tags: ["graphs", "bfs", "dfs", "algorithms", "academic"],
+    version: "1.0.0"
+  },
+  {
+    id: "academic/dynamic-programming",
+    name: "Dynamic Programming",
+    category: "academic",
+    description: "Solve a problem using dynamic programming with memoization and tabulation",
+    template: `Solve {{problem}} using dynamic programming in {{project.language}}.
+
+Approach: {{approach}}
+
+Step-by-step DP methodology:
+1. **Identify overlapping subproblems**: show a recursion tree that reveals repeated calls
+2. **Define the state**: what does dp[i] (or dp[i][j]) represent?
+3. **State transition (recurrence)**: write the formula relating dp[i] to smaller subproblems
+4. **Base cases**: smallest subproblems that can be answered directly
+5. **Iteration order**: which direction to fill the table (top-down or bottom-up)
+
+Implement both:
+- **Top-down (memoization)**: recursive + cache (dict/array), natural to write
+- **Bottom-up (tabulation)**: iterative, fills DP table from base cases up
+
+Complexity analysis:
+- Brute force: O(?) time
+- With DP: O(?) time, O(?) space
+- Space optimization (if applicable): reduce to O(1) or O(n) by only keeping needed rows
+
+Problem: {{problem}}
+Concrete example walkthrough: trace through a small input step by step, showing the DP table.
+
+{{#if (eq project.type "student")}}- Explain why greedy fails for this problem (if applicable){{/if}}`,
+    contextSchema: [
+      { key: "problem", label: "Problem to solve", type: "text", placeholder: "Longest common subsequence, 0/1 knapsack, coin change, edit distance" },
+      { key: "approach", label: "Starting approach", type: "select", options: ["top-down (memoization)", "bottom-up (tabulation)", "both"], default: "both" }
+    ],
+    tags: ["dynamic-programming", "memoization", "algorithms", "academic"],
+    version: "1.0.0"
+  },
+  {
+    id: "academic/binary-tree",
+    name: "Binary Tree Operations",
+    category: "academic",
+    description: "Implement binary tree traversals, insertion, deletion, and balancing",
+    template: `Implement binary tree operations for {{project.name}} in {{project.language}}.
+
+Tree type: {{treeType}}
+
+Implement:
+1. **Node structure**: value, left, right pointers (generic/typed)
+2. **Traversals** (recursive + iterative versions):
+   - In-order: Left \u2192 Root \u2192 Right (gives sorted sequence for BST)
+   - Pre-order: Root \u2192 Left \u2192 Right (useful for serialization)
+   - Post-order: Left \u2192 Right \u2192 Root (useful for deletion, expression evaluation)
+   - Level-order (BFS): use a queue, returns levels as array of arrays
+
+3. **BST operations** (if {{treeType}} is BST):
+   - insert(value): maintain BST property, O(log n) average
+   - search(value): return node or null
+   - delete(value): handle 3 cases (leaf, one child, two children \u2014 use in-order successor)
+   - isValid(): verify BST property using min/max bounds
+
+4. **Tree properties**:
+   - height(): max depth from root to leaf
+   - size(): total node count
+   - isBalanced(): height difference \u2264 1 for all subtrees
+
+{{#if (eq treeType "AVL tree")}}- Implement AVL rotations (LL, RR, LR, RL) to maintain balance after insert/delete{{/if}}
+
+Include: edge cases (empty tree, single node, skewed tree), and complexity analysis for each operation.`,
+    contextSchema: [
+      { key: "treeType", label: "Tree type", type: "select", options: ["Binary Search Tree (BST)", "AVL tree", "general binary tree"], default: "Binary Search Tree (BST)" }
+    ],
+    tags: ["binary-tree", "bst", "data-structures", "academic"],
+    version: "1.0.0"
+  },
+  {
+    id: "academic/hash-table",
+    name: "Hash Table Design",
+    category: "academic",
+    description: "Design and implement a hash table with collision handling",
+    template: `Design and implement a hash table for {{project.name}} in {{project.language}}.
+
+Collision strategy: {{collisionStrategy}}
+Key type: {{keyType}}
+
+Implementation:
+1. **Hash function**:
+   - For strings: polynomial rolling hash (djb2 or FNV-1a)
+   - For integers: Knuth's multiplicative hashing
+   - Properties: deterministic, uniform distribution, fast to compute
+
+2. **Collision handling \u2014 {{collisionStrategy}}**:
+{{#if (eq collisionStrategy "chaining")}}   - Each bucket holds a linked list of entries
+   - Lookup: hash \u2192 bucket \u2192 linear scan of chain
+   - Worst case: O(n) with bad hash function; O(1) average with good hash + load factor < 0.7{{/if}}
+{{#if (eq collisionStrategy "open addressing")}}   - All entries stored in the array; probe on collision
+   - Probe sequence: linear (h+1, h+2...) or quadratic (h+1\xB2, h+2\xB2...) or double hashing
+   - Deletion: use tombstone markers, not null (null would break probe chains){{/if}}
+
+3. **Load factor and resizing**:
+   - Threshold: resize when load factor > 0.7 (chaining) or > 0.5 (open addressing)
+   - Resize: allocate 2\xD7 array, re-hash all entries (do NOT copy \u2014 old indices are invalid)
+
+4. **API**: get(key), set(key, value), delete(key), has(key), size()
+
+Include: analysis of average vs worst-case complexity, and demonstration of clustering effect.
+
+{{#if (eq project.type "student")}}- Show why a bad hash function (e.g., always returning 0) degrades to O(n){{/if}}`,
+    contextSchema: [
+      { key: "collisionStrategy", label: "Collision handling", type: "select", options: ["chaining", "open addressing"], default: "chaining" },
+      { key: "keyType", label: "Key type", type: "select", options: ["string", "integer", "generic/any"], default: "string" }
+    ],
+    tags: ["hash-table", "data-structures", "hashing", "academic"],
+    version: "1.0.0"
+  },
+  // ── Review (continued) ────────────────────────────────────────────────────
+  {
+    id: "review/dependency-audit",
+    name: "Dependency Audit",
+    category: "review",
+    description: "Audit project dependencies for security vulnerabilities, outdated packages, and bloat",
+    template: `Audit the dependencies of {{project.name}} ({{project.language}}).
+
+Scope: {{scope}}
+
+Run these checks and report findings:
+
+1. **Security vulnerabilities**
+   - Run: \`npm audit --json\` / \`pip-audit\` / \`cargo audit\` / \`bundle audit\`
+   - Classify: Critical/High/Medium/Low
+   - For each Critical/High: identify the vulnerable package, the attack vector, and whether it's a direct or transitive dependency
+   - Action: upgrade, replace, or accept risk with justification
+
+2. **Outdated packages**
+   - Run: \`npm outdated\` / \`pip list --outdated\`
+   - Classify: major update (breaking), minor (new features), patch (bug fixes)
+   - Prioritize: packages with known CVEs or that are no longer maintained
+
+3. **Unused dependencies**
+   - Check: packages in package.json not imported anywhere in source
+   - Tools: \`depcheck\` (JS), \`deptry\` (Python)
+
+4. **Bundle size impact** (for frontend):
+   - Largest packages by install size
+   - Suggest lighter alternatives (e.g., date-fns vs moment, nanoid vs uuid)
+
+5. **License compatibility**
+   - Flag: GPL licenses in a commercial project, unlicensed packages
+
+Provide: prioritized action list with effort estimates.`,
+    contextSchema: [
+      { key: "scope", label: "What to audit", type: "select", options: ["all dependencies", "production only", "direct dependencies only"], default: "all dependencies" }
+    ],
+    tags: ["dependencies", "security", "audit", "review"],
+    version: "1.0.0"
+  },
+  {
+    id: "review/license-check",
+    name: "License Compatibility Review",
+    category: "review",
+    description: "Audit open-source licenses in the dependency tree for legal compatibility",
+    template: `Review open-source license compatibility for {{project.name}}.
+
+Project license: {{projectLicense}}
+Use case: {{useCase}}
+
+License compatibility matrix for {{projectLicense}} / {{useCase}}:
+
+| License | Compatible? | Notes |
+|---------|-------------|-------|
+| MIT | \u2705 Yes | Permissive, only requires attribution |
+| Apache 2.0 | \u2705 Yes | Permissive, requires NOTICE file |
+| BSD 2/3-Clause | \u2705 Yes | Permissive |
+| ISC | \u2705 Yes | Equivalent to simplified MIT |
+| LGPL v2/v3 | \u26A0\uFE0F Conditional | OK if dynamically linked; static link requires source disclosure |
+| GPL v2/v3 | \u274C No (commercial) | Copyleft \u2014 derivative work must also be GPL |
+| AGPL | \u274C No | Strongest copyleft \u2014 SaaS use triggers disclosure |
+| CC0 | \u2705 Yes | Public domain dedication |
+| Unlicensed | \u274C No | All rights reserved by default |
+
+Scan steps:
+1. Run \`license-checker --json\` (npm) or \`pip-licenses\` (Python) to list all licenses
+2. Flag all non-permissive licenses for legal review
+3. For flagged packages: find an MIT-licensed alternative or seek a commercial license
+
+Output: a CSV of all dependencies with their license, and a list requiring legal review.`,
+    contextSchema: [
+      { key: "projectLicense", label: "Your project's license", type: "select", options: ["MIT", "Apache 2.0", "Proprietary/Commercial", "GPL v3", "AGPL"], default: "Proprietary/Commercial" },
+      { key: "useCase", label: "Use case", type: "select", options: ["commercial SaaS", "open-source library", "internal tool", "academic project"], default: "commercial SaaS" }
+    ],
+    tags: ["license", "legal", "compliance", "review"],
+    version: "1.0.0"
+  },
+  {
+    id: "review/documentation-review",
+    name: "Documentation Review",
+    category: "review",
+    description: "Audit project documentation for completeness, accuracy, and clarity",
+    template: `Review the documentation for {{project.name}}.
+
+Documentation types to review: {{docTypes}}
+
+For each document, evaluate:
+
+**Completeness checklist:**
+- [ ] README: project purpose, installation, quick-start example, configuration, contributing guide
+- [ ] API docs: every public endpoint documented (method, path, auth, request shape, response shape, error codes)
+- [ ] Architecture: system diagram, component responsibilities, data flow, external dependencies
+- [ ] Deployment: step-by-step guide for each environment, rollback instructions
+- [ ] Runbooks: top 5 most likely incidents with diagnosis and resolution steps
+
+**Quality checks:**
+- Accuracy: does it match the current code? (spot-check 5 random code samples against docs)
+- Clarity: would a new team member understand this in < 30 minutes?
+- Code examples: do they actually run? Are they up to date?
+- Broken links: check all internal and external links
+- Outdated screenshots or UI references
+
+**Scoring (1-5 per dimension):**
+- Coverage: what % of the codebase is documented?
+- Accuracy: how many outdated/incorrect claims were found?
+- Clarity: readability and structure
+- Maintainability: is it easy to keep up to date?
+
+Output: prioritized list of gaps with suggested content for the top 3.`,
+    contextSchema: [
+      { key: "docTypes", label: "Documentation to review", type: "text", placeholder: "README, API docs, architecture diagrams, deployment guide" }
+    ],
+    tags: ["documentation", "review", "quality"],
+    version: "1.0.0"
+  },
+  {
+    id: "review/load-testing-plan",
+    name: "Load Testing Review",
+    category: "review",
+    description: "Review and improve an existing load testing setup",
+    template: `Review the load testing setup for {{project.name}}.
+
+Existing setup: {{existingSetup}}
+Target SLOs: {{slos}}
+
+Review dimensions:
+
+1. **Test scenario coverage**
+   - Does the load test reflect real user behavior (not just single endpoints)?
+   - Is the think time (pause between requests) realistic?
+   - Does it cover concurrent sessions, not just concurrent requests?
+
+2. **Ramp-up strategy**
+   - Is traffic introduced gradually (step-up) or all at once (spike)?
+   - Does it include a warm-up period to fill caches?
+
+3. **Assertions and thresholds**
+   - Are pass/fail thresholds defined against SLOs: {{slos}}?
+   - Does it assert on error rate (not just response time)?
+
+4. **Data realism**
+   - Does each virtual user use unique data (not the same user ID)?
+   - Is the request distribution realistic (20% POST, 80% GET)?
+
+5. **Monitoring correlation**
+   - Can you correlate load test timeline with APM/metrics data?
+   - Are resource metrics (CPU, memory, DB connections) captured during the test?
+
+6. **Findings and recommendations**
+   - List what's good about the existing setup
+   - List gaps and specific fixes
+
+Provide: an improved test script and a results analysis checklist.`,
+    contextSchema: [
+      { key: "existingSetup", label: "Existing setup description", type: "text", placeholder: "k6 script hitting /api/products with 100 VUs for 5 minutes" },
+      { key: "slos", label: "Target SLOs", type: "text", placeholder: "p95 < 500ms, error rate < 0.1%, 99.9% availability" }
+    ],
+    tags: ["load-testing", "slo", "performance", "review"],
+    version: "1.0.0"
+  },
+  // ── General (continued) ───────────────────────────────────────────────────
+  {
+    id: "general/feature-flag",
+    name: "Feature Flag",
+    category: "general",
+    description: "Implement a feature flag system with gradual rollout and kill switch",
+    template: `Implement a feature flag system for {{project.name}} in {{project.language}}{{#if project.framework}} using {{project.framework}}{{/if}}.
+
+Flag backend: {{flagBackend}}
+Flags to implement: {{flags}}
+
+Design:
+1. **Flag definition**: name, description, enabled (bool), rollout % (0-100), targeting rules
+2. **Evaluation**: isEnabled(flagName, context?) \u2014 context includes userId, environment, attributes
+3. **Rollout strategies**:
+   - All/none: simple on/off
+   - Percentage: hash(userId + flagName) % 100 < rolloutPct \u2014 consistent per user
+   - Targeted: specific user IDs, email domains, or custom attributes
+
+4. **Code integration**:
+\`\`\`
+if (await flags.isEnabled('new-checkout', { userId })) {
+  // new path
+} else {
+  // old path
+}
+\`\`\`
+
+5. **Kill switch**: disable a flag immediately without a deploy (set rollout to 0%)
+6. **Flag cleanup**: when a flag reaches 100% and is stable, delete it and the old code path \u2014 track flag age to enforce cleanup
+
+{{#if (eq flagBackend "environment variables")}}- Simple approach: flags as env vars; redeploy required to change{{/if}}
+{{#if (eq flagBackend "database")}}- Store in DB table: flags(name, config JSON, updated_at); cache with 60s TTL{{/if}}
+{{#if (eq flagBackend "LaunchDarkly / GrowthBook")}}- Use SDK; evaluate server-side; stream flag changes without redeploy{{/if}}
+
+Include: useFeatureFlag(name) React hook and a flag admin endpoint.`,
+    contextSchema: [
+      { key: "flagBackend", label: "Flag storage", type: "select", options: ["environment variables", "database", "LaunchDarkly / GrowthBook", "Redis"], default: "database" },
+      { key: "flags", label: "Flags to implement", type: "text", placeholder: "new-checkout-flow, ai-recommendations, dark-mode-v2" }
+    ],
+    tags: ["feature-flags", "rollout", "experimentation", "general"],
+    version: "1.0.0"
+  },
+  {
+    id: "general/ab-testing",
+    name: "A/B Test Plan",
+    category: "general",
+    description: "Design an A/B test with statistical validity and analysis plan",
+    template: `Design an A/B test for {{project.name}}.
+
+Hypothesis: {{hypothesis}}
+Primary metric: {{primaryMetric}}
+
+Test design:
+
+**1. Hypothesis**
+- Control (A): {{control}}
+- Variant (B): {{variant}}
+- Expected lift: {{expectedLift}}
+
+**2. Statistical requirements**
+- Significance level: \u03B1 = 0.05 (5% false positive rate)
+- Statistical power: 1 - \u03B2 = 0.80 (80% chance to detect a real effect)
+- Minimum detectable effect: {{expectedLift}}
+- Required sample size: [calculate using power analysis for {{primaryMetric}} baseline]
+
+**3. Randomization**
+- Unit of randomization: {{randomizationUnit}} (must be consistent across sessions)
+- Traffic split: 50/50 control/variant
+- Exclusion: new vs returning, mobile vs desktop (analyze as segments, not filters)
+
+**4. Duration**
+- Run for at least 2 full weeks (captures weekly seasonality)
+- Stop early only for safety issues, not promising results (avoids peeking bias)
+
+**5. Analysis**
+- Primary metric: {{primaryMetric}} \u2014 use t-test or z-test for proportions
+- Guardrail metrics: metrics that must not regress (page load time, error rate)
+- Segment analysis: check if effect is consistent across device, region, user age
+
+**6. Decision criteria**
+- Ship if: significant lift in primary metric AND no guardrail regression
+- Iterate if: directional positive but not significant (run longer or redesign)
+- Kill if: negative impact on primary or guardrail metric`,
+    contextSchema: [
+      { key: "hypothesis", label: "What you believe will improve", type: "text", placeholder: "Changing the CTA button color from gray to blue will increase clicks" },
+      { key: "control", label: "Control (current state)", type: "text", placeholder: 'Gray "Sign up" button' },
+      { key: "variant", label: "Variant (change to test)", type: "text", placeholder: 'Blue "Get started free" button' },
+      { key: "primaryMetric", label: "Primary metric", type: "text", placeholder: "Sign-up conversion rate" },
+      { key: "expectedLift", label: "Minimum expected lift", type: "text", default: "5%" },
+      { key: "randomizationUnit", label: "Randomization unit", type: "select", options: ["user ID", "session ID", "device ID", "IP address"], default: "user ID" }
+    ],
+    tags: ["ab-testing", "experimentation", "analytics", "general"],
+    version: "1.0.0"
+  },
+  {
+    id: "general/logging-strategy",
+    name: "Logging Strategy",
+    category: "general",
+    description: "Design a structured logging strategy with levels, fields, and sampling",
+    template: `Design a structured logging strategy for {{project.name}} in {{project.language}}{{#if project.framework}} using {{project.framework}}{{/if}}.
+
+Log destination: {{destination}}
+
+**Log levels (use strictly):**
+- DEBUG: detailed internal state \u2014 disabled in production
+- INFO: business-significant events (user registered, order placed, job completed)
+- WARN: unexpected state that the system recovered from (retry succeeded, fallback used)
+- ERROR: failure requiring investigation (exception with stack trace, failed job, broken integration)
+- FATAL: process is about to exit
+
+**Required fields on every log line:**
+\`\`\`json
+{
+  "timestamp": "ISO 8601",
+  "level": "info",
+  "service": "{{project.name}}",
+  "traceId": "propagated from incoming request",
+  "message": "human-readable summary",
+  ... event-specific fields
+}
+\`\`\`
+
+**What to log:**
+- \u2705 Request in/out (method, path, status, duration, userId)
+- \u2705 External API calls (provider, endpoint, status, latency)
+- \u2705 Database queries > 500ms (query, params redacted, duration)
+- \u2705 Background job lifecycle (started, completed, failed, duration)
+- \u274C Never log: passwords, tokens, full credit card numbers, PII (log user ID instead)
+
+**Sampling:**
+- 100% for ERROR and FATAL
+- 10% for INFO in high-traffic paths (adjust via env var)
+- 1% for DEBUG (only in staging)
+
+**Alerting rules** (set up in {{destination}}):
+- ERROR rate > 1% of requests \u2192 page oncall
+- FATAL \u2192 immediate page
+
+Provide: logger setup code, middleware integration, and redaction utility.`,
+    contextSchema: [
+      { key: "destination", label: "Log destination", type: "select", options: ["Datadog", "CloudWatch", "Elasticsearch (ELK)", "Grafana Loki", "stdout (self-hosted)"], default: "Datadog" }
+    ],
+    tags: ["logging", "observability", "structured-logs", "general"],
+    version: "1.0.0"
+  },
+  {
+    id: "general/data-migration",
+    name: "Data Migration Plan",
+    category: "general",
+    description: "Plan and implement a safe data migration with rollback",
+    template: `Plan a data migration for {{project.name}}.
+
+Migration: {{migrationDescription}}
+Data size: {{dataSize}}
+Downtime allowed: {{downtime}}
+
+Migration strategy: {{#if (eq downtime "zero")}}online (zero-downtime){{else}}offline (maintenance window){{/if}}
+
+**Pre-migration checklist:**
+- [ ] Create a full backup and verify restore works
+- [ ] Run migration against a production-sized staging copy
+- [ ] Measure migration duration on staging to estimate production time
+- [ ] Write and test the rollback script
+- [ ] Define success criteria (row count, checksum, smoke tests)
+- [ ] Notify affected users/teams of maintenance window (if any)
+
+**Migration steps:**
+1. Deploy new code that supports BOTH old and new schema (expand phase)
+2. Run the data migration script
+3. Verify: row counts match, checksums pass, smoke tests green
+4. Deploy code that uses ONLY the new schema (contract phase)
+5. Drop old columns/tables (after 1 week of clean operation)
+
+**Rollback plan:**
+- Trigger: any verification step fails
+- Action: restore from backup OR apply reverse migration script
+- RTO target: < {{rollbackRTO}}
+
+**Large dataset strategy ({{dataSize}}):**
+- Batch processing: migrate in chunks of 1000 rows with a brief sleep between batches
+- Track progress: store last-processed ID; resume on failure without re-processing
+- Monitor: DB replication lag, table lock waits, query performance during migration`,
+    contextSchema: [
+      { key: "migrationDescription", label: "What is being migrated", type: "text", placeholder: "Normalize user addresses from a single text field to a structured address table" },
+      { key: "dataSize", label: "Approximate data size", type: "text", placeholder: "10M rows, ~50GB" },
+      { key: "downtime", label: "Downtime tolerance", type: "select", options: ["zero", "30 minutes", "2 hours", "weekend window"], default: "zero" },
+      { key: "rollbackRTO", label: "Rollback time target", type: "text", default: "15 minutes" }
+    ],
+    tags: ["migration", "database", "data", "general"],
+    version: "1.0.0"
+  },
+  {
+    id: "general/sla-definition",
+    name: "SLA / SLO / SLI Definition",
+    category: "general",
+    description: "Define service level indicators, objectives, and agreements for a service",
+    template: `Define SLIs, SLOs, and SLAs for {{project.name}}.
+
+Service type: {{serviceType}}
+User expectations: {{userExpectations}}
+
+**SLI \u2192 SLO \u2192 SLA hierarchy:**
+- **SLI** (what you measure): the metric
+- **SLO** (your internal target): the threshold you aim to meet
+- **SLA** (the promise to customers): the threshold with consequences if missed
+
+**Recommended SLIs for {{serviceType}}:**
+
+| SLI | Measurement | Good event definition |
+|-----|-------------|----------------------|
+| Availability | % of successful requests | HTTP status < 500 |
+| Latency | p95 response time | p95 < 500ms |
+| Error rate | % of requests with errors | Error rate < 0.1% |
+| Throughput | Requests per second | \u2265 {{minThroughput}} RPS |
+
+**SLO targets:**
+| SLI | SLO | Error budget (30-day window) |
+|-----|-----|------------------------------|
+| Availability | 99.9% | 43.2 minutes downtime/month |
+| Latency (p95) | 99% of requests < 500ms | 1% slow requests allowed |
+| Error rate | < 0.1% | 1 in 1000 requests may fail |
+
+**Error budget policy:**
+- > 50% budget remaining: deploy freely, invest in features
+- 25-50% remaining: reduce deploy frequency, increase testing
+- < 25% remaining: freeze non-essential deploys, focus on reliability
+
+**SLA consequences** (if SLO is breached for customers):
+- 99.9% \u2192 99.5%: 10% service credit
+- < 99.5%: 25% service credit
+
+Provide: monitoring queries (PromQL/DataDog) for each SLI, and an error budget burn rate alert.`,
+    contextSchema: [
+      { key: "serviceType", label: "Service type", type: "select", options: ["HTTP API", "background job processor", "data pipeline", "real-time service"], default: "HTTP API" },
+      { key: "userExpectations", label: "User expectations", type: "text", placeholder: "Users expect < 1 second response times and 24/7 availability" },
+      { key: "minThroughput", label: "Minimum throughput (RPS)", type: "text", default: "100" }
+    ],
+    tags: ["sla", "slo", "sli", "reliability", "sre", "general"],
+    version: "1.0.0"
+  },
+  {
+    id: "general/technical-spec",
+    name: "Technical Specification",
+    category: "general",
+    description: "Write a technical specification document for a new feature or system",
+    template: `Write a technical specification for {{feature}} in {{project.name}}.
+
+Author: {{author}}
+Status: Draft
+
+---
+
+# Technical Spec: {{feature}}
+
+## Problem Statement
+{{problem}}
+
+## Goals
+- [Primary goal: what this feature achieves]
+- [Secondary goal]
+
+## Non-Goals
+- [Explicitly what this spec does NOT cover]
+- [Related ideas intentionally deferred]
+
+## Background & Context
+[Why now? What changed to make this necessary? Link to PRD/product brief]
+
+## Proposed Solution
+
+### High-Level Design
+[System diagram or description of the approach]
+
+### Data Model Changes
+[New tables, columns, or schema changes with migration plan]
+
+### API Changes
+[New or modified endpoints with request/response shapes]
+
+### Key Algorithms / Logic
+[Pseudocode or description of non-obvious logic]
+
+### Error Handling
+[How errors are surfaced to users and logged internally]
+
+## Alternative Approaches Considered
+| Approach | Pros | Cons | Reason rejected |
+|----------|------|------|-----------------|
+
+## Dependencies
+- [Other teams, services, or external systems required]
+
+## Risks & Mitigations
+| Risk | Likelihood | Impact | Mitigation |
+|------|-----------|--------|------------|
+
+## Implementation Plan
+| Phase | What | Estimated effort |
+|-------|------|-----------------|
+| 1 | Schema migration | 1 day |
+
+## Open Questions
+- [ ] [Question that needs answering before implementation]
+
+## Sign-off
+| Role | Name | Status |
+|------|------|--------|
+| Engineering | | Pending |
+| Product | | Pending |`,
+    contextSchema: [
+      { key: "feature", label: "Feature or system name", type: "text", placeholder: "Real-time Collaboration Engine" },
+      { key: "problem", label: "Problem being solved", type: "text", placeholder: "Users cannot collaborate on documents simultaneously without conflicts" },
+      { key: "author", label: "Author name", type: "text", placeholder: "Your name" }
+    ],
+    tags: ["spec", "technical-design", "documentation", "general"],
+    version: "1.0.0"
+  },
+  {
+    id: "general/capacity-planning",
+    name: "Capacity Planning",
+    category: "general",
+    description: "Plan infrastructure capacity for projected growth",
+    template: `Perform capacity planning for {{project.name}}.
+
+Current load: {{currentLoad}}
+Growth projection: {{growthProjection}}
+Time horizon: {{horizon}}
+
+**Step 1: Baseline measurements**
+Measure current resource utilization at peak:
+- CPU usage: ___% average, ___% peak
+- Memory usage: ___MB average, ___MB peak
+- Database connections: ___/{{maxConnections}} pool used
+- Storage growth: ___GB/month
+- Network: ___Mbps in/out
+
+**Step 2: Project future load**
+If current load is {{currentLoad}} and growth is {{growthProjection}}:
+- Load at 3 months: [calculate]
+- Load at 6 months: [calculate]
+- Load at {{horizon}}: [calculate]
+
+**Step 3: Identify bottlenecks (which resource hits limit first?)**
+For each resource, estimate when it saturates at projected growth:
+| Resource | Current | Limit | Time to saturation |
+|----------|---------|-------|-------------------|
+
+**Step 4: Mitigation options**
+For each bottleneck, provide 3 options ranked by effort:
+1. Quick fix (< 1 week): scale vertically, tune config
+2. Medium term (1-3 months): architectural change (add cache, read replica, CDN)
+3. Long term (3-6 months): re-architect (sharding, microservices, rewrite hot path)
+
+**Step 5: Cost projection**
+| Scenario | Current cost | Projected cost at {{horizon}} |
+|----------|-------------|-------------------------------|
+
+Recommendation: the option with the best cost/effort/risk trade-off for the next {{horizon}}.`,
+    contextSchema: [
+      { key: "currentLoad", label: "Current peak load", type: "text", placeholder: "500 req/s, 10k daily active users" },
+      { key: "growthProjection", label: "Growth rate", type: "text", placeholder: "20% month-over-month" },
+      { key: "horizon", label: "Planning horizon", type: "select", options: ["3 months", "6 months", "1 year", "2 years"], default: "6 months" },
+      { key: "maxConnections", label: "Current DB connection pool limit", type: "text", default: "100" }
+    ],
+    tags: ["capacity", "scaling", "infrastructure", "planning", "general"],
+    version: "1.0.0"
+  },
+  {
+    id: "general/team-workflow",
+    name: "Team Workflow & Git Strategy",
+    category: "general",
+    description: "Define a team git branching strategy and development workflow",
+    template: `Define a team workflow and git branching strategy for {{project.name}}.
+
+Team size: {{teamSize}}
+Release cadence: {{releaseCadence}}
+Workflow: {{workflow}}
+
+## Branching Strategy: {{workflow}}
+
+{{#if (eq workflow "GitHub Flow")}}
+**GitHub Flow** (simple, continuous deployment):
+- \`main\` is always deployable
+- Feature branches: \`feature/short-description\` \u2014 branch from main, merge back to main
+- No long-lived branches; PRs merged within 1-2 days
+- Deploy on every merge to main
+- Best for: teams shipping continuously, SaaS products
+{{/if}}
+{{#if (eq workflow "Git Flow")}}
+**Git Flow** (structured, release-based):
+- \`main\`: production code only, tagged at each release
+- \`develop\`: integration branch, always ahead of main
+- \`feature/*\`: branch from develop, merge to develop
+- \`release/*\`: branch from develop when ready, merge to main AND develop
+- \`hotfix/*\`: branch from main, merge to main AND develop
+- Best for: versioned products, multiple supported releases
+{{/if}}
+
+## Conventions
+
+**Branch names**: \`type/ticket-short-description\`
+Types: feat, fix, chore, refactor, docs, test
+
+**Commit messages** (Conventional Commits):
+\`\`\`
+feat(auth): add OAuth2 login with Google
+fix(checkout): prevent double-charge on network retry
+docs(api): update authentication endpoint examples
+\`\`\`
+
+**PR rules:**
+- Max 400 lines changed (larger = split the PR)
+- At least {{requiredReviewers}} approving review(s) before merge
+- CI must be green (lint, tests, security scan)
+- Squash merge to keep main history clean
+
+**Code review SLA:** respond within {{reviewSLA}}; merge within 48 hours of approval.
+
+Provide: a .github/PULL_REQUEST_TEMPLATE.md and branch protection rules configuration.`,
+    contextSchema: [
+      { key: "teamSize", label: "Team size", type: "select", options: ["1-3 (solo/duo)", "4-8 (small team)", "9-20 (medium team)", "20+ (large team)"], default: "4-8 (small team)" },
+      { key: "releaseCadence", label: "Release cadence", type: "select", options: ["continuous (multiple per day)", "weekly", "bi-weekly sprint", "monthly", "quarterly"], default: "weekly" },
+      { key: "workflow", label: "Branching workflow", type: "select", options: ["GitHub Flow", "Git Flow"], default: "GitHub Flow" },
+      { key: "requiredReviewers", label: "Required reviewers", type: "text", default: "1" },
+      { key: "reviewSLA", label: "Review response SLA", type: "text", default: "4 hours" }
+    ],
+    tags: ["workflow", "git", "team", "process", "general"],
+    version: "1.0.0"
   }
 ];