constella 0.1.0

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

@@ -0,0 +1,60 @@
+---
+name: vercel
+description: Managed hosting optimized for frontends and serverless functions; consult for deploys, preview URLs, env vars, and the Vercel CLI.
+domain: stack
+category: infra
+tags: [hosting, serverless, frontend, deploy, cli]
+official_sources:
+  - https://vercel.com/docs
+  - https://github.com/vercel/vercel
+verified: 2026-06-16
+---
+
+# Vercel
+
+## Overview
+Vercel is a managed platform for deploying frontend apps and serverless/edge functions, with Git-driven deployments and automatic preview URLs per branch/commit. It is optimized for frameworks like Next.js but supports any static or Node-based app. Read this when you need to deploy a web frontend, wire up preview environments, or script deploys via the CLI.
+
+## Official sources
+- Docs: https://vercel.com/docs
+- Repo: https://github.com/vercel/vercel
+- CLI install: https://vercel.com/docs/cli
+
+## Install / setup
+```bash
+npm i vercel
+```
+
+## Core concepts
+- Deployments: every push produces an immutable deployment with its own URL; production is a promoted deployment.
+- Preview deployments: non-production branches/commits get unique preview URLs for review before promotion.
+- Serverless & edge functions: backend logic runs as functions co-located with the deployment rather than a long-running server.
+- Environment variables: scoped per environment (development, preview, production) and pulled locally with `vercel pull`.
+- Projects & linking: a local directory is linked to a Vercel project so CLI commands target the right deployment target.
+- `vercel.json`: optional project configuration for routes, rewrites, headers, and cron jobs.
+
+## Best practices
+- Use `vercel build` then `vercel deploy --prebuilt` (or Git integration) so CI reproduces the same build the platform runs.
+- Store secrets as environment variables scoped to the correct environment, and use `vercel env pull` to sync them locally rather than committing them.
+- In CI/CD, authenticate with the `VERCEL_TOKEN` environment variable instead of passing `--token` on the command line (per the CLI docs) to keep tokens out of process lists/logs.
+- Promote a verified preview to production rather than deploying untested code straight to prod.
+
+## Common pitfalls
+- Assuming env vars set for production are available in preview/development → they are environment-scoped and must be added per environment.
+- Putting long-running or stateful work in serverless functions → they are short-lived and stateless; use a queue or external store.
+- Skipping `vercel link` → CLI commands may target the wrong or no project.
+
+## Examples
+```bash
+# Link the directory, pull env vars, and deploy to production
+vercel link
+vercel pull --environment=production
+vercel deploy --prod
+```
+
+## Further reading
+- https://vercel.com/docs/cli — full CLI command reference
+- https://vercel.com/docs/projects/environment-variables — environment variables
+
+## Related skills
+- ../netlify — comparable managed frontend hosting platform

