pi-rnd 0.2.1

package/skills/kiss-practices/bash.md

@@ -0,0 +1,70 @@
+# Bash — KISS Rules
+
+## Script Structure
+
+- Start with `set -euo pipefail` — don't add custom error trapping unless you need cleanup beyond what `trap` provides
+- Don't create bash "frameworks" with option parsers, logging libraries, or plugin systems — if the script is that complex, use a real language
+- Don't split a simple script into multiple sourced files — one file is easier to read, copy, and debug
+- Don't add `usage()` functions for scripts with 1-2 arguments — a comment at the top is enough
+
+## Variables and Quoting
+
+- Always double-quote variables — `"$var"` not `$var`; the exceptions (glob patterns, intentional splitting) should be commented
+- Use `local` in functions — don't pollute the global scope
+- Don't use `ALLCAPS` for local variables — reserve ALLCAPS for environment variables and constants
+- Use `readonly` for constants instead of `declare -r` — it's shorter and clearer
+- Don't use arrays when a simple loop over arguments or lines works — arrays add complexity in bash
+
+## Conditionals and Control Flow
+
+- Use `[[ ]]` not `[ ]` — double brackets handle quoting and patterns better; don't mix styles
+- Don't add `else` branches that just echo an error and exit — let `set -e` handle it
+- Use `&&` and `||` for simple one-liners — don't wrap a single command in `if/then/fi`
+- Don't use `case` for 2 options — `if/elif` is clearer when there are few branches
+
+## Pipelines and Commands
+
+- Use `$(command)` not backticks — backticks don't nest and are harder to read
+- Don't pipe to `grep | awk | sed` when a single `awk` or `sed` does the job
+- Don't use `cat file | grep` — use `grep pattern file` directly
+- Don't add `2>/dev/null` to silence errors you should be fixing
+- Use `mktemp` for temp files — don't hardcode `/tmp/myscript.tmp`
+- Don't use `for`/`while`/`until` loops in the Bash tool — they hang. Use the Glob tool to list files by pattern and the Grep tool to search content. For cross-referencing multiple items, use Grep with alternation patterns or multiple parallel tool calls
+
+## Error Handling
+
+- Don't wrap every command in `if ! command; then echo "failed"; exit 1; fi` — `set -e` already exits on failure
+- Use `trap 'cleanup' EXIT` for cleanup, not manual cleanup before every exit point
+- Don't add retry loops unless the operation is genuinely transient (network calls, lock contention)
+
+## Naming
+
+- Use full words, not abbreviations — `destination` not `dst`, `process_file` not `proc_f`
+- Name functions after what they do, not how — `send_notification` not `run_curl_loop`
+- Don't use magic numbers — assign them to `readonly` variables with descriptive names
+
+## Function Design
+
+- Keep functions under ~30 lines — if it's longer, it's doing too much
+- Do one thing per function — if you need "and" to describe what it does, split it
+- Prefer 0–2 parameters; more than 3 is a sign the function needs decomposing
+- Don't use flag parameters (`process_file 1` vs `process_file 0`) — write two named functions instead
+
+## Comments
+
+- Write self-explanatory code — a comment that restates what the code does adds no value
+- Explain intent and non-obvious constraints, not mechanism — `# retry: S3 returns 503 during deploys`
+- Remove commented-out code — use git history instead
+
+## Code Smells
+
+- Duplication across functions or scripts — extract a shared helper rather than copy-pasting
+- Global mutable state — functions that set globals are hard to test and compose; use `local` and stdout
+- Deep nesting (3+ levels of `if`/`for`) — extract inner blocks into named functions
+- Long parameter lists — group related values or restructure the calling code
+
+## Polish
+
+- Order functions by abstraction level: the main entry point first, low-level helpers at the bottom — readers should be able to read top-to-bottom without scrolling back up for context
+- Stick to one naming pattern per script: `verb_noun` (`send_report`, `parse_args`) or `noun_verb` — don't mix conventions mid-file
+- Comment placement: one comment per non-obvious block, placed above the block — don't interleave inline comments with code when a block comment would be clearer

