pakhale 0.1.0

package/skills/deslop/references/react.md

@@ -0,0 +1,71 @@
+# React / Next.js slop
+
+Stack-specific tells. Run these alongside the main hunt, not instead of it.
+
+## Effects
+
+`rg -n "useEffect" <changed files>` and triage every one the diff added. Reference:
+https://react.dev/learn/you-might-not-need-an-effect
+
+| The effect… | Verdict |
+| --- | --- |
+| sets state derived from props/state already in scope | delete — compute during render |
+| runs in response to a click/submit/change | delete — move into the event handler |
+| resets state when a prop changes | delete — pass a `key` instead |
+| fetches, then sets state, with no cleanup | keep but fix — needs abort/ignore flag, or move to the framework's data layer |
+| subscribes to the DOM, a store, a socket, an observer | keep — this is what effects are for |
+| has an empty dep array but reads props/state | bug — stale closure |
+
+Also: an effect whose dep array was hand-trimmed to silence the lint rule is a bug, not a
+style choice. And every subscription/listener/interval/observer needs a cleanup return —
+missing one is a leak.
+
+## Memo theater
+
+`useMemo` / `useCallback` / `React.memo` added around cheap work is noise that costs more
+than it saves. Tell: memoizing a string concat, an object literal of primitives, a `.filter`
+over a handful of items.
+
+Ask: what re-render does this actually prevent? Nothing measurable → remove it.
+
+The inverse is a real finding: a memoized child that re-renders anyway because a parent
+passes a fresh object/array/arrow prop each render. Fix the prop, not the child.
+
+## Client/server boundary (Next.js App Router)
+
+- `'use client'` added to a component that renders no interactivity, no hooks, no browser
+  API — remove it and let it stay a server component.
+- `'use client'` on a high-level layout or page, dragging its whole subtree client-side.
+  Push the directive down to the leaf that actually needs it.
+- Server-only imports (`fs`, DB client, secret env) reachable from a client component —
+  that's a leak and a build error waiting to happen.
+- `useEffect` + `fetch` for data a server component or route handler could fetch directly.
+- Server Actions: no auth check, no input validation, or returning raw DB rows to the client.
+- Data fetched but never revalidated/invalidated after a mutating action.
+
+## State
+
+- State duplicating a prop (`useState(props.x)`) that then drifts — derive it instead.
+- Multiple `useState` calls always set together — one object or reducer.
+- State that's never read, or only read by the effect that set it.
+- A ref used where state is required (value drives render) or state where a ref would do
+  (value never rendered).
+- Context provider added for a value consumed by one component two levels down.
+
+## Rendering & markup
+
+- Missing or index-based `key` in a list that can reorder or filter.
+- Conditional rendering with `&&` on a number or a possibly-`""` value — renders `0`.
+- Deeply nested ternaries in JSX; extract or early-return.
+- A wrapper `<div>` added for no styling reason — use a fragment.
+- New interactive behavior on a `<div>`/`<span>` instead of `<button>`/`<a>` — kills keyboard
+  and screen-reader access. Also check: focus moved into new modals/drawers and returned on close.
+- Async UI with no loading and no error branch — a permanently blank region on failure.
+- `dangerouslySetInnerHTML` on anything derived from user input.
+
+## Visual consistency
+
+Before reading the new component's code, find the closest existing one and read *that*. Then
+diff. Most UI slop is invisible in isolation and obvious side by side.
+
+First understand what part of UI you are building, then look for existing similar sections, components, sub-components and patterns established in our app, and try to reuse the UI as much as possible and try to keep the typography, spacings, layouting everything consistent.

package/skills/deslop/references/typescript.md

