Initial commit (fresh repo)

AGENTS.md

@@ -0,0 +1,30 @@
+# 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.
+
+## Build, Test, and Development Commands
+- `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).
+
+## Coding Style & Naming Conventions
+- 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.
+
+## Testing Guidelines
+- 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.
+
+## Commit & Pull Request Guidelines
+- 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.