@cubis/foundry 0.3.70 → 0.3.72

package/workflows/powers/devops-engineer/SKILL.md

@@ -1,82 +1,145 @@
 ---
-name: "devops-engineer"
-description: "Use when setting up CI/CD pipelines, containerizing applications, or managing infrastructure as code. Invoke for pipelines, Docker, Kubernetes, cloud platforms, GitOps."
+name: devops-engineer
+description: Design CI/CD pipelines, infrastructure-as-code, monitoring, deployment strategies, and incident response procedures for reliable software delivery.
+license: Apache-2.0
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI
 ---
 
-
 # DevOps Engineer
 
-## Overview
+## Purpose
+
+Guide DevOps practices including CI/CD pipeline design, infrastructure-as-code, deployment strategies, monitoring, and incident response. Bridge development and operations for reliable, automated delivery.
+
+## When to Use
+
+- Setting up or improving CI/CD pipelines
+- Designing deployment strategies (blue-green, canary, rolling)
+- Writing infrastructure-as-code (Terraform, Pulumi, CloudFormation)
+- Configuring monitoring, alerting, and observability
+- Building incident response procedures
+- Containerizing applications (Docker, Kubernetes)
+
+## Instructions
+
+### Step 1 — CI/CD Pipeline Design
+
+**Pipeline stages** (in order):
+
+1. **Lint & Format** — static analysis, code formatting (fastest feedback)
+2. **Unit Tests** — isolated logic tests (< 5 min target)
+3. **Build** — compile, bundle, generate artifacts
+4. **Integration Tests** — API, database, service boundary tests
+5. **Security Scan** — dependency audit, SAST, secret scanning
+6. **Deploy to Staging** — automated deployment to pre-production
+7. **E2E / Smoke Tests** — critical path verification on staging
+8. **Deploy to Production** — automated or gated release
+
+**Principles**:
+
+- Fail fast — put the quickest checks first
+- Parallelize independent stages
+- Cache dependencies between runs (node_modules, Docker layers)
+- Every merge to main should be deployable
+- Never skip tests to "move faster"
+
+### Step 2 — Deployment Strategies
+
+| Strategy      | Risk     | Rollback Speed      | When to Use                                     |
+| ------------- | -------- | ------------------- | ----------------------------------------------- |
+| Rolling       | Low      | Medium              | Default for most services                       |
+| Blue-Green    | Low      | Instant (switch)    | Stateless services, zero-downtime required      |
+| Canary        | Very Low | Fast (route change) | High-traffic services, gradual confidence       |
+| Feature Flags | Very Low | Instant (toggle)    | Decoupling deploy from release                  |
+| Recreate      | High     | Slow (redeploy)     | Only when breaking changes require full restart |
+
+**Rollback plan**: Every deployment must have a documented rollback path that takes < 5 minutes.
+
+### Step 3 — Infrastructure as Code
+
+**Principles**:
+
+- All infrastructure defined in version-controlled code
+- Environments are reproducible from code alone
+- No manual changes to production (drift = risk)
+- Use modules/components for reusable infrastructure patterns
+- Plan before apply — review changes before executing
+
+**Structure**:
+
+```
+infrastructure/
+├── modules/          (reusable components)
+│   ├── networking/
+│   ├── compute/
+│   └── database/
+├── environments/
+│   ├── staging/
+│   └── production/
+└── shared/           (DNS, IAM, secrets)
+```
 
-Senior DevOps engineer specializing in CI/CD pipelines, infrastructure as code, and deployment automation.
+### Step 4 — Monitoring & Alerting
 
-## Role Definition
+**Four Golden Signals** (monitor these for every service):
 
-You are a senior DevOps engineer with 10+ years of experience. You operate with three perspectives:
+| Signal     | Measures               | Example Metric                 |
+| ---------- | ---------------------- | ------------------------------ |
+| Latency    | Time to serve requests | p50, p95, p99 response time    |
+| Traffic    | Demand on the system   | Requests per second            |
+| Errors     | Failed requests        | Error rate (5xx / total)       |
+| Saturation | Resource utilization   | CPU, memory, disk, connections |
 
-- **Build Hat**: Automating build, test, and packaging
-- **Deploy Hat**: Orchestrating deployments across environments
-- **Ops Hat**: Ensuring reliability, monitoring, and incident response
+**Alerting rules**:
 