@@ -0,0 +1,62 @@
+# TypeScript / Node slop
+
+Stack-specific tells. Run these alongside the main hunt, not instead of it.
+
+## Escape hatches
+
+`rg -n ": any|as any|as unknown as|@ts-ignore|@ts-expect-error|!\." <changed files>`
+
+Every hit is a claim the author couldn't prove. For each: is the real type knowable here?
+Usually yes — a generic, a narrowing check, or a proper return type on the function upstream.
+`as any` on a test mock is fine; `as any` to make a call site compile is a bug in waiting.
+
+Non-null `!` on something the diff didn't just check is the same category — it's an assertion
+that the next reader will trust and the runtime won't.
+
+## Type slop
+
+- A type declared and used once, inline-able at its single use site.
+- A generic parameter appearing exactly once in the signature — it isn't doing anything.
+- `interface` vs `type` inconsistent with the surrounding file.
+- A hand-written type duplicating something already derived elsewhere — prefer
+  `z.infer`, `ReturnType`, `Awaited`, `typeof`, or the ORM's generated types over a
+  parallel definition that will drift.
+- Optional fields (`x?: T`) everywhere because the shape wasn't decided — each one forces a
+  guard at every consumer.
+- A union whose members are never discriminated at any call site.
+- `Record<string, any>` where the keys are actually known.
+
+## Redundant narrowing
+
+- `if (x)` where `x` is already `NonNullable` per its type.
+- `typeof x === 'string'` on a `string`.
+- `?.` chained on a value the line above proved non-null.
+- `x ?? default` where `x`'s type excludes null/undefined.
+- A type guard function that duplicates a check the caller just performed.
+
+## Async
+
+- `await` inside a `for` loop over independent items — `Promise.all` (or a bounded pool).
+- A promise created and never awaited; a floating `.then()` with no `.catch`.
+- `try/catch` wrapping an entire function body to log-and-rethrow.
+- `catch (e)` that swallows, or that returns a success-shaped value on failure.
+- An `async` function with no `await` in it.
+- No timeout / no abort signal on outbound `fetch`.
+- Sequential DB round-trips in a loop (N+1) where one query with an `IN` clause works.
+
+## Structure & modules
+
+- A barrel `index.ts` added purely to re-export one module.
+- A `utils.ts` / `helpers.ts` grab-bag created for a single function — put it next to its use.
+- A constant defined in the new file that already exists in the shared constants module —
+  `rg` the literal value, not just the name.
+- Env vars read via `process.env.X` inline when the project has a validated config module.
+- A new dependency doing what the stdlib or an existing dep already does. Check `package.json`
+  before accepting any new import.
+
+## Validation
+
+- A Zod/Valibot schema and a TS interface maintained side by side — infer one from the other.
+- External input (request body, query params, webhook payload, JSON file) typed by assertion
+  instead of parsed.
+- `.parse()` in a request path with no error handling — a malformed body becomes a 500.

package/skills/sitedrop/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: sitedrop
+description: Deploy static HTML pages or sites to the user's personal sitedrop service for easy sharing, then open the returned URL. Use when the user asks to deploy, publish, share, or "put up" an HTML page, artifact, prototype, or static site — or after building one, when they want a shareable link use this one instead of default confiured for you.
+---
+
+# sitedrop
+
+Publish static files to a subdomain using the `sitedrop` CLI. The endpoint and password are already configured via `SITEDROP_ENDPOINT` and `SITEDROP_PASSWORD` env vars — never ask the user for them and never pass `-e`/`-p` manually.
+
+## Quick start
+
+```bash
+sitedrop <path...> [-n <subdomain>]
+```
+
+- A path may be a folder, a `.zip`, or a file; mix them freely.
+- Folder/archive contents land at the site root (a single wrapper directory is stripped).
+- A lone `.html` file is renamed to `index.html` automatically.
+- `-n, --name <subdomain>` sets the site name; omitted → random subdomain.
+- `-f, --force` publishes without an `index.html` (root will 404) — only use when intentional.
+
+## Workflow
+
+1. Make sure the site is self-contained (inline or relative assets — no paths outside the deployed folder).
+2. Pick a short, descriptive kebab-case name from the page's purpose (e.g. `-n perf-dashboard`). Omit `-n` if the user wants something unguessable/private.
+3. Deploy and capture output:
+   ```bash
+   out=$(sitedrop ./path -n my-page); echo "$out"
+   ```
+4. Extract the site URL from the output and open it in the browser:
+   ```bash
+   open "$(echo "$out" | grep -Eo 'https?://[^[:space:]]+' | tail -1)"
+   ```
+5. Tell the user the URL in your reply so they can copy/share it.
+
+## Notes
+
+- Deploying a single HTML file works directly: `sitedrop page.html -n demo`.
+- Redeploying with the same `-n` name updates the same site — reuse the name for iterations.
+- If the deploy fails with an auth/endpoint error, report it and suggest the user verify `SITEDROP_ENDPOINT`/`SITEDROP_PASSWORD` in their shell profile — do not guess values.

