constella 0.1.0

package/skills/engineering/testing/tdd-and-coverage/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: testing/tdd-and-coverage
+description: Test-driven development's red-green-refactor cycle and how to read code coverage as a guide rather than a goal.
+domain: engineering
+category: engineering
+tags: [tdd, testing, refactoring, coverage, red-green-refactor]
+official_sources:
+  - https://martinfowler.com/bliki/TestDrivenDevelopment.html
+  - https://martinfowler.com/bliki/TestCoverage.html
+verified: 2026-06-16
+---
+
+# TDD and Meaningful Coverage
+
+## Overview
+Test-driven development (TDD) is a workflow where you write a failing test before the production code, make it pass, then refactor — the red-green-refactor cycle. This skill pairs that discipline with a sober view of code coverage: a useful signal for finding untested code, but a poor target to optimize blindly. Read it when adopting TDD on a feature or when a team is being pressured by a coverage number.
+
+## Official sources
+- Bliki — Test Driven Development: https://martinfowler.com/bliki/TestDrivenDevelopment.html
+- Bliki — Test Coverage: https://martinfowler.com/bliki/TestCoverage.html
+
+## Core concepts
+- **Red — green — refactor.** Write a test that fails (red), write the minimum code to pass it (green), then improve the structure of new and old code without changing behavior (refactor). Repeat.
+- **List the cases first.** Fowler describes writing out a list of test cases up front, then picking one and applying red-green-refactor to it before moving to the next.
+- **Self-testing code.** Because functional code only exists to satisfy a passing test, TDD produces a suite that lets you change code with confidence.
+- **Design pressure.** Writing the test first "forces us to think about the interface to the code first," encouraging a clean separation of interface from implementation.
+- **Coverage is a tool, not a target.** Coverage shows which lines/branches ran during tests; high coverage does not prove the tests assert the right things, and a fixed coverage percentage as a quality *gate* tends to be counterproductive (Fowler).
+
+## Best practices
+- Never skip the refactor step — Fowler calls neglecting it "the most common way... to screw up TDD," leaving a messy aggregation of code fragments.
+- Keep each cycle small: one test, the simplest passing change, then clean up.
+- Use coverage to *find* untested behavior and obvious gaps, not to chase 100%; review the uncovered lines, do not just read the number.
+- Write tests that assert meaningful behavior and outcomes, so coverage reflects real verification rather than mere execution.
+
+## Common pitfalls
+- Treating a coverage percentage as the goal → use it diagnostically; high coverage with weak assertions is false comfort.
+- Writing tests after the fact and calling it TDD → the value comes from test-first design pressure and the red step proving the test can fail.
+- Dropping the refactor step once tests pass → schedule the cleanup as part of the same cycle, not "later."
+
+## Examples
+```ts
+// 1. RED — write the failing test first
+import { expect, test } from 'vitest'
+import { slugify } from './slugify'
+test('lowercases and hyphenates', () => {
+  expect(slugify('Hello World')).toBe('hello-world')
+})
+
+// 2. GREEN — minimal implementation to pass
+export const slugify = (s: string) =>
+  s.toLowerCase().replace(/\s+/g, '-')
+
+// 3. REFACTOR — improve structure/edge handling, keep tests green
+```
+
+## Further reading
+- Test Coverage (Fowler): https://martinfowler.com/bliki/TestCoverage.html
+- Self-Testing Code (Fowler): https://martinfowler.com/bliki/SelfTestingCode.html
+
+## Related skills
+- ../testing-strategy-pyramid — where TDD's unit tests sit in the portfolio
+- ../unit-integration-e2e — the runners (Vitest) used to execute the cycle