package/skills/kiss-practices/duckdb.md

@@ -0,0 +1,30 @@
+# DuckDB — KISS Rules
+
+## Queries
+
+- Use `read_csv()`, `read_parquet()`, `read_json()` directly in queries — don't create tables from files unless you need to query them repeatedly
+- Use simple SQL over CTEs when a single `SELECT` with joins and subqueries is clear enough
+- Don't create views for one-off analysis queries — views are for queries reused from multiple places
+- Use `COPY ... TO` for exporting results — don't pipe through application code when DuckDB can write directly
+- Use `duckdb -c 'SQL'` for one-shot queries — don't create persistent databases for throwaway analysis
+
+## Types & Schema
+
+- Let DuckDB infer types from files — don't specify column types manually unless inference gets it wrong
+- Use `DESCRIBE` or `SUMMARIZE` to understand data before writing queries — don't guess at column names or types
+- Don't create custom types or macros for single-use transformations
+
+## Analysis Patterns
+
+- Use window functions (`OVER`, `PARTITION BY`) for ranking and running calculations — don't self-join
+- Use `GROUP BY ALL` when grouping by all non-aggregated columns — don't list every column
+- Use `EXCLUDE` in `SELECT * EXCLUDE (col)` to drop columns — don't list every column you want to keep
+- Use `UNPIVOT` and `PIVOT` instead of manual `CASE WHEN` for reshaping data
+- Use `QUALIFY` to filter window function results — don't wrap in a subquery
+
+## Polish
+
+- Name CTEs and subqueries after what they represent, not how they compute — `monthly_revenue` not `summed_and_grouped`
+- Group queries in a script by logical phase: ingestion, transformation, output — separate phases with a blank line and a comment marker
+- Within a script, pick one alias style (`t1`/`t2` vs. `orders`/`items`) and stick with it throughout — mixed alias conventions make joins hard to scan
+- Comment non-obvious `WHERE` clauses and filter constants: explain the business rule, not the SQL operator

package/skills/kiss-practices/elixir.md

@@ -0,0 +1,38 @@
+# Elixir / Phoenix / Ecto — KISS Rules
+
+## Language & OTP
+
+- Use pattern matching over conditionals — `case`/`cond`/`with` chains are a smell if a function head match works
+- Don't add GenServers when a plain module with functions will do — GenServer is for state, not namespacing
+- Don't add supervision trees for processes that don't need restart semantics
+- Don't create Behaviours for a single implementation — extract when the second implementation appears
+- Don't create Protocol implementations for a single type — protocols are for polymorphism across types
+- Use `Enum` pipelines over `Stream` unless you measurably need laziness
+- Don't reach for macros when a function works — macros are for compile-time transformations, not DRY
+
+## Phoenix
+
+- Use standard Phoenix generators (`mix phx.gen.html`, `mix phx.gen.json`) and follow their conventions
+- Don't replace standard CRUD controllers with LiveView unless there's a real interactivity need
+- Keep controllers thin — one context call, render response
+- Don't create nested route scopes for simple flat routes
+- Use Phoenix's built-in form helpers and changesets before reaching for custom validation layers
+- Don't add API versioning until you need it
+- Use `Phoenix.Component` for markup reuse — don't build a component library before you have 3+ uses
+
+## Ecto
+
+- Keep schemas lean — schemas define data shape, not business logic
+- Use simple `Ecto.Query` — avoid building composable query builder abstractions
+- Don't wrap `Repo` calls in context modules unless the context adds real logic beyond pass-through
+- Write migrations as simple `alter table` / `create table` — don't create migration helper modules
+- Don't add database indexes speculatively — add them when a query is measurably slow
+- Use `Ecto.Changeset` validations over custom validation modules
+- Don't create separate `Repo` functions for every possible query variation — compose queries at the call site
+
+## Polish
+
+- Order functions within a module: public interface first (`def`), private helpers last (`defp`) — keep the public contract at the top so callers don't have to scroll past implementation details
+- Within a context module, use one naming convention for the CRUD layer: `get_user` / `create_user` / `update_user` / `delete_user` — don't mix `fetch_`, `load_`, and `get_` for the same concept
+- Comments in Elixir belong in `@doc` and `@moduledoc` — don't add `# ...` comments where a doc attribute would serve; reserve inline comments for non-obvious pattern-match guards or pipeline branch rationale
+- Group related `def` clauses together — don't scatter pattern-match heads for the same function across the module interspersed with unrelated functions

