aigent-team 0.1.0

package/templates/teams/be/references/caching.md

@@ -0,0 +1,79 @@
+# Caching
+
+## Strategy Selection
+
+| Pattern | When to use | How it works |
+|---------|------------|--------------|
+| **Cache-aside** | Read-heavy, stale data OK | Check cache → miss → query DB → write cache |
+| **Write-through** | Data changes often, consistency critical | Write DB + cache simultaneously |
+| **Write-behind** | High write volume, eventual consistency OK | Write cache → async flush to DB |
+| **Memoization** | Expensive computation, immutable inputs | Compute once → cache result with TTL |
+
+## Cache Key Design
+
+Format: `{service}:{entity}:{id}:{version}`
+```
+user-service:profile:123:v2
+order-service:list:user_456:page_1:sort_date
+search:results:hash_of_query_params
+```
+
+- Keys must be deterministic (same input → same key)
+- Include version to handle schema changes
+- Hash complex parameters instead of using them directly
+
+## TTL Guidelines
+
+| Data type | TTL | Reason |
+|-----------|-----|--------|
+| App config | 1 hour | Changes rarely, OK to be slightly stale |
+| User profile | 15 min | Changes occasionally |
+| Search results | 5 min | Changes frequently |
+| Auth session | Match token expiry | Security-sensitive |
+| Never: infinite TTL | - | Memory leak, stale data |
+
+## Cache Stampede Prevention
+
+When a popular cache key expires, thousands of requests simultaneously hit the DB:
+
+**Solution 1: Probabilistic early expiration**
+```
+actual_ttl = ttl - random(0, ttl * 0.1)
+// Some requests refresh before expiry, preventing simultaneous miss
+```
+
+**Solution 2: Lock-based recomputation**
+```
+if cache miss:
+  if acquire_lock(key):
+    result = query_db()
+    cache.set(key, result, ttl)
+    release_lock(key)
+  else:
+    wait_and_retry()  // or return stale data
+```
+
+## Invalidation Strategy
+
+- **Event-driven** (preferred): On write, publish cache-invalidation event
+  ```
+  orderService.create(order) → publish('order:created', { id: order.id })
+  cacheSubscriber.on('order:created') → cache.del(`order:${id}`)
+  ```
+- **TTL-only** (safety net): Cache expires naturally. Simpler but allows stale reads.
+- **Write-through**: Update cache on every write. Consistent but slower writes.
+
+Rules:
+- Always set TTL even with event-driven invalidation (safety net)
+- Cache invalidation is one of the two hard problems — err on the side of shorter TTL
+- Monitor cache hit rate — target > 90%. Below 80% = likely misconfigured TTL or key design
+
+## Multi-layer Caching
+
+```
+Request → Local memory cache (1 min) → Redis (15 min) → Database
+```
+
+- L1 (in-process): Fastest, but per-instance (not shared). For truly hot data.
+- L2 (Redis/Memcached): Shared across instances. Primary cache layer.
+- Invalidate both layers on write.

package/templates/teams/be/references/database.md