package/skills/engineering/testing/testing-strategy-pyramid/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: testing/testing-strategy-pyramid
+description: How to balance a test portfolio across unit, integration, and end-to-end layers using the test pyramid (and the testing-trophy alternative).
+domain: engineering
+category: engineering
+tags: [testing, test-pyramid, strategy, e2e, unit-tests, integration]
+official_sources:
+  - https://martinfowler.com/bliki/TestPyramid.html
+  - https://martinfowler.com/articles/practical-test-pyramid.html
+verified: 2026-06-16
+---
+
+# Testing Strategy: The Test Pyramid
+
+## Overview
+The test pyramid is a heuristic for shaping an automated test portfolio so that most checks are cheap, fast, low-level tests and only a few are slow, broad, end-to-end tests. Read this when deciding how many tests to write at each layer, or when an existing suite is slow and brittle (a sign of an inverted "ice-cream cone"). It frames the cost/speed/confidence tradeoffs that the sibling tooling and TDD skills then implement.
+
+## Official sources
+- Bliki — Test Pyramid: https://martinfowler.com/bliki/TestPyramid.html
+- Article — The Practical Test Pyramid (Ham Vocke): https://martinfowler.com/articles/practical-test-pyramid.html
+
+## Core concepts
+- **Three layers.** A broad base of many fast **unit tests**, a middle band of **service / integration tests** that exercise components through APIs (subcutaneously, bypassing the UI), and a thin top of **UI / end-to-end tests**.
+- **Cost and speed rise with the layer.** Per Fowler, tests that run end-to-end through the UI are "brittle, expensive to write, and time consuming to run," so higher layers should hold fewer tests.
+- **Granularity drives the count.** The higher a test sits, the more integration it covers per test, so fewer are needed to cover the same ground; lower-level tests isolate behavior and pinpoint failures.
+- **The pyramid is a heuristic, not a law.** Exact layer names and counts matter less than the principle: push tests down to the cheapest level that still gives the confidence you need.
+- **The ice-cream cone anti-shape.** A suite dominated by UI automation with few unit tests inverts the pyramid and becomes slow and fragile.
+- **Testing trophy (community alternative).** A widely discussed alternative weights integration tests more heavily than a strict pyramid; treat it as a perspective, not an official Fowler model (see Further reading).
+
+## Best practices
+- Write the bulk of automated tests at the unit level and use end-to-end tests as a "second line of test defense" (Fowler).
+- When a higher-level test catches a bug, reproduce it with a lower-level unit test before fixing, so the regression is guarded cheaply and locally.
+- Keep end-to-end tests focused on a few critical user journeys rather than re-checking logic already covered by unit tests.
+- Push assertions to the lowest layer that can make them; reserve UI tests for things only the UI can verify.
+
+## Common pitfalls
+- Inverting the pyramid (ice-cream cone): over-investing in UI/e2e tests → rebalance toward fast unit and service tests.
+- Treating layer labels as rigid rules → focus on the cost/speed/confidence tradeoff the shape represents, not the vocabulary.
+- Duplicating the same business logic across every layer → cover logic once at the cheapest layer, integrate (not re-test) above it.
+
+## Examples
+```text
+        /\        few   UI / end-to-end tests   (slow, broad, brittle)
+       /  \
+      /----\      some  service / integration tests
+     /      \
+    /--------\    many  unit tests              (fast, isolated, cheap)
+```
+
+## Further reading
+- The Practical Test Pyramid: https://martinfowler.com/articles/practical-test-pyramid.html
+- Testing Trophy (community, Kent C. Dodds): https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications
+
+## Related skills
+- ../unit-integration-e2e — the tooling that implements each layer
+- ../tdd-and-coverage — writing the low-level tests first and measuring meaningful coverage

