constella 0.1.0

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

@@ -0,0 +1,64 @@
+---
+name: fastify
+description: Fast, low-overhead Node.js HTTP framework with schema validation and a plugin/encapsulation model; consult for performant APIs.
+domain: stack
+category: backend
+tags: [fastify, nodejs, http, plugins, json-schema, backend]
+official_sources:
+  - https://fastify.dev/docs/latest/
+  - https://github.com/fastify/fastify
+verified: 2026-06-16
+---
+
+# Fastify
+
+## Overview
+Fastify is a fast, low-overhead web framework for Node.js focused on serving the highest number of requests possible without sacrificing security validation or developer experience. It is built around a plugin architecture, hooks, and JSON-Schema-based validation and serialization. Read this when building performance-sensitive HTTP APIs that benefit from schema-driven request handling.
+
+## Official sources
+- Docs: https://fastify.dev/docs/latest/
+- Repo: https://github.com/fastify/fastify
+- Getting started: https://fastify.dev/docs/latest/Guides/Getting-Started/
+
+## Install / setup
+```bash
+npm i fastify
+```
+(Source: https://fastify.dev/docs/latest/Guides/Getting-Started/)
+
+## Core concepts
+- **Instance & lifecycle** — `fastify()` creates a server; routes and plugins register against it before `listen()`.
+- **Plugins** — almost everything is a plugin registered with `fastify.register()`; plugins encapsulate routes, decorators, and hooks.
+- **Encapsulation** — each plugin gets its own context that inherits from parents but is isolated from siblings; use the `fastify-plugin` wrapper to deliberately expose a plugin's decorators/hooks to the parent scope (https://fastify.dev/docs/latest/Reference/Encapsulation/).
+- **JSON Schema validation & serialization** — attach a `schema` to a route to validate input and fast-serialize output.
+- **Hooks** — lifecycle hooks (`onRequest`, `preHandler`, `onSend`, etc.) run code at defined request phases.
+- **Decorators** — extend `fastify`, `request`, and `reply` with custom properties/methods.
+
+## Best practices
+- Define route schemas for body/querystring/params and responses to get validation plus faster serialization (https://fastify.dev/docs/latest/Guides/Getting-Started/).
+- Prefer `async/await` handlers; returning a value sends the response, and thrown errors are routed to the error handler.
+- Encapsulate features as plugins and only break encapsulation with `fastify-plugin` when sharing is intentional (https://fastify.dev/docs/latest/Reference/Plugins/).
+- Register plugins and await readiness before calling `listen()` so the plugin tree is fully booted.
+
+## Common pitfalls
+- Mixing `async` handlers with manual `reply.send()` and also returning a value → causes "reply already sent"; in async handlers, return the payload OR call `reply.send`, not both (https://fastify.dev/docs/latest/Reference/Routes/).
+- Expecting a decorator/hook registered inside a child plugin to be visible to parents → it isn't, due to encapsulation; wrap with `fastify-plugin` to expose it upward.
+
+## Examples
+```javascript
+import Fastify from 'fastify';
+
+const fastify = Fastify({ logger: true });
+
+fastify.get('/', async () => ({ hello: 'world' }));
+
+await fastify.listen({ port: 3000 });
+```
+
+## Further reading
+- https://fastify.dev/docs/latest/Reference/Validation-and-Serialization/ — schema deep dive
+- https://fastify.dev/docs/latest/Reference/Hooks/ — hook reference
+
+## Related skills
+- ../express — the minimal framework Fastify positions against on performance
+- ../nestjs — can run on a Fastify platform adapter

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

@@ -0,0 +1,68 @@
+---
+name: fiber
+description: Express-inspired Go web framework built on Fasthttp for fast, low-allocation HTTP services; consult when building Go APIs with an Express-like API.
+domain: stack
+category: backend
+tags: [go, fiber, fasthttp, express, web-framework]
+official_sources:
+  - https://docs.gofiber.io/
+  - https://github.com/gofiber/fiber
+verified: 2026-06-16
+---
+
+# Fiber
+
+## Overview
+Fiber is an Express-inspired web framework written in Go and built on top of Fasthttp, the fastest HTTP engine for Go. It aims for fast development with zero memory allocation and high performance in mind. Read this when building Go HTTP APIs and you want an Express-like routing and middleware API.
+
+## Official sources
+- Docs: https://docs.gofiber.io/
+- Repo: https://github.com/gofiber/fiber
+- Install / download: https://docs.gofiber.io/ (Installation section)
+
+## Install / setup
+```bash
+# Requires Go 1.25 or higher
+go get github.com/gofiber/fiber/v3
+```
+
+## Core concepts
+- App: `fiber.New()` creates the application instance that registers routes and middleware and starts the server with `app.Listen`.
+- Context (`fiber.Ctx`): the per-request object exposing params, query, body parsing, and response helpers — the Express-like `c` argument.
+- Routing: HTTP-verb methods (`app.Get`, `app.Post`, ...) with path params (`:id`) and wildcards, plus route grouping.
+- Middleware: handlers chained with `c.Next()`; Fiber ships official middleware (logger, CORS, recover, etc.).
+- Built on Fasthttp: Fiber uses Fasthttp rather than net/http, which is what enables its low-allocation performance profile.
+
+## Best practices
+- Pin the major version in your import path (`/v3`) so upgrades are explicit and breaking changes are opt-in (https://docs.gofiber.io/).
+- Use the official middleware packages (recover, logger, CORS) instead of reimplementing common concerns.
+- Be aware that Fasthttp's `Ctx` and the values it returns are reused per request; copy values you need to retain beyond the handler.
+- Return errors from handlers and centralize handling with a custom error handler on `fiber.New`.
+
+## Common pitfalls
+- Assuming net/http compatibility → Fiber is built on Fasthttp, so net/http middleware and `http.Request` APIs do not apply directly.
+- Holding onto byte slices/strings from `Ctx` after the handler returns → they may be reused; copy them first.
+- Mixing Fiber versions (v2 vs v3) imports → keep a single major version; APIs differ between them.
+
+## Examples
+```go
+package main
+
+import "github.com/gofiber/fiber/v3"
+
+func main() {
+    app := fiber.New()
+    app.Get("/", func(c fiber.Ctx) error {
+        return c.SendString("Hello, World!")
+    })
+    app.Listen(":3000")
+}
+```
+
+## Further reading
+- https://docs.gofiber.io/ — Welcome / Installation / Zero allocation notes
+- https://github.com/gofiber/fiber — Source and examples
+
+## Related skills
+- ../gin — alternative high-performance Go web framework
+- ../adonisjs — Express-lineage framework in TypeScript

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

@@ -0,0 +1,71 @@
+---
+name: flask
+description: Minimal Python WSGI microframework built on Werkzeug and Jinja; consult for small services, APIs, or when you want to assemble your own stack.
+domain: stack
+category: backend
+tags: [flask, python, wsgi, microframework, jinja, backend]
+official_sources:
+  - https://flask.palletsprojects.com/
+  - https://github.com/pallets/flask
+verified: 2026-06-16
+---
+
+# Flask
+
+## Overview
+Flask is a lightweight WSGI web microframework for Python, designed for a quick start that scales up to complex applications. It is built on Werkzeug (WSGI) and Jinja (templating) and ships a minimal core, leaving database, validation, and other choices to you via extensions. Read this when you want a small, flexible Python web app or API without a prescribed project structure.
+
+## Official sources
+- Docs: https://flask.palletsprojects.com/
+- Repo: https://github.com/pallets/flask
+- Install: https://flask.palletsprojects.com/en/stable/installation/
+
+## Install / setup
+```bash
+pip install Flask
+```
+The docs recommend creating and activating a virtual environment first:
+```bash
+mkdir myproject
+cd myproject
+python3 -m venv .venv
+. .venv/bin/activate
+```
+(Source: https://flask.palletsprojects.com/en/stable/installation/)
+
+## Core concepts
+- **Application object** — `Flask(__name__)` creates the WSGI app; you register routes and run it.
+- **Routing & view functions** — the `@app.route()` decorator maps URLs to functions that return responses.
+- **Request / response context** — the request-bound `request` object and the application/request context manage per-request state.
+- **Templates (Jinja)** — `render_template()` renders Jinja templates with auto-escaping.
+- **Blueprints** — group related routes/handlers into reusable components for larger apps.
+- **Extensions** — optional packages (e.g. SQLAlchemy, Flask-Login) add ORM, auth, etc.
+
+## Best practices
+- Develop inside a virtual environment to isolate dependencies, as the install guide instructs (https://flask.palletsprojects.com/en/stable/installation/).
+- Use the application factory pattern and Blueprints to structure non-trivial apps (https://flask.palletsprojects.com/en/stable/patterns/appfactories/).
+- Never run the built-in development server in production; use a production WSGI server like Gunicorn or uWSGI (https://flask.palletsprojects.com/en/stable/deploying/).
+- Keep configuration in `app.config` / environment variables, not hardcoded.
+
+## Common pitfalls
+- Leaving `debug=True` (or the dev server) enabled in production → exposes the interactive debugger, which allows arbitrary code execution; disable debug and deploy behind a real WSGI server (https://flask.palletsprojects.com/en/stable/deploying/).
+- Accessing `request` or other context-bound globals outside a request/app context → raises a "working outside of request context" error; push a context or restructure the code (https://flask.palletsprojects.com/en/stable/appcontext/).
+
+## Examples
+```python
+from flask import Flask
+
+app = Flask(__name__)
+
+@app.route("/")
+def hello():
+    return "Hello, World!"
+```
+
+## Further reading
+- https://flask.palletsprojects.com/en/stable/quickstart/ — quickstart
+- https://flask.palletsprojects.com/en/stable/deploying/ — deployment options
+
+## Related skills
+- ../django — batteries-included Python alternative
+- ../fastapi — async, typed Python API framework

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

@@ -0,0 +1,68 @@
+---
+name: gin
+description: Fast Go HTTP web framework with httprouter-based routing, middleware, and JSON binding; consult when building Go REST APIs or microservices.
+domain: stack
+category: backend
+tags: [go, gin, http, rest-api, web-framework]
+official_sources:
+  - https://gin-gonic.com/en/docs/
+  - https://github.com/gin-gonic/gin
+verified: 2026-06-16
+---
+
+# Gin
+
+## Overview
+Gin is a high-performance HTTP web framework written in Go that offers a Martini-like API with much better performance thanks to httprouter. It targets REST APIs, microservices, and web apps where speed and developer productivity matter. Read this when building Go HTTP services with routing, middleware, and request binding.
+
+## Official sources
+- Docs: https://gin-gonic.com/en/docs/
+- Repo: https://github.com/gin-gonic/gin
+- Install / download: https://gin-gonic.com/en/docs/quickstart/
+
+## Install / setup
+```bash
+go get -u github.com/gin-gonic/gin
+```
+
+## Core concepts
+- Engine & router: `gin.Default()` returns an Engine with Logger and Recovery middleware attached; it dispatches requests via a zero-allocation router.
+- Context (`*gin.Context`): carries the request/response, params, and helpers for binding and rendering; passed to every handler.
+- Middleware: functions that run before/after handlers, attached globally or per route group, calling `c.Next()` to continue the chain.
+- Route grouping: `router.Group("/api")` clusters routes that share a prefix and middleware.
+- Binding & validation: `c.ShouldBindJSON` and friends parse and validate request bodies into structs using tags.
+- Rendering: built-in helpers for JSON, XML, and HTML responses.
+
+## Best practices
+- Use `gin.Default()` for built-in crash recovery and logging, or `gin.New()` when you want to compose middleware explicitly (https://gin-gonic.com/en/docs/quickstart/).
+- Group related routes and apply shared middleware at the group level rather than repeating it per route.
+- Validate input with binding tags and `ShouldBind*` methods so malformed requests are rejected early.
+- Set `gin.SetMode(gin.ReleaseMode)` in production to reduce debug overhead and log noise.
+
+## Common pitfalls
+- Forgetting to call `c.Next()` (or `c.Abort()`) in custom middleware → the chain stalls or continues unexpectedly; call the correct one explicitly.
+- Using `c.Bind*` (which auto-aborts with 400) when you want to handle errors yourself → use `c.ShouldBind*` to control the error response.
+- Running in debug mode in production → switch to release mode to avoid verbose logging and warnings.
+
+## Examples
+```go
+package main
+
+import "github.com/gin-gonic/gin"
+
+func main() {
+    r := gin.Default()
+    r.GET("/ping", func(c *gin.Context) {
+        c.JSON(200, gin.H{"message": "pong"})
+    })
+    r.Run() // listens on :8080
+}
+```
+
+## Further reading
+- https://gin-gonic.com/en/docs/quickstart/ — Quickstart
+- https://gin-gonic.com/en/docs/examples/ — Examples (binding, middleware, grouping)
+
+## Related skills
+- ../fiber — Express-inspired Go web framework alternative
+- ../actix — high-performance web framework in Rust

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

@@ -0,0 +1,70 @@
+---
+name: graphql
+description: GraphQL — a query language and server-side runtime for APIs where clients request exactly the fields they need from a strongly-typed schema. Consult when designing a schema (SDL), writing queries/mutations/subscriptions, building a resolver-based server (graphql-js, Apollo), avoiding over/under-fetching, or referencing the GraphQL specification.
+domain: stack
+category: backend
+tags: [graphql, api, schema, resolvers, query-language, graphql-js, backend]
+official_sources:
+  - https://graphql.org/learn/
+  - https://github.com/graphql/graphql-spec
+  - https://www.graphql-js.org/docs/getting-started/
+verified: 2026-06-17
+---
+
+# GraphQL
+
+## Overview
+GraphQL is an open-source query language for APIs plus a runtime that fulfills those queries against a typed schema. Clients ask for exactly the fields they need in one request, eliminating over- and under-fetching common to REST. It is transport- and database-agnostic — resolvers fetch data from any backend. Read this when designing a schema, writing resolvers, or choosing a GraphQL server.
+
+## Official sources
+- Docs: https://graphql.org/learn/
+- Repo: https://github.com/graphql/graphql-spec
+- Install: https://www.graphql-js.org/docs/getting-started/
+
+## Install / setup
+```bash
+# Reference JavaScript implementation:
+npm install graphql --save
+```
+Source: https://www.graphql-js.org/docs/getting-started/ (graphql-js is the official JS implementation: parser, type system, validator, executor).
+
+## Core concepts
+- **Schema (SDL)** — the typed contract; `type`, `Query`, `Mutation`, `Subscription` define the API surface.
+- **Types** — scalars, objects, enums, interfaces, unions, input types, and non-null/list modifiers.
+- **Operations** — queries (read), mutations (write), subscriptions (real-time streams).
+- **Resolvers** — functions that return the data for each field; the heart of execution.
+- **Fields & arguments** — clients select fields and pass typed arguments per field.
+- **Introspection** — the schema is self-describing; tools like GraphiQL query it.
+- **Single endpoint** — typically one POST endpoint (e.g. `/graphql`) for all operations.
+- **Fragments & variables** — reusable field sets and parameterized, cacheable queries.
+
+## Best practices
+- Design the schema around client/product needs, not your database tables (https://graphql.org/learn/schema/).
+- Solve N+1 resolver fan-out with batching/caching (DataLoader) (https://graphql.org/learn/best-practices/).
+- Use cursor-based (connections) pagination for lists (https://graphql.org/learn/pagination/).
+- Return structured `errors` and prefer nullable fields for partial failures (https://graphql.org/learn/best-practices/).
+
+## Common pitfalls
+- N+1 queries when a list resolver hits the DB per item → batch with DataLoader.
+- Unbounded query depth/complexity enables DoS → add depth/complexity limits and timeouts.
+- Exposing a single `/graphql` makes per-resource HTTP caching hard → use persisted queries / response caching.
+
+## Examples
+```javascript
+import { graphql, buildSchema } from 'graphql';
+
+const schema = buildSchema(`type Query { hello: String }`);
+const rootValue = { hello: () => 'Hello world!' };
+
+graphql({ schema, source: '{ hello }', rootValue })
+  .then((res) => console.log(res));
+// { data: { hello: 'Hello world!' } }
+```
+
+## Further reading
+- https://spec.graphql.org/ — the formal GraphQL specification versions
+- https://graphql.org/community/tools-and-libraries/ — servers and clients per language
+
+## Related skills
+- ../spring — expose a GraphQL API from a Spring backend (Spring for GraphQL)
+- ../nginx — reverse-proxy a GraphQL server behind Nginx

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

@@ -0,0 +1,64 @@
+---
+name: hono
+description: Tiny, ultrafast Web-Standards web framework that runs on Cloudflare Workers, Deno, Bun, Node.js and edge; consult for edge/multi-runtime APIs.
+domain: stack
+category: backend
+tags: [hono, edge, web-standards, cloudflare-workers, bun, deno, backend]
+official_sources:
+  - https://hono.dev/docs/
+  - https://github.com/honojs/hono
+verified: 2026-06-16
+---
+
+# Hono
+
+## Overview
+Hono is a small, simple, and ultrafast web framework built on Web Standards. The same code runs on any JavaScript runtime — Cloudflare Workers, Fastly Compute, Deno, Bun, Vercel, AWS Lambda, Lambda@Edge, and Node.js. Read this when targeting edge/serverless platforms or when you want one routing/middleware codebase portable across runtimes.
+
+## Official sources
+- Docs: https://hono.dev/docs/
+- Repo: https://github.com/honojs/hono
+- Getting started: https://hono.dev/docs/getting-started/basic
+
+## Install / setup
+```bash
+npm create hono@latest my-app
+```
+(Source: https://hono.dev/docs/getting-started/basic)
+
+## Core concepts
+- **App instance** — `new Hono()` creates the router/app; `.get()`, `.post()`, etc. register routes.
+- **Web Standards core** — built on the standard `Request`/`Response` and Fetch APIs, which is why it is runtime-portable.
+- **Context (`c`)** — handlers receive a `Context` exposing `c.req`, `c.json()`, `c.text()`, env bindings, and helpers.
+- **Middleware** — composable `async (c, next) => {}` functions; Hono ships built-in middleware (CORS, logger, JWT, etc.).
+- **Presets / adapters** — import paths/presets (`hono`, `hono/tiny`, `hono/quick`) and runtime adapters tailor the router and serving for each platform.
+- **RPC & typing** — routes can be typed end-to-end and shared with clients via the RPC feature.
+
+## Best practices
+- Pick the import preset that matches your workload (e.g. `hono/quick` for many cold starts) per the docs (https://hono.dev/docs/api/presets).
+- Use the official middleware (CORS, logger, secure headers) instead of hand-rolling cross-cutting concerns (https://hono.dev/docs/middleware/builtin/cors).
+- Use the runtime-specific starter template so the entrypoint and serving adapter match your target (https://hono.dev/docs/getting-started/basic).
+- Return `Response`-compatible values from handlers via `c.json` / `c.text` rather than mutating shared state.
+
+## Common pitfalls
+- Assuming Node-only APIs (e.g. `fs`, raw `http`) work everywhere → on Workers/Deno/edge only Web Standard APIs are available; keep handlers runtime-agnostic.
+- Forgetting a platform-specific entrypoint/adapter → each runtime has its own bootstrap (e.g. `@hono/node-server` for Node); follow the matching getting-started page (https://hono.dev/docs/getting-started/nodejs).
+
+## Examples
+```typescript
+import { Hono } from 'hono';
+
+const app = new Hono();
+
+app.get('/', (c) => c.text('Hello Hono!'));
+
+export default app;
+```
+
+## Further reading
+- https://hono.dev/docs/api/presets — choosing presets per runtime
+- https://hono.dev/docs/guides/rpc — typed RPC between server and client
+
+## Related skills
+- ../fastify — Node-focused performance framework
+- ../express — minimal Node framework with a similar middleware model

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

@@ -0,0 +1,63 @@
+---
+name: koa
+description: Expressive, minimal middleware framework for Node.js from the Express team, built on async/await; consult for lean, composable HTTP servers.
+domain: stack
+category: backend
+tags: [koa, nodejs, middleware, async-await, http, backend]
+official_sources:
+  - https://koajs.com/
+  - https://github.com/koajs/koa
+verified: 2026-06-16
+---
+
+# Koa
+
+## Overview
+Koa is an expressive HTTP middleware framework for Node.js, created by the team behind Express, designed to make web applications and APIs more enjoyable to write. It has a small core (no bundled middleware) and uses `async`/`await` with a cascading middleware model and a unified `ctx` object. Read this when you want a minimal, modern foundation and prefer composing middleware explicitly.
+
+## Official sources
+- Docs: https://koajs.com/
+- Repo: https://github.com/koajs/koa
+
+## Install / setup
+```bash
+npm i koa
+```
+Koa requires node v18.0.0 or higher for ES2015 and async function support. (Source: https://koajs.com/)
+
+## Core concepts
+- **Application** — `new Koa()` creates an app; `app.use()` adds middleware; `app.listen()` starts the server.
+- **Cascading middleware** — middleware are `async (ctx, next) => {}`; calling `await next()` runs downstream middleware, then control flows back upstream ("cascade").
+- **Context (`ctx`)** — a single object per request that wraps and delegates to `ctx.request` and `ctx.response` (e.g. `ctx.body`, `ctx.status`).
+- **Request / Response abstractions** — Koa's own objects sit on top of Node's, adding helpful accessors.
+- **No bundled middleware** — routing, body parsing, etc. come from separate packages (e.g. `@koa/router`, `koa-bodyparser`).
+
+## Best practices
+- Set the response with `ctx.body` / `ctx.status` rather than calling Node's `res` directly, so Koa handles serialization correctly (https://koajs.com/#response).
+- Use `try/catch` around `await next()` in an upstream middleware to centralize error handling (https://koajs.com/#error-handling).
+- Keep middleware focused and order them deliberately, since the cascade depends on registration order.
+- Add only the middleware packages you need (router, body parser, CORS) to keep the core minimal.
+
+## Common pitfalls
+- Forgetting to `await next()` (or returning before it) → downstream middleware never runs and the cascade breaks; always await the chain.
+- Treating Koa like Express (e.g. expecting built-in routing/body parsing or the `(req, res, next)` signature) → Koa uses `ctx` and bundles no middleware; install the equivalents explicitly.
+
+## Examples
+```javascript
+const Koa = require('koa');
+const app = new Koa();
+
+app.use(async (ctx) => {
+  ctx.body = 'Hello World';
+});
+
+app.listen(3000);
+```
+
+## Further reading
+- https://koajs.com/#error-handling — error handling patterns
+- https://github.com/koajs/koa/blob/master/docs/guide.md — official guide
+
+## Related skills
+- ../express — predecessor framework from the same team
+- ../fastify — higher-performance Node alternative

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

@@ -0,0 +1,73 @@
+---
+name: laravel
+description: Full-featured PHP web framework with Eloquent ORM, Blade, queues, and Artisan; consult when building or maintaining a Laravel backend.
+domain: stack
+category: backend
+tags: [php, laravel, mvc, eloquent, web-framework]
+official_sources:
+  - https://laravel.com/docs
+  - https://github.com/laravel/laravel
+verified: 2026-06-16
+---
+
+# Laravel
+
+## Overview
+Laravel is a PHP web application framework with expressive syntax that provides structure for full-stack apps and API backends. It bundles routing, dependency injection, the Eloquent ORM, queues, scheduled jobs, real-time broadcasting, and testing out of the box. Read this when scaffolding, routing, persisting data, or organizing a Laravel codebase.
+
+## Official sources
+- Docs: https://laravel.com/docs
+- Repo: https://github.com/laravel/laravel (application skeleton); framework at https://github.com/laravel/framework
+- Install / download: https://laravel.com/docs/installation
+
+## Install / setup
+```bash
+# Install the Laravel installer via Composer (requires PHP + Composer)
+composer global require laravel/installer
+
+# Create a new application
+laravel new example-app
+
+# Start dev server, queue worker, and Vite together
+cd example-app
+npm install && npm run build
+composer run dev
+```
+
+## Core concepts
+- Request lifecycle: requests enter through `public/index.php`, pass through middleware, are dispatched by the router, and return a response — understanding this order is key to debugging.
+- Routing & controllers: routes in `routes/web.php` and `routes/api.php` map URIs to closures or controllers; conventions make controller/file placement predictable.
+- Eloquent ORM: each model maps to a database table; relationships, migrations, and seeders manage schema and data.
+- Service container & facades: the container resolves dependencies via injection; facades provide a static-style interface to container-bound services.
+- Blade templates: Laravel's templating engine for full-stack rendering, with components and layouts.
+- Configuration via `.env`: environment-specific values live in `.env` (not committed); the `config/` directory holds documented options.
+
+## Best practices
+- Keep `.env` out of source control; each environment supplies its own credentials (https://laravel.com/docs/installation#environment-based-configuration).
+- Serve the app from the web root (the `public/` directory), never from a subdirectory, to avoid exposing sensitive files (https://laravel.com/docs/installation#directory-configuration).
+- Use migrations and seeders for schema/data so environments stay reproducible.
+- Use starter kits for authentication scaffolding rather than rolling your own (https://laravel.com/docs/starter-kits).
+
+## Common pitfalls
+- Committing `.env` or serving from a subdirectory → exposes credentials and source; keep `.env` ignored and serve from the public root.
+- Treating Laravel only as full-stack → it also works as an API backend with Sanctum auth; choose the path that matches your frontend.
+- Forgetting to run `php artisan migrate` after switching from the default SQLite to MySQL/PostgreSQL → create the database and run migrations.
+
+## Examples
+```php
+// routes/web.php
+use Illuminate\Support\Facades\Route;
+
+Route::get('/users/{id}', function (string $id) {
+    return \App\Models\User::findOrFail($id);
+});
+```
+
+## Further reading
+- https://laravel.com/docs/lifecycle — Request lifecycle
+- https://laravel.com/docs/eloquent — Eloquent ORM
+- https://laravel.com/docs/sanctum — API authentication
+
+## Related skills
+- ../rails — another convention-driven full-stack web framework
+- ../adonisjs — TypeScript framework with comparable full-stack ergonomics

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

@@ -0,0 +1,70 @@
+---
+name: nestjs
+description: Opinionated TypeScript backend framework with DI, modules, and decorators; consult when building structured Node server-side apps.
+domain: stack
+category: backend
+tags: [nestjs, nodejs, typescript, dependency-injection, backend]
+official_sources:
+  - https://docs.nestjs.com/
+  - https://github.com/nestjs/nest
+verified: 2026-06-16
+---
+
+# NestJS
+
+## Overview
+NestJS is a progressive Node.js framework for building efficient, scalable, enterprise-grade server-side applications with TypeScript. It layers an opinionated architecture (modules, providers, dependency injection, decorators) on top of an HTTP platform (Express by default, optionally Fastify). Read this when you need a structured, testable backend with first-class DI rather than wiring middleware by hand.
+
+## Official sources
+- Docs: https://docs.nestjs.com/
+- Repo: https://github.com/nestjs/nest
+- Install / first steps: https://docs.nestjs.com/first-steps
+
+## Install / setup
+```bash
+npm i -g @nestjs/cli
+nest new project-name
+```
+The CLI can also be run without a global install via `npx @nestjs/cli@latest`. Add `--strict` to `nest new` for TypeScript's stricter feature set. (Source: https://docs.nestjs.com/first-steps)
+
+## Core concepts
+- **Modules** — each app has a root module; modules group related providers and controllers and define the dependency boundary via `@Module({})`.
+- **Controllers** — handle incoming requests and return responses; routing is declared with decorators like `@Controller()` and `@Get()`.
+- **Providers / services** — injectable classes (`@Injectable()`) holding business logic, resolved by Nest's DI container.
+- **Dependency injection** — constructor-based injection wires providers together; the container manages instantiation and scope.
+- **Pipes, guards, interceptors, filters** — cross-cutting building blocks for validation/transformation, authorization, request/response wrapping, and exception handling.
+- **Platform-agnostic core** — the same code runs on `@nestjs/platform-express` or `@nestjs/platform-fastify`.
+
+## Best practices
+- Keep one feature per module and export only what other modules need, so the DI graph stays explicit (https://docs.nestjs.com/modules).
+- Use Pipes (e.g. the built-in `ValidationPipe` with class-validator) to validate and transform incoming payloads at the boundary (https://docs.nestjs.com/techniques/validation).
+- Centralize error handling with exception filters rather than try/catch in every controller (https://docs.nestjs.com/exception-filters).
+- Lean on the CLI (`nest generate`) to scaffold modules/controllers/services consistently.
+
+## Common pitfalls
+- Forgetting to register a provider in a module's `providers` (or import its module) → "Nest can't resolve dependencies" error; declare and export providers explicitly.
+- Treating default request-scoped vs singleton lifetimes interchangeably → request-scoped providers add per-request overhead; default to singleton scope unless you truly need per-request state (https://docs.nestjs.com/fundamentals/injection-scopes).
+
+## Examples
+```typescript
+import { Module, Controller, Get } from '@nestjs/common';
+
+@Controller('cats')
+export class CatsController {
+  @Get()
+  findAll(): string {
+    return 'This action returns all cats';
+  }
+}
+
+@Module({ controllers: [CatsController] })
+export class AppModule {}
+```
+
+## Further reading
+- https://docs.nestjs.com/fundamentals/custom-providers — advanced DI patterns
+- https://docs.nestjs.com/cli/overview — CLI reference
+
+## Related skills
+- ../express — the default underlying HTTP platform
+- ../fastify — alternative high-performance platform adapter