constellai 0.3.0

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

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

@@ -0,0 +1,67 @@
+---
+name: remix
+description: React meta-framework built on web fundamentals (nested routes, loaders/actions); note v2's successor is React Router v7. Consult for Remix apps.
+domain: stack
+category: meta
+tags: [react, ssr, web-standards, loaders, react-router]
+official_sources:
+  - https://remix.run/docs
+  - https://github.com/remix-run/remix
+verified: 2026-06-16
+---
+
+# Remix
+
+## Overview
+Remix is a React framework, by the remix-run team, focused on web standards (the Fetch API, forms, HTTP caching) and progressive enhancement, using nested routes with server `loader`/`action` functions for data flow. Read this when working on a Remix codebase or deciding between Remix and its successor. Important: the official v2 docs state that "the latest version of Remix is now React Router v7"; the `remix-run/remix` repo currently hosts Remix 3 (in beta as of mid-2026). Confirm which line a project targets before relying on version-specific details.
+
+## Official sources
+- Docs (v2): https://remix.run/docs
+- Repo: https://github.com/remix-run/remix
+- Install / quickstart (v2): https://remix.run/docs/en/main/start/quickstart
+
+## Install / setup
+```bash
+npx create-remix@latest
+```
+
+## Core concepts
+- **Nested routes.** The route hierarchy maps to nested UI; parent routes render layout around child route outlets, and each route can own its own data and error boundary.
+- **Loaders.** A route's `loader` runs on the server to provide data for that route on GET requests; the component reads it via `useLoaderData`.
+- **Actions.** A route's `action` runs on the server to handle mutations (typically form POSTs), pairing with HTML `<Form>` for progressive enhancement.
+- **Web standards first.** Remix builds on the Fetch `Request`/`Response`, forms, and HTTP semantics rather than bespoke abstractions.
+- **Server rendering + progressive enhancement.** Pages render on the server and work before/without client JS, then enhance once hydrated.
+
+## Best practices
+- **Decide your framework line first.** Per the official docs, new projects should generally adopt React Router v7 (Remix v2's successor); use the v2 docs only when maintaining an existing v2 app.
+- Co-locate **`loader`/`action`/component** in the route module so data and UI for a route live together.
+- Use Remix's **`<Form>`** and actions for mutations to get progressive enhancement and proper revalidation rather than manual client fetch wiring.
+- Lean on **web-standard `Request`/`Response`** objects in loaders/actions instead of framework-specific request shims.
+
+## Common pitfalls
+- Starting a brand-new project on Remix v2 without realizing it has moved to React Router v7 → check the official banner/docs and choose the current line deliberately.
+- Putting data-loading logic in client effects → move it to the route `loader` so it runs on the server with SSR and revalidation.
+- Confusing `remix-run/remix` (now Remix 3 beta) with the v2/React Router v7 lineage → verify the exact package and version a repo depends on.
+
+## Examples
+```tsx
+// app/routes/_index.tsx
+import { useLoaderData } from "@remix-run/react";
+
+export async function loader() {
+  return { message: "Hello from the server" };
+}
+
+export default function Index() {
+  const { message } = useLoaderData<typeof loader>();
+  return <h1>{message}</h1>;
+}
+```
+
+## Further reading
+- React Router v7 (Remix's successor): https://reactrouter.com/
+- Remix 3 (beta) repo README: https://github.com/remix-run/remix
+
+## Related skills
+- ../nextjs — alternative React meta-framework
+- ../vite — Remix v2 uses Vite for its dev/build pipeline

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

@@ -0,0 +1,70 @@
+---
+name: sveltekit
+description: Svelte meta-framework — file routing, SSR/SSG/SPA, load functions, form actions, deploy adapters; consult when building or debugging a SvelteKit app.
+domain: stack
+category: meta
+tags: [svelte, ssr, file-routing, adapters, vite]
+official_sources:
+  - https://svelte.dev/docs/kit
+  - https://github.com/sveltejs/kit
+verified: 2026-06-16
+---
+
+# SvelteKit
+
+## Overview
+SvelteKit is the official application framework for Svelte (maintained by sveltejs), with the tagline "Web development, streamlined." It provides file-system routing, server-side rendering, data-loading and form-action conventions, and deployment adapters, built on top of Vite. Read this when scaffolding a SvelteKit app or reasoning about routing, load functions, or deployment targets.
+
+## Official sources
+- Docs: https://svelte.dev/docs/kit
+- Repo: https://github.com/sveltejs/kit
+- Install / create a project: https://svelte.dev/docs/kit/creating-a-project
+
+## Install / setup
+```bash
+npx sv create my-app
+```
+
+## Core concepts
+- **File-system routing.** Routes live under `src/routes`; `+page.svelte`, `+layout.svelte`, `+page.server.ts`, and `+server.ts` files define pages, layouts, server logic, and endpoints by convention.
+- **Load functions.** `load` functions (in `+page.js`/`+page.server.js` and layout equivalents) fetch data for a route; server `load` runs only on the server.
+- **Form actions.** Server `actions` handle form submissions with progressive enhancement.
+- **Rendering modes.** Routes can be server-rendered, prerendered (SSG), or run as an SPA, configurable per route.
+- **Adapters.** Deployment adapters target platforms such as Node, static hosting, Cloudflare, Netlify, and Vercel.
+- **Built on Vite.** The dev server and build pipeline use Vite, giving fast HMR and the Vite plugin ecosystem.
+
+## Best practices
+- Use the official **`sv create`** scaffolder to start a project, then `npm run dev` — this is the path the docs recommend.
+- Put server-only/data-fetching logic in **`load` functions** (server variants for secrets/DB access) rather than in components.
+- Use **form actions** with `<form>` for mutations to get progressive enhancement instead of hand-written client fetches.
+- Choose the **adapter** that matches your deployment target so the build output fits the platform.
+
+## Common pitfalls
+- Importing server-only code (secrets, DB clients) into universal modules → keep it in `*.server.*` files / server `load` so it never ships to the client.
+- Expecting browser APIs to exist during SSR → guard with the `browser` check from `$app/environment` or run them in lifecycle hooks.
+- Forgetting to install/configure an adapter for your host → add the matching deployment adapter before building for production.
+
+## Examples
+```svelte
+<!-- src/routes/+page.svelte -->
+<script>
+  export let data;
+</script>
+
+<h1>{data.message}</h1>
+```
+```js
+// src/routes/+page.server.js
+export function load() {
+  return { message: 'Hello from the server' };
+}
+```
+
+## Further reading
+- Introduction: https://svelte.dev/docs/kit/introduction
+- Adapters: https://svelte.dev/docs/kit/adapters
+
+## Related skills
+- ../nuxt — Vue meta-framework with a comparable model
+- ../astro — content-focused framework that also supports Svelte islands
+- ../vite — the build tool SvelteKit is built on

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

@@ -0,0 +1,63 @@
+---
+name: vite
+description: Fast frontend build tool and dev server — native-ESM dev with instant HMR, optimized production builds; consult when scaffolding or configuring SPAs.
+domain: stack
+category: meta
+tags: [build-tool, dev-server, esm, hmr, bundler]
+official_sources:
+  - https://vite.dev/guide/
+  - https://github.com/vitejs/vite
+verified: 2026-06-16
+---
+
+# Vite
+
+## Overview
+Vite (by vitejs) is "next generation frontend tooling" — a build tool with two parts: a dev server that serves source over native ES modules with extremely fast Hot Module Replacement, and a production build command that bundles optimized static assets. It is framework-agnostic (templates for vanilla, React, Vue, Svelte, and more) and is the build layer under many meta-frameworks. Read this when scaffolding a single-page app or configuring builds, plugins, or the dev server.
+
+## Official sources
+- Docs / guide: https://vite.dev/guide/
+- Repo: https://github.com/vitejs/vite
+- Install / scaffolding: https://vite.dev/guide/#scaffolding-your-first-vite-project
+
+## Install / setup
+```bash
+npm create vite@latest
+```
+
+## Core concepts
+- **Native-ESM dev server.** In development Vite serves source files as native ES modules, so it does not bundle the whole app up front, enabling fast startup.
+- **Hot Module Replacement (HMR).** Edits update modules in place quickly without a full reload.
+- **Production build.** `vite build` produces optimized, bundled static assets (Vite uses Rolldown to bundle for production).
+- **Framework-agnostic templates.** Scaffolding offers templates for vanilla, React, Vue, Svelte, Solid, and others.
+- **Plugin API + JS API.** A typed Plugin API and programmatic JavaScript API let you extend and embed Vite.
+- **Dependency pre-bundling.** Vite pre-bundles dependencies to convert them to ESM and speed up dev page loads.
+
+## Best practices
+- Scaffold with **`npm create vite@latest`** and pick a template, as the official guide shows.
+- Run a supported **Node.js version (20.19+ or 22.12+)** per the docs; upgrade if a template warns it needs higher.
+- Use the **`public/`** folder for assets served as-is and `import` other assets so Vite can hash/optimize them.
+- Extend behavior through the **Plugin API** rather than patching the build manually.
+
+## Common pitfalls
+- Running on an unsupported Node.js version → install Node 20.19+/22.12+ (some templates require higher) as the docs state.
+- Expecting the dev server's unbundled behavior to mirror the production bundle exactly → test the output of `vite build` / `vite preview` before deploying.
+- Referencing static assets by a guessed path instead of importing them or placing them in `public/` → use imports or `public/` so paths resolve after build.
+
+## Examples
+```bash
+# Scaffold, then run the dev server
+npm create vite@latest my-app
+cd my-app
+npm install
+npm run dev
+```
+
+## Further reading
+- Features: https://vite.dev/guide/features
+- Plugin API: https://vite.dev/guide/api-plugin
+
+## Related skills
+- ../sveltekit — meta-framework built on Vite
+- ../nextjs — React meta-framework (uses its own bundler, Turbopack)
+- ../astro — content framework built on Vite tooling

package/skills/stacks/mobile/android/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: android
+description: Native Android app development with Kotlin, Jetpack Compose, and Android Studio/Gradle; consult when building native Android apps, working with activities, the lifecycle, Jetpack libraries, Gradle builds, or publishing to Google Play.
+domain: stack
+category: mobile
+tags: [android, kotlin, jetpack-compose, android-studio, gradle, mobile]
+official_sources:
+  - https://developer.android.com/develop
+  - https://github.com/android
+  - https://developer.android.com/studio
+verified: 2026-06-17
+---
+
+# Android (native)
+
+## Overview
+Native Android development builds apps that run directly on the Android OS, written primarily in Kotlin (or Java) using the Android SDK, Jetpack libraries, and Jetpack Compose for UI, built with Gradle in Android Studio. Read this when creating a native Android app, working with activities and the lifecycle, adopting Compose, configuring Gradle, or preparing a release for Google Play.
+
+## Official sources
+- Docs: https://developer.android.com/develop
+- Repo: https://github.com/android
+- Install: https://developer.android.com/studio
+
+## Install / setup
+```bash
+# Install Android Studio from developer.android.com/studio, then create a project:
+# File > New > New Project > "Empty Activity" (Compose), or via Gradle wrapper:
+./gradlew assembleDebug
+```
+Android Studio is the official IDE and SDK manager (https://developer.android.com/studio); new projects are created through its New Project wizard and built with the Gradle wrapper.
+
+## Core concepts
+- **Activity & lifecycle** — an `Activity` is an entry point/screen with `onCreate`/`onStart`/`onResume`/`onPause`/etc. callbacks.
+- **Jetpack Compose** — modern declarative UI toolkit using `@Composable` functions and state; the recommended way to build UI.
+- **Jetpack libraries** — AndroidX components: ViewModel, Lifecycle, Room, Navigation, WorkManager, DataStore.
+- **Gradle build system** — `build.gradle(.kts)` defines dependencies, SDK levels, and product flavors.
+- **Manifest** — `AndroidManifest.xml` declares components, permissions, and `minSdk`/`targetSdk`.
+- **Intents** — messages to start activities/services or pass data between components.
+- **Resources & R class** — strings, layouts, drawables in `res/`, referenced via generated `R`.
+
+## Best practices
+- Use Kotlin and Jetpack Compose for new UI (https://developer.android.com/courses/android-basics-compose/course).
+- Follow recommended app architecture: UI layer + ViewModel + data layer with unidirectional data flow (https://developer.android.com/topic/architecture).
+- Keep work off the main thread with coroutines/Flow (https://developer.android.com/kotlin/coroutines).
+- Target the latest stable `targetSdk` and test on multiple API levels (https://developer.android.com/google/play/requirements/target-sdk).
+
+## Common pitfalls
+- Blocking the main thread with network/disk work → causes ANRs; use coroutines or WorkManager.
+- Leaking `Context`/`Activity` across config changes → hold state in `ViewModel`, not the Activity.
+- Hardcoding strings/dimensions → use `res/values` resources for localization and theming.
+
+## Examples
+```kotlin
+class MainActivity : ComponentActivity() {
+    override fun onCreate(savedInstanceState: Bundle?) {
+        super.onCreate(savedInstanceState)
+        setContent {
+            MaterialTheme { Greeting("Android") }
+        }
+    }
+}
+
+@Composable
+fun Greeting(name: String) {
+    Text(text = "Hello, $name!")
+}
+```
+
+## Further reading
+- https://developer.android.com/jetpack/compose — Jetpack Compose UI
+- https://developer.android.com/topic/architecture — recommended app architecture
+- https://kotlinlang.org/docs/android-overview.html — Kotlin for Android
+
+## Related skills
+- ../flutter — cross-platform toolkit that compiles to native Android
+- ../react-native — cross-platform mobile framework targeting Android
+- ../nativescript — native Android APIs from JavaScript

package/skills/stacks/mobile/flutter/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: flutter
+description: Flutter is Google's UI toolkit for building natively compiled iOS, Android, web, and desktop apps from a single Dart codebase; consult when scaffolding with flutter create, building widget trees, managing state, or debugging hot reload, pub packages, and platform builds.
+domain: stack
+category: mobile
+tags: [flutter, dart, mobile, ios, android, cross-platform, widgets]
+official_sources:
+  - https://docs.flutter.dev/
+  - https://github.com/flutter/flutter
+  - https://docs.flutter.dev/install
+verified: 2026-06-17
+---
+
+# Flutter
+
+## Overview
+Flutter is an open-source UI framework from Google for building natively compiled applications for mobile, web, and desktop from a single Dart codebase. It renders its own widgets via the Impeller/Skia engine rather than wrapping native controls, giving consistent UI across platforms. Read this when creating a Flutter app, composing widget trees, choosing a state-management approach, or debugging hot reload and `pub` dependencies.
+
+## Official sources
+- Docs: https://docs.flutter.dev/
+- Repo: https://github.com/flutter/flutter
+- Install: https://docs.flutter.dev/install
+
+## Install / setup
+```bash
+flutter create my_app
+cd my_app
+flutter run
+```
+From the official "Create a new Flutter app" reference at https://docs.flutter.dev/reference/create-new-app (install the SDK first per https://docs.flutter.dev/install).
+
+## Core concepts
+- **Everything is a widget** — UI is a tree of immutable widgets (layout, styling, and structure are all widgets).
+- **Stateless vs Stateful** — `StatelessWidget` for static UI; `StatefulWidget` + `State` for mutable, re-rendering UI.
+- **Hot reload** — inject changed source into the running Dart VM without losing app state.
+- **BuildContext & build()** — `build()` describes UI from current config/state; `setState()` triggers rebuilds.
+- **pubspec.yaml** — declares dependencies and assets; resolved with `flutter pub get`.
+- **Material & Cupertino** — first-party widget libraries for Android-style and iOS-style design.
+- **Dart** — typed, AOT-compiled language; sound null safety is standard.
+
+## Best practices
+- Prefer composition over deep inheritance; build small, reusable widgets (https://docs.flutter.dev/perf/best-practices).
+- Use `const` constructors to let Flutter skip rebuilds of unchanged subtrees (https://docs.flutter.dev/perf/best-practices).
+- Pick a state-management approach deliberately (Provider/Riverpod/Bloc) (https://docs.flutter.dev/data-and-backend/state-mgmt/options).
+- Run `flutter analyze` and `flutter test` in CI; follow Effective Dart (https://dart.dev/effective-dart).
+
+## Common pitfalls
+- Doing expensive work in `build()` → it can run every frame; cache results or hoist out of `build`.
+- Calling `setState()` after dispose or off the widget's `State` → guard with `mounted` checks.
+- Forgetting `flutter pub get` after editing `pubspec.yaml` → run it (IDEs often do this automatically).
+
+## Examples
+```dart
+import 'package:flutter/material.dart';
+
+void main() => runApp(const MyApp());
+
+class MyApp extends StatelessWidget {
+  const MyApp({super.key});
+  @override
+  Widget build(BuildContext context) => const MaterialApp(
+        home: Scaffold(
+          body: Center(child: Text('Hello from Flutter')),
+        ),
+      );
+}
+```
+
+## Further reading
+- https://docs.flutter.dev/ui/widgets — widget catalog
+- https://dart.dev/guides — the Dart language
+- https://pub.dev/ — package registry for Flutter and Dart
+
+## Related skills
+- ../react-native — alternative cross-platform mobile framework (JS/React)
+- ../android — underlying native Android platform Flutter targets
+- ../ionic — web-tech cross-platform mobile alternative