constellai 0.3.0

package/skills/stacks/infra/aws/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: aws
+description: Amazon Web Services cloud platform and AWS CLI; consult for compute, storage, networking, IAM, and scripting AWS resources.
+domain: stack
+category: infra
+tags: [cloud, aws, iam, ec2, s3, cli]
+official_sources:
+  - https://docs.aws.amazon.com/
+  - https://github.com/aws/aws-cli
+verified: 2026-06-16
+---
+
+# AWS (Amazon Web Services)
+
+## Overview
+AWS is a broad cloud platform offering compute (EC2, Lambda), storage (S3, EBS), databases, networking (VPC), and identity (IAM), among hundreds of services. The AWS CLI (`aws`) is the unified command-line tool for managing these resources and scripting automation. Read this when you need to provision, manage, or script AWS infrastructure.
+
+## Official sources
+- Docs: https://docs.aws.amazon.com/
+- Repo (AWS CLI): https://github.com/aws/aws-cli
+- CLI install: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
+
+## Install / setup
+Linux (x86_64), copied verbatim from the official install page:
+```bash
+curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
+unzip awscliv2.zip
+sudo ./aws/install
+```
+
+## Core concepts
+- Regions & Availability Zones: resources live in a region, which contains isolated AZs for fault tolerance.
+- IAM: identities (users, roles) and policies that grant least-privilege permissions to AWS actions and resources.
+- EC2 & Lambda: virtual machines for long-running compute vs. event-driven serverless functions.
+- S3: object storage organized into buckets with fine-grained access policies.
+- VPC: a logically isolated virtual network with subnets, route tables, and security groups.
+- Credentials & profiles: the CLI resolves credentials from environment variables, shared config/credentials files, and named profiles.
+
+## Best practices
+- Grant least-privilege IAM policies and prefer roles over long-lived access keys (per AWS IAM best practices).
+- Avoid using the account root user for everyday tasks; create scoped IAM identities instead.
+- Scope resources to the correct region and use multiple AZs for high availability.
+- In CI, use short-lived role credentials (e.g. OIDC-assumed roles) rather than embedding static keys.
+
+## Common pitfalls
+- Running a CLI command with no/incorrect `--region` or profile → it targets the wrong region or fails to find resources.
+- Over-broad IAM policies (`Action: "*"`) → security risk; scope to specific actions and resources.
+- Public S3 bucket misconfiguration → unintended data exposure; verify bucket policies and Block Public Access.
+
+## Examples
+```bash
+# Configure credentials and a default region
+aws configure
+
+# List S3 buckets and copy a file
+aws s3 ls
+aws s3 cp ./report.csv s3://my-bucket/report.csv
+```
+
+## Further reading
+- https://docs.aws.amazon.com/cli/latest/userguide/ — AWS CLI user guide
+- https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html — IAM best practices
+
+## Related skills
+- ../gcp — comparable hyperscale cloud platform
+- ../kubernetes — container orchestration often run on AWS (EKS)

