This file is written for automated coding agents (for example: Copilot coding agents). It exists to provide a concise operational contract and guardrails for agents working in this repository. It is not the canonical source for design or style rules. Those live in the developer documentation linked below.
- Follow the prioritized shared instructions in hoverkraft-tech/.github/AGENTS.md before working in this repository.
This repository hosts Hoverkraft's marketing site, built with Astro 5 and Tailwind CSS inside the application/ directory. Environment requirements, setup commands, and the development workflow live in the Project readme.
- Readme — Getting Started – local install and dev server commands.
- Readme — Development Workflow – linting, build, and preview tasks.
- Readme — Project Structure – authoritative map of key files.
- Readme — Configuration Notes – metadata, analytics, and i18n guidance.
- Contributing guide – branching expectations, code review process, and community standards.
- Ensure all code changes maintain compatibility with the Astro framework and Tailwind design system already configured in
application/. - Integrate features with the existing i18n utilities so default (
fr) and secondary (en) locales stay consistent. - Preserve blog frontmatter structure and permalink patterns when updating content in
application/src/content/orapplication/src/data/. - Run
npm run lintandnpm run buildfromapplication/(ormake lint/make build) before finalizing changes. - Avoid hardcoding configuration values; update
application/src/config.yamlfor metadata, analytics IDs, and feature toggles. - Store optimized assets in
application/src/assets/imagesand import them via the sharedImagecomponent for metadata handling. - Align new components and utilities with the shared TypeScript types in
application/src/types.d.ts. - Pull analytics configuration from
application/src/config.yaml; do not inline vendor IDs. - Use the Partytown setup in
application/astro.config.tsfor third-party scripts when possible.
- Default to the Make targets documented in the readme to mirror CI behavior.
- Focus code edits inside
application/unless explicitly coordinating infrastructure changes. - Prefer referencing readme sections instead of recreating documentation in pull requests.