Правила проекта для агента: файл, который экономит часы
Файл правил в корне репозитория агент читает до того, как возьмётся за задачу. Один раз написали — работает во всех сессиях и у всей команды. Это самый дешёвый способ поднять качество: дешевле, чем переходить на модель подороже.
Шаг 1. Стек и инструменты
Первое, на чём ошибается агент, — версии и менеджер пакетов. Без явного указания он предложит установку через тот, которым пользуется большинство в интернете, а не тот, что у вас.
Стек: PHP 8.4, Laravel 13, Blade, SQLite. Пакетный менеджер: composer, для фронта — npm. Сборка фронтенда: vite, npm run build. Тесты: php artisan test.
Шаг 2. Запреты
Запреты работают лучше пожеланий. «Пиши аккуратно» агент проигнорирует, «не добавляй зависимости без просьбы» — выполнит.
Не добавляй зависимости без явной просьбы. Не переписывай файлы целиком — правь точечно. Не меняй публичные интерфейсы без предупреждения. Не удаляй существующие тесты. Не создавай документацию, если её не просили.
Шаг 3. Стиль кода
Опишите не абстрактную красоту, а конкретные решения, которые у вас уже приняты: именование, язык комментариев, отношение к комментариям вообще.
Имена — по-английски, тексты интерфейса — по-русски.
Без комментариев-очевидностей: комментарий только
там, где логика неочевидна.
Форматирование: {инструмент}, запускать после правок.
Шаг 4. Процесс работы
Самая ценная строка во всём файле — требование показать план до правок. Она превращает «агент что-то сделал» в «агент сказал, что собирается сделать, и вы согласились».
Перед большой правкой показывай план списком и жди подтверждения. После правок запускай тесты и показывай вывод. Если задача непонятна — задай вопрос, не угадывай.
Шаг 5. Проверить, что файл работает
Правила без проверки — самообман. Дайте агенту задачу, которая провоцирует нарушение: попросите добавить функцию, для которой напрашивается новая библиотека. Если он спросил разрешения — файл работает.