package/skills/stacks/infra/azure/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: azure
+description: Microsoft Azure is Microsoft's public cloud platform managed via the az CLI; consult when provisioning Azure resources, authenticating with az login, scripting deployments, working with resource groups, ARM/Bicep templates, AKS, App Service, storage accounts, or managing Azure subscriptions from the command line.
+domain: stack
+category: infra
+tags: [azure, cloud, microsoft, az-cli, devops, infrastructure, iac]
+official_sources:
+  - https://learn.microsoft.com/en-us/cli/azure/
+  - https://github.com/Azure/azure-cli
+  - https://learn.microsoft.com/en-us/cli/azure/install-azure-cli
+verified: 2026-06-17
+---
+
+# Microsoft Azure
+
+## Overview
+Microsoft Azure is Microsoft's public cloud platform for compute, storage, networking, databases, and managed services. The Azure CLI (`az`) is the cross-platform command-line tool for creating and managing those resources via scripts or interactive commands. Read this when you need to authenticate to Azure, provision or query resources, or automate deployments from the terminal.
+
+## Official sources
+- Docs: https://learn.microsoft.com/en-us/cli/azure/
+- Repo: https://github.com/Azure/azure-cli
+- Install: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli
+
+## Install / setup
+```bash
+# Windows (Windows Package Manager)
+winget install --exact --id Microsoft.AzureCLI
+# then authenticate
+az login
+```
+Source: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-windows
+
+## Core concepts
+- **Subscription** — billing/management boundary; each resource lives under one subscription (`az account show`).
+- **Resource group** — logical container grouping related resources sharing lifecycle and region.
+- **Resource provider** — service namespace (e.g. `Microsoft.Compute`) that must be registered to use its resources.
+- **ARM / Bicep** — Azure Resource Manager is the deployment/control plane; Bicep is the declarative IaC DSL that compiles to ARM JSON.
+- **Region** — physical datacenter location (e.g. `eastus`) where resources are deployed.
+- **RBAC** — role-based access control assigns roles (Owner, Contributor, Reader) to identities at a scope.
+- **Managed identity** — Azure-managed service principal so resources authenticate without stored secrets.
+- **az login** — interactive (browser/device-code) or service-principal authentication establishing CLI context.
+
+## Best practices
+- Use resource groups to align resource lifecycle and apply tags for cost tracking (https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/overview).
+- Prefer managed identities over storing credentials in code or config (https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview).
+- Define infrastructure with Bicep/ARM templates for repeatable, reviewable deployments (https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview).
+- Run `az login --use-device-code` on headless/remote machines where no browser is available (https://learn.microsoft.com/en-us/cli/azure/authenticate-azure-cli).
+- Keep the CLI current with `az upgrade` to get latest commands and fixes (https://learn.microsoft.com/en-us/cli/azure/update-azure-cli).
+
+## Common pitfalls
+- Forgetting to set the active subscription on multi-sub accounts → run `az account set --subscription <id>` before creating resources.
+- `az` not found after install on Windows → close and reopen the terminal so PATH refreshes.
+- Resource provider not registered → run `az provider register --namespace Microsoft.<Service>` and wait for it to complete.
+
+## Examples
+```bash
+az group create --name myRG --location eastus
+az storage account create \
+  --name mystorage$RANDOM \
+  --resource-group myRG \
+  --location eastus \
+  --sku Standard_LRS
+```
+
+## Further reading
+- https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/ — Bicep IaC language reference
+- https://learn.microsoft.com/en-us/cli/azure/reference-index — full `az` command reference
+- https://learn.microsoft.com/en-us/azure/architecture/ — Azure Architecture Center patterns
+
+## Related skills
+- ../terraform — provision Azure resources declaratively with the azurerm provider
+- ../ansible — configure Azure VMs and orchestrate post-provisioning

package/skills/stacks/infra/circleci/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: circleci
+description: CircleCI is a cloud and self-hosted CI/CD platform configured via a .circleci/config.yml file; consult when defining jobs, workflows, executors, orbs, caching, contexts, or runners, and when debugging pipeline syntax (version 2.1) or build failures.
+domain: stack
+category: infra
+tags: [circleci, ci-cd, automation, pipeline, devops, infrastructure, yaml]
+official_sources:
+  - https://circleci.com/docs/
+  - https://github.com/CircleCI-Public
+  - https://circleci.com/docs/guides/getting-started/getting-started/
+verified: 2026-06-17
+---
+
+# CircleCI
+
+## Overview
+CircleCI is a continuous integration and delivery platform that runs pipelines defined in a single `.circleci/config.yml` file at the root of your repository. It executes jobs in fully isolated cloud executors (Docker, Linux, macOS, Windows) or on self-hosted runners, orchestrated by workflows. Read this when authoring or debugging CircleCI config, wiring up jobs and workflows, or reusing logic with orbs.
+
+## Official sources
+- Docs: https://circleci.com/docs/
+- Repo: https://github.com/CircleCI-Public
+- Install: https://circleci.com/docs/guides/getting-started/getting-started/
+
+## Install / setup
+```yaml
+# .circleci/config.yml
+version: 2.1
+jobs:
+  build:
+    docker:
+      - image: cimg/base:current
+    steps:
+      - checkout
+      - run: echo "Hello, CircleCI"
+```
+Source: https://circleci.com/docs/guides/getting-started/introduction-to-yaml-configurations/
+
+## Core concepts
+- **config.yml** — single YAML file under `.circleci/` defining the entire pipeline; `version: 2.1` is current.
+- **Job** — a collection of `steps` run in a single executor; the unit of work.
+- **Step** — an individual action such as `checkout` or `run`.
+- **Executor** — the environment a job runs in (`docker`, `machine`, `macos`, `windows`).
+- **Workflow** — orchestrates jobs with ordering, fan-out/fan-in, and conditional/parallel execution.
+- **Orb** — reusable, shareable package of config (jobs, commands, executors).
+- **Context** — named, secured set of environment variables shared across projects.
+- **Self-hosted runner** — your own machine executing jobs for the CircleCI control plane.
+
+## Best practices
+- Use `version: 2.1` to unlock orbs, reusable commands, and pipeline parameters (https://circleci.com/docs/reference/configuration-reference/).
+- Organize multi-job pipelines with workflows for parallelism and dependencies (https://circleci.com/docs/guides/orchestrate/workflows/).
+- Cache dependencies with `save_cache`/`restore_cache` to speed up builds (https://circleci.com/docs/guides/optimize/caching/).
+- Store secrets in Contexts or project environment variables, never in config (https://circleci.com/docs/guides/security/contexts/).
+- Reuse vetted logic via the orb registry instead of copy-pasting steps (https://circleci.com/developer/orbs).
+
+## Common pitfalls
+- Misindented YAML silently breaks the pipeline → validate with the CircleCI CLI (`circleci config validate`) or VS Code extension.
+- Stale caches from an unchanging cache key → include a checksum of the lockfile in the key.
+- Committing secrets into config.yml → move them into Contexts or env vars in project settings.
+
+## Examples
+```yaml
+workflows:
+  build-and-test:
+    jobs:
+      - build
+      - test:
+          requires:
+            - build
+```
+
+## Further reading
+- https://circleci.com/docs/reference/configuration-reference/ — full config.yml reference
+- https://circleci.com/developer/orbs — orb registry
+- https://circleci.com/docs/guides/orchestrate/workflows/ — workflows guide
+
+## Related skills
+- ../jenkins — self-hosted CI/CD server alternative
+- ../terraform — provision infrastructure invoked from CircleCI jobs

package/skills/stacks/infra/cloudflare/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: cloudflare
+description: Cloudflare CDN, DNS, WAF, Workers edge compute, and Tunnels; consult for edge delivery, DNS, and exposing private origins securely.
+domain: stack
+category: infra
+tags: [cdn, dns, edge, tunnel, workers, waf]
+official_sources:
+  - https://developers.cloudflare.com/
+  - https://github.com/cloudflare/cloudflared
+verified: 2026-06-16
+---
+
+# Cloudflare
+
+## Overview
+Cloudflare is a global network that sits in front of your sites and services to provide CDN caching, DNS, TLS, a Web Application Firewall, and edge compute (Workers). `cloudflared` additionally creates outbound-only Tunnels so you can expose a local or private origin without opening inbound firewall ports. Read this when you need to accelerate, protect, or securely publish a web service.
+
+## Official sources
+- Docs: https://developers.cloudflare.com/
+- Repo (cloudflared): https://github.com/cloudflare/cloudflared
+- Tunnel install methods: https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/
+
+## Install / setup
+`cloudflared` is distributed as OS packages and binaries (Homebrew, Debian/RPM, Windows, Docker) rather than a single universal script. On macOS with Homebrew:
+```bash
+brew install cloudflared
+```
+See the repo and docs for Linux package and Docker installs.
+
+## Core concepts
+- CDN & caching: edge nodes cache origin responses; cache behavior is controlled by cache rules and response headers.
+- DNS: Cloudflare acts as authoritative DNS; records can be proxied (orange-cloud, traffic flows through Cloudflare) or DNS-only (grey-cloud).
+- WAF & security: managed and custom rules filter malicious requests at the edge before they reach the origin.
+- Workers: serverless JavaScript/Wasm functions that run on the edge close to users.
+- Tunnel (cloudflared): an outbound-only daemon that proxies traffic from Cloudflare's network to your origin, avoiding inbound port exposure.
+- Zero Trust (Access/Gateway): identity-aware policies gate access to applications and networks.
+
+## Best practices
+- Proxy (orange-cloud) records you want protected/cached; keep records DNS-only when the service must not route through Cloudflare.
+- Prefer Tunnels over opening inbound firewall ports for private origins, since cloudflared connects outbound only (see Cloudflare One docs).
+- Use cache rules and appropriate `Cache-Control` headers rather than relying on defaults to avoid caching dynamic/private responses.
+- Put authentication-sensitive apps behind Zero Trust Access policies instead of relying on network obscurity.
+
+## Common pitfalls
+- Proxying a record that needs the visitor's real IP → the origin sees Cloudflare IPs; read `CF-Connecting-IP` instead of the socket address.
+- Caching authenticated or per-user responses → set proper cache bypass rules or no-store headers.
+- Running a Tunnel without scoping its public hostname/routes → unintended exposure; define ingress rules explicitly.
+
+## Examples
+```bash
+# Authenticate cloudflared and create a named tunnel
+cloudflared tunnel login
+cloudflared tunnel create my-app
+
+# Route a hostname to the tunnel and run it
+cloudflared tunnel route dns my-app app.example.com
+cloudflared tunnel run my-app
+```
+
+## Further reading
+- https://developers.cloudflare.com/workers/ — edge compute
+- https://developers.cloudflare.com/cloudflare-one/ — Zero Trust and Tunnels
+
+## Related skills
+- ../tailscale — alternative private-network/VPN approach for device connectivity

package/skills/stacks/infra/fly-io/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: fly-io
+description: Run full-stack apps and databases on a global edge using flyctl and Fly Machines; consult for deploys, regions, and scaling.
+domain: stack
+category: infra
+tags: [hosting, edge, containers, deploy, flyctl, global]
+official_sources:
+  - https://fly.io/docs/
+  - https://github.com/superfly/flyctl
+verified: 2026-06-16
+---
+
+# Fly.io
+
+## Overview
+Fly.io runs your app as containers (Fly Machines) on hardware in many regions, placing instances close to users worldwide. It deploys apps, databases, and background workers driven by the `flyctl` CLI and a `fly.toml` config. Read this when you need to deploy a containerized full-stack app with low latency across regions.
+
+## Official sources
+- Docs: https://fly.io/docs/
+- Repo (flyctl): https://github.com/superfly/flyctl
+- Install: https://fly.io/docs/flyctl/install/
+
+## Install / setup
+```bash
+curl -L https://fly.io/install.sh | sh
+```
+
+## Core concepts
+- Fly Machines: fast-starting micro-VMs running your container image; the unit of compute you deploy and scale.
+- `fly.toml`: per-app configuration declaring services, ports, regions, health checks, and scaling.
+- Regions: apps run in chosen regions; Fly's edge routes each request to a nearby instance.
+- Volumes: persistent local disks attached to a Machine for stateful workloads.
+- Apps & deploys: `fly deploy` builds/pushes an image and rolls Machines to the new release.
+- Private networking: apps in an organization share a private IPv6 (6PN) network for service-to-service traffic.
+
+## Best practices
+- Define health checks in `fly.toml` so rolling deploys only shift traffic to healthy Machines.
+- Co-locate stateful storage (volumes/databases) in the same region as the app instances that use them to avoid cross-region latency.
+- Use secrets (`fly secrets set`) for credentials instead of baking them into the image or committing them.
+- Scale by region to match where your users are rather than over-provisioning a single region.
+
+## Common pitfalls
+- Assuming volumes follow the app across regions → a volume is pinned to one region/Machine; plan placement and replication.
+- Forgetting health checks → a broken release can receive traffic before failing.
+- Treating Machines as long-lived pets → they can be recreated; persist state in volumes or external databases.
+
+## Examples
+```bash
+# Authenticate, scaffold config, and deploy
+fly auth login
+fly launch
+fly deploy
+
+# Store a secret used by the app at runtime
+fly secrets set DATABASE_URL=postgres://...
+```
+
+## Further reading
+- https://fly.io/docs/reference/configuration/ — fly.toml reference
+- https://fly.io/docs/volumes/ — persistent volumes
+
+## Related skills
+- ../railway — similar deploy-anything platform for apps and databases

package/skills/stacks/infra/gcp/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: gcp
+description: Google Cloud Platform and the gcloud CLI; consult for compute, storage, networking, IAM, and scripting GCP resources.
+domain: stack
+category: infra
+tags: [cloud, gcp, gcloud, iam, compute, cli]
+official_sources:
+  - https://cloud.google.com/docs
+  - https://cloud.google.com/sdk/docs/install
+verified: 2026-06-16
+---
+
+# GCP (Google Cloud Platform)
+
+## Overview
+Google Cloud Platform offers compute (Compute Engine, Cloud Run, GKE), storage (Cloud Storage), databases, networking, and IAM across Google's global infrastructure. The Google Cloud CLI (`gcloud`, part of the Google Cloud SDK) is the unified tool for managing and scripting these resources. Read this when you need to provision, manage, or automate GCP infrastructure.
+
+## Official sources
+- Docs: https://cloud.google.com/docs
+- CLI install: https://cloud.google.com/sdk/docs/install
+- Note: the gcloud CLI / Google Cloud SDK is a Google-distributed product without a single canonical public source repo; install from the official download above. The GoogleCloudPlatform GitHub org (https://github.com/GoogleCloudPlatform) hosts samples and tooling such as the cloud-sdk-docker image.
+
+## Install / setup
+Linux, copied verbatim from the official install page:
+```bash
+curl -O https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-cli-linux-x86_64.tar.gz
+tar -xf google-cloud-cli-linux-x86_64.tar.gz
+./google-cloud-sdk/install.sh
+```
+
+## Core concepts
+- Projects: the top-level container for resources, billing, and permissions; nearly everything belongs to a project.
+- IAM: roles and policies binding members (users, service accounts) to permissions on resources.
+- Service accounts: non-human identities used by workloads to call GCP APIs.
+- Regions & zones: resources are deployed to zones within regions for locality and redundancy.
+- Compute options: Compute Engine (VMs), Cloud Run (containers, serverless), and GKE (managed Kubernetes).
+- gcloud config: the active project, account, and region/zone are stored in a CLI configuration.
+
+## Best practices
+- Set the active project/region in your gcloud config (or pass `--project`) so commands target the intended resources.
+- Grant least-privilege IAM roles and use service accounts for workloads instead of personal credentials (per GCP IAM docs).
+- Use Workload Identity / short-lived credentials for CI rather than downloading long-lived service-account key files.
+- Separate environments into distinct projects to isolate billing, quotas, and blast radius.
+
+## Common pitfalls
+- Forgetting to set the active project → commands fail or hit the wrong project.
+- Downloading and committing service-account JSON keys → credential leakage; prefer keyless/short-lived auth.
+- Over-broad primitive roles (Owner/Editor) → use predefined or custom least-privilege roles instead.
+
+## Examples
+```bash
+# Authenticate and select the active project
+gcloud auth login
+gcloud config set project my-project-id
+
+# List compute instances
+gcloud compute instances list
+```
+
+## Further reading
+- https://cloud.google.com/sdk/gcloud — gcloud command reference
+- https://cloud.google.com/iam/docs — IAM documentation
+
+## Related skills
+- ../aws — comparable hyperscale cloud platform
+- ../kubernetes — container orchestration often run on GCP (GKE)

package/skills/stacks/infra/jenkins/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: jenkins
+description: Jenkins is an open-source automation server for building, testing, and deploying software via CI/CD pipelines; consult when configuring Jenkinsfile pipelines, declarative vs scripted syntax, agents/nodes, plugins, stages, credentials, or running a Jenkins controller in Docker.
+domain: stack
+category: infra
+tags: [jenkins, ci-cd, automation, pipeline, devops, infrastructure, build]
+official_sources:
+  - https://www.jenkins.io/doc/
+  - https://github.com/jenkinsci/jenkins
+  - https://www.jenkins.io/doc/book/installing/
+verified: 2026-06-17
+---
+
+# Jenkins
+
+## Overview
+Jenkins is a self-hosted, open-source automation server that orchestrates continuous integration and continuous delivery (CI/CD) pipelines. Pipelines are defined as code in a `Jenkinsfile` and executed across a controller and distributed agents, with thousands of plugins extending its capabilities. Read this when you need to author pipelines, configure build agents, manage credentials, or stand up a Jenkins instance.
+
+## Official sources
+- Docs: https://www.jenkins.io/doc/
+- Repo: https://github.com/jenkinsci/jenkins
+- Install: https://www.jenkins.io/doc/book/installing/
+
+## Install / setup
+```bash
+docker run --name jenkins --restart=on-failure --detach \
+  --publish 8080:8080 --publish 50000:50000 \
+  --volume jenkins-data:/var/jenkins_home \
+  jenkins/jenkins:lts-jdk21
+```
+Source: https://www.jenkins.io/doc/book/installing/docker/
+
+## Core concepts
+- **Controller** — central Jenkins server that stores config, schedules builds, and dispatches work to agents.
+- **Agent (node)** — worker machine/container that executes build steps; isolates workloads from the controller.
+- **Pipeline** — end-to-end automated process defined in a `Jenkinsfile` (declarative or scripted Groovy).
+- **Stage / step** — `stage` groups related work; `step` is a single task (e.g. `sh 'make'`).
+- **Job/project** — a configured unit of work (freestyle, pipeline, or multibranch).
+- **Plugin** — installable extension adding integrations, tools, and pipeline steps.
+- **Credentials** — securely stored secrets injected into builds via the Credentials plugin.
+- **Executor** — a slot on a node that runs one build at a time.
+
+## Best practices
+- Define pipelines as code in a versioned `Jenkinsfile` rather than configuring jobs in the UI (https://www.jenkins.io/doc/book/pipeline/).
+- Prefer the Declarative Pipeline syntax for readability and built-in validation (https://www.jenkins.io/doc/book/pipeline/syntax/).
+- Run builds on agents, keeping the controller free of heavy workloads (https://www.jenkins.io/doc/book/using/using-agents/).
+- Store secrets in the Credentials store and reference via `credentials()`/`withCredentials` (https://www.jenkins.io/doc/book/using/using-credentials/).
+- Pin the LTS release line and update plugins regularly for stability and security (https://www.jenkins.io/doc/book/managing/plugins/).
+
+## Common pitfalls
+- Running heavy builds on the controller → configure dedicated agents and set controller executors to 0.
+- Hardcoding secrets in the Jenkinsfile → use the Credentials plugin and masked bindings.
+- Losing config on container restart → mount a persistent volume at `/var/jenkins_home`.
+
+## Examples
+```groovy
+pipeline {
+    agent any
+    stages {
+        stage('Build') { steps { sh 'make' } }
+        stage('Test')  { steps { sh 'make test' } }
+    }
+}
+```
+
+## Further reading
+- https://www.jenkins.io/doc/book/pipeline/syntax/ — Declarative & Scripted pipeline syntax reference
+- https://plugins.jenkins.io/ — official plugin index
+- https://www.jenkins.io/doc/book/security/ — securing a Jenkins instance
+
+## Related skills
+- ../circleci — managed CI/CD alternative using YAML config
+- ../ansible — provision and configure Jenkins agents

package/skills/stacks/infra/kubernetes/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: kubernetes
+description: Container orchestration for deploying, scaling, and managing containerized apps; consult for Pods, Deployments, Services, and kubectl.
+domain: stack
+category: infra
+tags: [kubernetes, k8s, containers, orchestration, kubectl, cncf]
+official_sources:
+  - https://kubernetes.io/docs/
+  - https://github.com/kubernetes/kubernetes
+verified: 2026-06-16
+---
+
+# Kubernetes
+
+## Overview
+Kubernetes (K8s) is an open-source system, hosted by the CNCF, for automating the deployment, scaling, and management of containerized applications across a cluster of hosts. It exposes a declarative API where you describe desired state and controllers continuously reconcile actual state toward it. Read this when you need to run, scale, or operate containerized workloads on a cluster.
+
+## Official sources
+- Docs: https://kubernetes.io/docs/
+- Repo: https://github.com/kubernetes/kubernetes
+- Install tools: https://kubernetes.io/docs/tasks/tools/
+
+## Install / setup
+Install `kubectl` on Linux, copied verbatim from the official install page:
+```bash
+curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
+sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
+```
+
+## Core concepts
+- Pod: the smallest deployable unit, wrapping one or more containers that share network and storage.
+- Deployment: declares a desired replica count and manages rolling updates of stateless Pods via ReplicaSets.
+- Service: a stable network endpoint and load balancer for a set of Pods selected by labels.
+- ConfigMap & Secret: inject non-secret config and sensitive data into Pods separately from images.
+- Namespace: a virtual cluster partition for isolating and scoping resources.
+- Controllers & reconciliation: control loops continuously drive actual state toward declared desired state.
+- Ingress: rules for routing external HTTP(S) traffic to Services.
+
+## Best practices
+- Manage resources declaratively with version-controlled manifests applied via `kubectl apply`, not imperative one-off edits.
+- Set resource requests and limits on containers so the scheduler can place Pods and prevent noisy-neighbor exhaustion (per the docs).
+- Define liveness and readiness probes so Kubernetes restarts unhealthy Pods and only routes traffic to ready ones.
+- Store sensitive values in Secrets (and a real secrets manager) rather than baking them into images or ConfigMaps.
+
+## Common pitfalls
+- Omitting resource requests/limits → unschedulable Pods or nodes overcommitted and OOM-killed.
+- Missing readiness probe → traffic is sent to Pods before they can serve, causing errors during rollouts.
+- Treating Secrets as encrypted by default → base64 is encoding, not encryption; enable encryption at rest and restrict RBAC access.
+
+## Examples
+```bash
+# Apply a manifest and inspect the rollout
+kubectl apply -f deployment.yaml
+kubectl get pods -n my-namespace
+kubectl rollout status deployment/my-app -n my-namespace
+```
+
+## Further reading
+- https://kubernetes.io/docs/concepts/ — concepts overview
+- https://kubernetes.io/docs/reference/kubectl/ — kubectl reference
+
+## Related skills
+- ../aws — managed Kubernetes via EKS
+- ../gcp — managed Kubernetes via GKE

package/skills/stacks/infra/netlify/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: netlify
+description: Managed hosting for web apps with Git deploys, functions, and edge; consult for deploys, redirects, env vars, and the Netlify CLI.
+domain: stack
+category: infra
+tags: [hosting, serverless, frontend, deploy, cli, jamstack]
+official_sources:
+  - https://docs.netlify.com/
+  - https://github.com/netlify/cli
+verified: 2026-06-16
+---
+
+# Netlify
+
+## Overview
+Netlify is a managed platform for building and hosting web apps, providing Git-connected continuous deployment, serverless and edge functions, and per-deploy preview URLs. It targets static sites and frontend frameworks plus their attached backend functions. Read this when you need to deploy a web app, configure redirects/headers, or drive deploys with the CLI.
+
+## Official sources
+- Docs: https://docs.netlify.com/
+- Repo (CLI): https://github.com/netlify/cli
+- CLI install: https://docs.netlify.com/cli/get-started/
+
+## Install / setup
+```bash
+npm install -g netlify-cli
+```
+
+## Core concepts
+- Continuous deployment: connecting a Git repo triggers a build and deploy on each push.
+- Deploy previews: pull requests/branches get isolated preview URLs before merging to production.
+- Functions: serverless (and edge) functions deployed alongside the site for backend logic.
+- `netlify.toml`: project configuration for build settings, redirects, headers, and function paths.
+- Redirects & rewrites: rule-based routing (including SPA fallback and proxying) defined in config or a `_redirects` file.
+- Environment variables: configured per site/context (production, deploy-preview, branch) and used during build and at runtime.
+
+## Best practices
+- Keep build, publish directory, redirects, and headers in `netlify.toml` so configuration is versioned with the code.
+- For CI environments, install the CLI as a local dev dependency (`npm install netlify-cli --save-dev`) rather than relying on a global install (per the docs).
+- Use an SPA catch-all redirect (`/* /index.html 200`) for client-side routed apps so deep links resolve.
+- Scope environment variables to the correct deploy context to avoid leaking production secrets into previews.
+
+## Common pitfalls
+- Missing SPA redirect → client-side routes 404 on direct navigation.
+- Setting a wrong publish directory → the build succeeds but the deployed site is empty or shows the wrong root.
+- Expecting functions to hold state between invocations → they are stateless and short-lived; use external storage.
+
+## Examples
+```bash
+# Authenticate, link the repo, and deploy to production
+netlify login
+netlify link
+netlify deploy --prod
+```
+
+## Further reading
+- https://docs.netlify.com/routing/redirects/ — redirects and rewrites
+- https://docs.netlify.com/functions/overview/ — functions overview
+
+## Related skills
+- ../vercel — comparable managed frontend hosting platform