package/skills/kiss-practices/javascript.md

@@ -0,0 +1,43 @@
+# JavaScript / TypeScript / CSS / HTML — KISS Rules
+
+## JavaScript & TypeScript
+
+- Use native APIs before reaching for packages — `fetch` over axios, `URL` over uri-parser, `structuredClone` over lodash.cloneDeep
+- Don't add TypeScript generics when concrete types work — `function getUser(id: string): User` over `function get<T>(id: string): T`
+- Don't create utility files for one-time helpers — inline the logic at the call site
+- Don't add abstraction layers over `fetch` — a wrapper adds indirection without value until you need interceptors
+- Don't add state management libraries for local component state — `useState` is enough until you measurably need shared state
+- Don't create custom hooks for trivial effects — `useEffect` with a comment is clearer than `useDataFetcher`
+- Use `async/await` over `.then()` chains — but don't add `try/catch` around every await unless you handle the error differently than letting it propagate
+- Don't add barrel files (`index.ts` re-exports) until imports are genuinely painful
+- Don't type every intermediate variable — let TypeScript infer
+
+## CSS
+
+- Use simple selectors — avoid BEM/SMACSS methodology unless the project already uses it
+- Don't create CSS utility classes for one-off styles — inline styles or scoped classes are fine
+- Use CSS custom properties for values used 3+ times, not for every color and spacing
+- Don't add a CSS-in-JS library when a stylesheet works
+- Flexbox and Grid solve most layouts — don't reach for layout libraries
+
+## Tailwind CSS
+
+- Use utility classes directly in markup — don't extract to `@apply` unless a pattern repeats 3+ times
+- Don't create custom Tailwind plugins for one-off design tokens — use arbitrary values (`bg-[#1a1a2e]`) instead
+- Don't add `@layer components` abstractions for single-use component styles
+- Use Tailwind's built-in responsive prefixes (`md:`, `lg:`) — don't create custom breakpoint utilities
+- Don't override Tailwind's spacing/color scales unless the project has a design system that conflicts
+- Use `class:` conditional syntax (Svelte) or template literals over `clsx`/`classnames` for simple conditionals — reach for utility libraries only when conditional logic is genuinely complex
+
+## HTML
+
+- Use semantic HTML elements (`nav`, `main`, `article`, `section`) over `div` soup
+- Don't add ARIA attributes that duplicate native semantics — a `<button>` doesn't need `role="button"`
+- Don't create component abstractions for simple markup — a `<Card>` component wrapping a `<div>` with a class adds indirection for no reuse benefit until it appears 3+ times
+
+## Polish
+
+- Within a module, pick one naming convention for async functions and stick to it: `fetchUser` / `loadUser` — don't mix `fetch*`, `load*`, and `get*` for the same operation type
+- Order exports by public surface first, unexported helpers at the bottom — readers should see the API before implementation details
+- Comments should explain WHY the code makes a non-obvious choice — e.g., `// Safari 16 doesn't support X, so we use Y`; remove comments that just restate what the next line does
+- Keep CSS class naming consistent within a component tree: if the project uses BEM, don't introduce utility-class-style names for one component

package/skills/kiss-practices/koka.md

