Repository Guidelines

Project Structure & Module Organization

app/app.vue hosts the root Nuxt view; keep it lean and delegate features to components under a future components/ directory.
public/ holds static assets served as-is.
nuxt.config.ts centralizes Nuxt settings; add modules and runtime config here instead of inside components.
package.json scripts are the source of truth for commands; avoid ad-hoc shell scripts.

npm run dev — start Nuxt dev server at http://localhost:3000 with HMR.
npm run build — production build; ensure this passes before merging.
npm run preview — serve the production build locally to validate routes and assets.
npm run generate — create a static export for static hosting targets.
Install dependencies with npm install (npm lockfile is committed).

Language: Vue 3 with Nuxt 4; prefer <script setup lang="ts"> and the Composition API.
Formatting: 2-space indentation; run a formatter (e.g., npx prettier) before pushing; keep templates tidy and avoid inline styles when practical.
Naming: PascalCase for components (HeroSection.vue), camelCase for composables/utilities (useFeatureFlag), kebab-case for file names except Vue components.
Imports: use Nuxt aliases for clarity (e.g., ~/components/Button.vue) instead of long relative paths.

No automated tests are configured yet; add coverage with new features rather than deferring.
If you add tests, co-locate unit specs with components (Button.spec.ts) and keep integration/E2E flows under tests/.
Always run npm run build and do a quick browser smoke test of impacted routes before opening a PR.

Commits: imperative mood (Add hero CTA copy) and scoped to a single concern; avoid mixing refactors with feature work.
Pull Requests: include a concise summary, screenshots or recordings for UI changes, reproduction steps for fixes, and any follow-up items.
Link issues when relevant and call out breaking changes explicitly in the description.