constellai 0.3.0

package/skills/stacks/auth/lucia/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: lucia
+description: Lucia is now a learning resource for implementing auth from scratch in JS/TS, NOT a maintained library — consult to learn session-based auth patterns.
+domain: stack
+category: auth
+tags: [auth, sessions, learning-resource, typescript, deprecated-library, from-scratch]
+official_sources:
+  - https://lucia-auth.com/
+  - https://github.com/lucia-auth/lucia
+verified: 2026-06-16
+---
+
+# Lucia
+
+## Overview
+Important: Lucia is no longer a maintained authentication library. Per the official repo, "Lucia v3 will be deprecated by March 2025. Lucia is now a learning resource on implementing auth from scratch." Treat `lucia-auth.com` as an open-source guide that teaches you to implement session-based authentication in JavaScript/TypeScript yourself, copying the code into your project rather than installing a package. Read this when you want to understand and own your auth implementation.
+
+## Official sources
+- Docs: https://lucia-auth.com/
+- Repo: https://github.com/lucia-auth/lucia
+
+## Core concepts
+- Learning resource, not a dependency: the project provides resources on implementing auth; you write/own the session code rather than depend on a maintained library.
+- Sessions: the guide centers on server-side session tokens and validating them on each request, instead of relying on opaque library magic.
+- Session token hashing & storage: sessions are stored in your database; the guide teaches hashing tokens and validating/expiring them yourself.
+- Database ownership: you define your own user and session tables/schema — there is no enforced schema from a package.
+- Deprecated v3 library: the old `lucia` package source remains in the `v3` branch for reference, but it is deprecated and should not be treated as actively maintained.
+
+## Best practices
+- Treat Lucia as documentation to copy and adapt, not an `npm install` dependency — that is the project's stated direction (https://github.com/lucia-auth/lucia).
+- Store sessions server-side and validate the session token on every request, following the guide's patterns.
+- Hash session tokens before storing them and enforce expiration, as the guide teaches.
+
+## Common pitfalls
+- Adding the deprecated `lucia` v3 package to a new production project → it is deprecated; follow the from-scratch guide or choose a maintained library instead.
+- Expecting ongoing maintenance, releases, or security patches → the library is no longer maintained; only the learning content is current.
+
+## Examples
+```ts
+// Conceptual: validate a session token (pattern from the Lucia guide).
+// You implement and own this code — there is no library to import.
+async function validateSession(token: string) {
+  const sessionId = hash(token)             // hash before lookup
+  const session = await db.getSession(sessionId)
+  if (!session || session.expiresAt < new Date()) return null
+  return session
+}
+```
+
+## Further reading
+- https://lucia-auth.com/ — the learning resource (implementation guides)
+- https://github.com/lucia-auth/lucia — repo with the deprecation notice and `v3` reference branch
+
+## Related skills
+- ../authjs — maintained, framework-agnostic auth library for JS/TS
+- ../supabase-auth — managed auth if you prefer not to implement sessions yourself