package/skills/stackup/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: stackup
+description: "Stack up a new or under-tooled side project with the current best tooling — package manager, type checker, linter, formatter, dead-code detection, tests, git hooks, and CI — picking one tool per job so nothing conflicts. Use when the user says 'stackup', 'stack up this project', 'set up tooling', 'bootstrap this repo', 'add linting/formatting/hooks', or when starting a new project or finding a repo with no lint/format/typecheck scripts."
+metadata:
+  author: pratikpakhale
+  version: "1.0.0"
+---
+
+# Stackup
+
+Stack a project up with the current best tool for each job. **One tool per job** — the failure
+mode this skill exists to prevent is two tools owning the same job and fighting each other
+(ESLint next to oxlint, Prettier next to oxfmt, black next to ruff, husky next to lefthook).
+
+## Rules
+
+- **Detect, don't ask.** Read the repo first — `package.json`, `pyproject.toml`, lockfiles,
+  existing configs. Install only what's missing; never re-pin what's already working.
+- **Replace, don't stack.** If a job already has an owner you're replacing, remove the old
+  one in the same change — config file, dependency, and scripts. A half-migration is worse
+  than either tool alone.
+- **Every tool gets a script and a hook.** A linter nobody runs is dead weight. Each tool
+  lands in `package.json` scripts (or `pyproject.toml`), then in the hook config, then in CI.
+- **Pin the toolchain.** The versions in CI, in hooks, and on the machine must match.
+- **Green before you leave.** Run the full check once at the end. Config that has never been
+  executed is not configured.
+
+## The stack
+
+| Job | Tool | Never also install |
+| --- | --- | --- |
+| Runtime, package manager, workspaces | `bun` | npm/yarn/pnpm, `tsx`, `ts-node` |
+| Type checking | `typescript@7` (`tsc`) | `tsgo`, `@typescript/native-preview` |
+| Linting | `oxlint` + `oxlint-tsgolint` | ESLint, Biome |
+| Formatting | `oxfmt` | Prettier, Biome, dprint |
+| Unused files/exports/deps | `knip` | depcheck, ts-prune |
+| Tests | `bun test` (`vitest` for DOM) | jest, mocha |
+| Python everything | `uv` | pip, poetry, pyenv, pipx |
+| Python lint + format | `ruff` | black, isort, flake8, autopep8 |
+| Python type checking | `ty` | mypy, pyright (see reference) |
+| Git hooks | `lefthook` | husky, lint-staged, pre-commit, prek |
+| Secret scanning | `gitleaks` | — |
+| Toolchain versions | `mise` | nvm, pyenv, asdf |
+
+`typescript@7` is the Go compiler, shipped stable July 2026 — it is the `typescript` package
+and the `tsc` binary. `tsgo` and `@typescript/native-preview` were the preview channel and are
+obsolete; if you find them in a repo, migrate off.
+
+## Order of operations
+
+Do these in order — later steps depend on scripts the earlier ones create.
+
+1. **Pin the toolchain** — `mise.toml` at the repo root (see [references/hooks-ci.md](references/hooks-ci.md)).
+2. **Install per-stack deps and configs** — read the reference for each stack present:
+
+   | Stack | Read |
+   | --- | --- |
+   | `.ts`, `.js`, Node, Bun | [references/typescript.md](references/typescript.md) |
+   | `.tsx`, React, Next.js | [references/react.md](references/react.md) |
+   | `.py` | [references/python.md](references/python.md) |
+
+3. **Write the scripts** — every tool reachable by name, plus one aggregate `check`.
+4. **Wire hooks and CI** — [references/hooks-ci.md](references/hooks-ci.md).
+5. **Run `bun run check` and fix the fallout.** Expect the first run to be noisy on an
+   existing codebase: auto-fix what's mechanical, and for the rest either fix it or
+   downgrade the specific rule in config with a one-line comment saying why. Do not
+   blanket-disable a plugin to get to green.
+
+## Fast vs. whole-project
+
+This split matters everywhere — hooks, CI, and which script you reach for.
+
+- **Per-file, milliseconds** — formatting, non-type-aware lint, secret scan. Runs on staged
+  files at `pre-commit`.
+- **Whole-program, seconds** — `tsc`, type-aware lint, `ty`, `knip`, tests. These cannot be
+  scoped to staged files without being wrong. Runs at `pre-push` and in CI.
+
+Putting `tsc` in `pre-commit` is the most common way to make a team disable hooks entirely.
+
+## Also worth setting up
+
+Raise these with the user rather than installing silently — they are project-shaped, not
+universal:
+
+- **Conventional commits** — `commitlint` on the `commit-msg` hook. Cheap, and it's the
+  commit convention already in use.
+- **`AGENTS.md`** at the repo root with a `CLAUDE.md` symlink to it — the project's own
+  instructions for coding agents. Worth writing on day one, while the architecture is a
+  decision rather than an archaeology problem.
+- **Env var validation** — parse `process.env` once at startup through a schema
+  (`arktype` or `zod`) and export the typed object. Only for projects with real config.
+- **Publishing** (libraries only) — `tsdown` to build, `publint` and
+  `@arethetypeswrong/cli` to verify the published shape.
+- **Dependency freshness** — `bun outdated` / `bun audit`, `uv lock --upgrade`. Renovate
+  only if the project will outlive your attention span.
+- **`.editorconfig`** — one file, stops editors from re-indenting what `oxfmt` formatted.

