AI Prompts Library

You are a DevOps engineer specializing in containerization and orchestration. Generate production-ready Docker and Kubernetes configurations for the described application.

**Application Details:**
- Application name: [APP_NAME]
- Language/Runtime: [e.g., Node.js 20, Python 3.12, Go 1.22, Java 21]
- Framework: [e.g., Next.js, FastAPI, Gin, Spring Boot]
- Dependencies: [e.g., PostgreSQL, Redis, RabbitMQ, Elasticsearch]
- Environment: [Development / Staging / Production]

**Generate the following:**

1. **Dockerfile** (multi-stage build):
   - Stage 1: Dependencies installation with layer caching
   - Stage 2: Build/compile step
   - Stage 3: Production image (minimal base like alpine/distroless)
   - Non-root user for security
   - .dockerignore file
   - Health check instruction
   - Proper signal handling (tini or dumb-init)
   - Labels for metadata (version, maintainer, description)

2. **docker-compose.yml** (for local development):
   - Application service with hot reload
   - Database service with persistent volume
   - Cache service (Redis) if needed
   - Network configuration
   - Environment variable files
   - Health checks for all services

3. **Kubernetes Manifests:**
   - Deployment with rolling update strategy
   - Service (ClusterIP and/or LoadBalancer)
   - ConfigMap for non-sensitive config
   - Secret for sensitive values (base64 encoded)
   - HorizontalPodAutoscaler (CPU/memory based)
   - PodDisruptionBudget
   - Ingress with TLS
   - Resource requests and limits
   - Liveness, readiness, and startup probes
   - Pod anti-affinity for high availability

4. **Helm Chart** (optional): values.yaml with environment-specific overrides

All configurations must follow security best practices: no root containers, read-only filesystems where possible, minimal capabilities, and network policies.

You are a CI/CD expert specializing in GitHub Actions. Generate a comprehensive pipeline configuration for the described project.

**Project Details:**
- Repository: [REPO_NAME]
- Language: [e.g., TypeScript, Python, Go, Rust, Java]
- Framework: [e.g., Next.js, Django, Gin]
- Deploy Target: [e.g., AWS ECS, Vercel, GCP Cloud Run, Kubernetes, Netlify]
- Package Registry: [npm, PyPI, Docker Hub, GitHub Container Registry]

**Generate these workflow files:**

1. **ci.yml** (runs on every push and PR):
   - Checkout code
   - Setup language/runtime with caching (node_modules, pip cache, go modules)
   - Install dependencies
   - Lint (ESLint, Ruff, golangci-lint)
   - Type check (tsc, mypy, go vet)
   - Unit tests with coverage report
   - Integration tests (with service containers for databases)
   - Build verification
   - Upload coverage to Codecov
   - Comment PR with test results and coverage diff

2. **cd.yml** (runs on merge to main):
   - All CI steps
   - Semantic versioning (semantic-release or similar)
   - Build Docker image with proper tagging (sha, version, latest)
   - Push to container registry
   - Deploy to staging environment
   - Run smoke tests against staging
   - Manual approval gate for production
   - Deploy to production
   - Post-deploy health check
   - Notify Slack/Discord on success or failure

3. **security.yml** (scheduled weekly + on PR):
   - Dependency vulnerability scan (Dependabot, Snyk, or Trivy)
   - SAST scan (CodeQL or Semgrep)
   - Container image scan
   - License compliance check
   - Secret scanning

4. **release.yml** (manual trigger):
   - Create GitHub release with changelog
   - Publish package to registry
   - Generate and attach build artifacts

**Requirements:** Use composite actions for reusable steps, pin action versions by SHA, use OIDC for cloud authentication where possible, and include proper concurrency controls.

You are a cloud infrastructure expert who reviews Infrastructure as Code (IaC) for security, reliability, and best practices. Review the provided IaC code.

**IaC Code to Review:**
[PASTE TERRAFORM, CLOUDFORMATION, PULUMI, OR CDK CODE HERE]

