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.

How-To

How to Write AGENTS.md

One file that works across Codex, Cursor, Jules, GitHub Copilot, and Gemini CLI. Here is exactly how to write it.

Last updated: 2026-07-01

Why AGENTS.md exists

As AI coding tools multiplied, teams ended up maintaining separate CLAUDE.md, .cursorrules, and other tool-specific files that drifted out of sync. AGENTS.md is the open-standard solution: one plain-markdown file that any compliant tool reads. No proprietary syntax, no required structure. You write it once; every tool that supports the standard reads it.

Which tools support AGENTS.md

As of mid-2026: OpenAI Codex, Cursor (reads it alongside .cursor/rules), Google Jules, GitHub Copilot Agent mode, Gemini CLI, and a growing list of others. The standard is governed by the Agentic AI Foundation under the Linux Foundation -adoption is accelerating.

Structure your AGENTS.md for compliance

No required structure, but these sections are most effective: (1) Project overview -one paragraph. (2) Tech stack -specific versions matter. (3) Repository structure -an annotated directory tree. (4) Coding conventions -concrete rules, not principles. (5) Must-not-do list -explicit prohibitions. (6) Test commands -so agents can verify their changes.

Complete AGENTS.md template

Copy this and customize the stack section for your project.

AGENTS.md

# Project Agent Guidelines

## Overview
[One paragraph: what this project does and who uses it.]

## Tech Stack
- Language: TypeScript 5.x (strict mode)
- Framework: Next.js 16 (App Router)  
- Runtime: Node.js 20+
- Styling: Tailwind CSS v4
- Database: PostgreSQL via Prisma
- Auth: [your auth provider]
- Testing: Vitest + React Testing Library + Playwright

## Repository Structure
```
src/
├── app/          # Routes (App Router). Thin pages only.
├── components/   # Shared UI (used in 2+ routes).
├── features/     # Business domain modules.
├── hooks/        # Shared custom React hooks.
├── lib/          # Server-only utilities (import 'server-only').
├── store/        # Zustand stores (UI state only).
├── types/        # Global TypeScript types.
└── utils/        # Pure helpers (client + server safe).
```

## Code Conventions

### TypeScript
- strict: true -no any, no implicit returns, no unchecked indexing.
- Interface for object shapes. Type alias for unions and utility types.
- No enums -use union string literals.
- Zod validates all external data. Infer types with z.infer<typeof Schema>.

### React
- Named exports only for all components and hooks.
- One component per file. Props typed with interfaces.
- Default to Server Components. "use client" only when required.
- No useEffect for data fetching.

### Naming
- Files: kebab-case | Components: PascalCase | Hooks: useCamelCase
- Booleans: isX, hasX, canX | Handlers: handleX | Callbacks: onX

## Must NOT Do
- Create pages/ directory -App Router only.
- Use any without written justification.
- Store server/async data in Zustand.
- Import lib/ utilities from Client Components.
- Use default exports for components.

## Tests
```bash
npm run test           # unit + integration
npm run test:e2e       # Playwright e2e
npm run type-check     # TypeScript compiler
npm run lint           # ESLint
```

## PR Guidelines
- Every new feature needs at least one test.
- Types go in src/types/ (global) or feature/types.ts (local).
- Keep PRs focused -one concern per PR.