@@ -0,0 +1,34 @@
+# Koka — KISS Rules
+
+## Effects
+
+- Declare effects explicitly in function signatures — don't use polymorphic effect variables when specific effects are known
+- Don't mask effects to make types look simpler — visible effects are the point; hiding them defeats Koka's design
+- Let implicit handler resolution work — don't create explicit handlers for effects that have obvious default handlers
+- Don't nest handlers without clear semantic intent — prefer flat handler stacking
+
+## Data Types
+
+- Use value types (structs) for small immutable data — the compiler eliminates heap allocation automatically
+- Don't wrap everything in reference types — let Perceus reference counting manage memory; unnecessary refs increase GC pressure
+- Use `type` for algebraic data, `struct` for simple records — don't conflate them
+
+## Performance
+
+- Write naturally functional code — FBIP analysis optimizes many functional patterns to in-place updates
+- Structure recursive functions for TRMC (tail recursion modulo cons) — prevents stack overflow on large data
+- Don't hand-optimize what the compiler handles — Perceus reuse analysis is better at spotting in-place update opportunities than manual attempts
+- Use `var` blocks explicitly when mutable state is needed — don't mix mutation and functional style implicitly
+
+## Common Pitfalls
+
+- Don't assume functional code is slow — FBIP means tree rebalancing and similar algorithms run in-place
+- Don't ignore effect types in signatures — they are the primary tool for reasoning about code behavior
+- Don't create utility modules for one-off effect handlers — inline simple handlers at the call site
+
+## Polish
+
+- Group functions by the effect they operate under — functions touching the same effect belong together; don't scatter them across the file
+- Use one naming convention for effect-producing functions: either `verb-noun` (`read-line`) or `noun-verb` — Koka's standard library favors `verb` or `verb-noun`; follow it within a module
+- Comments on effect signatures should explain the observable contract — what callers can expect from the effect, not just what the handler does internally
+- Name handler functions to match their effect type — a handler for `console` effect should read as `console-handler`, not `my-handler`

package/skills/kiss-practices/lean.md

@@ -0,0 +1,45 @@
+# Lean 4 — KISS Rules
+
+## Proofs and Tactics
+
+- Don't use `sorry` as a placeholder — either close the proof or mark the claim as `axiom`
+- Don't use bare `simp` — use `simp [lemma1, lemma2]` with an explicit lemma list so proofs don't break on Mathlib updates
+- Don't nest tactic blocks more than 3 levels deep — extract intermediate results as `have` lemmas
+- Place `by` at the end of the preceding line, never on its own line
+- Use focusing dots `·` for subgoals — one tactic per line, indent everything in the block
+- Don't squeeze terminal `simp` calls — unsqueezed is shorter and survives lemma renames
+
+## Types and Definitions
+
+- Always explicitly declare argument types and return types — implicit inference obscures intent on GitHub/docs
+- Use `where` syntax for structure/class instances — not enclosing braces
+- Prefer arguments left of the colon over universal quantifiers
+- Default definitions to semireducible — use `abbrev` for reducible, `irreducible_def` only when profiling justifies it
+
+## Decision Procedures
+
+- Don't use `decide` for large finite checks — use `native_decide` for runtime evaluation
+- Don't define custom notation for one-off proofs — notation is for reusable domain language
+
+## Imports
+
+- Don't `import Mathlib` — import specific modules (`import Mathlib.Data.List.Basic`) so compile times stay fast and dependencies stay traceable
+
+## Recursion
+
+- Don't write recursive functions without `termination_by` when termination is not structurally obvious
+- Don't define `partial` functions to silence termination errors — prove termination or restructure
+
+## Style
+
+- Prefer `fun x ↦` over `λ` syntax — and `<|` over `$`
+- Keep lines to 100 characters maximum
+- Don't orphan parentheses — keep them with their arguments
+- Use `<|` and `|>` to reduce parenthesis nesting
+
+## Polish
+
+- Order definitions by dependency: helper lemmas and definitions before the theorems that use them — never require a reader to jump forward to understand a proof
+- Name lemmas after the property they establish, not the tactic used — `list_length_positive` not `simp_length_proof`
+- Within a file, pick one naming convention for related theorems: either `noun_property` (e.g., `list_nil_length`) or `property_of_noun` — don't mix both styles
+- Use `-- ` comments to explain non-obvious tactic choices or why a particular lemma is chosen; omit comments that only name the tactic being applied