package/skills/engineering/testing/unit-integration-e2e/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: testing/unit-integration-e2e
+description: The three test layers and the tooling that implements them — Vitest for unit/integration and Playwright for end-to-end browser tests.
+domain: engineering
+category: engineering
+tags: [testing, vitest, playwright, e2e, integration, unit-tests]
+official_sources:
+  - https://vitest.dev/guide/
+  - https://playwright.dev/docs/intro
+verified: 2026-06-16
+---
+
+# Unit, Integration, and End-to-End Tests
+
+## Overview
+This skill maps the three test layers to concrete tooling: **unit** and **integration** tests with Vitest (a Vite-native test runner) and **end-to-end** browser tests with Playwright. Read it when setting up a test suite in a Vite/TypeScript stack and deciding which framework runs which layer. The strategy for how many tests live at each layer is covered by the sibling test-pyramid skill.
+
+## Official sources
+- Docs: Vitest — https://vitest.dev/guide/ ; Playwright — https://playwright.dev/docs/intro
+- Repo: https://github.com/vitest-dev/vitest ; https://github.com/microsoft/playwright
+- Install: https://vitest.dev/guide/ ; https://playwright.dev/docs/intro
+
+## Install / setup
+```bash
+# Unit & integration tests (Vitest)
+npm install -D vitest
+
+# End-to-end browser tests (Playwright) — scaffolds config, tests/, browsers
+npm init playwright@latest
+```
+
+## Core concepts
+- **Unit tests** isolate a single function/module, run in milliseconds, and pinpoint failures. In Vitest they live in `*.test.ts` / `*.spec.ts` files and use the `expect` matcher API.
+- **Integration tests** exercise several units together (e.g. a service plus its DB or HTTP layer). Vitest runs these through the same runner; choose an environment such as `node` or `jsdom`/`happy-dom` for DOM-dependent code.
+- **End-to-end (e2e) tests** drive a real browser through real user journeys. Playwright is "an end-to-end test framework for modern web apps" that runs across Chromium, Firefox, and WebKit.
+- **Vitest is Vite-native:** it reads your `vite.config.*` by default, so existing Vite plugins and aliases work in tests out of the box (requires Vite >=6 and Node >=20).
+- **Playwright runs cross-browser in parallel,** headless by default, with a headed mode and an interactive UI Mode for debugging, plus an HTML reporter.
+- **Auto-waiting:** Playwright waits for elements to be actionable before acting, reducing flaky timing-based failures common in older e2e tools.
+
+## Best practices
+- Run unit/integration tests with Vitest in watch mode during development (`vitest`) and once in CI (`vitest run`).
+- Keep e2e tests few and focused on critical paths; they are the slow, broad top of the pyramid.
+- Prefer Playwright's web-first locators and auto-waiting assertions over manual sleeps to avoid flaky tests.
+- Run Playwright across the browsers your users actually use; it is supported on Windows, Linux, and macOS, locally or in CI.
+
+## Common pitfalls
+- Using Playwright (or any e2e tool) for logic that a Vitest unit test could check → push the assertion down to the cheapest layer.
+- Mixing the `@vitest/browser` Playwright provider with a separate `@playwright/test` install in one project can conflict → pick one driver per project (per upstream issues).
+- Forgetting to select a DOM environment in Vitest for component/DOM tests → set `environment: 'jsdom'` (or `happy-dom`) so `document` exists.
+
+## Examples
+```ts
+// Vitest unit test — sum.test.ts
+import { expect, test } from 'vitest'
+import { sum } from './sum'
+test('adds numbers', () => {
+  expect(sum(2, 3)).toBe(5)
+})
+```
+```ts
+// Playwright e2e test — example.spec.ts
+import { test, expect } from '@playwright/test'
+test('homepage has title', async ({ page }) => {
+  await page.goto('https://example.com')
+  await expect(page).toHaveTitle(/Example/)
+})
+```
+
+## Further reading
+- Vitest config reference: https://vitest.dev/config/
+- Playwright writing tests: https://playwright.dev/docs/writing-tests
+
+## Related skills
+- ../testing-strategy-pyramid — how many tests to write per layer
+- ../tdd-and-coverage — red-green-refactor and measuring coverage