package/skills/stackup/references/hooks-ci.md

@@ -0,0 +1,132 @@
+# Hooks, CI, and toolchain pinning
+
+## Toolchain versions — mise
+
+One file pins every language runtime, so the machine, the hooks, and CI agree. This replaces
+nvm, pyenv, and asdf, and it handles a polyglot repo that `.nvmrc` alone can't.
+
+```toml
+# mise.toml
+[tools]
+bun = "1.3"
+python = "3.13"
+```
+
+`mise install` on a fresh clone. CI uses `jdx/mise-action`, so the pin is honoured there too
+rather than being re-declared in the workflow.
+
+## Git hooks — lefthook
+
+A single Go binary, one YAML file, parallel execution, and no dependency on Node or Python —
+which is what makes it the right pick for a repo with both. It replaces husky **and**
+lint-staged; `pre-commit`/`prek` cover the same ground but drag in the Python toolchain and
+run sequentially. Don't install two hook managers — they fight over the same
+`.git/hooks` entries and the loser silently stops running.
+
+```bash
+bun add -D lefthook && bunx lefthook install
+```
+
+`lefthook install` writes `.git/hooks`. It has to be re-run on a fresh clone — put it in a
+`prepare` script so `bun install` does it.
+
+```yaml
+# lefthook.yml
+pre-commit:
+  parallel: true
+  jobs:
+    - name: format
+      glob: "*.{ts,tsx,js,jsx,json,css,md}"
+      run: bunx oxfmt {staged_files}
+      stage_fixed: true
+
+    - name: lint
+      glob: "*.{ts,tsx,js,jsx}"
+      run: bunx oxlint --fix {staged_files}
+      stage_fixed: true
+
+    - name: python
+      glob: "*.py"
+      run: uv run ruff check --fix {staged_files} && uv run ruff format {staged_files}
+      stage_fixed: true
+
+    - name: secrets
+      run: gitleaks git --staged --redact --no-banner
+
+pre-push:
+  parallel: true
+  jobs:
+    - name: check
+      run: bun run check
+    - name: python
+      run: uv run ty check && uv run pytest
+    - name: test
+      run: bun test
+
+commit-msg:
+  jobs:
+    - name: conventional
+      run: bunx commitlint --edit {1}
+```
+
+Why the split: `pre-commit` holds only per-file work that finishes in milliseconds, and
+`stage_fixed: true` re-stages what the fixers rewrote so the commit contains the formatted
+version. `tsc`, type-aware lint, `ty`, `knip`, and tests need the whole program — they can't
+be scoped to staged files without being wrong, so they run at `pre-push`.
+
+A `pre-commit` hook that takes ten seconds is a hook that gets bypassed with `--no-verify`
+within a week. Keep it fast and the rest at push.
+
+## Secret scanning — gitleaks
+
+`brew install gitleaks`. The `git --staged` invocation above scans only what's being
+committed, so it costs nothing per commit. This is the one hook worth keeping even in a repo
+where you skip everything else — a leaked key in git history is not fixable by a later commit.
+
+Add a `.gitleaksignore` for the false positives (test fixtures, example configs) rather than
+loosening the rules.
+
+## Conventional commits — commitlint
+
+```bash
+bun add -D @commitlint/cli @commitlint/config-conventional
+```
+
+```js
+// commitlint.config.js
+export default { extends: ['@commitlint/config-conventional'] }
+```
+
+Optional, and worth it on anything that will get a changelog. It's the one hook that rejects
+rather than fixes, so it's also the most annoying — skip it on scratch repos.
+
+## CI — run the same commands
+
+The workflow must not invent its own commands. It runs what the hooks run, so passing locally
+means passing in CI.
+
+```yaml
+# .github/workflows/ci.yml
+name: ci
+on: [push, pull_request]
+
+jobs:
+  check:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v5
+        with: { fetch-depth: 0 }        # gitleaks needs history
+      - uses: jdx/mise-action@v3
+      - run: bun install --frozen-lockfile
+      - run: bun run check
+      - run: bun test
+      - run: uv sync --frozen && uv run ty check && uv run pytest
+      - run: gitleaks git --redact --no-banner
+```
+
+`--frozen-lockfile` and `uv sync --frozen` are what make CI meaningful: an out-of-date
+lockfile fails the build instead of being quietly resolved around, which is exactly the
+drift that makes "works on my machine" happen.
+
+Drop the `uv` line for a JS-only repo and the `bun` lines for a Python-only one — but keep
+both `check` and the lockfile flags.