package/skills/kiss-practices/markdown.md

@@ -0,0 +1,20 @@
+# Markdown — KISS Rules
+
+- Use ATX headings (`#`) not Setext (underlines) — pick one style and stick with it
+- Don't nest headings deeper than 3 levels — if you need `####`, restructure into separate sections or files
+- Use `-` for unordered lists, `1.` for ordered — don't mix `*`, `+`, and `-` within a file
+- Don't add HTML when Markdown syntax covers it — use `**bold**` not `<strong>bold</strong>`
+- Don't create elaborate table formatting — simple pipe tables are enough; if the table is too complex for Markdown, use a different format
+- Don't add blank lines between every paragraph for "readability" — one blank line separates blocks, more is noise
+- Use reference-style links `[text][ref]` only when the same URL appears 3+ times — inline links are clearer for one-off references
+- Don't add a table of contents manually — let the renderer or tooling generate it
+- Don't wrap lines at 80 characters in prose — let the editor soft-wrap; hard wraps create noisy diffs
+- Don't use blockquotes (`>`) for emphasis — they're for quotations; use bold or callout syntax for emphasis
+- Keep frontmatter minimal — only fields the system actually reads; don't add metadata nobody consumes
+
+## Polish
+
+- Use one list marker style per document (`-` or `*` or `1.`) — don't mix within the same file even across sections
+- Heading hierarchy must be consistent: if top-level concepts use `##`, don't introduce a parallel `##` section that is logically a child of another `##`
+- Code fences must always name the language — ` ```bash `, ` ```json `, never a bare ` ``` ` — so syntax highlighters and linters can apply
+- If a document uses bold for key terms, apply it consistently — don't bold some terms and leave equivalent terms unbolded later in the same file

package/skills/kiss-practices/postgresql.md

@@ -0,0 +1,31 @@
+# PostgreSQL — KISS Rules
+
+## Queries
+
+- Use simple SQL before reaching for CTEs — a subquery or join is often clearer
+- Don't create database views for one-off queries — views are for queries used from multiple places
+- Don't create stored procedures when application code works — procedures are for database-level reuse, not application logic
+- Use `WHERE` clauses over `HAVING` when filtering non-aggregated columns
+- Don't use `SELECT *` in application queries — list the columns you need
+
+## Schema
+
+- Don't normalize beyond what the queries need — a denormalized column that avoids a join is often the right call
+- Don't add indexes speculatively — add them when `EXPLAIN ANALYZE` shows a sequential scan on a query that matters
+- Use `text` over `varchar(n)` unless a length constraint is a business rule — PostgreSQL stores them identically
+- Don't create custom types (domains, enums) for values only used in one table
+- Use simple foreign keys — don't create junction tables for 1:1 relationships
+
+## Migrations
+
+- Keep migrations simple: `CREATE TABLE`, `ALTER TABLE`, `CREATE INDEX`
+- Don't create migration helper functions or DSLs — the SQL is the documentation
+- Don't add rollback logic for destructive migrations in production — you'll restore from backup, not roll back
+- One concern per migration — don't combine schema changes with data migrations
+
+## Polish
+
+- Name tables and columns consistently: either `snake_case` plural nouns for tables (`user_sessions`) or singular — pick one and don't mix within a schema
+- Comment constraints and indexes that implement non-obvious business rules — `-- enforces one active subscription per account`; don't comment on what `NOT NULL` or `PRIMARY KEY` does
+- Order columns in a `CREATE TABLE` predictably: primary key first, foreign keys next, required columns, nullable columns last — makes schemas scannable across tables
+- Use consistent CTE naming within a query: either descriptive nouns (`monthly_totals`) or verb phrases (`compute_totals`) — don't mix both styles in one WITH clause

package/skills/kiss-practices/python.md

@@ -0,0 +1,64 @@
+# Python — KISS Rules
+
+## Package Management
+
+- Use `uv` instead of `pip`, `pip3`, or `pipx` — it is faster, handles lockfiles, and manages virtual environments in one tool
+- Use `uv add`/`uv remove` to manage `pyproject.toml` dependencies — don't manually edit dependency lists
+- Use `uvx` to run one-off CLI tools — don't install them globally with `pipx`
+- Use `uv venv` for virtual environments — don't use `python -m venv` or `virtualenv`
+- Use `uv sync` to reproduce environments from lockfiles — don't `pip freeze > requirements.txt`
+
+## Code Quality
+
+- Use `ruff` for both linting and formatting — don't install separate tools (flake8, black, isort, pylint)
+- Run `ruff check --fix . && ruff format .` as a single pass — don't chain multiple linters
+- Configure ruff in `pyproject.toml` under `[tool.ruff]` — don't create `.flake8`, `.isort.cfg`, or `setup.cfg` for linter config
+
+## Project Structure
+
+- Use `pyproject.toml` as the single project config — don't maintain `setup.py`, `setup.cfg`, and `requirements.txt` separately
+- Don't create `__init__.py` files in every directory — implicit namespace packages work since Python 3.3; add `__init__.py` only when you need to export a public API or run initialization code
+- Don't create a `utils.py` or `helpers.py` catch-all — put functions in the module where they're used
+
+## Type Hints
+
+- Use built-in generics (`list[str]`, `dict[str, int]`, `str | None`) — don't import from `typing` for types available as builtins since Python 3.10
+- Don't annotate every local variable — let type checkers infer from assignment
+- Don't create TypedDict for one-off structures — a plain dict or dataclass is clearer
+
+## Data Classes and Models
+
+- Use `@dataclass` for simple value objects — don't write `__init__`, `__repr__`, `__eq__` by hand
+- Don't use `@dataclass` when a named tuple or plain tuple suffices — if it's just grouping 2-3 return values, a tuple is simpler
+- Don't add validators, serializers, or factory methods to dataclasses until you need them
+
+## Error Handling
+
+- Don't catch `Exception` or `BaseException` without re-raising — catch specific exceptions
+- Don't wrap every function call in try/except — let exceptions propagate to where they can be meaningfully handled
+- Don't create custom exception hierarchies for internal code — use built-in exceptions (ValueError, TypeError, RuntimeError) with descriptive messages
+
+## Imports
+
+- Use absolute imports — relative imports (`from . import`) are harder to grep and refactor
+- Don't create barrel modules (`__init__.py` that re-exports everything) until imports are genuinely painful
+- Group imports: stdlib, third-party, local — but let ruff/isort handle the sorting
+
+## Functions
+
+- Return early for guard clauses — don't nest the happy path inside `if valid:`
+- Don't use `*args, **kwargs` unless you're genuinely wrapping or forwarding — explicit parameters are self-documenting
+- Don't add default arguments for values that are always passed by callers — defaults signal "optional"
+
+## Testing
+
+- Use `pytest` — don't use `unittest.TestCase` classes unless the project already does
+- Don't create test base classes or fixtures for one-off setup — inline the setup in the test
+- Don't mock what you can construct — if a function takes a dict, pass a dict, don't mock a dict
+
+## Polish
+
+- Order module contents predictably: constants, then public functions, then private functions (prefixed with `_`) — don't interleave public and private at will
+- Within a module, use one naming style for related operations: `get_user` / `create_user` / `delete_user` — don't mix `fetch_`, `load_`, and `get_` for the same concept across functions in the same file
+- Comments explain WHY, not WHAT — `# S3 returns 503 during rolling deploys, so we retry` is useful; `# call the API` is not; delete comments that restate the code
+- Use docstrings for public functions that are not self-evident from their signature — skip docstrings on private helpers and one-liner utilities where the body is the documentation