package/skills/languages/c/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: c
+description: C is a low-level, statically typed, compiled systems programming language (ISO/IEC 9899, latest C23) used for OS kernels, embedded firmware, and performance-critical code; consult when writing or debugging C, choosing a compiler (gcc/clang), managing pointers, memory, undefined behavior, build flags, or standard-library usage.
+domain: language
+category: language
+tags: [c, c23, gcc, clang, systems, compiled, iso-9899]
+official_sources:
+  - https://en.cppreference.com/w/c
+  - https://www.iso-9899.info/wiki/The_Standard
+  - https://gcc.gnu.org/
+verified: 2026-06-17
+---
+
+# C
+
+## Overview
+C is a small, statically typed, compiled language standardized by ISO/IEC 9899 (current revision C23, published 2024) that maps closely to the machine: manual memory, pointers, and no runtime. It powers operating systems, embedded firmware, language runtimes, and libraries. Read this when writing or debugging C, picking compiler flags, reasoning about undefined behavior, or managing memory and pointers.
+
+## Official sources
+- Docs: https://en.cppreference.com/w/c
+- Repo: https://gcc.gnu.org/git.html (GCC) / https://github.com/llvm/llvm-project (Clang)
+- Install: https://gcc.gnu.org/install/
+
+## Install / setup
+```bash
+# Debian/Ubuntu: install the GNU toolchain, then compile to C23
+sudo apt install build-essential
+gcc -std=c23 -Wall -Wextra -O2 hello.c -o hello
+```
+Toolchain per https://gcc.gnu.org/install/ ; `-std=c23` flag per https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
+
+## Core concepts
+- **Pointers** — variables holding memory addresses; foundation for arrays, strings, and indirection.
+- **Manual memory** — `malloc`/`calloc`/`realloc`/`free`; no GC, so leaks and double-frees are caller's responsibility.
+- **Undefined behavior (UB)** — out-of-bounds access, signed overflow, use-after-free; the compiler may assume UB never happens.
+- **Translation units & headers** — `.c` files compiled separately; `.h` headers declare shared interfaces; the preprocessor handles `#include`/`#define`.
+- **Standard library** — `<stdio.h>`, `<stdlib.h>`, `<string.h>`, `<stdint.h>` for fixed-width ints.
+- **`const` / `volatile` / `restrict`** — qualifiers controlling mutability, optimization barriers, and aliasing.
+- **C23 additions** — `bool`/`true`/`false`/`nullptr` keywords, `constexpr`, `typeof`, `[[attributes]]`.
+
+## Best practices
+- Compile with `-Wall -Wextra` and treat warnings as errors (`-Werror`) (https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html).
+- Use sanitizers during development: `-fsanitize=address,undefined` to catch memory and UB bugs (https://clang.llvm.org/docs/AddressSanitizer.html).
+- Prefer fixed-width types from `<stdint.h>` (`int32_t`, `size_t`) over assuming `int` width (https://en.cppreference.com/w/c/types/integer).
+- Always check return values of `malloc`, `fopen`, and I/O calls; free every allocation exactly once.
+
+## Common pitfalls
+- Reading/writing past array bounds → use ASan and validate indices; never rely on UB.
+- Forgetting to null-terminate strings or off-by-one in buffer sizes → use `snprintf` and size the buffer for the terminator.
+- Returning a pointer to a stack local → allocate on the heap or pass a caller-owned buffer.
+
+## Examples
+```c
+#include <stdio.h>
+#include <stdlib.h>
+
+int main(void) {
+    int *xs = malloc(3 * sizeof *xs);
+    if (!xs) return EXIT_FAILURE;
+    for (int i = 0; i < 3; i++) xs[i] = i * i;
+    for (int i = 0; i < 3; i++) printf("%d\n", xs[i]);
+    free(xs);
+    return EXIT_SUCCESS;
+}
+```
+
+## Further reading
+- https://en.cppreference.com/w/c — community C standard-library and language reference
+- https://gcc.gnu.org/onlinedocs/gcc/ — GCC command and option documentation
+- https://www.iso-9899.info/wiki/The_Standard — index of C standard editions and public working drafts
+
+## Related skills
+- ../objectivec — Objective-C is a strict superset of C with Smalltalk-style messaging
+- ../lua — Lua is implemented in pure ISO C and embeds via the C API

package/skills/languages/clojure/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: clojure
+description: Clojure is a dynamic, functional Lisp dialect on the JVM with immutable persistent data structures and strong concurrency support; consult when writing Clojure, using the Clojure CLI/deps.edn or Leiningen, working with the REPL, transducers, atoms/refs/agents, or interop with Java and ClojureScript.
+domain: language
+category: language
+tags: [clojure, lisp, jvm, functional, repl, deps-edn, clojurescript]
+official_sources:
+  - https://clojure.org/
+  - https://github.com/clojure/clojure
+  - https://clojure.org/guides/install_clojure
+verified: 2026-06-17
+---
+
+# Clojure
+
+## Overview
+Clojure is a dynamic, functional Lisp that compiles to JVM bytecode (with ClojureScript targeting JavaScript), built around immutable persistent data structures and a REPL-driven workflow. It emphasizes pure functions, explicit state, and easy Java interop. Read this when writing Clojure, setting up the CLI/deps.edn, using the REPL, or reasoning about its concurrency primitives.
+
+## Official sources
+- Docs: https://clojure.org/
+- Repo: https://github.com/clojure/clojure
+- Install: https://clojure.org/guides/install_clojure
+
+## Install / setup
+```bash
+# macOS (Homebrew); Java 11+ required
+brew install clojure/tools/clojure
+clj  # start a REPL
+```
+Command per https://clojure.org/guides/install_clojure (Linux uses the `linux-install.sh` script from the same page).
+
+## Core concepts
+- **Immutable persistent data structures** — lists, vectors, maps, sets are values; "updates" return new structures via structural sharing.
+- **REPL-driven development** — evaluate forms interactively against a running program; the core of the Clojure workflow.
+- **Homoiconicity & macros** — code is data (s-expressions); `defmacro` transforms forms at compile time.
+- **deps.edn & the CLI** — `clj`/`clojure` resolve dependencies from `deps.edn`; tools.deps is the official build/run mechanism.
+- **Sequences & laziness** — the `seq` abstraction plus lazy sequences over collections; `map`/`filter`/`reduce` are universal.
+- **Concurrency primitives** — `atom` (uncoordinated sync state), `ref`+`dosync` (STM), `agent` (async), `volatile`.
+- **Java interop** — call any Java via `(.method obj)`, `(Class/staticMethod)`, and `(new Class)` / `Class.`.
+- **Transducers** — composable, source-independent transformations decoupled from input/output collections.
+
+## Best practices
+- Drive development from the REPL; reload changed namespaces rather than restarting (https://clojure.org/guides/repl/introduction).
+- Prefer pure functions on immutable data; isolate state in `atom`/`ref` and mutate explicitly (https://clojure.org/reference/atoms).
+- Use `deps.edn` aliases for tasks (test, build, run) instead of ad-hoc scripts (https://clojure.org/guides/deps_and_cli).
+- Add type/shape checks with `clojure.spec` at boundaries (https://clojure.org/guides/spec).
+
+## Common pitfalls
+- Holding the head of a large lazy seq → memory blowup; consume eagerly with `doall`/`reduce` or avoid retaining the binding.
+- Expecting side effects inside lazy `map` to run → use `doseq`/`run!` for effects, not lazy sequences.
+- Confusing `=` (value equality) with `identical?` (reference) on immutable values → use `=`.
+
+## Examples
+```clojure
+(defn word-freq [text]
+  (->> (re-seq #"\w+" text)
+       (map clojure.string/lower-case)
+       (frequencies)
+       (sort-by val >)))
+
+(word-freq "the cat the dog the cat")
+;; => ([\"the\" 3] [\"cat\" 2] [\"dog\" 1])
+```
+
+## Further reading
+- https://clojure.org/reference/documentation — official language reference index
+- https://clojuredocs.org/ — community examples for core functions
+- https://clojure.org/guides/deps_and_cli — deps.edn and CLI guide
+
+## Related skills
+- ../haskell — another functional language emphasizing immutability and pure functions
+- ../erlang — shares a focus on concurrency and the actor/process model
+- ../lua — fellow dynamically typed embeddable language

package/skills/languages/cpp/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: cpp
+description: High-performance, statically typed systems language with zero-overhead abstractions; consult for C++ syntax, RAII, and setup.
+domain: language
+category: language
+tags: [cpp, systems, performance, native, compiled]
+official_sources:
+  - https://en.cppreference.com/
+  - https://github.com/cplusplus/draft
+verified: 2026-06-16
+---
+
+# C++
+
+## Overview
+C++ is a statically typed, compiled systems programming language offering low-level control and high performance alongside high-level abstractions (classes, templates, the standard library) with a zero-overhead philosophy. It is standardized by ISO/IEC JTC1/SC22/WG21, with C++23 the most recent published standard and C++26 in progress. Read this when writing performance-critical native code, managing manual resources, or setting up a C++ toolchain.
+
+## Official sources
+- Docs (community reference): https://en.cppreference.com/
+- Repo (standard draft sources): https://github.com/cplusplus/draft
+- Get started: https://isocpp.org/get-started
+
+## Install / setup
+C++ has no single installer; you install a compiler. The official ISO C++ "Get Started" page lists free compilers including GCC (`g++`), Clang, and Visual C++ Community. Typical install of GCC on Debian/Ubuntu:
+
+```bash
+sudo apt install g++
+```
+
+Source / recommended compilers: https://isocpp.org/get-started
+
+## Core concepts
+- RAII (Resource Acquisition Is Initialization) — tie resource lifetime to object scope so destructors release resources deterministically.
+- Value semantics and the rule of move — objects are copied by default; move semantics (`std::move`, move constructors) transfer ownership efficiently.
+- Templates and generic programming — compile-time polymorphism over types; the STL (containers, algorithms, iterators) is built on them.
+- Smart pointers — `std::unique_ptr` and `std::shared_ptr` express ownership and automate deallocation, replacing raw `new`/`delete`.
+- The standard library — containers (`vector`, `map`), algorithms, strings, and ranges (cppreference is the canonical reference).
+- Undefined behavior — the standard leaves some operations (out-of-bounds access, signed overflow, use-after-free) with no defined meaning.
+
+## Best practices
+- Prefer RAII and smart pointers over manual `new`/`delete` to avoid leaks and double-frees (per the C++ Core Guidelines, linked from isocpp.org).
+- Use standard-library containers and algorithms instead of hand-rolled loops and C arrays.
+- Pass large objects by `const&`; use move semantics to avoid needless copies.
+- Compile with warnings on (`-Wall -Wextra`) and target a recent standard (e.g. `-std=c++23`).
+
+## Common pitfalls
+- Dangling pointers/references from use-after-free or returning references to locals → use smart pointers and value semantics; this is undefined behavior.
+- Out-of-bounds container/array access → undefined behavior; use bounds-checked access (`.at()`) or `std::span`/ranges where appropriate.
+- Manual memory management with raw `new`/`delete` leaking on early return/exception → use `unique_ptr`/`shared_ptr` and RAII.
+
+## Examples
+```cpp
+#include <memory>
+#include <string>
+#include <iostream>
+
+struct Greeter {
+    std::string greet(const std::string& name) const {
+        return "Hello, " + name;
+    }
+};
+
+int main() {
+    auto g = std::make_unique<Greeter>();   // RAII: freed automatically
+    std::cout << g->greet("ada") << '\n';
+}
+```
+
+## Further reading
+- Language and library reference: https://en.cppreference.com/
+- ISO C++ home and Core Guidelines: https://isocpp.org/get-started
+
+## Related skills
+- ../swift — a memory-safe systems language that interoperates with C/C++
+- ../scala — managed-VM language for contrast with native compilation

package/skills/languages/csharp/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: csharp
+description: Modern .NET object-oriented language compiled by Roslyn; consult for OOP, async/await, LINQ, and the dotnet CLI.
+domain: language
+category: language
+tags: [csharp, dotnet, roslyn, async, linq]
+official_sources:
+  - https://learn.microsoft.com/en-us/dotnet/csharp/
+  - https://github.com/dotnet/roslyn
+  - https://dotnet.microsoft.com/download
+verified: 2026-06-16
+---
+
+# C#
+
+## Overview
+C# is a modern, statically typed, object-oriented language for the .NET platform. It is compiled by Roslyn (the open-source .NET compiler platform, which also exposes rich code-analysis APIs) and runs on the cross-platform .NET runtime. It is used for web (ASP.NET Core), desktop, mobile (MAUI), cloud, and game development. Read this for OOP fundamentals, async/await, LINQ, and the dotnet CLI.
+
+## Official sources
+- Docs: https://learn.microsoft.com/en-us/dotnet/csharp/
+- Repo (Roslyn compiler): https://github.com/dotnet/roslyn
+- Install / download (.NET SDK): https://dotnet.microsoft.com/download
+
+## Install / setup
+Install the .NET SDK from https://dotnet.microsoft.com/download. Then create and run a console project (per https://learn.microsoft.com/en-us/dotnet/core/tutorials/with-visual-studio-code):
+```bash
+dotnet new console -o HelloWorld
+cd HelloWorld
+dotnet run
+```
+
+## Core concepts
+- Classes, structs, and records: reference types (`class`), value types (`struct`), and `record` types for concise immutable data with value equality.
+- Static typing with type inference: `var` infers the compile-time type; generics provide type-safe collections and APIs.
+- Properties and access modifiers: encapsulate fields with auto-properties; `public`/`private`/`protected`/`internal` control visibility.
+- async/await: the Task-based asynchronous pattern for non-blocking I/O; `async` methods return `Task`/`Task<T>`.
+- LINQ: language-integrated query over collections and other sources, using query or method syntax.
+- Nullable reference types: opt-in compiler analysis (`string?`) that flags potential null dereferences.
+- Exceptions and `using`: structured error handling via `try`/`catch`/`finally`; `using` disposes `IDisposable` resources deterministically.
+
+## Best practices
+- Enable nullable reference types and address compiler nullability warnings to avoid `NullReferenceException`.
+- Use `async`/`await` for I/O-bound work and avoid blocking on tasks (e.g. `.Result`/`.Wait()`), which can deadlock.
+- Dispose `IDisposable` resources with `using` declarations/statements rather than manual cleanup.
+- Prefer LINQ and immutable `record` types for clear, declarative data handling.
+
+## Common pitfalls
+- Blocking on async code with `.Result` or `.Wait()` → can deadlock and wastes threads; `await` instead, all the way up.
+- Dereferencing null references → enable nullable reference types and handle `null` at boundaries.
+- Forgetting to dispose resources (streams, connections) → use `using` to release them deterministically.
+- Catching `Exception` broadly and swallowing it → catch specific exceptions and let unexpected ones propagate.
+
+## Examples
+```csharp
+using System;
+using System.Net.Http;
+using System.Threading.Tasks;
+
+class Program
+{
+    static async Task Main()
+    {
+        using var client = new HttpClient();
+        string body = await client.GetStringAsync("https://example.com");
+        Console.WriteLine(body.Length);
+    }
+}
+```
+
+## Further reading
+- A tour of C#: https://learn.microsoft.com/en-us/dotnet/csharp/tour-of-csharp/overview
+- C# language reference: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/
+
+## Related skills
+- ../java — another statically typed, object-oriented, VM-hosted language

package/skills/languages/dart/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: dart
+description: Client-optimized, strongly typed language for building apps on any platform (powers Flutter); consult for syntax and setup.
+domain: language
+category: language
+tags: [dart, flutter, client, cross-platform, null-safety]
+official_sources:
+  - https://dart.dev/guides
+  - https://github.com/dart-lang/sdk
+verified: 2026-06-16
+---
+
+# Dart
+
+## Overview
+Dart is an approachable, portable, and productive language for building high-quality apps on any platform; it is the language behind the Flutter UI toolkit. It is strongly typed with sound null safety and compiles to native machine code (mobile/desktop/backend) or to JavaScript and WebAssembly for the web. Read this when writing Dart, building Flutter apps, or setting up the SDK.
+
+## Official sources
+- Docs: https://dart.dev/guides
+- Repo: https://github.com/dart-lang/sdk
+- Install / download: https://dart.dev/get-dart
+
+## Install / setup
+From the official Get Dart page. macOS via Homebrew, verbatim:
+
+```bash
+brew tap dart-lang/dart
+brew install dart
+```
+
+Windows via Chocolatey, verbatim from the same page:
+
+```powershell
+choco install dart-sdk
+```
+
+Source: https://dart.dev/get-dart (note: the Flutter SDK already includes the full Dart SDK)
+
+## Core concepts
+- Sound null safety — types are non-nullable by default; nullable types use `?`, and the compiler guarantees non-null values are never null at runtime.
+- Strong static typing with inference — `var`/`final`/`const` plus full type inference; `dynamic` opts out when needed.
+- Everything is an object — including numbers and functions; functions are first-class values.
+- Async with Futures and Streams — `async`/`await`, `Future<T>`, and `Stream<T>` model single and multiple asynchronous results.
+- Isolates — concurrency via isolated memory units that communicate by message passing (no shared mutable state).
+- AOT and JIT compilation — JIT with hot reload during development, ahead-of-time native or JS/Wasm for release.
+
+## Best practices
+- Follow Effective Dart (the official style/usage/design guide on dart.dev) for idiomatic code.
+- Embrace sound null safety: prefer non-nullable types and handle nullability explicitly rather than reaching for `!`.
+- Use `final`/`const` for values that don't change; mark compile-time constants `const`.
+- Use the Dart SDK tooling (`dart analyze`, `dart format`, `dart test`) and pub for packages.
+
+## Common pitfalls
+- Overusing the null-assertion operator `!` → throws if the value is null at runtime; prefer null-aware operators (`?.`, `??`) and proper null checks.
+- Assuming shared mutable state across isolates → isolates do not share memory; pass data via messages.
+- Forgetting to `await` a `Future` → the code continues before the async work completes, causing race conditions.
+
+## Examples
+```dart
+class Greeter {
+  final String prefix;
+  const Greeter(this.prefix);
+
+  String greet(String? name) =>
+      '$prefix, ${(name == null || name.isEmpty) ? 'world' : name}';
+}
+
+void main() {
+  const g = Greeter('Hello');
+  for (final n in ['ada', 'grace']) {
+    print(g.greet(n));
+  }
+}
+```
+
+## Further reading
+- Language and library guides: https://dart.dev/guides
+- Effective Dart: https://dart.dev/guides (Effective Dart section)
+
+## Related skills
+- ../swift — another client-optimized, null-safe app language
+- ../../stacks — Flutter and Dart web frameworks build on this language

package/skills/languages/elixir/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: elixir
+description: Dynamic, functional language on the BEAM (Erlang VM) for scalable, fault-tolerant apps; consult for syntax, OTP, and setup.
+domain: language
+category: language
+tags: [elixir, functional, beam, erlang, concurrency]
+official_sources:
+  - https://elixir-lang.org/docs.html
+  - https://github.com/elixir-lang/elixir
+verified: 2026-06-16
+---
+
+# Elixir
+
+## Overview
+Elixir is a dynamic, functional language designed for building scalable and maintainable applications, running on the Erlang VM (BEAM) and inheriting its lightweight-process concurrency and fault tolerance. It pairs an approachable Ruby-influenced syntax with OTP's battle-tested distribution and supervision model. Read this when writing Elixir, structuring OTP applications, or setting up the toolchain.
+
+## Official sources
+- Docs: https://elixir-lang.org/docs.html
+- Repo: https://github.com/elixir-lang/elixir
+- Install / download: https://elixir-lang.org/install.html
+
+## Install / setup
+The official install page lists install scripts as the quickest method. Verbatim (Bash):
+
+```bash
+curl -fsSO https://elixir-lang.org/install.sh && sh install.sh elixir@1.20.1 otp@28.4
+```
+
+PowerShell (Windows), verbatim from the same page:
+
+```powershell
+curl.exe -fsSO https://elixir-lang.org/install.bat && .\install.bat elixir@1.20.1 otp@28.4
+```
+
+Source: https://elixir-lang.org/install.html (Homebrew alternative: `brew install elixir`)
+
+## Core concepts
+- Immutability — data is never mutated in place; functions return new transformed values.
+- Pattern matching — the `=` match operator and function-head matching destructure and branch on data shape.
+- The pipe operator `|>` — threads a value through a series of function calls for readable data pipelines.
+- Processes and the actor model — lightweight BEAM processes communicate by message passing, not shared memory.
+- OTP behaviours — GenServer, Supervisor, and Application provide standard patterns for stateful, supervised, fault-tolerant systems.
+- Mix — the build tool for creating projects, running tasks, managing dependencies (Hex), and testing.
+
+## Best practices
+- Embrace the "let it crash" philosophy: supervise processes so failures restart cleanly rather than defensively guarding every error.
+- Use pattern matching in function heads instead of nested conditionals for clear, declarative branching.
+- Structure work into small pure functions and compose them with the pipe operator.
+- Use Mix and the Hex package manager for dependencies and project tasks.
+
+## Common pitfalls
+- Treating BEAM processes like OS threads or assuming shared mutable state → state lives inside a process and is changed only via messages.
+- Overusing `try/rescue` for control flow → prefer pattern matching and supervisors ("let it crash").
+- Blocking a GenServer's single message loop with long synchronous work → offload heavy work to a separate process or Task.
+
+## Examples
+```elixir
+defmodule Greeter do
+  def greet(name), do: "Hello, #{name}"
+end
+
+["ada", "grace"]
+|> Enum.map(&String.capitalize/1)
+|> Enum.each(&IO.puts(Greeter.greet(&1)))
+```
+
+## Further reading
+- Getting started & guides: https://elixir-lang.org/docs.html
+- Installation details and version managers: https://elixir-lang.org/install.html
+
+## Related skills
+- ../ruby — syntactic inspiration for Elixir
+- ../scala — another language emphasizing functional programming on a managed VM