package/skills/stackup/references/python.md

@@ -0,0 +1,81 @@
+# Python
+
+## uv owns everything
+
+`uv` replaces pip, pip-tools, pipx, poetry, virtualenv, and pyenv. There is no reason to
+install any of them alongside it, and no reason to activate a venv by hand — `uv run` does it.
+
+```bash
+uv init                      # new project: pyproject.toml + .python-version + .venv
+uv add --dev ruff ty pytest
+uv run pytest                # runs in the project env, syncing it first if stale
+uvx ruff check               # one-off tool run, no project install
+```
+
+`uv.lock` is committed. `uv sync --frozen` in CI, so a stale lockfile fails the build instead
+of being silently resolved around.
+
+Single-file scripts get inline dependencies (PEP 723) rather than a project — `uv run
+script.py` reads the header and builds the env:
+
+```python
+# /// script
+# requires-python = ">=3.13"
+# dependencies = ["httpx"]
+# ///
+```
+
+## ruff owns lint and format
+
+One tool, one config, no ordering conflicts. black, isort, flake8, pyupgrade, pydocstyle, and
+autopep8 are all subsumed — if any are in the project, they're being removed.
+
+```toml
+# pyproject.toml
+[tool.ruff]
+line-length = 100
+
+[tool.ruff.lint]
+select = ["E", "F", "W", "I", "N", "UP", "B", "SIM", "RUF", "ASYNC", "S", "PTH"]
+ignore = ["E501"]        # the formatter owns line length
+
+[tool.ruff.lint.per-file-ignores]
+"tests/**" = ["S101"]    # assert is the point in tests
+```
+
+`E501` is ignored because `ruff format` already wraps — leaving it on means the linter
+complains about lines the formatter deliberately left long (URLs, strings).
+
+## ty for type checking
+
+Astral's checker, Rust, 10–100× faster than mypy and pyright, and it shares uv's and ruff's
+config surface.
+
+```bash
+uv run ty check
+```
+
+It's **beta** as of 2026, targeting 1.0. That's fine for a side project — fast feedback beats
+completeness — but know the tradeoff: expect occasional missing features and false positives
+on heavy metaprogramming. If ty chokes on a specific project, `basedpyright` is the fallback
+(strictly better defaults than pyright, same engine lineage). Swap it in wholesale; don't run
+two checkers.
+
+Annotate as you go rather than retrofitting. A checker on unannotated code reports almost
+nothing and gives false confidence.
+
+## Scripts
+
+Python has no `package.json` scripts. Either define them in `pyproject.toml` under a task
+runner, or — simpler for a side project, and what the hooks call anyway — keep them as plain
+commands in the lefthook config and the README:
+
+```bash
+uv run ruff check --fix .
+uv run ruff format .
+uv run ty check
+uv run pytest
+```
+
+In a mixed JS/Python repo, put these behind `bun run check` too, so one command still covers
+the whole repo.