package/skills/stacks/meta/astro/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: astro
+description: Content-focused web framework with an islands architecture — ships zero JS by default, supports React/Vue/Svelte; consult for content sites and blogs.
+domain: stack
+category: meta
+tags: [islands, content, ssg, ssr, ui-agnostic]
+official_sources:
+  - https://docs.astro.build/
+  - https://github.com/withastro/astro
+verified: 2026-06-16
+---
+
+# Astro
+
+## Overview
+Astro (by withastro) is "the web framework for content-driven websites" — a build tool whose islands architecture ships HTML with zero client-side JavaScript by default, hydrating only the interactive components ("islands") you opt in. It is UI-agnostic, integrating React, Vue, Svelte, and more. Read this when building content sites, blogs, or marketing pages, or reasoning about partial hydration.
+
+## Official sources
+- Docs: https://docs.astro.build/
+- Repo: https://github.com/withastro/astro
+- Install / setup: https://docs.astro.build/en/install-and-setup/
+
+## Install / setup
+```bash
+npm create astro@latest
+```
+
+## Core concepts
+- **Islands architecture.** Pages are mostly static HTML; interactive UI components are isolated "islands" that hydrate independently.
+- **Zero JS by default.** Components render to HTML at build/request time and ship no client JavaScript unless explicitly hydrated.
+- **`client:*` directives.** Directives like `client:load`, `client:idle`, and `client:visible` control whether and when an island hydrates on the client.
+- **UI-framework agnostic.** Astro components (`.astro`) coexist with React, Vue, Svelte, Solid, and others via integrations.
+- **Content collections.** Type-safe collections organize and query Markdown/MDX and other content for content-driven sites.
+- **Static or server output.** Astro can output a fully static site (SSG) or render on demand (SSR) via adapters.
+
+## Best practices
+- Keep most of the page as **static Astro components** and add interactivity only as islands, preserving the zero-JS default.
+- Choose the **least eager `client:*` directive** that meets the need (e.g. `client:visible`/`client:idle` over `client:load`) to minimize JS execution.
+- Use **content collections** for Markdown/MDX so content is type-checked and queryable rather than ad-hoc imports.
+- Run **Node.js v22.12.0 or higher**, as the official install docs require (odd-numbered versions like v23 are not supported).
+
+## Common pitfalls
+- Forgetting a `client:*` directive on an interactive component → it renders as static HTML and won't be interactive; add the appropriate directive.
+- Defaulting everything to `client:load` → over-hydrates the page and defeats Astro's performance model; pick a lazier directive.
+- Using an unsupported (odd-numbered) Node.js version → install Node v22.12.0+ as the docs require.
+
+## Examples
+```astro
+---
+// src/pages/index.astro
+import Counter from '../components/Counter.jsx';
+---
+<h1>Static heading, zero JS</h1>
+<Counter client:visible />
+```
+
+## Further reading
+- Islands architecture: https://docs.astro.build/en/concepts/islands/
+- Getting started: https://docs.astro.build/en/getting-started/
+
+## Related skills
+- ../nextjs — React meta-framework for full-stack apps
+- ../gatsby — alternative React static-site framework
+- ../vite — build tooling Astro builds upon