@@ -0,0 +1,65 @@
+# Database
+
+## Schema Standards
+
+- Every table has: `id` (UUID v7 or ULID — sortable, no sequential guessing), `created_at`, `updated_at` timestamps
+- Soft deletes: `deleted_at` column. All queries filter `WHERE deleted_at IS NULL`. Never hard-delete unless legally required (GDPR).
+- Use `NOT NULL` with defaults wherever possible. Nullable columns require explicit justification.
+
+## Indexes
+
+- Create indexes for every column used in `WHERE`, `JOIN`, or `ORDER BY`
+- Composite indexes: left-prefix rule — put the most selective (high-cardinality) column first
+- Cover frequently used queries with covering indexes (include all SELECT columns)
+- Run `EXPLAIN ANALYZE` on every new/modified query to verify index usage
+- Create indexes concurrently in production: `CREATE INDEX CONCURRENTLY` (Postgres) to avoid table locks
+
+## Query Performance
+
+- A single API request should execute ≤ 5 queries. More = missing JOIN or need to denormalize.
+- N+1 detection: enable ORM query logging in tests, count queries per endpoint.
+- Use `EXPLAIN ANALYZE` to check:
+  - Seq Scan on large tables (missing index)
+  - Hash Join on large datasets (consider optimization)
+  - Sort operations (add index for ORDER BY)
+  - High row estimates vs actuals (stale statistics → `ANALYZE`)
+
+## Transactions
+
+- Use for any operation modifying multiple tables
+- Scope as narrowly as possible — don't hold locks during HTTP calls
+- Read-only queries outside transactions (no unnecessary locking)
+- Use optimistic locking (`version` column) for concurrent update scenarios:
+  ```sql
+  UPDATE orders SET status = 'confirmed', version = version + 1
+  WHERE id = :id AND version = :expected_version
+  ```
+
+## Connection Pooling
+
+- Pool size: `(number_of_cores * 2) + effective_spindle_count` — typically 10-20 per service instance
+- Never unlimited connections
+- Monitor pool usage — exhaustion causes cascading failures
+- Use PgBouncer or application-level pooling for serverless environments
+
+## Migration Safety
+
+**Zero-downtime migration sequence (for breaking changes):**
+1. Add new column with default value (backward compatible)
+2. Deploy code that writes to BOTH old and new columns
+3. Backfill existing data in batches (not in the migration)
+4. Deploy code that reads from new column
+5. Drop old column (separate migration, after verification)
+
+**Rules:**
+- Schema migrations must complete in < 30 seconds
+- Data backfills in separate scripts, run in batches of 1000
+- Always test `down` migration — verify rollback works
+- Large table migrations: `ALTER TABLE ... ADD COLUMN ... DEFAULT` is fast in Postgres 11+ (metadata-only)
+- Test with production-scale data volume
+
+## Read Replicas
+
+- Use for reporting, analytics, search queries
+- Write to primary only
+- Account for replication lag in application code — after write, read from primary for consistency

package/templates/teams/be/references/error-handling.md

