Анатомія rules file, який працює

Бачив rules files на 1000+ рядків.
Не працюють. AI губиться, ігнорує половину, плутає інструкції.
Дослідження показують: максимум — 500 рядків. Краще — менше.
Але справа не тільки в довжині.
—
5 секцій, які мають бути

1. Project Overview
Контекст в двох реченнях.
# Project: MealMatics
AI-powered meal planning app
Stack: Flutter, Supabase, Riverpod

2. Code Style
Конкретні правила, не "пиши гарний код".
## Code Style
- TypeScript strict, no any
- Functional components only
- camelCase variables, PascalCase components
- Named exports, no default

3. Structure
Де що лежить.
## Structure
- lib/features/ — feature modules
- lib/core/ — shared utilities
- lib/data/ — repositories, API

4. Commands
Як білдити, тестувати, запускати.
## Commands
- pnpm dev — local server
- pnpm test — run tests
- pnpm lint — check code

5. Don'ts
Найважливіше. Що НЕ робити.
## Don'ts
- No class components
- No inline styles
- No console.log in commits
- No any type
- No eslint-disable without comment
—

Anti-patterns

Що вбиває ефективність rules:

God Prompt
Один гігантський файл на всі випадки життя.
- Рішення: розбий на модулі по 50-100 рядків

Суперечливі інструкції
"Використовуй класи" в одному місці, "тільки функції" в іншому.
- AI буде робити рандомно

Негативні формулювання
"Не використовуй X, не роби Y, ніколи Z"
- Працює гірше, ніж "Використовуй A замість X"

Over-documentation
Правила для того, що лінтер і так перевірить.
- Форматування — ESLint. Rules — для архітектурних рішень.

Semantic Drift
Rules file не оновлюється, код змінився.
- Версіонуй разом з кодом, рев'юй раз на місяць
—
Мінімальний шаблон
Почни з цього, розширюй по потребі:
# Project: [name]
[One sentence what it does]
Stack: [tech stack]

## Code Style
- [3-5 key rules]

## Structure
- [main folders]

## Commands
- [dev, test, build]

## Don'ts
- [3-5 things to avoid]

50 рядків. Цього достатньо для старту.
—
Завтра — advanced фішки: globs, Model Decision, Memory Bank pattern.

Stay tuned 🧠