What is a CLAUDE.md file and how does it work?

A CLAUDE.md file is a Markdown conventions file that Claude Code reads automatically when you start a session. It contains your project's folder structure, coding standards, naming conventions, and performance rules - so Claude writes consistent code from the first prompt. standarx generates this file for you in under 3 minutes with a guided wizard for React and Next.js projects.

How do I create cursor rules (.cursor/rules/*.mdc) for my project?

A .cursor/rules/*.mdc file tells Cursor's AI Composer exactly how to structure and write code for your project. With standarx, you select your framework (React or Next.js), choose a folder structure, toggle coding standards, and configure performance optimizations. The tool generates a clean .cursor/rules/*.mdc file you drop into your project root - Cursor reads it automatically.

Why does my AI coding assistant write messy or inconsistent code?

AI coding assistants like Claude Code, Cursor, and Codex produce inconsistent code because they don't know your project's specific conventions. Without explicit rules, the AI invents a different folder layout every time, mixes naming patterns, skips error handling, and ignores performance optimizations. The fix is giving your AI a conventions file (CLAUDE.md, .cursorrules, or AGENTS.md) that defines what "good" means for your stack. standarx generates these files automatically.

How do I stop AI from changing my folder structure every time?

AI coding agents change folder structures because they have no reference for your project's architecture. The solution is creating a rules file that explicitly defines your directory layout, what each folder is for, and how new files should be organized. standarx lets you configure a complete folder structure (with definitions for each directory), then generates a Markdown file your AI reads before writing any code - ensuring consistent structure across every session.

What coding standards should my AI agent follow for React and Next.js?

For React and Next.js projects, your AI agent should follow standards covering: named exports for components, TypeScript strict mode, proper error boundaries, semantic HTML, file size limits, import ordering, consistent naming conventions (PascalCase for components, camelCase for utilities), and accessibility (ARIA attributes, keyboard navigation). standarx provides a curated library of 30+ coding standards you can toggle on/off and customize, then generates a file your AI obeys.

What is "vibe coding" and how do I fix problems with it?

Vibe coding is when you build with AI tools (like Cursor or Claude Code) without setting explicit rules - you just "vibe" and let the AI decide everything. The problems: inconsistent folder structures, mixed coding patterns, missing optimizations, and unmaintainable code. The fix is giving your AI a conventions file before you start coding. standarx generates these files (CLAUDE.md, .cursorrules, AGENTS.md) so your AI follows consistent standards from line one - structured vibe coding.

Tool-Specific

Cursor Rules for TypeScript

TypeScript without rules gives you TypeScript with any everywhere. Here is the .cursor/rules setup that makes Cursor write strict, idiomatic TypeScript from the first line.

Last updated: 2026-07-01

The TypeScript mistakes Cursor makes without rules

Left to defaults, Cursor writes valid-but-weak TypeScript: it uses any when types get complex, writes type instead of interface for component props, invents inconsistent generic names, and rarely adds return type annotations. None of this breaks compilation, but it erodes the value of TypeScript entirely.

Key TypeScript conventions to encode

The most impactful rules are: strict mode on (catches nullability bugs), no any without a comment explaining why, interfaces for object shapes and component props, type aliases for unions and utility types, consistent generic naming (T, TData, TResponse), and Zod for runtime validation at API boundaries. Encode all of these explicitly -Cursor won't infer them from your tsconfig alone.

Ready-to-use TypeScript rules

Place this at .cursor/rules/typescript.mdc in your project root.

.cursor/rules/typescript.mdc

---
description: TypeScript conventions for this project
globs: ["**/*.ts", "**/*.tsx"]
alwaysApply: true
---

# TypeScript Rules

## Strictness
- tsconfig strict: true is enabled. Never disable strictNullChecks.
- Never use `any`. If unavoidable, add: // eslint-disable-next-line @typescript-eslint/no-explicit-any with a comment explaining why.
- Use `unknown` for values of unknown type, then narrow with type guards.

## Types vs Interfaces
- Use `interface` for object shapes, component props, and API response structures.
- Use `type` for union types, intersection types, and utility type aliases.
- Do NOT use enums. Prefer union string literals: type Status = 'idle' | 'loading' | 'error' | 'success'

## Generics
- Name generics: T (general), TData (data payloads), TResponse (API responses), TProps (component props).
- Avoid single-letter generics beyond T in complex signatures.

## Zod
- All external data (API responses, form inputs, env vars) must be validated with a Zod schema at the boundary.
- Infer TypeScript types from Zod: type User = z.infer<typeof UserSchema>. Never duplicate the type manually.

## Return Types
- Always annotate return types on exported functions and React components.
- Exception: simple arrow function callbacks where the type is obvious from context.

## Naming
- Boolean variables: is/has/can/should prefix. (isLoading, hasError, canSubmit)
- Event handlers: handle prefix. (handleSubmit, handleChange)
- Custom hooks: use prefix. (useAuth, useDebounce)

Combining with ESLint

Your Cursor rules and your ESLint config should agree. If your .eslintrc bans any, your cursor rules should too. When they conflict, Cursor will follow its rules file -but your CI will catch the violations anyway. Consistency between the two avoids confusion.