The app is a SvelteKit project targeting Vercel via
@sveltejs/adapter-vercel
. Core UI and logic reside in
src
, with routable pages in
src/routes
(e.g.
+page.svelte
) and shared modules exported through
src/lib
. Global assets such as the favicon live under
src/lib/assets
, while files meant to be served verbatim go in
static
. Build and tooling settings are centralized in
svelte.config.js
,
vite.config.ts
, and
tsconfig.json
.
npm run dev
– start the Vite dev server; append -- --open
to launch a browser tab.npm run build
– create an optimized production bundle ready for deployment.npm run preview
– serve the latest build locally to validate production behavior.npm run check
– run svelte-check
with the project tsconfig for type and accessibility linting.npm run check:watch
– keep svelte-check
running for incremental feedback during refactors.
Write components in Svelte + TypeScript; prefer PascalCase for component filenames stored in
src/lib
. Route files follow the SvelteKit
+page.svelte
and
+layout.svelte
pattern and should stay lightweight. Indent with tabs (the default across existing config files). Scope styles with Svelte
<style>
blocks or Tailwind utility classes; keep shared CSS in
src/app.css
. Re-export shared modules from
src/lib/index.ts
to provide a clear public surface.
Leverage
npm run check
before every PR; treat a clean run as the baseline quality gate. Don't add any tests for now.
Follow Conventional Commits (
feat:
,
fix:
,
chore:
) for clarity in history and changelog generation. Write commits that isolate logical changes and include a short body when context is not obvious. Pull requests should describe the problem, the solution, and any follow-up work; link to an issue tracker or include reproduction steps. Add screenshots or terminal output when UI or CLI behavior changes, and confirm
npm run build
and
npm run check
in the PR description.