-## When to Use This Skill
+- Alert on symptoms (high error rate), not causes (high CPU)
+- Every alert must be actionable — if no one needs to act, it's noise
+- Use severity levels: critical (page), warning (ticket), info (dashboard)
+- Include runbook link in every alert
 
-- Setting up CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins)
-- Containerizing applications (Docker, Docker Compose)
-- Kubernetes deployments and configurations
-- Infrastructure as code (Terraform, Pulumi)
-- Cloud platform configuration (AWS, GCP, Azure)
-- Deployment strategies (blue-green, canary, rolling)
-- Building internal developer platforms and self-service tools
-- Incident response, on-call, and production troubleshooting
-- Release automation and artifact management
+### Step 5 — Incident Response
 
-## Core Workflow
+**Incident lifecycle**:
 
-1. **Assess** - Understand application, environments, requirements
-2. **Design** - Pipeline structure, deployment strategy
-3. **Implement** - IaC, Dockerfiles, CI/CD configs
-4. **Deploy** - Roll out with verification
-5. **Monitor** - Set up observability, alerts
+1. **Detect** — monitoring alerts or user reports
+2. **Respond** — acknowledge, assess severity, assemble responders
+3. **Mitigate** — stop the bleeding (rollback, feature flag, scale up)
+4. **Resolve** — fix root cause
+5. **Review** — blameless postmortem within 48 hours
 
-## Available Steering Files
+**Postmortem template**:
 
-Load detailed guidance on-demand:
+- What happened? (timeline)
+- What was the impact? (users affected, duration)
+- What was the root cause?
+- What prevented earlier detection?
+- Action items (with owners and deadlines)
 
-| Topic          | Reference                           | Load When                                                      |
-| -------------- | ----------------------------------- | -------------------------------------------------------------- |
-| GitHub Actions | `references/github-actions.md`        | Setting up CI/CD pipelines, GitHub workflows                   |
-| Docker         | `references/docker-patterns.md`       | Containerizing applications, writing Dockerfiles               |
-| Kubernetes     | `references/kubernetes.md`            | K8s deployments, services, ingress, pods                       |
-| Terraform      | `references/terraform-iac.md`         | Infrastructure as code, AWS/GCP provisioning                   |
-| Deployment     | `references/deployment-strategies.md` | Blue-green, canary, rolling updates, rollback                  |
-| Platform       | `references/platform-engineering.md`  | Self-service infra, developer portals, golden paths, Backstage |
-| Release        | `references/release-automation.md`    | Artifact management, feature flags, multi-platform CI/CD       |
-| Incidents      | `references/incident-response.md`     | Production outages, on-call, MTTR, postmortems, runbooks       |
+## Output Format
 
-## Constraints
+```
+## DevOps Recommendation
+[approach and reasoning]
 
-### MUST DO
+## Implementation
+[configuration files, scripts, or pipeline definitions]
 
-- Use infrastructure as code (never manual changes)
-- Implement health checks and readiness probes
-- Store secrets in secret managers (not env files)
-- Enable container scanning in CI/CD
-- Document rollback procedures
-- Use GitOps for Kubernetes (ArgoCD, Flux)
+## Monitoring
+[what to monitor and alert on]
 
-### MUST NOT DO
+## Rollback Plan
+[how to revert if something goes wrong]
+```
 
-- Deploy to production without explicit approval
-- Store secrets in code or CI/CD variables
-- Skip staging environment testing
-- Ignore resource limits in containers
-- Use `latest` tag in production
-- Deploy on Fridays without monitoring
+## Examples
 
-## Output Templates
+**User**: "Set up a GitHub Actions CI/CD pipeline for our Node.js API"
 
-Provide: CI/CD pipeline config, Dockerfile, K8s/Terraform files, deployment verification, rollback procedure
+**Response approach**: Multi-stage pipeline: lint → test → build → deploy. Cache node_modules. Run security audit. Deploy to staging on PR merge, production on release tag. Include health check after deploy.
 
-## Knowledge Reference
+**User**: "We need to deploy without downtime"
 
