tune
AI Rules Generator
Eight quick questions about your stack and conventions. The generator composes a rules file in real-time and exports for any AI tool. Every state is encoded into the URL — share the link to share your config.
Loading…
Eight quick questions about your stack and conventions. The generator composes a rules file in real-time and exports for any AI tool. Every state is encoded into the URL — share the link to share your config.
Pick the primary language and project type.
Updates as you change answers. Format: Cline (.clinerules)
# Project AI Rules ## Project context This is a TypeScript web app built with Next.js (App Router). These rules tell the AI how the codebase is structured, which patterns to follow, and how to behave during a session. ## Stack - **Language:** TypeScript - **Framework:** Next.js (App Router) - **Database:** Postgres - **ORM / data layer:** Drizzle - **Auth:** Auth.js / NextAuth - **Hosting:** Vercel - **Styling:** Tailwind CSS - **UI library:** shadcn/ui - **State:** TanStack Query (server state) - **Package manager:** pnpm - **Linter / formatter:** ESLint + Prettier - **Testing:** Vitest ## Stack-specific guidance - Default to Server Components; mark `"use client"` only at the leaf component that needs state, effects, or browser APIs. - Fetch data in async server components or via Server Actions; never in `useEffect`. - Use Server Actions for mutations; route handlers only for public APIs and webhooks. - Never `getServerSideProps` / `getStaticProps` — Pages Router only. ## Code style & conventions - Use functional components and hooks; never class components. - Use named exports only. Never default exports (except where the framework requires them, e.g. Next.js `page.tsx`). - File names: `kebab-case` for utilities, `PascalCase.tsx` for components. - Throw real `Error` subclasses (or language equivalents) for errors; never throw strings or plain objects. ## Testing - Use Vitest for tests. - Place unit tests next to the source files they exercise. - Mock at the boundary (HTTP, FS, external SDKs); never mock internal modules. - Don't claim a task is complete without at least one test exercising the new code path. ## Tooling - Linter / formatter: ESLint + Prettier - Package manager: pnpm - Run the linter, type checker, and tests before considering a task done. ## AI behavioral rules - Ask before installing dependencies. Surface the exact package and reason; let the human approve before running the install command. - Write tests alongside the feature you're building. Don't claim a task is complete without at least one test exercising the new path. - Never modify a database migration after it's been committed to git. Always generate a new migration to amend. - Prefer composition over inheritance. Build complex behavior by composing small, focused functions or components rather than extending base classes. - Don't extract code into a shared helper on the first repetition. Wait until the third occurrence before abstracting — wrong abstractions are harder to refactor than duplicated code. - Never use `any` in TypeScript. Use `unknown` and narrow with type guards. If `any` seems necessary, look harder for the right type. - Always run the linter, type checker, and test suite before declaring a task complete. If any of them fail, the task isn't done. - Remove all debug log statements (`console.log`, `print`, `dbg!`) before committing. If a log is genuinely useful in production, use the project's structured logger instead. - Prefer editing an existing file over creating a new one when the new code fits an existing concern. Only create new files when the concern doesn't have a natural home. - Don't refactor or rename code unrelated to the current task in the same commit. One concern per commit; one PR per logical change. - Validate inputs at system boundaries (HTTP request bodies, queue messages, file uploads, user-submitted forms) using a schema validator (Zod / Pydantic / Valibot). Internal modules trust their inputs. - Never embed API keys, service-role tokens, or other secrets in client-side code. Read them from environment variables on the server only. Never commit `.env` files. - When you're unsure about scope, behavior, or intent, ask one clarifying question before writing code. A good question costs less than rewriting a misguided implementation. - When editing existing code, match the surrounding style — naming conventions, import grouping, formatting. Don't introduce a different style locally just because you prefer it.