constella 0.1.0

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

@@ -0,0 +1,63 @@
+---
+name: auth0
+description: Auth0 — hosted identity platform built on OAuth 2.0 and OpenID Connect for adding login, SSO, and M2M auth via Universal Login and SDKs.
+domain: stack
+category: auth
+tags: [auth, identity, oauth2, oidc, sso, universal-login, jwt, saml]
+official_sources:
+  - https://auth0.com/docs
+  - https://github.com/auth0
+verified: 2026-06-16
+---
+
+# Auth0
+
+## Overview
+Auth0 is a hosted identity and access management platform that adds authentication and authorization to applications using OAuth 2.0 and OpenID Connect (plus SAML). It provides Universal Login, quickstarts and SDKs for many frameworks, and supports flows for web, single-page, native, machine-to-machine, and device apps. Read this when you want a managed IdP rather than self-hosting auth.
+
+## Official sources
+- Docs: https://auth0.com/docs
+- Repo (org): https://github.com/auth0
+- Install / quickstarts: https://auth0.com/docs/quickstarts
+
+## Install / setup
+```bash
+npm install @auth0/nextjs-auth0
+```
+(Auth0 publishes per-framework SDKs from its official, domain-verified GitHub org — e.g. `nextjs-auth0`, `auth0-react`, `auth0-spa-js`, `node-auth0`. Pick the SDK matching your stack from https://auth0.com/docs/quickstarts.)
+
+## Core concepts
+- Tenant: your isolated Auth0 environment with its own users, applications, and configuration.
+- Application (client): a registered app type — Single Page, Regular Web, Native, or Machine-to-Machine — each mapped to an appropriate OAuth flow.
+- Universal Login: Auth0-hosted login page that centralizes authentication and enables SSO across apps.
+- OAuth 2.0 / OIDC flows: Auth0 documents Authorization Code, Authorization Code with PKCE, Client Credentials (M2M), Device Authorization, and more, each suited to an app type.
+- Tokens: Auth0 issues ID tokens (OIDC) and access tokens (often JWTs) that apps and APIs validate.
+- APIs & scopes: protect your backend by registering it as an API with an audience and scopes/permissions.
+
+## Best practices
+- Use Authorization Code Flow with PKCE for SPAs and native/mobile apps; Auth0 documents PKCE as the recommended public-client flow (https://auth0.com/docs/get-started/authentication-and-authorization-flow).
+- Use the Client Credentials flow for machine-to-machine access, not user-facing flows.
+- Prefer Universal Login over embedding login forms, to get SSO, attack protection, and consistent UX.
+- Validate access tokens at your API by audience and issuer; don't trust ID tokens for API authorization.
+
+## Common pitfalls
+- Choosing the wrong application type → mismatched flow (e.g. SPA configured as a Regular Web App) breaks token handling; pick the type that matches your app.
+- Using the Resource Owner Password flow for normal logins → Auth0 marks it as not recommended and only for highly-trusted clients.
+- Treating the ID token as an API access token → use the access token (with the right audience/scopes) to authorize API calls.
+
+## Examples
+```ts
+// Next.js (App Router) with @auth0/nextjs-auth0
+import { Auth0Client } from "@auth0/nextjs-auth0/server"
+
+export const auth0 = new Auth0Client()
+// Configure AUTH0_DOMAIN, AUTH0_CLIENT_ID, AUTH0_CLIENT_SECRET, AUTH0_SECRET, APP_BASE_URL in env.
+```
+
+## Further reading
+- https://auth0.com/docs/get-started/authentication-and-authorization-flow — choosing the right flow
+- https://auth0.com/docs/quickstarts — framework quickstarts
+
+## Related skills
+- ../keycloak — self-hosted open-source IdP alternative
+- ../clerk — hosted auth with prebuilt UI components

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

@@ -0,0 +1,69 @@
+---
+name: authjs
+description: Framework-agnostic authentication for JS/TS apps (Auth.js, formerly NextAuth.js) — consult when adding OAuth/OIDC, email, or credentials sign-in.
+domain: stack
+category: auth
+tags: [auth, oauth, oidc, nextauth, nextjs, sveltekit, sessions]
+official_sources:
+  - https://authjs.dev/
+  - https://github.com/nextauthjs/next-auth
+verified: 2026-06-16
+---
+
+# Auth.js (NextAuth.js)
+
+## Overview
+Auth.js is an open-source set of packages for authentication built on standard Web APIs, usable with any framework on any JS runtime. It was formerly known as NextAuth.js; the `next-auth` package serves Next.js, while sibling packages (`@auth/sveltekit`, `@auth/express`, Qwik, etc.) target other frameworks. Read this when wiring sign-in flows, OAuth providers, or sessions into a JS/TS app.
+
+## Official sources
+- Docs: https://authjs.dev/
+- Repo: https://github.com/nextauthjs/next-auth
+- Install / download: https://authjs.dev/getting-started/installation
+
+## Install / setup
+```bash
+npm install next-auth@beta
+```
+After installing, generate the required secret:
+```bash
+npx auth secret
+```
+(For other frameworks the official install page lists `@auth/sveltekit`, `@auth/express`, and the Qwik `qwik add auth` flow.)
+
+## Core concepts
+- Providers: pluggable sign-in methods — OAuth/OIDC providers, email (magic link), and credentials. Configure them in the Auth.js config object.
+- Sessions: Auth.js issues a session that can be a JWT (default, stateless) or database-backed via an adapter; you read it on server and client.
+- Adapters: connect Auth.js to your database (Prisma, Drizzle, etc.) to persist users, accounts, and sessions.
+- Callbacks: hooks (`signIn`, `jwt`, `session`, `redirect`) let you customize token contents, authorization, and redirects.
+- `AUTH_SECRET`: required environment variable used to encrypt tokens and sign cookies; generated with `npx auth secret`.
+- Framework packages: the core is framework-agnostic; you install the package matching your framework (`next-auth`, `@auth/sveltekit`, `@auth/express`).
+
+## Best practices
+- Always set a strong `AUTH_SECRET` (use `npx auth secret`) and keep it out of source control. See https://authjs.dev/getting-started/installation.
+- Prefer OAuth/OIDC or email providers over the Credentials provider; the docs note credentials are inherently less secure and bypass much of Auth.js's built-in protection.
+- Use an adapter when you need to persist users/accounts or link multiple providers to one user.
+- Restrict access using the `signIn`/`authorized` callbacks rather than ad-hoc checks scattered through your app.
+
+## Common pitfalls
+- Installing the stable major when following current docs → the v5 (Auth.js) getting-started uses `next-auth@beta`; mixing v4 docs with v5 config breaks setup.
+- Forgetting `AUTH_SECRET` in production → sign-in fails or sessions cannot be decrypted; set it in the deployment environment.
+- Assuming Auth.js is Next.js-only → it is framework-agnostic; use the correct package for your framework.
+
+## Examples
+```ts
+// auth.ts (Next.js, Auth.js v5)
+import NextAuth from "next-auth"
+import GitHub from "next-auth/providers/github"
+
+export const { handlers, signIn, signOut, auth } = NextAuth({
+  providers: [GitHub],
+})
+```
+
+## Further reading
+- https://authjs.dev/getting-started — official getting-started guides per framework
+- https://authjs.dev/getting-started/providers — provider catalog
+
+## Related skills
+- ../auth0 — hosted OAuth/OIDC platform you can plug in as a provider
+- ../clerk — alternative hosted auth with prebuilt UI

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

@@ -0,0 +1,72 @@
+---
+name: clerk
+description: Hosted authentication and user management with prebuilt React/JS UI components — consult when adding sign-up, sign-in, and profile flows fast.
+domain: stack
+category: auth
+tags: [auth, user-management, react, nextjs, components, sessions, mfa]
+official_sources:
+  - https://clerk.com/docs
+  - https://github.com/clerk/javascript
+verified: 2026-06-16
+---
+
+# Clerk
+
+## Overview
+Clerk is a hosted authentication and user-management platform that ships prebuilt, customizable UI components (sign-up, sign-in, user profile, organization switcher) plus SDKs for frameworks like Next.js and React. It handles sessions, MFA, and organizations so you don't build user storage yourself. Read this when you want production auth with minimal UI work.
+
+## Official sources
+- Docs: https://clerk.com/docs
+- Repo: https://github.com/clerk/javascript
+- Install / download: https://clerk.com/docs/quickstarts/setup-clerk
+
+## Install / setup
+```bash
+npm install @clerk/nextjs
+```
+(Command from the official Next.js quickstart, https://clerk.com/docs/quickstarts/nextjs. Other frameworks use the matching `@clerk/*` package, e.g. `@clerk/clerk-react`.)
+
+## Core concepts
+- Prebuilt components: `<SignIn />`, `<SignUp />`, `<UserButton />`, `<UserProfile />`, and `<OrganizationSwitcher />` provide drop-in, themeable auth UI.
+- Application / instance: Clerk apps have a development and production instance, each with publishable and secret keys.
+- Sessions & JWTs: Clerk manages user sessions and can issue JWTs/templates to authenticate requests to your backend.
+- Organizations: built-in multi-tenancy — users belong to organizations with roles and memberships.
+- Control components: `<SignedIn>`, `<SignedOut>`, and helpers gate UI based on auth state; middleware protects routes (e.g. `clerkMiddleware` in Next.js).
+- SDK packages: the `@clerk/javascript` monorepo provides environment-specific SDKs under the `@clerk` namespace.
+
+## Best practices
+- Keep the secret key server-side only; expose only the publishable key to the client. See https://clerk.com/docs.
+- Use Clerk middleware to protect routes centrally rather than checking auth in each handler.
+- Use Organizations for B2B/multi-tenant apps instead of rolling your own tenancy model.
+- Customize the prebuilt components via appearance props rather than rebuilding flows from scratch.
+
+## Common pitfalls
+- Installing the wrong SDK package → use `@clerk/nextjs` for Next.js, `@clerk/clerk-react` for plain React; mixing them breaks the integration.
+- Leaking the secret key into client bundles → only the publishable key is safe client-side.
+- Forgetting to wrap the app in the Clerk provider / middleware → components throw because there's no Clerk context.
+
+## Examples
+```tsx
+// app/layout.tsx (Next.js App Router)
+import { ClerkProvider, SignedIn, SignedOut, SignInButton, UserButton } from "@clerk/nextjs"
+
+export default function RootLayout({ children }: { children: React.ReactNode }) {
+  return (
+    <ClerkProvider>
+      <html><body>
+        <SignedOut><SignInButton /></SignedOut>
+        <SignedIn><UserButton /></SignedIn>
+        {children}
+      </body></html>
+    </ClerkProvider>
+  )
+}
+```
+
+## Further reading
+- https://clerk.com/docs/quickstarts/nextjs — Next.js quickstart
+- https://clerk.com/docs/references/nextjs/clerk-middleware — route protection
+
+## Related skills
+- ../auth0 — alternative hosted identity platform (OAuth/OIDC focused)
+- ../authjs — open-source, self-hosted alternative for JS/TS

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

@@ -0,0 +1,63 @@
+---
+name: keycloak
+description: Keycloak — open-source identity and access management server (OIDC, OAuth 2.0, SAML) for adding SSO, federation, and user management to apps.
+domain: stack
+category: auth
+tags: [auth, iam, sso, oidc, oauth2, saml, self-hosted, identity-provider]
+official_sources:
+  - https://www.keycloak.org/documentation
+  - https://github.com/keycloak/keycloak
+verified: 2026-06-16
+---
+
+# Keycloak
+
+## Overview
+Keycloak is open-source Identity and Access Management for modern applications and services. It lets you add authentication and secure services with minimal effort, so you don't store users or write login flows yourself. It is an identity provider speaking OpenID Connect, OAuth 2.0, and SAML, with built-in SSO, identity brokering, and user federation. Read this when you need a self-hosted IAM/IdP.
+
+## Official sources
+- Docs: https://www.keycloak.org/documentation
+- Repo: https://github.com/keycloak/keycloak
+- Install / download: https://www.keycloak.org/getting-started/getting-started-docker
+
+## Install / setup
+```bash
+docker run -p 127.0.0.1:8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.6.3 start-dev
+```
+(Verbatim from the official Docker getting-started page. `start-dev` runs Keycloak in development mode and creates an initial admin user `admin`/`admin`. Do not use `start-dev` in production.)
+
+## Core concepts
+- Realm: an isolated tenant that owns its own users, clients, roles, and configuration; the `master` realm is admin-only.
+- Client: an application or service registered with Keycloak that requests authentication (confidential or public).
+- Protocols: Keycloak speaks OpenID Connect, OAuth 2.0, and SAML so standard apps can integrate without custom code.
+- Roles & groups: authorization is modeled with realm/client roles assigned directly or via groups.
+- Identity brokering & federation: Keycloak can delegate login to external IdPs (social, SAML, OIDC) and federate users from LDAP/Active Directory.
+- Tokens: after login Keycloak issues ID, access, and refresh tokens (JWTs) that apps validate.
+
+## Best practices
+- Never run `start-dev` in production — it uses dev defaults; use `start` with a production database and proper hostname/TLS config (https://www.keycloak.org/server/configuration-production).
+- Create a dedicated realm per environment/tenant; don't put applications in the `master` realm.
+- Use confidential clients with a secret for server-side apps and public clients with PKCE for SPAs/native apps.
+- Front Keycloak with TLS and set the correct hostname so issued token issuer URLs are valid.
+
+## Common pitfalls
+- Using `start-dev` or the bootstrap admin credentials in production → insecure defaults and no proper persistence; switch to `start` and a real DB.
+- Putting client apps in the `master` realm → mixes admin and app users; create a separate realm.
+- Public client without PKCE for browser/native apps → vulnerable to code interception; enable PKCE.
+
+## Examples
+```bash
+# Start a development server (creates admin/admin), then visit http://localhost:8080
+docker run -p 127.0.0.1:8080:8080 \
+  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
+  -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \
+  quay.io/keycloak/keycloak:26.6.3 start-dev
+```
+
+## Further reading
+- https://www.keycloak.org/guides — task-oriented guides (server, securing apps, operator)
+- https://www.keycloak.org/server/configuration-production — production configuration
+
+## Related skills
+- ../auth0 — hosted alternative to a self-managed IdP
+- ../authjs — JS/TS app library that can use Keycloak as an OIDC provider

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