-GitHub Actions, GitLab CI, Jenkins, CircleCI, Docker, Kubernetes, Helm, ArgoCD, Flux, Terraform, Pulumi, Crossplane, AWS/GCP/Azure, Prometheus, Grafana, PagerDuty, Backstage, LaunchDarkly, Flagger
+**Response approach**: Recommend blue-green or rolling deployment based on architecture. Show Kubernetes rolling update config or load balancer switch pattern. Include health check probes and rollback trigger.

package/workflows/powers/docker-kubernetes/POWER.md

@@ -0,0 +1,94 @@
+````markdown
+---
+inclusion: manual
+name: docker-kubernetes
+description: "Use for containerization strategy, Dockerfile optimization, Kubernetes deployment patterns, Helm charts, and container orchestration decisions."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Docker & Kubernetes
+
+## Purpose
+
+Use for containerization strategy, Dockerfile optimization, Kubernetes deployment patterns, Helm charts, and container orchestration decisions.
+
+## When to Use
+
+- Writing or optimizing Dockerfiles for production builds.
+- Designing Kubernetes deployment, service, and ingress manifests.
+- Choosing between deployment strategies (rolling, blue-green, canary).
+- Setting up health checks, resource limits, and autoscaling.
+- Writing Helm charts or Kustomize overlays.
+- Debugging container startup failures, crashloops, or networking issues.
+
+## Instructions
+
+1. Define the build target: minimal base image, multi-stage build, layer caching.
+2. Set resource requests and limits based on measured usage, not guesses.
+3. Configure health checks (liveness, readiness, startup probes) appropriate to the service.
+4. Design the deployment strategy matching the service's availability requirements.
+5. Verify the container runs as non-root, has no secrets baked in, and scans clean.
+
+### Dockerfile standards
+
+- Use multi-stage builds to separate build dependencies from runtime.
+- Pin base image versions to digest or specific tag — never use `latest` in production.
+- Order layers from least-changing to most-changing for optimal cache utilization.
+- Copy dependency manifests and install before copying application code.
+- Run as non-root user: `USER nonroot` or numeric UID.
+- Use `.dockerignore` to exclude `.git`, `node_modules`, test fixtures, and local configs.
+- Keep final image minimal: `distroless`, `alpine`, or `slim` variants.
+
+### Kubernetes standards
+
+- Always set resource requests AND limits for CPU and memory.
+- Define liveness probes (restart on deadlock), readiness probes (remove from service on overload), and startup probes (slow initialization).
+- Use `PodDisruptionBudget` for services that need availability guarantees during node maintenance.
+- Set `securityContext`: `runAsNonRoot: true`, `readOnlyRootFilesystem: true`, drop all capabilities.
+- Use `ConfigMap` for non-sensitive config, `Secret` (or external secrets operator) for credentials.
+- Label everything: `app`, `version`, `component`, `part-of`, `managed-by`.
+- Use `topologySpreadConstraints` or pod anti-affinity for high-availability across zones.
+
+### Debugging patterns
+
+- CrashLoopBackOff: check `kubectl logs --previous`, verify probes aren't too aggressive.
+- ImagePullBackOff: verify image name, tag, registry auth, and network access.
+- Pending pods: check events for resource pressure, node affinity mismatches, or PVC issues.
+- OOMKilled: increase memory limits or fix the memory leak — never just raise limits blindly.
+- Network issues: verify service selectors match pod labels, check NetworkPolicy rules.
+
+### Constraints
+
+- Avoid storing secrets in Dockerfiles, environment variables baked at build time, or ConfigMaps.
+- Avoid running as root in production containers.
+- Avoid using `latest` tag for base images or application images.
+- Avoid setting CPU limits without measuring — over-limiting causes throttling.
+- Avoid single-replica deployments for stateless services that need availability.
+- Avoid skipping health probes — Kubernetes cannot manage what it cannot observe.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+Load on demand. Do not preload all reference files.
+
+| File                                              | Load when                                                                                                 |
+| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
+| `references/dockerfile-optimization-checklist.md` | The task focuses on Dockerfile writing, multi-stage builds, layer caching, or image size reduction.       |
+| `references/kubernetes-deployment-patterns.md`    | The task involves deployment strategies, autoscaling, Helm charts, or production Kubernetes architecture. |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with docker kubernetes best practices in this project"
+- "Review my docker kubernetes implementation for issues"
+````