package/skills/stacks/meta/docusaurus/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: docusaurus
+description: Docusaurus is the React-based static site generator optimized for documentation sites and blogs; consult when scaffolding with create-docusaurus, editing docusaurus.config.js or sidebars.js, authoring MDX docs, versioning, i18n, or running `npm run start`.
+domain: stack
+category: meta
+tags: [docusaurus, ssg, static-site, react, mdx, documentation, blog]
+official_sources:
+  - https://docusaurus.io/docs
+  - https://github.com/facebook/docusaurus
+  - https://docusaurus.io/docs/installation
+verified: 2026-06-17
+---
+
+# Docusaurus
+
+## Overview
+Docusaurus (by Meta / the facebook org) is a static site generator that builds documentation websites and blogs as a React single-page app rendered to static HTML. It centers on MDX content, a `docs/` + `blog/` structure, versioning, and built-in i18n and search integrations. Read this when scaffolding a Docusaurus site, editing `docusaurus.config.js` or `sidebars.js`, authoring MDX, or configuring versioning and internationalization.
+
+## Official sources
+- Docs: https://docusaurus.io/docs
+- Repo: https://github.com/facebook/docusaurus
+- Install: https://docusaurus.io/docs/installation
+
+## Install / setup
+```bash
+npx create-docusaurus@latest my-website classic
+cd my-website
+npm run start
+```
+Commands from the official installation docs: https://docusaurus.io/docs/installation
+
+## Core concepts
+- **Classic preset** — `@docusaurus/preset-classic` bundles the docs, blog, pages, and theme/CSS; configured under `presets` in the config.
+- **`docusaurus.config.js`** — central site config (title, URL, presets, plugins, `themeConfig` for navbar/footer).
+- **MDX content** — docs and blog posts are MDX, mixing Markdown with imported React components.
+- **Sidebars** — `sidebars.js` defines the docs navigation tree (autogenerated from folders or hand-authored).
+- **Docs versioning** — `npm run docusaurus docs:version <v>` snapshots docs so multiple versions ship side by side.
+- **i18n** — built-in localization writes translations under `i18n/<locale>/` and builds per-locale sites.
+- **Pages & swizzling** — standalone React/MDX pages live in `src/pages/`; "swizzling" overrides theme components for customization.
+
+## Best practices
+- Use **`create-docusaurus@latest ... classic`** to scaffold so you start from the supported preset (https://docusaurus.io/docs/installation).
+- Pass `--typescript` to scaffold a typed config and components when you want TS (https://docusaurus.io/docs/installation).
+- Cut new doc versions with **`docs:version`** rather than copying folders, to keep the version dropdown consistent (https://docusaurus.io/docs/versioning).
+- Prefer **`--eject` swizzling sparingly** and favor `--wrap`, since wrapping survives upgrades better (https://docusaurus.io/docs/swizzling).
+
+## Common pitfalls
+- Broken internal links fail `npm run build` by default → fix the link or adjust `onBrokenLinks` in the config.
+- Heavy use of ejected (swizzled) theme components → upgrades break; prefer wrapping or theme config where possible.
+
+## Examples
+```js
+// docusaurus.config.js (excerpt)
+export default {
+  title: 'My Docs',
+  url: 'https://example.com',
+  baseUrl: '/',
+  presets: [
+    ['classic', { docs: { sidebarPath: './sidebars.js' }, blog: {} }],
+  ],
+};
+```
+
+## Further reading
+- https://docusaurus.io/docs/category/guides — feature guides (docs, blog, versioning, i18n)
+- https://docusaurus.io/docs/api/docusaurus-config — full config API reference
+
+## Related skills
+- ../astro — content framework with islands and partial hydration
+- ../nextjs — React meta-framework for full-stack apps
+- ../eleventy — JavaScript SSG with flexible template languages

package/skills/stacks/meta/eleventy/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: eleventy
+description: Eleventy (11ty) is the zero-config JavaScript static site generator with pluggable template languages; consult when installing @11ty/eleventy, writing eleventy.config.js, using Nunjucks/Liquid/Markdown templates, collections, data cascade, or running `npx @11ty/eleventy --serve`.
+domain: stack
+category: meta
+tags: [eleventy, 11ty, ssg, static-site, javascript, nunjucks, markdown]
+official_sources:
+  - https://www.11ty.dev/docs/
+  - https://github.com/11ty/eleventy
+  - https://www.11ty.dev/docs/get-started/
+verified: 2026-06-17
+---
+
+# Eleventy (11ty)
+
+## Overview
+Eleventy (by the 11ty org) is a simpler, zero-config static site generator that runs on Node.js and transforms a directory of templates into HTML. It is template-language agnostic — Markdown, Nunjucks, Liquid, JavaScript, and more work out of the box — and avoids imposing a client-side framework. Read this when installing Eleventy, configuring `eleventy.config.js`, working with the data cascade, collections, or shortcodes, or running the dev server.
+
+## Official sources
+- Docs: https://www.11ty.dev/docs/
+- Repo: https://github.com/11ty/eleventy
+- Install: https://www.11ty.dev/docs/get-started/
+
+## Install / setup
+```bash
+npm install @11ty/eleventy
+npx @11ty/eleventy --serve
+```
+Commands from the official getting-started docs: https://www.11ty.dev/docs/
+
+## Core concepts
+- **Template languages** — many engines are supported per file extension (`.md`, `.njk`, `.liquid`, `.11ty.js`); pick freely or mix.
+- **Data cascade** — data merges from front matter, template/directory data files, global `_data/`, and computed data with a defined precedence.
+- **Collections** — tagged content is grouped into collections (`collections.post`) for listing, pagination, and navigation.
+- **Permalinks** — the `permalink` front-matter key controls each page's output path independent of the input path.
+- **Shortcodes & filters** — reusable functions added via config (`addShortcode`, `addFilter`) callable from any template language.
+- **Config file** — `eleventy.config.js` (or `.eleventy.js`) exports a function to register plugins, collections, passthrough copy, and input/output dirs.
+- **Passthrough copy** — `addPassthroughCopy` copies static assets (CSS, images) straight to the output untouched.
+
+## Best practices
+- Install Eleventy **locally** (devDependency) and run via `npx`, not globally, so versions are pinned per project (https://www.11ty.dev/docs/get-started/).
+- Configure passthrough copy and input/output directories in **`eleventy.config.js`** rather than CLI flags for reproducibility (https://www.11ty.dev/docs/config/).
+- Use the **data cascade** and `_data/` files for shared data instead of duplicating values in front matter (https://www.11ty.dev/docs/data-cascade/).
+- Prefer official plugins (e.g. **Image**, **RSS**, **Syntax Highlight**) over hand-rolled equivalents (https://www.11ty.dev/docs/plugins/).
+
+## Common pitfalls
+- Assets (CSS/images) missing from the build → register them with `addPassthroughCopy`; Eleventy only processes recognized template files by default.
+- Global install drift → install `@11ty/eleventy` as a project devDependency and invoke with `npx @11ty/eleventy`.
+
+## Examples
+```js
+// eleventy.config.js
+export default function (eleventyConfig) {
+  eleventyConfig.addPassthroughCopy("css");
+  eleventyConfig.addFilter("uppercase", (s) => String(s).toUpperCase());
+  return {
+    dir: { input: "src", output: "_site" },
+  };
+}
+```
+
+## Further reading
+- https://www.11ty.dev/docs/get-started/ — getting started walkthrough
+- https://www.11ty.dev/docs/data-cascade/ — data cascade reference
+
+## Related skills
+- ../astro — content framework with islands and partial hydration
+- ../hugo — Go SSG alternative with very fast builds
+- ../jekyll — Ruby SSG that powers GitHub Pages

package/skills/stacks/meta/gatsby/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: gatsby
+description: React-based static-site framework with a GraphQL data layer and plugin ecosystem; consult when building or maintaining a Gatsby site.
+domain: stack
+category: meta
+tags: [react, ssg, graphql, plugins, static-site]
+official_sources:
+  - https://www.gatsbyjs.com/docs/
+  - https://github.com/gatsbyjs/gatsby
+verified: 2026-06-16
+---
+
+# Gatsby
+
+## Overview
+Gatsby is a free, open-source, React-based framework "with performance, scalability, and security built in," used to build fast websites and apps. It pulls data from many sources into a unified GraphQL data layer and renders pages with React, with a large plugin ecosystem. Read this when building or maintaining a Gatsby site, especially content sites that aggregate data from CMSes, Markdown, or APIs.
+
+## Official sources
+- Docs: https://www.gatsbyjs.com/docs/
+- Repo: https://github.com/gatsbyjs/gatsby
+- Install / quick start: https://www.gatsbyjs.com/docs/quick-start/
+
+## Install / setup
+```bash
+npm init gatsby
+```
+
+## Core concepts
+- **React + GraphQL data layer.** Pages are React components that query a unified GraphQL layer aggregating data from many sources.
+- **Source and transformer plugins.** Plugins pull data in (CMS, filesystem, APIs) and transform it (e.g. Markdown → HTML) into the GraphQL layer.
+- **Pages.** Components in `src/pages` become routes automatically; pages can also be created programmatically in `gatsby-node`.
+- **Static generation.** Gatsby builds pages ahead of time for fast, secure static delivery (with additional rendering modes available).
+- **Configuration files.** `gatsby-config`, `gatsby-node`, `gatsby-browser`, and `gatsby-ssr` configure plugins, build-time APIs, and runtime hooks.
+
+## Best practices
+- Scaffold with **`npm init gatsby`** (optionally `npm init gatsby -- -y -ts my-site-name` for defaults + TypeScript) as the quick-start docs show.
+- Source and transform data through **plugins** rather than ad-hoc fetching so it flows into the GraphQL layer consistently.
+- Query data with **GraphQL** (page queries / `useStaticQuery`) to get exactly the data a component needs.
+- Note the quick start targets **intermediate-to-advanced developers**; beginners should start with the official tutorial first (per the docs).
+
+## Common pitfalls
+- Expecting `gatsby new` / `create-gatsby` → the current quick-start command is `npm init gatsby`.
+- Fetching data imperatively in components instead of via the GraphQL layer → use source/transformer plugins and GraphQL queries for build-time data.
+- Treating the quick start as a beginner path → it is aimed at intermediate/advanced users; use the tutorial to learn the fundamentals.
+
+## Examples
+```jsx
+// src/pages/index.js
+import * as React from "react"
+
+export default function Home() {
+  return <h1>Hello, Gatsby!</h1>
+}
+```
+
+## Further reading
+- Quick start: https://www.gatsbyjs.com/docs/quick-start/
+- Tutorial: https://www.gatsbyjs.com/docs/tutorial/
+
+## Related skills
+- ../nextjs — React framework with broader full-stack/SSR support
+- ../astro — content-focused islands framework
+- ../vite — modern build tooling for SPAs

package/skills/stacks/meta/hugo/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: hugo
+description: Hugo is the Go-based static site generator known for very fast builds; consult when scaffolding a Hugo site, configuring hugo.toml, working with content/layouts/partials, themes, taxonomies, shortcodes, or running `hugo server`.
+domain: stack
+category: meta
+tags: [hugo, ssg, static-site, go, content, markdown, themes]
+official_sources:
+  - https://gohugo.io/documentation/
+  - https://github.com/gohugoio/hugo
+  - https://gohugo.io/installation/
+verified: 2026-06-17
+---
+
+# Hugo
+
+## Overview
+Hugo (by gohugoio) is a static site generator written in Go that renders Markdown content and Go templates into a static site, optimized for very fast builds. It uses a convention-driven directory layout (content, layouts, themes) and a single self-contained binary with no runtime dependencies. Read this when scaffolding or theming a Hugo site, editing `hugo.toml`/`config`, writing templates and shortcodes, or running the dev server.
+
+## Official sources
+- Docs: https://gohugo.io/documentation/
+- Repo: https://github.com/gohugoio/hugo
+- Install: https://gohugo.io/installation/
+
+## Install / setup
+```bash
+hugo new project quickstart
+cd quickstart
+git init
+git submodule add https://github.com/gohugo-ananke/ananke themes/ananke
+echo "theme = 'ananke'" >> hugo.toml
+hugo server
+```
+Commands from the official quick start: https://gohugo.io/getting-started/quick-start/
+
+## Core concepts
+- **Content + front matter** — Markdown files under `content/` carry TOML/YAML/JSON front matter that sets title, date, draft, and custom params.
+- **Page bundles** — leaf/branch bundles colocate a page's resources (images, data) with its `index.md`/`_index.md`.
+- **Templates & lookup order** — Go `html/template` files in `layouts/` selected by a type/kind/layout lookup order (single, list, baseof, partials).
+- **Shortcodes** — reusable snippets called inside content (e.g. `{{< figure >}}`) to avoid raw HTML in Markdown.
+- **Taxonomies** — built-in tags/categories (and custom taxonomies) generate term and list pages automatically.
+- **Hugo Modules** — Go-modules-based dependency system for themes and components, an alternative to git submodules.
+- **Hugo Pipes** — asset pipeline for SCSS/PostCSS, minification, fingerprinting via `resources.*` functions.
+
+## Best practices
+- Prefer **Hugo Modules** over git submodules for themes and shared components (https://gohugo.io/hugo-modules/).
+- Keep work-in-progress as `draft: true` and preview with `hugo server -D`; drafts are excluded from production builds (https://gohugo.io/getting-started/usage/).
+- Pin the **Hugo version** and use the `extended` edition when your theme needs SCSS/WebP (https://gohugo.io/installation/).
+- Use **Hugo Pipes** (`css.Sass`, `fingerprint`) to bundle and cache-bust assets (https://gohugo.io/functions/css/sass/, https://gohugo.io/hugo-pipes/introduction/).
+
+## Common pitfalls
+- Theme not applied → the `theme` key in `hugo.toml` must match the folder name under `themes/`, and submodules must be fetched (`git submodule update --init`).
+- SCSS build error "this feature is not available in your current Hugo version" → install the **extended** edition of Hugo.
+
+## Examples
+```toml
+# hugo.toml
+baseURL = 'https://example.org/'
+languageCode = 'en-us'
+title = 'My Hugo Site'
+theme = 'ananke'
+
+[params]
+  description = 'A site built with Hugo'
+```
+
+## Further reading
+- https://gohugo.io/getting-started/quick-start/ — official quick start
+- https://gohugo.io/templates/ — template (layout) reference
+
+## Related skills
+- ../jekyll — Ruby SSG alternative, the other GitHub Pages classic
+- ../eleventy — JavaScript SSG with flexible template languages
+- ../astro — content framework with islands and partial hydration

package/skills/stacks/meta/jekyll/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: jekyll
+description: Jekyll is the Ruby blog-aware static site generator that powers GitHub Pages; consult when scaffolding a Jekyll site, editing _config.yml, working with Liquid templates, layouts, includes, collections, front matter, or running `bundle exec jekyll serve`.
+domain: stack
+category: meta
+tags: [jekyll, ssg, static-site, ruby, liquid, github-pages, markdown]
+official_sources:
+  - https://jekyllrb.com/docs/
+  - https://github.com/jekyll/jekyll
+  - https://jekyllrb.com/docs/installation/
+verified: 2026-06-17
+---
+
+# Jekyll
+
+## Overview
+Jekyll (by the jekyll org) is a blog-aware static site generator written in Ruby that transforms Markdown and Liquid templates into a static website, and is the engine behind GitHub Pages. It is built around front matter, Liquid templating, and convention-based directories (`_layouts`, `_includes`, `_posts`). Read this when scaffolding a Jekyll site, editing `_config.yml`, writing Liquid templates or collections, or deploying to GitHub Pages.
+
+## Official sources
+- Docs: https://jekyllrb.com/docs/
+- Repo: https://github.com/jekyll/jekyll
+- Install: https://jekyllrb.com/docs/installation/
+
+## Install / setup
+```bash
+gem install jekyll bundler
+jekyll new myblog
+cd myblog
+bundle exec jekyll serve
+```
+Commands from the official quickstart: https://jekyllrb.com/docs/
+
+## Core concepts
+- **Front matter** — a YAML block (`---`) at the top of a file that sets variables (layout, title, permalink) and tells Jekyll to process the file.
+- **Liquid** — the templating language (objects `{{ }}`, tags `{% %}`, filters) used to inject and transform content.
+- **Layouts & includes** — reusable templates in `_layouts/` and partial snippets in `_includes/` referenced via `layout:` and `{% include %}`.
+- **Posts & collections** — dated posts live in `_posts/` (`YYYY-MM-DD-title.md`); custom `_config.yml` collections group other content.
+- **`_config.yml`** — site-wide settings (title, plugins, build options); changes require restarting the server.
+- **Bundler & Gemfile** — gem dependencies are managed via a `Gemfile`; run Jekyll through `bundle exec` to use pinned versions.
+- **`_site` output** — the generated static site that gets deployed; should be git-ignored.
+
+## Best practices
+- Always run via **`bundle exec`** with a committed `Gemfile.lock` so builds are reproducible (https://jekyllrb.com/docs/installation/).
+- On Ruby 3.0+, add the missing `webrick` gem (`bundle add webrick`) before serving (https://jekyllrb.com/docs/).
+- For GitHub Pages, pin to the **`github-pages` gem** or build with Actions to match the hosted toolchain (https://jekyllrb.com/docs/github-pages/).
+- Use **`--livereload`** during development for automatic browser refresh (https://jekyllrb.com/docs/configuration/options/).
+
+## Common pitfalls
+- "cannot load such file -- webrick" on Ruby 3.0+ → run `bundle add webrick`.
+- Edits to `_config.yml` not taking effect → restart `jekyll serve`; the config is only read at startup.
+
+## Examples
+```yaml
+---
+layout: post
+title: "Hello Jekyll"
+date: 2026-06-17 10:00:00 -0000
+categories: intro
+---
+Welcome to my **first post** rendered by Jekyll and Liquid.
+```
+
+## Further reading
+- https://jekyllrb.com/docs/step-by-step/01-setup/ — step-by-step tutorial
+- https://jekyllrb.com/docs/liquid/ — Liquid templating reference
+
+## Related skills
+- ../hugo — Go SSG alternative with very fast builds
+- ../eleventy — JavaScript SSG with flexible template languages
+- ../astro — content framework with islands and partial hydration

package/skills/stacks/meta/nextjs/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: nextjs
+description: React meta-framework for full-stack apps — file-system routing, Server Components, SSR/SSG/ISR; consult when building or debugging a Next.js app.
+domain: stack
+category: meta
+tags: [react, ssr, rsc, app-router, vercel]
+official_sources:
+  - https://nextjs.org/docs
+  - https://github.com/vercel/next.js
+verified: 2026-06-16
+---
+
+# Next.js
+
+## Overview
+Next.js is a React framework (by Vercel) for building full-stack web applications. It layers file-system routing, server-side rendering, static generation, and React Server Components on top of React, plus built-in bundling, image optimization, and data-fetching primitives. Read this when scaffolding a Next.js app or reasoning about rendering modes, the App Router, or caching.
+
+## Official sources
+- Docs: https://nextjs.org/docs
+- Repo: https://github.com/vercel/next.js
+- Install / getting started: https://nextjs.org/docs/app/getting-started/installation
+
+## Install / setup
+```bash
+npx create-next-app@latest
+```
+
+## Core concepts
+- **App Router vs Pages Router.** The App Router (`app/` directory) is the recommended model and uses React Server Components by default; the older Pages Router (`pages/`) remains supported.
+- **File-system routing.** Routes are derived from the folder/file structure. In the App Router, special files such as `layout.tsx`, `page.tsx`, `loading.tsx`, and `error.tsx` define UI and conventions per route segment.
+- **Server vs Client Components.** Components render on the server by default; add the `"use client"` directive to opt a component into client-side interactivity (state, effects, browser APIs).
+- **Rendering strategies.** Pages can be statically rendered (SSG), dynamically rendered per request (SSR), or incrementally regenerated (ISR), giving per-route control over freshness vs performance.
+- **Root layout.** The App Router requires a root `layout.tsx` containing the `<html>` and `<body>` tags; it wraps all routes.
+- **Built-in optimizations.** First-class `next/image`, `next/font`, and a default bundler (Turbopack) ship out of the box; a `public/` folder serves static assets from the base URL.
+
+## Best practices
+- Prefer the **App Router** for new projects — it is the recommended setup that `create-next-app` enables by default (per the official installation docs).
+- Keep components as **Server Components** unless they need interactivity; only push `"use client"` to the leaf components that actually need it, to minimize client JS.
+- Use **Module Path Aliases** (`@/*` via `tsconfig.json` `paths`/`baseUrl`) for clean imports — Next.js supports these natively.
+- Use the appropriate **package.json scripts** (`next dev`, `next build`, `next start`) for each stage; run linting through your own npm scripts (Next.js 16 no longer lints automatically during `next build`).
+
+## Common pitfalls
+- Using browser-only APIs or React hooks in a Server Component → mark the component with `"use client"` or move that logic into a dedicated client component.
+- Forgetting the required root `layout.tsx` with `<html>`/`<body>` → Next.js auto-creates one in dev, but production builds expect it; add it explicitly.
+- Assuming `next build` runs the linter (older behavior) → since Next.js 16 you must invoke the linter via your own npm script.
+
+## Examples
+```tsx
+// app/page.tsx — a Server Component route at "/"
+export default function Page() {
+  return <h1>Hello, Next.js!</h1>
+}
+```
+
+## Further reading
+- App Router getting started: https://nextjs.org/docs/app/getting-started
+- create-next-app reference: https://nextjs.org/docs/app/api-reference/cli/create-next-app
+
+## Related skills
+- ../remix — React meta-framework built on web fundamentals
+- ../gatsby — React static-site framework
+- ../vite — build tool used by many React SPAs

package/skills/stacks/meta/nuxt/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: nuxt
+description: Vue meta-framework for full-stack apps — SSR, file-based routing, auto-imports, modules; consult when building or debugging a Nuxt app.
+domain: stack
+category: meta
+tags: [vue, ssr, file-routing, full-stack, nitro]
+official_sources:
+  - https://nuxt.com/docs
+  - https://github.com/nuxt/nuxt
+verified: 2026-06-16
+---
+
+# Nuxt
+
+## Overview
+Nuxt is a free, open-source framework that provides an intuitive, extendable way to build type-safe, performant, production-grade full-stack web apps and sites with Vue.js. It adds server-side rendering, file-based routing, automatic imports, data fetching, and a module ecosystem on top of Vue. Read this when scaffolding a Nuxt project or reasoning about its rendering modes, directory structure, or modules.
+
+## Official sources
+- Docs: https://nuxt.com/docs
+- Repo: https://github.com/nuxt/nuxt
+- Install / getting started: https://nuxt.com/docs/getting-started/installation
+
+## Install / setup
+```bash
+npm create nuxt@latest <project-name>
+```
+
+## Core concepts
+- **Vue + SSR by default.** Nuxt renders Vue components on the server and hydrates them on the client, with control over rendering mode per route.
+- **File-based routing.** Files in the `pages/` directory automatically become routes; the framework wires up the router for you.
+- **Auto-imports.** Components, composables, and Vue/Nuxt APIs are auto-imported, reducing boilerplate import statements.
+- **Server engine (Nitro).** Nuxt ships a server layer for API routes (`server/`) and deployment to many providers/runtimes.
+- **Data fetching.** Composables like `useFetch` / `useAsyncData` fetch data with SSR-aware caching and hydration.
+- **Modules.** A large module ecosystem (300+) extends Nuxt with integrations configured in `nuxt.config`.
+
+## Best practices
+- Use an **even-numbered, active-LTS Node.js** release (22, 24, etc.) — the official install docs require Node 22.x or newer and recommend the active LTS.
+- Let Nuxt **auto-import** components and composables rather than adding manual imports, keeping files lean.
+- Configure behavior in **`nuxt.config`** (rendering modes, modules, runtime config) rather than scattering ad-hoc setup.
+- Add functionality via official/community **modules** instead of hand-rolling integrations where a maintained module exists.
+
+## Common pitfalls
+- Using an odd-numbered Node.js version → install an even-numbered LTS release as the docs instruct, since odd versions are not the supported target.
+- Accessing browser-only APIs during SSR → guard such code so it runs only on the client (e.g. `import.meta.client` / lifecycle hooks).
+- Manually importing things Nuxt already auto-imports → remove redundant imports to avoid confusion and conflicts.
+
+## Examples
+```vue
+<!-- pages/index.vue — auto-routed to "/" -->
+<script setup>
+const { data } = await useFetch('/api/hello')
+</script>
+
+<template>
+  <h1>{{ data }}</h1>
+</template>
+```
+
+## Further reading
+- Introduction: https://nuxt.com/docs/getting-started/introduction
+- Directory structure: https://nuxt.com/docs/guide/directory-structure
+
+## Related skills
+- ../sveltekit — Svelte meta-framework with similar file-routing/SSR model
+- ../nextjs — React equivalent meta-framework
+- ../vite — build tool underpinning Nuxt's dev server