package/skills/kiss-practices/svelte.md

@@ -0,0 +1,59 @@
+# Svelte 5 — KISS Rules
+
+## Runes and Reactivity
+
+- Use `$state` only for variables that trigger effects, derived values, or template updates — don't make every variable reactive
+- Use `$state.raw` for large objects that are only reassigned (never mutated) — avoids proxy overhead on API responses
+- Use `$derived` for computed values, not `$effect` — derived is cleaner, side-effect-free, and expresses intent
+- `$effect` is an escape hatch — avoid it; put logic in event handlers, use `$derived`, or use `$inspect` for debugging
+- Never update `$state` inside `$effect` — this creates reactive loops; restructure as `$derived` instead
+- Treat `$props` as values that will change — always derive dependent values with `$derived`, don't compute once at init
+
+## Components
+
+- Keep components small and flat — extract a child component only when it's used 3+ times or manages independent state
+- Don't create wrapper components that just pass props through — use snippets or direct rendering
+- Use `{#snippet}` and `{@render}` for reusable markup chunks — don't create components for template-only reuse
+- Use keyed `{#each}` blocks — improves performance; key must uniquely identify items, never use array index
+- Don't destructure `{#each}` items if you bind to them — `bind:value={item.count}` needs the reference
+
+## State Sharing
+
+- Use `createContext` for state scoped to a component subtree — prevents state leakage during SSR
+- Don't use module-level `$state` for shared state — use context or classes with `$state` fields instead
+- Don't create stores (`writable`/`readable`) — use classes with `$state` fields for shared reactivity in Svelte 5
+
+## Events
+
+- Use `onclick={handler}` attribute syntax — not the legacy `on:click={handler}` directive
+- Use `<svelte:window>` and `<svelte:document>` for global listeners — not `onMount` or `$effect`
+
+## Styling
+
+- Use Svelte's scoped `<style>` blocks — don't add CSS-in-JS or global stylesheet frameworks unless the project already uses them
+- Use `style:--property={value}` to pass JS variables to CSS — not inline style strings
+- Style child components via CSS custom properties (`<Child --color="red" />`) — use `:global` only as last resort
+- Don't create utility CSS classes within a component — if a style is used once, put it inline in the style block
+
+## SvelteKit
+
+- Use standard load functions (`+page.ts`, `+layout.ts`) — don't build custom data fetching abstractions
+- Use form actions for mutations — don't reach for client-side API calls when a form action works
+- Don't add API route wrappers — `+server.ts` files are already simple enough
+- Use the built-in error/redirect helpers — don't create custom response utilities
+
+## Legacy Patterns to Avoid
+
+- `$:` reactive declarations → use `$derived` and `$effect`
+- `export let` → use `$props`
+- `<slot>` and `$$slots` → use `{#snippet}` and `{@render}`
+- `on:click` directive → use `onclick` attribute
+- `use:action` → use `{@attach}`
+- `<svelte:component this={X}>` → use dynamic component `<X />`
+
+## Polish
+
+- Order a component's script block predictably: `$props` first, `$state` declarations next, `$derived` values, then `$effect` blocks, then event handlers — don't scatter reactive declarations throughout the script
+- Use one naming convention for event handlers within a component: either `handleX` or `onX` — don't mix `handleClick` and `onSubmit` in the same file
+- Comments in `<script>` blocks should explain non-obvious reactive dependencies or browser workarounds — don't comment on what `$derived` or `$state` does; that's self-evident
+- Keep prop names consistent with the component's domain: if sibling components use `user`, don't introduce `currentUser` or `activeUser` for the same concept