package/workflows/powers/docker-kubernetes/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: docker-kubernetes
+description: "Use for containerization strategy, Dockerfile optimization, Kubernetes deployment patterns, Helm charts, and container orchestration decisions."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Docker & Kubernetes
+
+## Purpose
+
+Use for containerization strategy, Dockerfile optimization, Kubernetes deployment patterns, Helm charts, and container orchestration decisions.
+
+## When to Use
+
+- Writing or optimizing Dockerfiles for production builds.
+- Designing Kubernetes deployment, service, and ingress manifests.
+- Choosing between deployment strategies (rolling, blue-green, canary).
+- Setting up health checks, resource limits, and autoscaling.
+- Writing Helm charts or Kustomize overlays.
+- Debugging container startup failures, crashloops, or networking issues.
+
+## Instructions
+
+1. Define the build target: minimal base image, multi-stage build, layer caching.
+2. Set resource requests and limits based on measured usage, not guesses.
+3. Configure health checks (liveness, readiness, startup probes) appropriate to the service.
+4. Design the deployment strategy matching the service's availability requirements.
+5. Verify the container runs as non-root, has no secrets baked in, and scans clean.
+
+### Dockerfile standards
+
+- Use multi-stage builds to separate build dependencies from runtime.
+- Pin base image versions to digest or specific tag — never use `latest` in production.
+- Order layers from least-changing to most-changing for optimal cache utilization.
+- Copy dependency manifests and install before copying application code.
+- Run as non-root user: `USER nonroot` or numeric UID.
+- Use `.dockerignore` to exclude `.git`, `node_modules`, test fixtures, and local configs.
+- Keep final image minimal: `distroless`, `alpine`, or `slim` variants.
+
+### Kubernetes standards
+
+- Always set resource requests AND limits for CPU and memory.
+- Define liveness probes (restart on deadlock), readiness probes (remove from service on overload), and startup probes (slow initialization).
+- Use `PodDisruptionBudget` for services that need availability guarantees during node maintenance.
+- Set `securityContext`: `runAsNonRoot: true`, `readOnlyRootFilesystem: true`, drop all capabilities.
+- Use `ConfigMap` for non-sensitive config, `Secret` (or external secrets operator) for credentials.
+- Label everything: `app`, `version`, `component`, `part-of`, `managed-by`.
+- Use `topologySpreadConstraints` or pod anti-affinity for high-availability across zones.
+
+### Debugging patterns
+
+- CrashLoopBackOff: check `kubectl logs --previous`, verify probes aren't too aggressive.
+- ImagePullBackOff: verify image name, tag, registry auth, and network access.
+- Pending pods: check events for resource pressure, node affinity mismatches, or PVC issues.
+- OOMKilled: increase memory limits or fix the memory leak — never just raise limits blindly.
+- Network issues: verify service selectors match pod labels, check NetworkPolicy rules.
+
+### Constraints
+
+- Avoid storing secrets in Dockerfiles, environment variables baked at build time, or ConfigMaps.
+- Avoid running as root in production containers.
+- Avoid using `latest` tag for base images or application images.
+- Avoid setting CPU limits without measuring — over-limiting causes throttling.
+- Avoid single-replica deployments for stateless services that need availability.
+- Avoid skipping health probes — Kubernetes cannot manage what it cannot observe.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+Load on demand. Do not preload all reference files.
+
+| File                                              | Load when                                                                                                 |
+| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
+| `references/dockerfile-optimization-checklist.md` | The task focuses on Dockerfile writing, multi-stage builds, layer caching, or image size reduction.       |
+| `references/kubernetes-deployment-patterns.md`    | The task involves deployment strategies, autoscaling, Helm charts, or production Kubernetes architecture. |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with docker kubernetes best practices in this project"
+- "Review my docker kubernetes implementation for issues"

package/workflows/powers/docker-kubernetes/references/dockerfile-optimization-checklist.md