@@ -0,0 +1,106 @@
+# Error Handling & Resilience
+
+## Domain Error Hierarchy
+
+Create typed errors that map to HTTP status codes in one place:
+```typescript
+abstract class DomainError extends Error {
+  abstract statusCode: number;
+  abstract code: string;
+}
+
+class NotFoundError extends DomainError {
+  statusCode = 404;
+  code = 'NOT_FOUND';
+}
+
+class ConflictError extends DomainError {
+  statusCode = 409;
+  code = 'CONFLICT';
+}
+
+class ValidationError extends DomainError {
+  statusCode = 400;
+  code = 'VALIDATION_ERROR';
+  constructor(public details: Array<{ field: string; message: string }>) {
+    super('Validation failed');
+  }
+}
+```
+
+Map in error handler middleware, not in every controller:
+```typescript
+app.use((err, req, res, next) => {
+  if (err instanceof DomainError) {
+    return res.status(err.statusCode).json({
+      error: { code: err.code, message: err.message }
+    });
+  }
+  // Unknown error = 500, log full stack
+  logger.error({ err, requestId: req.id }, 'Unhandled error');
+  res.status(500).json({ error: { code: 'INTERNAL_ERROR', message: 'Something went wrong' } });
+});
+```
+
+## External Service Resilience
+
+**Timeouts:**
+- Connect timeout: 3 seconds (can't establish connection = service is down)
+- Read timeout: 10 seconds (waiting for response)
+- Total timeout: 15 seconds max
+
+**Retries with exponential backoff + jitter:**
+```
+Attempt 1: immediate
+Attempt 2: 1s + random(0-500ms)
+Attempt 3: 2s + random(0-500ms)
+Attempt 4: 4s + random(0-500ms)
+Max: 3 retries
+```
+Only retry on 5xx and network errors. Never retry 4xx (client error).
+
+**Circuit breaker:**
+- **Closed** (normal): requests pass through. Track failure rate.
+- **Open** (failing): requests fail immediately without calling the service. Timer starts.
+- **Half-open** (testing): allow one request through. If it succeeds → close. If it fails → open again.
+- Trigger: 5 consecutive failures or >50% failure rate in 10-second window.
+
+**Graceful degradation:**
+- Non-critical service down (recommendations, analytics) → main flow continues, skip the feature
+- Critical service down (auth, payment) → fail with clear error, retry mechanism
+- Return cached data when possible for degraded responses
+
+## Health Checks
+
+```
+GET /health/live   → { status: "ok" }     // Process alive (K8s liveness probe)
+GET /health/ready  → { status: "ok",      // Can serve traffic (K8s readiness)
+                       checks: {
+                         database: "ok",
+                         cache: "ok",
+                         queue: "ok"
+                       }}
+```
+- Liveness: never check dependencies (prevents cascade restarts)
+- Readiness: check all critical dependencies
+
+## Graceful Shutdown
+
+On SIGTERM:
+1. Stop accepting new requests (remove from load balancer)
+2. Finish in-flight requests (30 second timeout)
+3. Close database connections
+4. Close queue connections
+5. Exit process
+
+```typescript
+process.on('SIGTERM', async () => {
+  server.close(); // Stop accepting
+  await Promise.race([
+    finishInFlightRequests(),
+    new Promise(resolve => setTimeout(resolve, 30000)), // 30s max
+  ]);
+  await db.disconnect();
+  process.exit(0);
+});
+```

package/templates/teams/be/references/observability.md

@@ -0,0 +1,83 @@
+# Observability
+
+## Three Pillars
+
+### 1. Structured Logging
+
+Every log entry must include:
+```json
+{
+  "timestamp": "2024-01-15T10:30:00.000Z",
+  "level": "info",
+  "message": "Order created",
+  "service": "order-service",
+  "environment": "production",
+  "request_id": "req_abc123",
+  "user_id": "usr_456",
+  "duration_ms": 45,
+  "order_id": "ord_789"
+}
+```
+
+**Log levels:**
+- `ERROR`: Something broke, requires investigation. Pages on-call in production.
+- `WARN`: Unexpected but handled. Rate limit hit, cache miss on hot key, slow query.
+- `INFO`: Significant business events: user registered, order placed, payment processed.
+- `DEBUG`: Development only. Never enable in production (performance + noise).
+
+**Never log:** passwords, tokens, credit card numbers, full email addresses, session IDs.
+
+### 2. Distributed Tracing
+
+- Propagate trace context (`traceparent` header) across all service calls
+- Every outgoing HTTP, gRPC, queue message carries the trace ID
+- Instrument: incoming requests, outgoing HTTP calls, database queries, cache operations, queue publish/consume
+- Sample rate: 100% for errors, 10% for success in production
+
+### 3. Metrics (Prometheus format)
+
+Essential metrics to expose:
+- `http_requests_total{method, path, status}` — request rate
+- `http_request_duration_seconds{method, path}` — latency histogram (p50, p95, p99)
+- `http_requests_in_flight` — active connections
+- `db_query_duration_seconds{query}` — database latency
+- `cache_hits_total` / `cache_misses_total` — cache effectiveness
+- `queue_depth{queue}` — backlog size
+- `circuit_breaker_state{service}` — open/closed/half-open
+
+## Alerting
+
+**Alert on symptoms (user impact), not causes:**
+- GOOD: "Error rate > 1% for 5 minutes"
+- BAD: "CPU > 80%" (might be normal)
+- GOOD: "p99 latency > 2s for 10 minutes"
+- BAD: "Memory > 70%" (might be normal for JVM)
+
+**Severity levels:**
+| Level | Action | Example |
+|-------|--------|---------|
+| P1 Critical | Page on-call NOW | Error rate > 5%, service down |
+| P2 High | Slack team channel | Error rate > 1%, p99 > 2x baseline |
+| P3 Medium | Create ticket | Disk > 80%, cert expires in 14d |
+| P4 Low | Dashboard only | Cost anomaly, deprecation warning |
+
+Every P1/P2 alert must have a runbook.
+
+## Request Tracing Pattern
+
+```typescript
+// Middleware: create request context
+app.use((req, res, next) => {
+  req.id = req.headers['x-request-id'] || crypto.randomUUID();
+  res.setHeader('x-request-id', req.id);
+  next();
+});
+
+// Logger: auto-include request context
+const logger = createLogger({
+  defaultMeta: { service: 'api', env: process.env.NODE_ENV },
+});
+
+// Usage: always include request_id
+logger.info({ request_id: req.id, user_id: user.id }, 'Order created');
+```

package/templates/teams/be/references/review-checklist.md

@@ -0,0 +1,50 @@
+# Backend Review Checklist
+
+### API Contract
+- [ ] URL is RESTful and consistent with existing endpoints
+- [ ] HTTP status codes semantically correct (not just 200 and 500)
+- [ ] Request/response schemas documented (OpenAPI/Swagger updated)
+- [ ] Error responses include machine-readable `code` + human-readable `message`
+- [ ] Pagination for list endpoints (cursor-based for large datasets)
+- [ ] No breaking changes to existing API contracts
+
+### Data Layer
+- [ ] No N+1 queries — verified with query logging
+- [ ] Queries use indexes — ran `EXPLAIN ANALYZE` on new queries
+- [ ] Transactions scoped correctly (cover related mutations, not too broad)
+- [ ] Migrations backward compatible (old code works with new schema during deploy)
+- [ ] Large table migrations done in phases (no locks on tables > 100K rows)
+- [ ] Soft deletes used (unless GDPR erasure required)
+
+### Security
+- [ ] All input validated at API boundary (schema validation, string length limits)
+- [ ] No SQL injection vectors — parameterized queries only
+- [ ] IDOR check — resource queries scoped by authenticated user
+- [ ] Auth/authz middleware applied with correct role/permission
+- [ ] Rate limiting configured
+- [ ] No PII in logs
+- [ ] Secrets from secret manager, not hardcoded
+
+### Error Handling & Resilience
+- [ ] All error paths return appropriate HTTP status codes
+- [ ] External service calls have timeouts (connect + read)
+- [ ] Retries use exponential backoff with jitter
+- [ ] Circuit breaker for non-critical dependencies
+- [ ] Race conditions considered (optimistic locking, idempotency keys)
+
+### Observability
+- [ ] Structured JSON logs with `request_id`, `user_id`, `duration_ms`
+- [ ] Error logs include stack trace and context
+- [ ] New metrics exposed if applicable
+- [ ] Distributed trace context propagated
+
+### Async Processing
+- [ ] Queue jobs are idempotent
+- [ ] Dead letter queue configured
+- [ ] Job payloads minimal (IDs, not full objects)
+
+### Testing
+- [ ] Integration tests: happy path, validation, auth, not-found, concurrent
+- [ ] Edge cases: empty body, max-length, unicode, null vs missing
+- [ ] Database state isolated per test
+- [ ] Mocks at correct boundary (external services, not internal modules)

package/templates/teams/be/references/testing.md

@@ -0,0 +1,100 @@
+# Backend Testing
+
+## Test Levels
+
+**Unit tests** (service layer business logic):
+- Test in isolation. Mock repositories and external services.
+- Focus on business rules, edge cases, error paths.
+- Fast: < 5ms per test.
+
+**Integration tests** (API endpoints — most valuable):
+- Test real HTTP request → response with a real database.
+- Use testcontainers or Docker Compose for database.
+- Each test creates its own data, cleans up after.
+- Cover: happy path, validation errors, auth failures, not-found, concurrent access.
+
+**Contract tests** (service boundaries):
+- Use Pact for consumer-driven contracts between services.
+- Each service tests its own contracts independently.
+- Runs in CI — breaks the build if contract violated.
+
+**Load tests** (performance):
+- Run before every release touching data path.
+- Baseline: system must handle 2x current peak traffic.
+- Use k6 or Artillery with realistic data patterns.
+
+## Database Test Isolation
+
+**Option 1: Transaction rollback** (fastest)
+```typescript
+beforeEach(async () => {
+  await db.beginTransaction();
+});
+afterEach(async () => {
+  await db.rollback();
+});
+```
+
+**Option 2: Truncate tables** (simpler)
+```typescript
+afterEach(async () => {
+  await db.query('TRUNCATE users, orders, payments CASCADE');
+});
+```
+
+**Option 3: Unique identifiers** (for parallel tests)
+```typescript
+const testId = crypto.randomUUID();
+const user = await createUser({ email: `${testId}@test.com` });
+```
+
+Rules:
+- Same database engine as production (not SQLite when prod is Postgres)
+- Each test creates what it needs — no shared seed data
+- Tests must pass in any order, in parallel
+
+## Test Structure
+
+```typescript
+describe('POST /api/orders', () => {
+  it('should create order and return 201', async () => {
+    const user = await createTestUser();
+    const product = await createTestProduct({ price: 2999 });
+
+    const response = await request(app)
+      .post('/api/orders')
+      .set('Authorization', `Bearer ${user.token}`)
+      .send({ productId: product.id, quantity: 2 });
+
+    expect(response.status).toBe(201);
+    expect(response.body.data.total).toBe(5998);
+    expect(response.body.data.status).toBe('pending');
+  });
+
+  it('should return 400 when quantity is zero', async () => {
+    const user = await createTestUser();
+    const response = await request(app)
+      .post('/api/orders')
+      .set('Authorization', `Bearer ${user.token}`)
+      .send({ productId: 'prod_1', quantity: 0 });
+
+    expect(response.status).toBe(400);
+    expect(response.body.error.code).toBe('VALIDATION_ERROR');
+  });
+
+  it('should return 401 without auth token', async () => {
+    const response = await request(app)
+      .post('/api/orders')
+      .send({ productId: 'prod_1', quantity: 1 });
+
+    expect(response.status).toBe(401);
+  });
+});
+```
+
+## What to Test
+
+- **Always**: Happy path, validation errors, auth/authz, not-found, edge cases (empty, max, unicode)
+- **Important**: Concurrent access (two users modify same resource), race conditions
+- **For data mutations**: Verify database state changed correctly (not just API response)
+- **For async operations**: Verify job was enqueued with correct payload

package/templates/teams/be/review-checklist.md

@@ -0,0 +1,54 @@
+### API Contract
+- [ ] URL is RESTful and consistent with existing endpoints
+- [ ] HTTP status codes are semantically correct (not just 200 and 500)
+- [ ] Request/response schemas are documented (OpenAPI/Swagger updated)
+- [ ] Error responses include machine-readable `code` + human-readable `message`
+- [ ] Pagination implemented for list endpoints (cursor-based for large datasets)
+- [ ] No breaking changes to existing API contracts (or version bumped)
+
+### Data Layer
+- [ ] No N+1 queries — checked by enabling query logging during tests
+- [ ] Queries use indexes — ran `EXPLAIN ANALYZE` on new/modified queries
+- [ ] Transactions scope is correct — covers all related mutations, not too broad
+- [ ] Migrations are backward compatible (old code works with new schema during deploy)
+- [ ] Large table migrations done in phases (no table locks on tables >100K rows)
+- [ ] Soft deletes used instead of hard deletes (unless GDPR erasure required)
+- [ ] All new columns have appropriate defaults and constraints (NOT NULL where applicable)
+
+### Security
+- [ ] All input validated at API boundary (Zod/Pydantic schema, string length limits, enum checks)
+- [ ] No SQL injection vectors — all queries use parameterized statements
+- [ ] IDOR check — resource queries scoped by authenticated user's ID/org
+- [ ] Auth/authz middleware applied — endpoint requires correct role/permission
+- [ ] Rate limiting configured — per-user for authenticated, per-IP for public
+- [ ] No PII in logs (emails, tokens, passwords, credit card numbers scrubbed)
+- [ ] Secrets from secret manager — not hardcoded or in env files committed to git
+- [ ] Mass assignment protection — only whitelisted fields accepted from request body
+
+### Error Handling & Resilience
+- [ ] All error paths return appropriate HTTP status codes (no `catch → res.json({ error })`)
+- [ ] External service calls have timeouts configured (connect + read)
+- [ ] Retries use exponential backoff with jitter — no fixed-interval retries
+- [ ] Circuit breaker for non-critical dependencies — failure doesn't cascade
+- [ ] Graceful degradation — if recommendation service is down, main flow still works
+- [ ] Race conditions considered — concurrent requests to same resource handled (optimistic locking, idempotency keys)
+
+### Observability
+- [ ] Structured JSON logs with `request_id`, `user_id`, `duration_ms`
+- [ ] Error logs include stack trace and context (not just error message)
+- [ ] New metrics exposed for monitoring (request rate, error rate, latency)
+- [ ] Distributed trace context propagated in outgoing requests
+- [ ] Health check endpoints updated if new dependencies added
+
+### Async Processing
+- [ ] Queue jobs are idempotent — safe to retry on failure
+- [ ] Dead letter queue configured for failed messages
+- [ ] Long-running jobs expose progress/status endpoint
+- [ ] Job payloads are minimal (IDs, not full objects) — fetch fresh data in the worker
+
+### Testing
+- [ ] Integration tests cover: happy path, validation errors, auth failures, not-found, concurrent access
+- [ ] Edge cases tested: empty body, max-length fields, unicode, null vs missing fields
+- [ ] Database state isolated per test — no shared data, no ordering dependency
+- [ ] Mocks at correct boundary — mock external services, not internal modules
+- [ ] Load test results reviewed if endpoint is on the hot path

package/templates/teams/be/skill.md

@@ -0,0 +1,71 @@
+# Backend Agent
+
+You are a senior backend engineer with 8+ years of experience building production systems handling millions of requests.
+
+## Core Principles
+
+1. **Design for failure**: Every external call (DB, cache, API) will fail. Handle timeouts, retries with exponential backoff + jitter, circuit breakers, graceful degradation.
+2. **Data integrity over speed**: Never sacrifice correctness for performance. Use transactions for multi-step mutations. Idempotency keys for retryable operations.
+3. **Observability is not logging**: Structured logs, distributed traces, and metrics are three separate pillars. A request must be traceable from gateway through every service to DB and back.
+4. **Security is a constraint, not a feature**: Auth, input validation, rate limiting, encryption are non-negotiable baselines.
+5. **Separation of concerns**: Controllers handle HTTP (thin). Services handle business logic. Repositories abstract data access. Never mix layers.
+
+## Key Anti-patterns — Catch Immediately
+
+- **N+1 queries**: Loading a list then querying each item. Always eager-load or batch.
+- **Transactions spanning HTTP calls**: If step 3 of 5 fails, can you roll back 1-2? Use Sagas or Outbox pattern.
+- **Catching exceptions → returning 200**: Use proper HTTP status codes.
+- **String concatenation for SQL**: Always parameterized queries, even "internal" ones.
+- **Logging PII**: Emails, tokens, passwords — scrub before logging, even in debug.
+- **Unbounded queries**: `SELECT *` without LIMIT, endpoints returning all records without pagination.
+- **Single point of failure**: One DB instance, one cache node. Plan redundancy.
+
+## Decision Frameworks
+
+**API design:**
+- CRUD on resources → REST (`GET /users/:id`, `POST /users`)
+- Complex queries / aggregation → GraphQL or dedicated search endpoint
+- Real-time → WebSocket or SSE
+- Service-to-service, high throughput → gRPC
+
+**Caching strategy:**
+- Data changes rarely + stale OK → Cache-aside with TTL
+- Data changes often + stale NOT OK → Write-through
+- Expensive computation + immutable input → Memoization with TTL
+
+**Async processing:**
+- Takes > 500ms or can fail independently → Message queue (email, PDF, webhooks)
+- Jobs must be idempotent (safe to retry)
+- Dead letter queue for failures, monitor DLQ size
+
+## Reference Files
+
+Read the relevant reference when working on specific tasks:
+
+| Reference | When to read |
+|-----------|-------------|
+| `api-design.md` | Creating endpoints, designing request/response schemas |
+| `database.md` | Schema design, migrations, query optimization, indexes |
+| `auth-security.md` | Authentication, authorization, IDOR prevention, rate limiting |
+| `error-handling.md` | Error hierarchy, circuit breakers, graceful degradation, retries |
+| `observability.md` | Logging, tracing, metrics, alerting |
+| `caching.md` | Cache strategy, invalidation, stampede prevention |
+| `async-processing.md` | Queues, jobs, idempotency, dead letter queues |
+| `testing.md` | Unit/integration/contract/load testing strategies |
+| `review-checklist.md` | Reviewing any backend PR |
+
+## Workflows
+
+### Create API Endpoint
+1. Define contract first: method, URL, request/response schema (Zod/Pydantic), error responses
+2. Input validation at controller layer → Service layer logic → Repository for data
+3. Auth middleware + rate limiting
+4. Proper error handling (domain errors → HTTP status codes)
+5. Structured logging, tests, OpenAPI docs update
+→ Read `references/api-design.md` for full procedure
+
+### Database Migration
+→ Read `references/database.md` for backward-compatible migration procedure
+
+### Code Review
+→ Read `references/review-checklist.md` for full checklist

package/templates/teams/devops/agent.yaml

@@ -0,0 +1,35 @@
+id: devops
+name: DevOps Agent
+description: >
+  Senior DevOps/SRE agent. Expert in CI/CD pipeline architecture,
+  container orchestration, infrastructure as code, GitOps, observability,
+  cost optimization, and disaster recovery.
+role: devops
+techStack:
+  languages: [YAML, HCL, Bash, Python, Go]
+  frameworks: [Terraform, Pulumi, CDK, Crossplane]
+  libraries: [Helm, Kustomize, ArgoCD, Flux, GitHub Actions, GitLab CI]
+  buildTools: [Docker, Kubernetes, Nginx, Prometheus, Grafana, Loki, Jaeger, Vault, Trivy, Falco]
+tools:
+  allowed: [Read, Write, Edit, Bash, Grep, Glob]
+globs:
+  - "Dockerfile*"
+  - "docker-compose*.yml"
+  - "docker-compose*.yaml"
+  - ".github/workflows/**/*"
+  - ".gitlab-ci.yml"
+  - "Jenkinsfile"
+  - "terraform/**/*"
+  - "**/*.tf"
+  - "**/*.tfvars"
+  - "k8s/**/*"
+  - "helm/**/*"
+  - "charts/**/*"
+  - "infra/**/*"
+  - "deploy/**/*"
+  - "scripts/**/*"
+  - "Makefile"
+  - "monitoring/**/*"
+sharedKnowledge:
+  - project-conventions
+  - git-workflow