package/skills/stacks/auth/passport/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: passport
+description: Passport — Express-compatible authentication middleware for Node.js using pluggable strategies; consult when adding login to an Express/Node app.
+domain: stack
+category: auth
+tags: [auth, nodejs, express, middleware, strategies, sessions, oauth]
+official_sources:
+  - https://www.passportjs.org/docs/
+  - https://github.com/jaredhanson/passport
+verified: 2026-06-16
+---
+
+# Passport
+
+## Overview
+Passport is Express-compatible authentication middleware for Node.js, designed for the singular purpose of authenticating requests. It works through an extensible plugin system of "strategies" (local username/password, OAuth, OpenID, etc.) and does not mount routes or impose a database schema, leaving you in control. Read this when adding authentication to an Express or Node.js app.
+
+## Official sources
+- Docs: https://www.passportjs.org/docs/
+- Repo: https://github.com/jaredhanson/passport
+
+## Install / setup
+```bash
+npm install passport
+```
+(Verbatim from the official repo README. Each authentication method needs its own strategy package, e.g. `npm install passport-local`.)
+
+## Core concepts
+- Middleware: Passport is authentication middleware you plug into the Express request pipeline; it authenticates the incoming request.
+- Strategies: pluggable mechanisms (e.g. `passport-local`, OAuth strategies) implement a specific way to authenticate; install one per method.
+- `passport.authenticate()`: the middleware that runs a named strategy on a route to verify credentials.
+- Sessions: Passport can establish a persistent login session, storing a minimal user reference in the session.
+- `serializeUser` / `deserializeUser`: control what user data is stored in the session and how it is restored on later requests.
+- `req.user`: once authenticated, Passport populates the authenticated user on the request object.
+
+## Best practices
+- Install and configure one strategy per authentication method (e.g. `passport-local` for username/password); the core package alone authenticates nothing.
+- Keep `serializeUser` payloads minimal (typically just an ID) and reload the full user in `deserializeUser`.
+- Place `passport.initialize()` (and `passport.session()` when using sessions) in the correct middleware order before protected routes.
+- Pair session-based logins with a secure session store and configured cookies; Passport does not manage session storage for you.
+
+## Common pitfalls
+- Expecting login to work with only `passport` installed → you must also install and register a strategy package.
+- Wrong middleware ordering → `passport.session()` before the session middleware, or routes before `passport.initialize()`, leaves `req.user` undefined.
+- Assuming Passport provides routes or a schema → it intentionally does not; you define routes, user storage, and verification logic yourself.
+
+## Examples
+```js
+const passport = require("passport")
+const LocalStrategy = require("passport-local")
+
+passport.use(new LocalStrategy(async (username, password, done) => {
+  const user = await findUser(username)
+  if (!user || !(await verify(user, password))) return done(null, false)
+  return done(null, user)
+}))
+
+passport.serializeUser((user, done) => done(null, user.id))
+passport.deserializeUser(async (id, done) => done(null, await getUser(id)))
+
+app.post("/login", passport.authenticate("local", { successRedirect: "/", failureRedirect: "/login" }))
+```
+
+## Further reading
+- https://www.passportjs.org/concepts/authentication/strategies/ — strategies
+- https://www.passportjs.org/packages/ — strategy package catalog
+
+## Related skills
+- ../authjs — higher-level, framework-agnostic JS/TS auth library
+- ../auth0 — hosted IdP you can integrate via a Passport strategy