**IaC Tool:** [Terraform / CloudFormation / Pulumi / CDK / Ansible]
**Cloud Provider:** [AWS / GCP / Azure / Multi-cloud]
**Environment:** [Development / Staging / Production]
**Compliance Requirements:** [SOC 2 / HIPAA / PCI-DSS / None specific]

**Review Checklist:**

1. **Security Review:**
   - [ ] No hardcoded secrets, API keys, or passwords
   - [ ] S3 buckets/storage not publicly accessible
   - [ ] Security groups/firewall rules follow least privilege
   - [ ] Encryption enabled for all data stores
   - [ ] IAM roles have minimal required permissions
   - [ ] VPC/network configuration is secure
   - [ ] Logging and monitoring enabled on all resources
   - [ ] WAF/DDoS protection configured
   - [ ] Database instances not publicly accessible
   - [ ] KMS keys used for sensitive data encryption

2. **Reliability Review:**
   - [ ] Multi-AZ or multi-region deployment for critical services
   - [ ] Auto-scaling configured with appropriate min/max
   - [ ] Health checks defined for all services
   - [ ] Backup and disaster recovery configured
   - [ ] Connection draining and graceful shutdown
   - [ ] Circuit breakers for external dependencies

3. **Cost Optimization:**
   - [ ] Right-sized instances (not over-provisioned)
   - [ ] Reserved instances or savings plans for steady-state workloads
   - [ ] Lifecycle policies for storage (transition to cheaper tiers)
   - [ ] Unused resources identified
   - [ ] Cost allocation tags on all resources

4. **Code Quality:**
   - [ ] Modules used for reusable components
   - [ ] Variables have descriptions and validation rules
   - [ ] Outputs defined for cross-module references
   - [ ] State management properly configured (remote backend, locking)
   - [ ] Naming conventions consistent
   - [ ] Resource tagging strategy implemented

5. **Operational Readiness:**
   - [ ] CloudWatch/monitoring alarms configured
   - [ ] SNS/PagerDuty notifications for critical alerts
   - [ ] Runbook documentation for manual operations
   - [ ] Terraform plan reviewed before apply

**Output**: Findings report with severity, location, explanation, and remediation code for each issue.

Optimize Dockerfile:

**Multi-stage Build** - Builder + production stages
**Layer Caching** - Dependencies first, code last
**Security** - Non-root user, minimal base image
**Size Reduction** - Alpine Linux, .dockerignore
**Performance** - Parallel builds, BuildKit

Include: Optimized Dockerfile, .dockerignore, docker-compose.yml, build commands, size comparison.

Incident response plan for [SYSTEM/SERVICE]:

**Severity Levels**:
- **P0 (Critical)**: Total outage, data breach
- **P1 (High)**: Major feature down, perf degradation
- **P2 (Medium)**: Minor feature issue
- **P3 (Low)**: Cosmetic, no user impact

**Response Timeline**:
- P0: Immediate response, 15min updates
- P1: 30min response, hourly updates
- P2: 4hr response, daily updates
- P3: Best effort

**Incident Response Steps**:

**1. Detection & Alerting** (0-5min)
- Monitor alerts trigger
- On-call engineer paged
- Acknowledge alert

**2. Assessment** (5-15min)
- Determine severity
- Identify affected systems/users
- Assemble incident team
- Create incident channel (#incident-123)

**3. Communication** (15-30min)
- Post status page update
- Notify stakeholders
- Start incident log (timeline)

**4. Mitigation** (Ongoing)
- Implement temporary fix
- Monitor metrics
- Update stakeholders regularly

**5. Resolution**
- Deploy permanent fix
- Verify resolution
- Monitor for regression
- Close incident

**6. Post-Mortem** (Within 48hr)
- Timeline of events
- Root cause analysis
- Impact assessment
- Action items (with owners)
- Lessons learned
- Preventive measures

**Communication Templates**:
- Initial: "We're investigating [issue]."
- Update: "Still working. ETA: [time]. Impact: [scope]."
- Resolved: "Issue resolved at [time]. RCA to follow."

**Tools**:
- Monitoring: [Datadog/New Relic]
- On-call: [PagerDuty/Opsgenie]
- Status: [StatusPage]
- Comms: [Slack/Teams]