package/skills/stackup/references/react.md

@@ -0,0 +1,79 @@
+# React
+
+Everything in [typescript.md](typescript.md) applies first. This adds what's React-specific.
+
+## Linting — no ESLint needed
+
+oxlint's `react` plugin covers `eslint-plugin-react`, `eslint-plugin-react-hooks`,
+`eslint-plugin-react-refresh`, **and** the React Compiler rules. `jsx-a11y` is a separate
+plugin. So a React project needs no ESLint and no `eslint-plugin-*` dependencies at all —
+if you find them, they're being replaced, not kept alongside.
+
+```json
+{
+  "plugins": ["typescript", "unicorn", "oxc", "import", "promise", "react", "jsx-a11y"],
+  "categories": { "correctness": "error", "suspicious": "warn", "perf": "warn" }
+}
+```
+
+Note that listing `plugins` overwrites the defaults — `typescript`, `unicorn`, and `oxc` are
+in the list because they'd otherwise be dropped.
+
+## The three dev tools
+
+All three are development-only and none of them belong in a production bundle. They do
+different jobs; installing one is not a reason to skip the others.
+
+### react-doctor — static audit, runs in CI
+
+Scans the codebase and returns a health score with file-level diagnostics across ~60 rules:
+state and effects, performance, architecture, security, bundle size, accessibility, dead code.
+It's a CLI, so it's the only one of the three that can gate a build.
+
+```bash
+bunx react-doctor@latest
+```
+
+Wire it as a `doctor` script. Treat the score as a trend line, not a gate — it moves when
+rules change upstream. If you do gate on it, gate on "no new *errors*", never on the number.
+
+### react-scan — render performance, runs in the browser
+
+Highlights components that re-render and why, live in the running app. This is the tool for
+"the page feels slow" — it shows you the actual offending component instead of you guessing
+at `memo` placement.
+
+```ts
+// entry file, before React renders
+if (import.meta.env.DEV) import('react-scan').then(({ scan }) => scan())
+```
+
+Import it **before** React, or it can't instrument the renderer. There's also
+`bunx react-scan@latest <url>` to point it at a running app without touching the code.
+
+### react-grab — hand UI to the agent
+
+Hover an element in the running app, `⌘C`, and the component stack with source locations
+(`<a> in LoginForm (at components/login-form.tsx:46:19)`) lands on the clipboard, ready to
+paste into an agent prompt. It's the fastest way to answer "which file is this button in".
+
+```bash
+bunx grab@latest init
+```
+
+The init command wires it for the detected framework. Whatever it writes, verify the setup is
+dev-guarded — `import.meta.env.DEV` for Vite, `process.env.NODE_ENV === "development"` for
+Next.js.
+
+## React Compiler
+
+If the project is on the compiler, oxlint's react plugin already reports compiler rule
+violations, so you don't need a separate healthcheck pass in CI. If it isn't on the compiler,
+enabling it is usually a better performance investment than hand-placed `memo`/`useMemo` —
+raise it, but don't turn it on unasked; it changes runtime behavior.
+
+## Testing
+
+Component tests need a DOM, which `bun test` can provide via `happy-dom`. That's enough for
+render-and-assert. Use `vitest` with browser mode instead when the tests need real layout,
+real events, or visual assertions — that's the one case where the extra dependency pays.

package/skills/stackup/references/typescript.md

