Write a .github/copilot-instructions.md file Copilot actually follows

# Repository custom instructions for GitHub Copilot
# Save as .github/copilot-instructions.md at the repo root. Copilot loads this automatically into
# every Copilot Chat request, every automated code-review pass, every coding-agent session, and
# every commit-message and pull-request-description generation in this repository — you never
# retype any of it per conversation.

## What this project is
tools.scult.in — Next.js 15 App Router, TypeScript strict mode, Tailwind CSS, Biome for lint and format

## Conventions Copilot must apply by default, unprompted
- Prefer named exports over default exports.
- Co-locate component tests next to the component, not in a separate __tests__ tree.
- Use the existing cn() helper for conditional class names, never template-literal concatenation.

## Patterns to reject outright, not just discourage
- Never use the any type without a comment justifying it.
- Never add a new npm dependency without flagging it in the PR description first.

## What matters most when Copilot is reviewing a change here
Accessibility of any new UI component, and whether new API routes validate input with a schema before touching the database.

## Generated or vendored paths these rules do not govern
.next/, coverage/, and any *.generated.ts file — build output and generated code, not hand-written source.

Copilot has no built-in way to scope this particular file to a subdirectory, so say explicitly
which paths sit outside these rules rather than letting a convention written for hand-authored
source code get silently applied to a generated lockfile, a vendored dependency, or a build
output directory where enforcing it would be actively wrong rather than merely unhelpful.

## Interaction with path-scoped instructions
If a more specific .github/instructions/*.instructions.md file elsewhere in this repo also
applies to the code Copilot is currently touching, both files are added to context together —
this file's rules and the path-scoped file's rules combine, they do not override each other. Do
not repeat a rule here that a path-scoped file already states more precisely for its own
directory; repeating the general version at the repo-wide level only means it wins the reader's
attention first, which defeats the reason the narrower file exists at all.

## How to write every rule above
Each line here gets re-checked and re-applied on every single request Copilot handles in this
repository, with no surrounding conversation available to disambiguate it — write every rule so
it holds standing alone, never only in combination with a sentence written three lines above it.
Prefer one short declarative sentence over a paragraph of context: 'Never use the any type
without a comment justifying it' is a rule Copilot can check itself against; 'we try to keep
things reasonably well typed' is not, because there is no failing case it actually rules out. If
a convention only makes sense with an example, give the example in the same bullet, not as a
separate note two sections away that a single-request read might never reach in combination.

## Maintenance
The first time Copilot suggests something that directly contradicts a rule in this file, treat
that as a signal the rule is unclear or missing a case, not a one-off mistake to wave off — add
the missing case immediately, in the same session, rather than filing it away to fix later. A
rule that has quietly stopped being true and is never removed is worse than no rule at all,
because every future session trusts it by default without re-verifying it against the current
code.