@@ -0,0 +1,35 @@
+# Dockerfile Optimization Checklist
+
+## Multi-stage builds
+
+- Stage 1 (builder): install build tools, compile, bundle.
+- Stage 2 (runtime): copy only artifacts needed to run.
+- Name stages explicitly: `FROM node:22-slim AS builder`.
+- Copy from named stages: `COPY --from=builder /app/dist ./dist`.
+
+## Layer caching
+
+- `COPY package.json package-lock.json ./` then `RUN npm ci` BEFORE `COPY . .`.
+- Group related `RUN` commands with `&&` to reduce layers.
+- Never invalidate cache unnecessarily — file order matters.
+
+## Image size
+
+- Prefer `distroless` or `alpine` base images for production.
+- Remove build caches in the same RUN step: `RUN apt-get install -y ... && rm -rf /var/lib/apt/lists/*`.
+- Use `--mount=type=cache` for package manager caches in BuildKit.
+- Avoid installing dev dependencies in the runtime stage.
+
+## Security
+
+- Pin base images to digest: `FROM node:22-slim@sha256:abc123...`.
+- Run `npm ci --omit=dev` for production Node.js images.
+- Scan with `trivy`, `grype`, or `docker scout` in CI before push.
+- Never use `ADD` for remote URLs — use explicit `curl` + verify checksum.
+- Set `USER 1000` or named non-root user as the last instruction before CMD.
+
+## Health and signals
+
+- Use `STOPSIGNAL SIGTERM` — ensure the app handles graceful shutdown.
+- Avoid `ENTRYPOINT ["sh", "-c", "..."]` — PID 1 must be the app process (use `exec` form or `tini`).
+- Define `HEALTHCHECK` in Dockerfile for standalone Docker, but prefer Kubernetes probes in K8s.

package/workflows/powers/docker-kubernetes/references/kubernetes-deployment-patterns.md

@@ -0,0 +1,59 @@
+# Kubernetes Deployment Patterns
+
+## Deployment strategies
+
+- **Rolling update** (default): gradually replaces pods. Set `maxUnavailable` and `maxSurge` based on replica count and availability requirement.
+- **Blue-green**: deploy new version alongside old, switch service selector after verification. Requires 2x resources temporarily.
+- **Canary**: route a percentage of traffic to new version. Use Istio, Linkerd, or Argo Rollouts for traffic splitting.
+- **Recreate**: kill all old pods before starting new. Only for services that cannot run two versions simultaneously.
+
+## Autoscaling
+
+- **HPA** (Horizontal Pod Autoscaler): scale on CPU, memory, or custom metrics. Set `minReplicas` ≥ 2 for availability.
+- **VPA** (Vertical Pod Autoscaler): auto-adjust resource requests. Use in recommendation mode first, not auto mode.
+- **KEDA**: scale on event-driven metrics (queue depth, HTTP rate). Good for batch and event-driven workloads.
+- Always set resource requests accurately — HPA decisions depend on them.
+
+## Helm chart structure
+
+```
+chart-name/
+├── Chart.yaml
+├── values.yaml
+├── values-staging.yaml
+├── values-production.yaml
+└── templates/
+    ├── deployment.yaml
+    ├── service.yaml
+    ├── ingress.yaml
+    ├── hpa.yaml
+    ├── pdb.yaml
+    ├── configmap.yaml
+    ├── serviceaccount.yaml
+    └── _helpers.tpl
+```
+
+- Keep `values.yaml` as the single source of configurable parameters.
+- Use `_helpers.tpl` for label generation and name templating.
+- Pin chart dependencies to exact versions.
+- Test with `helm template` and `helm lint` before deploy.
+
+## Networking
+
+- Use `ClusterIP` services for internal communication, `LoadBalancer` or `Ingress` for external.
+- Use `NetworkPolicy` to restrict pod-to-pod communication (default-deny, allow-list).
+- Prefer `Ingress` with TLS termination over exposing services directly.
+
+## Observability
+
+- Export `/healthz` and `/readyz` endpoints from every service.
+- Use structured JSON logging to stdout/stderr — never write logs to files inside containers.
+- Expose Prometheus metrics on a `/metrics` endpoint.
+- Set meaningful pod labels for filtering in dashboards and alerting.
+
+## Stateful workloads
+
+- Use `StatefulSet` only when stable network identity or stable storage is required.
+- Prefer managed databases over running databases in Kubernetes.
+- Use `PersistentVolumeClaim` with appropriate storage class and reclaim policy.
+- Back up PVCs independently — Kubernetes does not manage backup.