package/skills/stacks/auth/supabase-auth/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: supabase-auth
+description: Supabase Auth — managed user authentication (password, magic link, OTP, social, SSO) that integrates with Postgres Row Level Security.
+domain: stack
+category: auth
+tags: [auth, supabase, postgres, rls, oauth, jwt, sso, magic-link]
+official_sources:
+  - https://supabase.com/docs/guides/auth
+  - https://github.com/supabase/auth
+verified: 2026-06-16
+---
+
+# Supabase Auth
+
+## Overview
+Supabase Auth makes it easy to add authentication and authorization to an app via client SDKs and API endpoints for creating and managing users. It supports password, magic link, one-time password (OTP), social login, and single sign-on (SSO), and integrates tightly with the Supabase Postgres database so the auth token can drive Row Level Security. Read this when your app already uses Supabase or you want auth coupled to Postgres RLS.
+
+## Official sources
+- Docs: https://supabase.com/docs/guides/auth
+- Repo: https://github.com/supabase/auth
+
+## Install / setup
+```bash
+npm install @supabase/supabase-js
+```
+(The `@supabase/supabase-js` client provides the `auth` namespace; see https://supabase.com/docs/guides/auth. The server in github.com/supabase/auth is a Go service, originally based on Netlify's GoTrue, that Supabase runs for you.)
+
+## Core concepts
+- Auth methods: password, magic link, OTP, social login (OAuth2/OIDC providers), phone auth, and SSO are all supported.
+- JWT access token: on sign-in, Auth issues a JWT representing the user; SDK calls send it to scope access.
+- Row Level Security (RLS): the auth token scopes database access row-by-row when RLS policies are enabled — this is how authorization is enforced.
+- Users vs. sessions: Auth manages user records and sessions; `auth.users` lives in the database and is referenced by your tables.
+- GoTrue server: the underlying server (github.com/supabase/auth) issues JWTs, handles sign-in, and manages users; it diverged from Netlify's GoTrue.
+- External providers: sign in with Google, Apple, Facebook, Discord, and other OAuth providers configured per project.
+
+## Best practices
+- Enable Row Level Security on every table holding user data and write policies against the auth token — RLS is the documented authorization mechanism (https://supabase.com/docs/guides/auth).
+- Use the client SDK's `auth` methods rather than calling endpoints manually, so tokens and refresh are handled for you.
+- Never expose the service-role key to the client; use the anon key client-side and the service-role key only on trusted servers.
+- Configure redirect URLs / allowed origins for OAuth and magic-link flows to prevent broken or hijacked redirects.
+
+## Common pitfalls
+- Leaving RLS disabled → any client with the anon key can read/write all rows; enable RLS and add policies.
+- Using the service-role key in browser code → it bypasses RLS entirely; keep it server-side only.
+- Assuming a user is authorized just because they're authenticated → authentication (who they are) is separate from RLS-based authorization (what they can touch).
+
+## Examples
+```ts
+import { createClient } from "@supabase/supabase-js"
+
+const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY)
+
+// Magic link sign-in
+await supabase.auth.signInWithOtp({ email: "user@example.com" })
+
+// OAuth sign-in
+await supabase.auth.signInWithOAuth({ provider: "github" })
+```
+
+## Further reading
+- https://supabase.com/docs/guides/auth/row-level-security — RLS with Auth
+- https://supabase.com/docs/guides/auth/social-login — social providers
+
+## Related skills
+- ../authjs — framework-agnostic JS/TS auth (can also use external providers)
+- ../keycloak — self-hostable OIDC server you could federate as an SSO provider

package/skills/stacks/baas/amplify/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: amplify
+description: AWS Amplify (Gen 2) is a TypeScript-first fullstack platform for building and hosting cloud backends on AWS (Auth via Cognito, data/GraphQL via AppSync+DynamoDB, Functions via Lambda, Storage via S3). Consult when scaffolding an Amplify backend, defining code-first cloud resources, running the sandbox, wiring auth/data/storage into a React/Next app, or deploying via Amplify Hosting.
+domain: stack
+category: baas
+tags: [amplify, aws, baas, typescript, cognito, appsync, fullstack]
+official_sources:
+  - https://docs.amplify.aws/
+  - https://github.com/aws-amplify/amplify-backend
+  - https://www.npmjs.com/package/create-amplify
+verified: 2026-06-17
+---
+
+# AWS Amplify
+
+## Overview
+AWS Amplify Gen 2 is a fullstack development platform that lets you define cloud backends in TypeScript and deploy them on AWS managed services — Cognito for auth, AppSync + DynamoDB for data, Lambda for functions, and S3 for storage. The code-first model generates infrastructure (CDK under the hood) and a typed client so frontend and backend ship together. Read this when scaffolding an Amplify backend, running the cloud sandbox, or integrating auth/data/storage into a web app deployed on Amplify Hosting.
+
+## Official sources
+- Docs: https://docs.amplify.aws/
+- Repo: https://github.com/aws-amplify/amplify-backend
+- Install: https://www.npmjs.com/package/create-amplify
+
+## Install / setup
+```bash
+npm create amplify@latest
+npx ampx sandbox
+```
+Source: https://docs.amplify.aws/react/start/manual-installation/
+
+## Core concepts
+- **Backend definition** — `amplify/backend.ts` composes resources via `defineBackend({ auth, data, storage })` in TypeScript.
+- **Auth** — `defineAuth` provisions Amazon Cognito user pools (email/social/MFA) with typed access rules.
+- **Data** — `defineData` builds an AppSync GraphQL API over DynamoDB from a typed schema with per-model authorization.
+- **Functions** — `defineFunction` creates Lambda handlers triggered by data events, schedules, or auth flows.
+- **Storage** — `defineStorage` provisions an S3 bucket with path-based access rules.
+- **Sandbox** — `ampx sandbox` deploys an isolated per-developer cloud environment that hot-reloads on file changes.
+- **amplify_outputs.json** — generated config consumed by `Amplify.configure()` to wire the frontend client.
+
+## Best practices
+- Use per-developer cloud sandboxes for iteration, not a shared environment (https://docs.amplify.aws/react/deploy-and-host/sandbox-environments/).
+- Define authorization rules in the data schema (`a.allow.*`) rather than in client code (https://docs.amplify.aws/react/build-a-backend/data/customize-authz/).
+- Connect a Git branch to Amplify Hosting for fullstack CI/CD deploys per commit (https://docs.amplify.aws/react/deploy-and-host/fullstack-branching/).
+- Generate a typed data client with `generateClient<Schema>()` for end-to-end type safety (https://docs.amplify.aws/react/build-a-backend/data/connect-to-API/).
+
+## Common pitfalls
+- Confusing Gen 1 (CLI `amplify ...`) with Gen 2 (`ampx`/`create-amplify`) docs → follow Gen 2 only for new projects.
+- Missing/expired AWS credentials or profile → sandbox deploy fails; configure an AWS profile first.
+- Committing `amplify_outputs.json` from a teammate's sandbox → wrong endpoints; regenerate locally.
+
+## Examples
+```typescript
+// amplify/data/resource.ts
+import { a, defineData, type ClientSchema } from "@aws-amplify/backend";
+
+const schema = a.schema({
+  Todo: a.model({ content: a.string() }).authorization(allow => [allow.owner()]),
+});
+
+export type Schema = ClientSchema<typeof schema>;
+export const data = defineData({ schema });
+```
+
+## Further reading
+- https://docs.amplify.aws/react/start/ — React getting-started guide
+- https://docs.amplify.aws/react/build-a-backend/ — building auth/data/storage/functions
+- https://aws-amplify.github.io/amplify-backend/ — Amplify Toolbox / ampx reference
+
+## Related skills
+- ../firebase — comparable Google BaaS with auth/data/functions
+- ../appwrite — open-source self-hosted BaaS alternative

package/skills/stacks/baas/appwrite/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: appwrite
+description: Appwrite is an open-source, self-hostable Backend-as-a-Service (Auth, Databases, Storage, Functions, Messaging, Realtime, Hosting) deployable via Docker. Consult when self-hosting a backend, adding authentication, building a document database, running serverless functions, handling file storage, or using the Appwrite CLI and client SDKs for web/mobile/Flutter apps.
+domain: stack
+category: baas
+tags: [appwrite, baas, self-hosted, docker, open-source, auth, serverless]
+official_sources:
+  - https://appwrite.io/docs
+  - https://github.com/appwrite/appwrite
+  - https://github.com/appwrite/sdk-for-cli
+verified: 2026-06-17
+---
+
+# Appwrite
+
+## Overview
+Appwrite is an open-source Backend-as-a-Service that packages authentication, a document database, file storage, serverless Functions, Messaging, and Realtime behind REST/GraphQL APIs and client SDKs. It runs as a set of Docker containers you self-host (or use Appwrite Cloud), giving you a Firebase-style backend you fully control. Read this when self-hosting a backend, wiring up auth/databases/storage/functions, or scripting deployments with the Appwrite CLI.
+
+## Official sources
+- Docs: https://appwrite.io/docs
+- Repo: https://github.com/appwrite/appwrite
+- Install: https://github.com/appwrite/sdk-for-cli
+
+## Install / setup
+```bash
+docker run -it --rm \
+    --publish 20080:20080 \
+    --volume /var/run/docker.sock:/var/run/docker.sock \
+    --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \
+    --entrypoint="install" \
+    appwrite/appwrite:1.9.0
+```
+Source: https://appwrite.io/docs/advanced/self-hosting/installation (CLI: `npm install -g appwrite-cli`)
+
+## Core concepts
+- **Project** — isolated namespace holding databases, users, functions, and API keys; created in the Console.
+- **Databases / Collections / Documents** — structured document store with typed attributes, indexes, and per-document permissions.
+- **Authentication** — sessions and accounts supporting email/password, OAuth2, magic URL, phone, anonymous, and JWT.
+- **Permissions** — role/user-scoped access (`read`, `create`, `update`, `delete`) set on collections or individual documents.
+- **Functions** — serverless code in many runtimes, triggered by HTTP, events, or schedules; deployed via CLI.
+- **Storage** — file buckets with encryption, antivirus scanning, and on-the-fly image transforms.
+- **Realtime** — WebSocket subscriptions to channels for live document, file, and account updates.
+
+## Best practices
+- Set collection/document permissions explicitly; default is no access until granted (https://appwrite.io/docs/advanced/platform/permissions).
+- Use server SDKs with API keys for trusted backends and the lighter client SDKs in apps (https://appwrite.io/docs/sdks).
+- Pin a specific Appwrite version tag and follow the updates/migrations guide between minors — install the new version, then run the Appwrite migration tool (https://appwrite.io/docs/advanced/self-hosting/production/updates).
+- Configure `_APP_DOMAIN` and TLS/Traefik for production rather than localhost defaults (https://appwrite.io/docs/advanced/self-hosting).
+
+## Common pitfalls
+- Leaving the default `.env` secrets/keys from install → insecure server; rotate `_APP_OPENSSL_KEY_V1` and API keys.
+- Exposing API keys in client-side code → use scoped client SDK + permissions, keep API keys server-only.
+- Forgetting to register a platform (web/Flutter) for your hostname → CORS blocks requests; add it in Console settings.
+
+## Examples
+```javascript
+import { Client, Databases, ID } from "appwrite";
+
+const client = new Client()
+  .setEndpoint("http://localhost/v1")
+  .setProject("YOUR_PROJECT_ID");
+
+const db = new Databases(client);
+await db.createDocument({
+  databaseId: "dbId",
+  collectionId: "messages",
+  documentId: ID.unique(),
+  data: { text: "hello" },
+});
+```
+
+## Further reading
+- https://appwrite.io/docs/advanced/self-hosting — self-hosting and production setup
+- https://appwrite.io/docs/products/databases — Databases product guide
+- https://github.com/appwrite/sdk-for-cli — official CLI and deployment tooling
+
+## Related skills
+- ../firebase — proprietary Google BaaS with comparable feature set
+- ../amplify — AWS fullstack BaaS alternative

package/skills/stacks/baas/firebase/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: firebase
+description: Firebase is Google's Backend-as-a-Service platform (Auth, Firestore, Realtime Database, Cloud Functions, Hosting, Cloud Storage, FCM). Consult when building serverless app backends, adding Google/email auth, syncing NoSQL data in real time, deploying static/SSR hosting, writing Cloud Functions, or using the Firebase CLI/emulator suite.
+domain: stack
+category: baas
+tags: [firebase, baas, google, firestore, auth, serverless, cloud-functions]
+official_sources:
+  - https://firebase.google.com/docs
+  - https://github.com/firebase/firebase-tools
+  - https://www.npmjs.com/package/firebase-tools
+verified: 2026-06-17
+---
+
+# Firebase
+
+## Overview
+Firebase is Google's Backend-as-a-Service platform that bundles authentication, NoSQL databases (Cloud Firestore and the older Realtime Database), serverless Cloud Functions, static/SSR Hosting, Cloud Storage, and messaging behind client SDKs and a single CLI. It removes the need to run your own backend for most app features. Read this when adding auth, real-time data sync, file storage, push notifications, or deploying functions/hosting from the Firebase CLI.
+
+## Official sources
+- Docs: https://firebase.google.com/docs
+- Repo: https://github.com/firebase/firebase-tools
+- Install: https://www.npmjs.com/package/firebase-tools
+
+## Install / setup
+```bash
+npm install -g firebase-tools
+firebase login
+firebase init
+```
+Source: https://firebase.google.com/docs/cli
+
+## Core concepts
+- **Project** — top-level container; one project holds all Firebase products and maps to a Google Cloud project.
+- **Cloud Firestore** — scalable document/collection NoSQL DB with real-time listeners and offline cache; preferred over Realtime Database for new apps.
+- **Authentication** — managed identity (email/password, Google, Apple, phone, anonymous, OIDC/SAML) issuing ID tokens verified by Security Rules.
+- **Security Rules** — declarative server-side access control evaluated per request for Firestore, Storage, and Realtime Database.
+- **Cloud Functions** — serverless Node/Python handlers triggered by HTTPS, Firestore/Auth events, schedules, or Pub/Sub.
+- **Hosting** — global CDN for static assets and SSR frameworks (Next.js/Angular), wired to functions via rewrites.
+- **Emulator Suite** — local emulators for Auth, Firestore, Functions, Hosting for offline development and CI.
+
+## Best practices
+- Write and test Security Rules first; never rely on client-side checks alone (https://firebase.google.com/docs/rules).
+- Develop against the Emulator Suite before touching production data (https://firebase.google.com/docs/emulator-suite).
+- Model Firestore data for your queries — denormalize and avoid unbounded collection scans (https://firebase.google.com/docs/firestore/data-model).
+- Keep API keys/config public but lock data with Rules and App Check (https://firebase.google.com/docs/app-check).
+
+## Common pitfalls
+- Default-open or test-mode Security Rules left in production → leaked/writable data; deploy least-privilege rules before launch.
+- Missing composite indexes for compound queries → query fails at runtime; create the suggested index from the error link.
+- Per-document write contention on hot Firestore documents → throttling; shard counters or distribute writes.
+
+## Examples
+```javascript
+import { initializeApp } from "firebase/app";
+import { getFirestore, collection, addDoc } from "firebase/firestore";
+
+const app = initializeApp({ projectId: "demo", apiKey: "..." });
+const db = getFirestore(app);
+
+await addDoc(collection(db, "messages"), {
+  text: "hello",
+  createdAt: Date.now(),
+});
+```
+
+## Further reading
+- https://firebase.google.com/docs/firestore — Cloud Firestore guide
+- https://firebase.google.com/docs/functions — Cloud Functions reference
+- https://firebase.google.com/docs/cli — Firebase CLI reference
+
+## Related skills
+- ../appwrite — open-source self-hosted BaaS alternative
+- ../amplify — AWS fullstack BaaS with similar auth/data/functions

package/skills/stacks/baas/heroku/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: heroku
+description: Heroku is a Git-push Platform-as-a-Service for deploying and running apps (Node, Python, Ruby, Java, Go, PHP) with managed add-ons like Postgres and Redis. Consult when deploying an app via git push, configuring buildpacks/Procfile/dynos, setting config vars, scaling processes, provisioning Postgres/Redis add-ons, or using the Heroku CLI.
+domain: stack
+category: baas
+tags: [heroku, paas, deployment, dynos, buildpacks, postgres, git]
+official_sources:
+  - https://devcenter.heroku.com/
+  - https://github.com/heroku/cli
+  - https://devcenter.heroku.com/articles/heroku-cli
+verified: 2026-06-17
+---
+
+# Heroku
+
+## Overview
+Heroku is a managed Platform-as-a-Service that runs your application code on isolated containers called dynos, deployed by pushing to a Git remote. It detects your language via buildpacks, runs processes declared in a `Procfile`, and offers a marketplace of add-ons (Heroku Postgres, Redis, etc.) so you avoid managing servers. Read this when deploying via `git push heroku`, defining dynos/process types, managing config vars and add-ons, or scaling with the Heroku CLI.
+
+## Official sources
+- Docs: https://devcenter.heroku.com/
+- Repo: https://github.com/heroku/cli
+- Install: https://devcenter.heroku.com/articles/heroku-cli
+
+## Install / setup
+```bash
+heroku login
+heroku create
+git push heroku main
+```
+Source: https://devcenter.heroku.com/articles/getting-started-with-nodejs (install CLI via https://devcenter.heroku.com/articles/heroku-cli)
+
+## Core concepts
+- **Dyno** — lightweight isolated container running one process type; scaled horizontally/vertically by dyno type.
+- **Buildpack** — language-specific scripts that detect and compile your app into a runnable slug.
+- **Procfile** — root-level file declaring process types (`web:`, `worker:`) and their start commands.
+- **Config vars** — environment variables set with `heroku config:set`, the standard place for secrets/settings.
+- **Add-ons** — managed services (Heroku Postgres, Heroku Redis, etc.) attached and exposed via config vars.
+- **Release** — immutable deploy unit (slug + config); rolled back with `heroku rollback`.
+- **Stack** — the base OS/runtime image (e.g. `heroku-24`) your dynos run on.
+
+## Best practices
+- Store all configuration and secrets in config vars, never in the repo (https://devcenter.heroku.com/articles/config-vars).
+- Build stateless processes following the Twelve-Factor App methodology (https://12factor.net).
+- Run DB migrations in a `release` Procfile phase, not at boot (https://devcenter.heroku.com/articles/release-phase).
+- Provision Heroku Postgres as an add-on instead of an ephemeral local DB (https://devcenter.heroku.com/articles/heroku-postgresql).
+
+## Common pitfalls
+- Writing to the dyno's local filesystem → data lost on restart/deploy (ephemeral); use Postgres/S3 add-ons instead.
+- Web process not binding to `$PORT` → boot timeout / R10 error; bind your server to `process.env.PORT`.
+- Free/Eco dynos sleeping or missing a `web` process type → app returns errors; ensure a valid `Procfile`.
+
+## Examples
+```procfile
+web: node index.js
+worker: node worker.js
+release: node ./scripts/migrate.js
+```
+```bash
+heroku config:set NODE_ENV=production
+heroku addons:create heroku-postgresql:essential-0
+heroku ps:scale web=2
+```
+
+## Further reading
+- https://devcenter.heroku.com/categories/deployment — deployment methods and Git workflow
+- https://devcenter.heroku.com/articles/dynos — dyno types, scaling, and lifecycle
+- https://devcenter.heroku.com/articles/procfile — Procfile and process types reference
+
+## Related skills
+- ../firebase — BaaS with managed hosting and functions
+- ../amplify — AWS fullstack hosting + backend platform

package/skills/stacks/backend/actix/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: actix
+description: Powerful, fast Rust web framework (actix-web) on Tokio with HTTP/1 and HTTP/2, routing, and middleware; consult when building Rust HTTP services.
+domain: stack
+category: backend
+tags: [rust, actix-web, tokio, http, web-framework]
+official_sources:
+  - https://actix.rs/docs/
+  - https://github.com/actix/actix-web
+verified: 2026-06-16
+---
+
+# Actix Web
+
+## Overview
+actix-web is a powerful, pragmatic, and extremely fast web framework for Rust. It supports HTTP/1.x and HTTP/2, streaming and pipelining, powerful request routing with optional macros, and comprehensive middleware. Built on Tokio and running on stable Rust, it ranks among the fastest web frameworks in TechEmpower benchmarks. Read this when building Rust HTTP APIs and services.
+
+## Official sources
+- Docs: https://actix.rs/docs/
+- Repo: https://github.com/actix/actix-web
+- Install / download: https://actix.rs/docs/getting-started/
+
+## Install / setup
+```bash
+cargo new hello-world
+cd hello-world
+```
+```toml
+# Cargo.toml — add the dependency (requires a recent stable Rust)
+[dependencies]
+actix-web = "4"
+```
+
+## Core concepts
+- App & HttpServer: an `App` registers routes and shared state; `HttpServer` binds an address and runs the app, often across multiple worker threads.
+- Handlers (extractors): async functions whose typed arguments (path, query, JSON, state) are extracted from the request automatically.
+- Routing: route macros (`#[get("/path")]`) or builder methods (`.route(...)`, `.service(...)`) map paths and methods to handlers.
+- Application state: shared data wrapped in `web::Data<T>` injected into handlers; it must be thread-safe.
+- Middleware: wraps handlers for cross-cutting concerns (logging, auth, compression) via the `wrap` API.
+- Responders: handler return types implementing `Responder` are converted into HTTP responses.
+
+## Best practices
+- Pin `actix-web = "4"` and use a recent stable Rust toolchain as the docs require (https://actix.rs/docs/getting-started/).
+- Share state with `web::Data` instead of globals so it is cleanly injected and thread-safe.
+- Use typed extractors (Json, Path, Query) so deserialization and validation happen at the boundary.
+- Add the Logger middleware and structured error handling rather than panicking in handlers.
+
+## Common pitfalls
+- Doing blocking work directly in an async handler → blocks the worker; offload with `web::block` or an async client.
+- Expecting non-Send state to be shared across workers → `App` state must be thread-safe; wrap shared data in `web::Data`.
+- Confusing the actor framework `actix` with the web framework `actix-web` → for web servers depend on `actix-web`.
+
+## Examples
+```rust
+use actix_web::{get, App, HttpServer, Responder};
+
+#[get("/")]
+async fn hello() -> impl Responder {
+    "Hello, World!"
+}
+
+#[actix_web::main]
+async fn main() -> std::io::Result<()> {
+    HttpServer::new(|| App::new().service(hello))
+        .bind(("127.0.0.1", 8080))?
+        .run()
+        .await
+}
+```
+
+## Further reading
+- https://actix.rs/docs/getting-started/ — Getting started
+- https://actix.rs/docs/extractors/ — Type-safe extractors
+
+## Related skills
+- ../gin — comparable high-performance framework in Go
+- ../aspnet-core — cross-platform compiled-language web framework (.NET)

package/skills/stacks/backend/adonisjs/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: adonisjs
+description: TypeScript-first full-stack Node MVC framework with testing, ORM, and official packages; consult when building AdonisJS web apps or API servers.
+domain: stack
+category: backend
+tags: [nodejs, typescript, adonisjs, mvc, web-framework]
+official_sources:
+  - https://docs.adonisjs.com/
+  - https://github.com/adonisjs/core
+verified: 2026-06-16
+---
+
+# AdonisJS
+
+## Overview
+AdonisJS is a TypeScript-first web framework for building web apps and API servers on Node.js. It ships a full-stack MVC structure with testing support, modern tooling, and an ecosystem of official packages, emphasizing ergonomics and speed. Read this when building or maintaining an AdonisJS backend.
+
+## Official sources
+- Docs: https://docs.adonisjs.com/
+- Repo: https://github.com/adonisjs/core
+- Install / download: https://docs.adonisjs.com/guides/getting-started/installation
+
+## Install / setup
+```bash
+# Requires Node.js >= 24.x and npm >= 11.x
+npm init adonisjs@latest [project-name]
+```
+
+## Core concepts
+- IoC container & providers: services are registered via providers and resolved from a dependency-injection container.
+- Routing & controllers: routes in `start/routes.ts` map URLs to controller methods; route groups apply shared prefixes and middleware.
+- Middleware: composable request handlers run before route handlers for cross-cutting concerns (auth, body parsing).
+- Lucid ORM: the official Active Record-style ORM with models, migrations, and query building.
+- HttpContext: the per-request object (`ctx`) exposing request, response, and session passed to controllers.
+- Config & environment: typed configuration and validated environment variables via the framework's config system.
+
+## Best practices
+- Use the official starter and ecosystem packages (auth, Lucid, validation) rather than ad-hoc libraries, since they integrate with the IoC container (https://docs.adonisjs.com/guides/getting-started/installation).
+- Keep controllers thin and move logic into services resolved from the container.
+- Use Lucid migrations for schema changes so databases stay reproducible.
+- Validate request input with the built-in validator before using it.
+
+## Common pitfalls
+- Running on an unsupported Node version → the installer requires Node.js >= 24.x and npm >= 11.x; upgrade before installing.
+- Bypassing the IoC container by instantiating services manually → register and resolve them so dependencies and lifecycles are managed.
+- Skipping input validation → validate with the framework's validator instead of trusting raw request data.
+
+## Examples
+```ts
+// start/routes.ts
+import router from '@adonisjs/core/services/router'
+
+router.get('/users/:id', async ({ params }) => {
+  return { id: params.id }
+})
+```
+
+## Further reading
+- https://docs.adonisjs.com/guides/getting-started/installation — Installation
+- https://docs.adonisjs.com/guides/basics/routing — Routing
+- https://lucid.adonisjs.com/ — Lucid ORM
+
+## Related skills
+- ../laravel — the PHP framework AdonisJS's conventions are often compared to
+- ../fiber — Express-lineage framework in Go