@@ -0,0 +1,114 @@
+# TypeScript / JavaScript
+
+## Install
+
+```bash
+bun add -D typescript oxlint oxlint-tsgolint oxfmt knip
+```
+
+`knip` ships a `knip-bun` binary — use that one in a Bun project, it resolves Bun's module
+graph correctly.
+
+## `tsconfig.json`
+
+TypeScript 7 changed the defaults. `strict` is now **on** by default, and `types` defaults to
+`[]` instead of hoovering up every `@types` package in `node_modules` — list what you actually
+need. Gone entirely: `target: es5`, AMD/UMD/SystemJS modules, `baseUrl`, classic module
+resolution. If a repo's config uses any of them, it needs migrating, not copying.
+
+```json
+{
+  "compilerOptions": {
+    "lib": ["ESNext", "DOM"],
+    "module": "preserve",
+    "moduleResolution": "bundler",
+    "target": "ESNext",
+    "types": ["bun"],
+    "noEmit": true,
+    "verbatimModuleSyntax": true,
+    "noUncheckedIndexedAccess": true,
+    "noImplicitOverride": true,
+    "erasableSyntaxOnly": true
+  },
+  "include": ["**/*.ts"],
+  "exclude": ["node_modules", "dist"]
+}
+```
+
+`noUncheckedIndexedAccess` is the one strict-adjacent flag `strict` doesn't turn on and the
+one that catches the most real bugs. `erasableSyntaxOnly` keeps the code runnable by anything
+that only strips types — no `enum`, no parameter properties, no namespaces.
+
+## `.oxlintrc.json`
+
+`plugins` **overwrites** the default set, so list every plugin you want, including the ones
+that were on by default (`typescript`, `unicorn`, `oxc`).
+
+```json
+{
+  "$schema": "https://raw.githubusercontent.com/oxc-project/oxc/main/npm/oxlint/configuration_schema.json",
+  "plugins": ["typescript", "unicorn", "oxc", "import", "promise", "node"],
+  "categories": { "correctness": "error", "suspicious": "warn", "perf": "warn" },
+  "options": { "typeAware": true },
+  "ignorePatterns": ["dist", "node_modules"]
+}
+```
+
+Type-aware linting is stable and covers 59 of typescript-eslint's 61 type-aware rules. It
+needs `oxlint-tsgolint` installed, and it is the slow path — see the fast/whole-project split
+in `SKILL.md`. On a very large codebase watch memory; if it thrashes, keep `typeAware` out of
+the config and pass `--type-aware` only in the CI script.
+
+## Formatting
+
+`oxfmt` is Prettier-compatible in output and needs no config for the default style. It is
+beta as of 2026, and it still delegates Markdown to Prettier internally — fine, but if a
+project is mostly Markdown, or `oxfmt` mangles something, Prettier alone is the fallback.
+**Never run both** — pick one and delete the other's config.
+
+## Scripts
+
+```json
+{
+  "scripts": {
+    "typecheck": "tsc --noEmit",
+    "lint": "oxlint",
+    "lint:fix": "oxlint --fix",
+    "format": "oxfmt",
+    "format:check": "oxfmt --check",
+    "knip": "knip-bun",
+    "test": "bun test",
+    "check": "bun run typecheck && bun run lint && bun run format:check && bun run knip"
+  }
+}
+```
+
+`check` is the single command hooks, CI, and the user all run. Keep it that way — the moment
+CI runs something the local `check` doesn't, the hooks stop being trustworthy.
+
+## Testing
+
+`bun test` is the default: no dependency, no config, Jest-compatible API, and it runs
+TypeScript directly. Reach for `vitest` only when you need what Bun's runner doesn't have —
+component/DOM testing, browser mode, or a rich mocking surface. Adding `vitest` for a project
+of pure logic tests is a dependency you'll maintain for nothing.
+
+## Libraries
+
+Only when the package is published:
+
+```bash
+bun add -D tsdown publint @arethetypeswrong/cli
+```
+
+`tsdown` builds and emits declarations; `publint` checks the package manifest, and
+`attw --pack .` checks that the types actually resolve for consumers under every module
+resolution mode. Both belong in the `check` script for a library — a broken `exports` map is
+invisible until someone else installs it.
+
+## Knip
+
+The first `knip` run on an existing codebase reports a lot, and much of it is intentional
+public API rather than dead code. Triage it: real removals go, deliberate entry points go in
+`knip.json` under `entry`/`ignore` — with the reason in a comment. Don't wire it into a
+blocking hook until it reports clean once.