constella 0.1.0

package/skills/stacks/container/podman/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: podman
+description: Daemonless, rootless OCI container and pod engine with a Docker-compatible CLI — consult for running containers without a root daemon.
+domain: stack
+category: container
+tags: [podman, containers, rootless, daemonless, oci, pods]
+official_sources:
+  - https://docs.podman.io/
+  - https://github.com/containers/podman
+verified: 2026-06-16
+---
+
+# Podman
+
+## Overview
+Podman is a daemonless, open-source, Linux-native tool for finding, running, building, sharing, and deploying applications using OCI containers and pods. Unlike Docker it runs without a long-lived root daemon and supports rootless containers, making it attractive for security-sensitive and multi-user environments. Its CLI is largely Docker-compatible, so most `docker` commands map directly to `podman`. Read this when running containers without a daemon or migrating Docker workflows.
+
+## Official sources
+- Docs: https://docs.podman.io/
+- Repo: https://github.com/containers/podman
+- Install / download: https://podman.io/docs/installation
+
+## Install / setup
+Install commands per platform from the official installation page (https://podman.io/docs/installation):
+
+```bash
+# Fedora / CentOS Stream / RHEL
+sudo dnf -y install podman
+
+# Debian
+sudo apt-get -y install podman
+
+# Ubuntu
+sudo apt-get update
+sudo apt-get -y install podman
+
+# Arch / Manjaro
+sudo pacman -S podman
+
+# Alpine
+sudo apk add podman
+
+# openSUSE
+sudo zypper install podman
+```
+
+On macOS and Windows, Podman runs containers inside a managed Linux VM. Initialize and start the machine (https://podman.io/docs/installation):
+
+```bash
+podman machine init
+podman machine start
+podman info
+```
+
+## Core concepts
+- **Daemonless architecture**: each `podman` command is a short-lived process; there is no central root daemon mediating requests.
+- **Rootless containers**: containers can run under an unprivileged user via user namespaces, reducing the blast radius of a container escape.
+- **Pods**: Podman groups one or more containers that share namespaces (e.g. network) into a pod, mirroring the Kubernetes pod concept.
+- **OCI compliance**: images and runtime conform to Open Containers Initiative standards, so images are interchangeable with other OCI tools.
+- **Docker-compatible CLI**: command syntax largely matches Docker; `alias docker=podman` works for many workflows.
+- **libpod**: the underlying library that manages pods, containers, images, and volumes.
+
+## Best practices
+- Prefer rootless mode for everyday use to limit privileges; reserve rootful mode for cases that genuinely require it (https://docs.podman.io/en/latest/markdown/podman.1.html).
+- Generate Kubernetes YAML from running pods/containers with `podman kube generate` to bridge local development and cluster deployment (https://docs.podman.io/en/latest/markdown/podman-kube-generate.1.html).
+- Use `podman generate systemd` / Quadlet to run containers as managed systemd services for reliable startup and restart (https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html).
+- Build images with the bundled Buildah-backed `podman build`, consuming standard Dockerfiles (https://docs.podman.io/en/latest/markdown/podman-build.1.html).
+
+## Common pitfalls
+- Expecting a background daemon/socket like Docker → Podman is daemonless; tools needing the Docker API require enabling the Podman socket service (https://docs.podman.io/en/latest/markdown/podman-system-service.1.html).
+- Privileged-port or low-level networking surprises in rootless mode → rootless containers have restricted capabilities and use slirp/pasta networking by default (https://docs.podman.io/en/latest/markdown/podman-network.1.html).
+- Assuming containers persist across host reboot → use systemd/Quadlet units to auto-restart them (https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html).
+
+## Examples
+```bash
+# Run a rootless container, mapping a host port
+podman run -d --name web -p 8080:80 docker.io/library/nginx:latest
+
+# Create a pod and add a container to it
+podman pod create --name app -p 8000:8000
+podman run -d --pod app docker.io/library/python:3.12 python -m http.server 8000
+
+# Export a running pod to Kubernetes YAML
+podman kube generate app -f app.yaml
+```
+
+## Further reading
+- Podman command reference: https://docs.podman.io/en/latest/Commands.html
+- Tutorials (incl. Docker-to-Podman transition): https://docs.podman.io/en/latest/Tutorials.html
+
+## Related skills
+- ../docker — the daemon-based engine Podman mirrors at the CLI level
+- ../containerd — lower-level OCI runtime used by other container stacks

package/skills/stacks/database/cassandra/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: cassandra
+description: Distributed wide-column NoSQL database for high write throughput and linear scalability; consult for partition-key data modeling with CQL.
+domain: stack
+category: database
+tags: [cassandra, nosql, wide-column, distributed, cql]
+official_sources:
+  - https://cassandra.apache.org/doc/latest/
+  - https://github.com/apache/cassandra
+verified: 2026-06-16
+---
+
+# Apache Cassandra
+
+## Overview
+Apache Cassandra is a distributed, wide-column NoSQL database designed for high write throughput, linear scalability, and no single point of failure across many nodes and data centers. Read this when modeling query-driven schemas with CQL, choosing partition keys, or tuning replication and consistency.
+
+## Official sources
+- Docs: https://cassandra.apache.org/doc/latest/
+- Repo (official, Apache Software Foundation): https://github.com/apache/cassandra
+- Download: https://cassandra.apache.org/_/download.html
+
+## Install / setup
+On Debian/Ubuntu via the official Apache APT repository (from cassandra.apache.org/_/download.html; replace `41x` with the desired series):
+
+```bash
+curl -o /etc/apt/keyrings/apache-cassandra.asc https://downloads.apache.org/cassandra/KEYS
+echo "deb [signed-by=/etc/apt/keyrings/apache-cassandra.asc] https://debian.cassandra.apache.org 41x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
+sudo apt-get update
+sudo apt-get install cassandra
+```
+
+A tarball binary is also available from the same download page.
+
+## Core concepts
+- Wide-column model: data is organized in tables with partition keys and clustering columns; query with CQL.
+- Partition key: determines which node(s) store a row's partition; the foundation of data distribution.
+- Clustering columns: define row ordering within a partition.
+- Tunable consistency: per-query consistency levels (e.g., ONE, QUORUM, ALL) trade latency vs. consistency.
+- Replication: replication factor and strategy (e.g., NetworkTopologyStrategy) control copies across racks/data centers.
+- Masterless/peer-to-peer architecture: every node is equal; there is no single point of failure.
+
+## Best practices
+- Design tables per query: denormalize and create one table per access pattern rather than normalizing.
+- Choose partition keys that spread data evenly and keep partitions bounded in size.
+- Use QUORUM reads and writes when you need strong-ish consistency; understand the consistency-level tradeoffs.
+- Avoid unbounded partitions and very wide rows; they cause hotspots and slow queries.
+- Prefer prepared statements in application code for efficiency and safety.
+
+## Common pitfalls
+- Modeling like a relational database (normalization, ad-hoc joins) → Cassandra has no joins; model by query.
+- Picking a low-cardinality partition key → uneven distribution and hotspots.
+- Allowing partitions to grow unbounded → degraded performance and node pressure.
+- Using `ALLOW FILTERING` to make arbitrary queries work → full scans; redesign the table instead.
+
+## Examples
+```sql
+CREATE TABLE messages_by_user (
+  user_id uuid,
+  created_at timestamp,
+  message_id timeuuid,
+  body text,
+  PRIMARY KEY ((user_id), created_at, message_id)
+) WITH CLUSTERING ORDER BY (created_at DESC);
+```
+
+## Further reading
+- Data modeling: https://cassandra.apache.org/doc/latest/cassandra/developing/data-modeling/index.html
+- CQL reference: https://cassandra.apache.org/doc/latest/cassandra/developing/cql/index.html
+
+## Related skills
+- ../cockroachdb — distributed SQL alternative with strong consistency
+- ../mongodb — document NoSQL alternative
+- ../dynamodb — managed key-value/wide-column alternative

package/skills/stacks/database/cockroachdb/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: cockroachdb
+description: Distributed, strongly-consistent SQL database with Postgres wire compatibility; consult for horizontally scalable, survivable SQL backends.
+domain: stack
+category: database
+tags: [cockroachdb, distributed-sql, postgres-compatible, newsql, acid]
+official_sources:
+  - https://www.cockroachlabs.com/docs/
+  - https://github.com/cockroachdb/cockroach
+verified: 2026-06-16
+---
+
+# CockroachDB
+
+## Overview
+CockroachDB is a cloud-native distributed SQL database built on a transactional, strongly-consistent key-value store; it scales horizontally and survives node, zone, and region failures while offering familiar SQL. Read this when you need a resilient, geo-distributed SQL backend that speaks the PostgreSQL wire protocol.
+
+## Official sources
+- Docs: https://www.cockroachlabs.com/docs/
+- Repo (official, Cockroach Labs; CockroachDB Software License for v24.3+): https://github.com/cockroachdb/cockroach
+- Install: https://www.cockroachlabs.com/docs/stable/install-cockroachdb
+
+## Install / setup
+On macOS via Homebrew (from the official install page; note macOS is documented as experimental, not for production):
+
+```bash
+brew install cockroachdb/tap/cockroach
+```
+
+For Linux/Windows or production deployments, download the binary from the official Releases page linked at https://www.cockroachlabs.com/docs/stable/install-cockroachdb.
+
+## Core concepts
+- Distributed SQL: data is automatically split into ranges and replicated across nodes using the Raft consensus protocol.
+- Strong consistency and serializable isolation by default for ACID transactions across the cluster.
+- PostgreSQL wire compatibility: existing Postgres drivers and many SQL features work against CockroachDB.
+- Survivability: configure replication and locality so the cluster tolerates node/zone/region failures.
+- Horizontal scaling: add nodes to increase capacity and throughput without manual sharding.
+- Multi-region features: regional and global tables to control data placement and latency.
+
+## Best practices
+- Choose primary keys that distribute writes (avoid sequential keys that create hotspots); consider hash-sharded indexes for sequential patterns.
+- Run at least three nodes so Raft can tolerate a node failure; set replication factor accordingly.
+- Use the multi-region abstractions (table localities, region survival goals) instead of hand-rolling placement.
+- Retry transactions on serialization errors (40001) — required under serializable isolation.
+- Test against a local cluster that mirrors production replication, not a single insecure node.
+
+## Common pitfalls
+- Using monotonically increasing primary keys → write hotspots on a single range; use UUIDs or hash-sharded indexes.
+- Not handling transaction retry errors → serializable isolation can abort transactions that must be retried.
+- Treating macOS Homebrew installs as production-ready → documented as experimental; use Linux binaries/containers in production.
+- Assuming full Postgres feature parity → most features map, but verify unsupported/different behaviors in the docs.
+
+## Examples
+```sql
+CREATE TABLE events (
+  id UUID NOT NULL DEFAULT gen_random_uuid() PRIMARY KEY,
+  user_id UUID NOT NULL,
+  payload JSONB NOT NULL,
+  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
+);
+```
+
+## Further reading
+- Performance best practices: https://www.cockroachlabs.com/docs/stable/performance-best-practices-overview
+- Transactions & retries: https://www.cockroachlabs.com/docs/stable/transactions
+
+## Related skills
+- ../postgresql — wire-compatible single-node relational database
+- ../cassandra — distributed wide-column alternative (different consistency model)

package/skills/stacks/database/dynamodb/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: dynamodb
+description: AWS fully managed serverless key-value and document NoSQL database; consult for single-digit-ms scale, key design, and access-pattern modeling.
+domain: stack
+category: database
+tags: [dynamodb, aws, nosql, key-value, serverless]
+official_sources:
+  - https://docs.aws.amazon.com/dynamodb/
+  - https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html
+verified: 2026-06-16
+---
+
+# Amazon DynamoDB
+
+## Overview
+Amazon DynamoDB is a serverless, fully managed, distributed NoSQL database offering single-digit-millisecond performance at any scale, supporting both key-value and document models. Read this when designing tables, primary keys, and secondary indexes around access patterns for a managed AWS NoSQL backend.
+
+## Official sources
+- Docs: https://docs.aws.amazon.com/dynamodb/
+- Local development (DynamoDB Local): https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html
+
+> Note: DynamoDB is a managed AWS service with no public source repository. There is no open-source server to clone; cite the AWS documentation as the authoritative source.
+
+## Core concepts
+- Tables, items, and attributes: a table holds items (rows); each item is a set of attributes.
+- Primary key: either a partition key alone, or a composite of partition key + sort key.
+- Partition key: hashed to distribute items across storage partitions; central to performance.
+- Sort key: orders items within a partition and enables range queries.
+- Secondary indexes: Global Secondary Indexes (GSI) and Local Secondary Indexes (LSI) enable queries on alternate keys.
+- Capacity modes: on-demand (pay-per-request, auto-scaling, scale to zero) vs. provisioned (set RCU/WCU).
+- No JOINs: DynamoDB has no join operator; denormalize and model around queries.
+
+## Best practices
+- Model around access patterns first; design keys and indexes to serve known queries (often single-table design).
+- Choose high-cardinality partition keys that spread traffic evenly to avoid hot partitions.
+- Use `Query` (which targets a partition key) rather than `Scan` (which reads the whole table) for efficiency.
+- Use on-demand capacity for unpredictable traffic; provisioned with auto-scaling for steady, cost-sensitive workloads.
+- Use DynamoDB Streams to react to item-level changes for event-driven architectures.
+
+## Common pitfalls
+- Designing the schema before the access patterns → leads to costly Scans and missing indexes; model queries first.
+- Using a low-cardinality partition key → hot partitions and throttling.
+- Relying on `Scan` for routine reads → expensive and slow; prefer `Query` with proper keys/indexes.
+- Expecting relational features (joins, ad-hoc queries) → denormalize and precompute instead.
+
+## Examples
+```bash
+# Run DynamoDB Local for development (Docker image)
+docker run -p 8000:8000 amazon/dynamodb-local
+
+# Point the AWS CLI at the local endpoint
+aws dynamodb list-tables --endpoint-url http://localhost:8000
+```
+
+## Further reading
+- Core components: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html
+- Best practices: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html
+
+## Related skills
+- ../mongodb — document NoSQL alternative (self-hostable)
+- ../cassandra — wide-column NoSQL alternative
+- ../redis — in-memory store for caching alongside DynamoDB

package/skills/stacks/database/mariadb/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: mariadb
+description: Community-developed open-source fork of MySQL with extra storage engines and features; consult for MySQL-compatible relational backends.
+domain: stack
+category: database
+tags: [mariadb, sql, rdbms, relational, mysql-fork]
+official_sources:
+  - https://mariadb.com/docs/
+  - https://github.com/MariaDB/server
+verified: 2026-06-16
+---
+
+# MariaDB
+
+## Overview
+MariaDB is a community-developed fork of MySQL started by core members of the original MySQL team, designed as a drop-in replacement with additional storage engines, features, and a permissive license. Read this when you want a MySQL-compatible relational database with the MariaDB ecosystem (e.g., Galera clustering, additional engines).
+
+## Official sources
+- Docs: https://mariadb.com/docs/
+- Repo (official, MariaDB Foundation/Corporation): https://github.com/MariaDB/server
+- Download: https://mariadb.org/download/
+
+## Install / setup
+MariaDB ships in the standard repositories of major Linux distributions as the `mariadb-server` package. On Ubuntu/Debian (from the official quickstart install guide):
+
+```bash
+sudo apt update
+sudo apt install mariadb-server mariadb-client galera-4
+sudo mariadb-secure-installation
+```
+
+For specific MariaDB versions, the MariaDB download page (mariadb.org/download/) generates tailored repository setup instructions per OS/architecture.
+
+## Core concepts
+- MySQL compatibility: largely a drop-in replacement; the `mysql`/`mariadb` client and wire protocol are compatible.
+- Pluggable storage engines: InnoDB by default, plus MariaDB-specific engines (Aria, ColumnStore, etc.).
+- Galera Cluster: synchronous multi-source replication for high availability (the `galera-4` package).
+- Indexes, transactions, and ACID semantics under InnoDB, as in MySQL.
+- `mariadb-secure-installation` to harden a new server.
+- Character sets/collations: use `utf8mb4` for full Unicode.
+
+## Best practices
+- Use InnoDB for transactional, crash-safe workloads (the default engine).
+- Use `utf8mb4` rather than legacy `utf8` for full Unicode support.
+- Run `mariadb-secure-installation` after install to remove anonymous users and test databases.
+- For high availability, evaluate Galera Cluster rather than rolling your own replication.
+- Verify query plans with `EXPLAIN` and index columns used in joins and filters.
+
+## Common pitfalls
+- Assuming 100% feature parity with the latest MySQL → divergence has grown; check the MariaDB docs for version-specific syntax and functions.
+- Using legacy `utf8` and hitting 4-byte character errors → use `utf8mb4`.
+- Mixing MariaDB and MySQL client/server versions and assuming identical behavior → confirm compatibility for your versions.
+- Skipping `mariadb-secure-installation` on a fresh server → insecure defaults remain.
+
+## Examples
+```sql
+CREATE TABLE orders (
+  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
+  customer_email VARCHAR(255) NOT NULL,
+  total_cents INT NOT NULL,
+  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
+```
+
+## Further reading
+- MariaDB quickstart guides: https://mariadb.com/docs/server/mariadb-quickstart-guides/
+- Downloads & repository setup: https://mariadb.org/download/
+
+## Related skills
+- ../mysql — the upstream project MariaDB forked from
+- ../postgresql — alternative open-source RDBMS

package/skills/stacks/database/mongodb/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: mongodb
+description: Document database storing flexible JSON-like (BSON) documents; consult for schema design, indexing, aggregation, and NoSQL data modeling.
+domain: stack
+category: database
+tags: [mongodb, nosql, document, bson, database]
+official_sources:
+  - https://www.mongodb.com/docs/
+  - https://github.com/mongodb/mongo
+verified: 2026-06-16
+---
+
+# MongoDB
+
+## Overview
+MongoDB is a document-oriented NoSQL database that stores flexible, JSON-like documents (BSON) in collections, well suited for evolving schemas and nested data. Read this when modeling document data, designing indexes, writing queries/aggregations, or choosing between embedding and referencing.
+
+## Official sources
+- Docs: https://www.mongodb.com/docs/
+- Repo (official; SSPL v1 license for releases after 2018-10-16): https://github.com/mongodb/mongo
+- Download (Community Server): https://www.mongodb.com/try/download/community
+
+## Install / setup
+Download MongoDB Community Server from mongodb.com/try/download/community for your platform (Ubuntu, Debian, RedHat/CentOS, SUSE, Amazon Linux, macOS, Windows). MongoDB Atlas is the managed cloud alternative; its quick setup uses Homebrew:
+
+```bash
+brew install mongodb-atlas
+atlas setup
+```
+
+For self-hosted Community Server, follow the platform-specific install guide at https://www.mongodb.com/docs/manual/administration/install-community/.
+
+## Core concepts
+- Documents and collections: documents (BSON) are grouped into collections; no fixed schema is required.
+- Flexible schema: fields can vary between documents in the same collection.
+- Indexes: single-field, compound, multikey (arrays), text, and others; needed for query performance.
+- Aggregation pipeline: stages (`$match`, `$group`, `$lookup`, etc.) transform and compute over documents.
+- Embedding vs referencing: model related data inline (embed) or via references depending on access patterns.
+- Replica sets and sharding: replica sets provide HA; sharding partitions data horizontally across shards.
+
+## Best practices
+- Model schema around your application's query patterns; embed data that is read together, reference data that grows unboundedly.
+- Create indexes that support your queries and sorts; confirm usage with `explain()`.
+- Use the aggregation pipeline for server-side data transformation instead of pulling and processing in the app.
+- Prefer a replica set (even of one for dev parity) so transactions and failover behave as in production.
+- Use schema validation rules when you need to enforce document shape.
+
+## Common pitfalls
+- Treating MongoDB like a relational DB with many `$lookup` joins → reconsider the data model; embed where appropriate.
+- Letting documents grow without bound (e.g., ever-growing arrays) → can exceed the 16 MB document limit; use references/bucketing.
+- Forgetting indexes on filtered/sorted fields → full collection scans.
+- Assuming multi-document atomicity without transactions → use transactions (requires a replica set) when you need them.
+
+## Examples
+```javascript
+db.users.insertOne({
+  email: "a@example.com",
+  profile: { name: "Ada", roles: ["admin"] },
+  createdAt: new Date()
+});
+
+db.users.createIndex({ email: 1 }, { unique: true });
+```
+
+## Further reading
+- Data modeling: https://www.mongodb.com/docs/manual/data-modeling/
+- Aggregation: https://www.mongodb.com/docs/manual/aggregation/
+
+## Related skills
+- ../dynamodb — managed key-value/document NoSQL alternative
+- ../redis — in-memory store for caching and ephemeral data

package/skills/stacks/database/mysql/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: mysql
+description: Popular open-source relational database from Oracle; consult for schema design, SQL, storage engines (InnoDB), and replication.
+domain: stack
+category: database
+tags: [mysql, sql, rdbms, relational, innodb]
+official_sources:
+  - https://dev.mysql.com/doc/
+  - https://github.com/mysql/mysql-server
+verified: 2026-06-16
+---
+
+# MySQL
+
+## Overview
+MySQL is a widely deployed open-source relational database maintained by Oracle, known for speed, reliability, and broad ecosystem support. Read this when building on a MySQL backend: designing tables, choosing storage engines, writing SQL, or configuring replication.
+
+## Official sources
+- Docs: https://dev.mysql.com/doc/
+- Repo (official, Oracle): https://github.com/mysql/mysql-server
+- Install / download: https://dev.mysql.com/downloads/
+
+## Install / setup
+On Debian/Ubuntu, MySQL provides the APT Repository (mysql-apt-config) from dev.mysql.com/downloads/. The Community Server, MySQL Shell, MySQL Router, and Workbench are listed there. On macOS the recommended path is via the MySQL Installer / DMG, and on Windows via the MySQL Installer for Windows.
+
+```bash
+# After installing the APT repo config package from dev.mysql.com/downloads/repo/apt/
+sudo apt update
+sudo apt install mysql-server
+```
+
+(Follow the exact repo-config steps on the official APT Repository download page for your distribution.)
+
+## Core concepts
+- Relational model with ACID transactions when using a transactional storage engine.
+- Storage engines: InnoDB (default, transactional, row-level locking, foreign keys) vs MyISAM (non-transactional, table locks).
+- Indexes: B-tree by default; covering, composite, and full-text indexes available.
+- Replication: source/replica (formerly master/slave) for read scaling and availability.
+- Character sets and collations: use `utf8mb4` for full Unicode (including emoji).
+- The `mysql` client and MySQL Shell for administration and scripting.
+
+## Best practices
+- Use the InnoDB storage engine for transactional integrity and crash recovery (it's the default).
+- Use `utf8mb4` character set rather than the legacy `utf8` (which is limited to 3-byte sequences).
+- Add appropriate indexes and verify with `EXPLAIN`; avoid functions on indexed columns in WHERE clauses.
+- Define explicit foreign keys and constraints under InnoDB to enforce referential integrity.
+- Run `mysql_secure_installation` to harden a fresh server.
+
+## Common pitfalls
+- Choosing `utf8` and later hitting 4-byte character failures → use `utf8mb4` from the start.
+- Relying on MyISAM for data that needs transactions or crash safety → use InnoDB.
+- Wrapping indexed columns in functions (e.g., `WHERE DATE(col) = ...`) → prevents index use.
+- Assuming default isolation; MySQL/InnoDB defaults to REPEATABLE READ → know the level your app needs.
+
+## Examples
+```sql
+CREATE TABLE users (
+  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
+  email VARCHAR(255) NOT NULL,
+  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
+  UNIQUE KEY uq_email (email)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
+```
+
+## Further reading
+- The InnoDB storage engine: https://dev.mysql.com/doc/refman/en/innodb-storage-engine.html
+- Optimization: https://dev.mysql.com/doc/refman/en/optimization.html
+
+## Related skills
+- ../mariadb — community-driven MySQL fork
+- ../planetscale — managed MySQL-compatible (Vitess) platform
+- ../postgresql — alternative open-source RDBMS

package/skills/stacks/database/neon/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: neon
+description: Open-source serverless Postgres that separates storage and compute with autoscaling, scale-to-zero, and database branching; consult for serverless Postgres.
+domain: stack
+category: database
+tags: [neon, postgres, serverless, branching, autoscaling]
+official_sources:
+  - https://neon.com/docs
+  - https://github.com/neondatabase/neon
+verified: 2026-06-16
+---
+
+# Neon
+
+## Overview
+Neon is an open-source serverless Postgres platform that separates storage and compute, enabling autoscaling, scale-to-zero, and Git-like database branching. Read this when you want managed PostgreSQL with per-developer/per-preview branches and pay-for-what-you-use compute.
+
+## Official sources
+- Docs: https://neon.com/docs
+- Repo (official): https://github.com/neondatabase/neon
+- Get started / sign up: https://neon.com/docs/get-started-with-neon/signing-up
+
+## Install / setup
+Neon is a managed serverless platform — there is no local server to install for normal use. Get started by signing up at console.neon.tech (email, GitHub, Google, or partner accounts), which provisions a Project with a default production branch. The Neon CLI manages projects and branches from the terminal; install it per the docs:
+
+```bash
+npm install -g neonctl
+```
+
+(See https://neon.com/docs/reference/neon-cli for the authoritative install instructions.)
+
+## Core concepts
+- Project: the top-level container holding branches, databases, and roles.
+- Storage/compute separation: a custom storage layer (Pageserver + Safekeepers for WAL) backs stateless Postgres compute nodes.
+- Branching: create instant, copy-on-write branches of your database for dev, testing, and previews.
+- Autoscaling and scale-to-zero: compute scales with load and can suspend when idle to save cost.
+- Standard Postgres: it is real PostgreSQL, so SQL, drivers, and most extensions work unchanged.
+- Roles and databases live within a branch; resetting a branch to its parent is a core workflow.
+
+## Best practices
+- Use database branches for each feature/PR/preview environment instead of sharing one database.
+- Account for cold starts when compute has scaled to zero in latency-sensitive paths; keep a minimum compute if needed.
+- Use connection pooling (Neon provides a pooled connection string) for serverless/edge clients that open many short connections.
+- Treat it as standard Postgres: apply normal schema design, indexing, and migration practices.
+- Keep the production branch protected and develop on child branches.
+
+## Common pitfalls
+- Ignoring cold-start latency after scale-to-zero → first query on a suspended compute is slower; configure accordingly.
+- Opening many direct (non-pooled) connections from serverless functions → exhausts connections; use the pooled endpoint.
+- Assuming branches are fully isolated forever → they share a parent point-in-time; understand copy-on-write semantics.
+- Forgetting it is plain Postgres and reaching for bespoke tooling → standard Postgres practices apply.
+
+## Examples
+```bash
+# Create a branch for a feature using the Neon CLI
+neonctl branches create --name feature-x
+
+# Get its connection string
+neonctl connection-string feature-x
+```
+
+## Further reading
+- Branching: https://neon.com/docs/introduction/branching
+- Connection pooling: https://neon.com/docs/connect/connection-pooling
+
+## Related skills
+- ../postgresql — the database engine Neon runs
+- ../supabase — Postgres-based backend platform with auth/storage/realtime

package/skills/stacks/database/planetscale/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: planetscale
+description: Managed database platform offering Vitess (MySQL-compatible) and Postgres clusters with branching and non-blocking schema changes; consult for scalable managed SQL.
+domain: stack
+category: database
+tags: [planetscale, vitess, mysql, postgres, managed]
+official_sources:
+  - https://planetscale.com/docs
+  - https://github.com/planetscale/cli
+verified: 2026-06-16
+---
+
+# PlanetScale
+
+## Overview
+PlanetScale is a managed database platform that offers fully managed Vitess (MySQL-compatible, horizontally shardable) clusters and PostgreSQL clusters on locally-attached NVMe storage, with developer features like database branching, deploy requests, and non-blocking schema changes. Read this when you want managed, scalable SQL with a branch-and-merge schema workflow.
+
+## Official sources
+- Docs: https://planetscale.com/docs
+- CLI repo (official): https://github.com/planetscale/cli
+- Org: https://github.com/planetscale
+
+> Note: PlanetScale is a managed cloud platform; there is no single open-source server repo to self-host the product. The `pscale` CLI is open source. As of verification, PlanetScale offers both Vitess and PostgreSQL clusters — check the docs for current engine support.
+
+## Install / setup
+Install the `pscale` CLI via Homebrew (from the official CLI repo README):
+
+```bash
+brew install planetscale/tap/pscale
+```
+
+Some `pscale` commands require a MySQL 8 client in your PATH. See the docs for environment setup.
+
+## Core concepts
+- Managed clusters: Vitess (MySQL-compatible, supports horizontal sharding) and PostgreSQL options.
+- Database branching: create isolated branches of your schema, like Git branches for the database.
+- Deploy requests: review and merge schema changes from a branch to production safely.
+- Non-blocking schema changes: schema migrations apply without locking tables/downtime.
+- High availability: deployments across availability zones with a primary and replicas, with automated failover.
+- Query insights: built-in observability for query performance.
+
+## Best practices
+- Use branches plus deploy requests to review schema changes rather than altering production directly.
+- For Vitess/MySQL, design with the sharding model in mind (Vitess does not support cross-shard foreign keys the way single-node MySQL does).
+- Use the `pscale` CLI and connection strings rather than embedding raw credentials.
+- Verify which engine (Vitess vs Postgres) your project uses, since features and SQL behavior differ.
+- Lean on non-blocking schema changes for online migrations instead of manual lock-heavy ALTERs.
+
+## Common pitfalls
+- Assuming full single-node MySQL semantics on a Vitess cluster → foreign keys and some cross-shard operations differ; check docs.
+- Editing production schema directly instead of via deploy requests → bypasses review/safety.
+- Hardcoding credentials rather than using the CLI/connection management → security and rotation issues.
+- Treating the platform as static → the product is evolving; re-verify engine/feature support against the docs.
+
+## Examples
+```bash
+# Authenticate and create a development branch
+pscale auth login
+pscale branch create my-db dev
+# Connect locally through a secure proxy
+pscale connect my-db dev
+```
+
+## Further reading
+- Environment setup: https://planetscale.com/docs/reference/planetscale-environment-setup
+- Branching: https://planetscale.com/docs
+
+## Related skills
+- ../mysql — the engine family PlanetScale's Vitess clusters are compatible with
+- ../postgresql — the engine behind PlanetScale's Postgres clusters