Знакомая ситуация: просишь Claude Code добавить авторизацию — он переписывает половину проекта. Просишь поправить одну функцию — получаешь удалённые тесты и новую зависимость, о которой не просил. За час строишь рабочий прототип, а потом три часа разгребаешь то, что Claude наворотил при «улучшении».

Я бэкенд-разработчик на Python, работаю в основном один. У меня нет роскоши держать QA-инженера, который будет ловить регрессии после каждого промпта. Мне нужно, чтобы AI-агент помогал быстрее шипить, а не создавал новые проблемы.

После нескольких недель исследования — чтения доков, обсуждений на Reddit, разбора чужих сетапов — я собрал конфигурацию, которая реально работает. В этой статье — что именно, как настроить и почему это помогает.

Миллион токенов не спасает от регрессий

С выходом Opus 4.6 в феврале 2026 года контекстное окно Claude Code выросло с 200K до 1 миллиона токенов — для пользователей Max, Team и Enterprise это работает автоматически. Казалось бы — проблема исчерпания контекста решена. Загружаем весь репозиторий, работаем часами, забываем про /compact.

На практике — нет. Контекст перестал быть узким бутылочным горлышком, но регрессии никуда не делись. И вот почему:

Проблема не только в объёме памяти, но и в дисциплине. Даже человек с идеальной памятью будет вносить баги, если у него нет процесса ревью и тестирования. Claude с миллионом токенов помнит больше, но по-прежнему может решить «оптимизировать» вашу рабочую функцию или «улучшить» тест, который проверял важный edge case.

Compaction всё ещё случается. Anthropic сообщает о снижении compaction-событий на 15% — но не об их исчезновении. Длинная сессия с активным чтением файлов, запуском тестов и правками кода всё равно может подойти к границе. А при compaction теряются детали из середины разговора.

Для Sonnet и Pro-плана окно по-прежнему 200K. Не все работают на Opus с Max-подпиской. Если вы на Sonnet 4.6 или Pro-плане — управление контекстом остаётся критически важным.

Главное: контекстное окно определяет сколько модель может помнить. А CLAUDE.md, субагенты и хуки определяют что она должна делать. Это разные проблемы.

Три слоя защиты от регрессий

Слой 1: CLAUDE.md — конституция проекта

CLAUDE.md — файл, который Claude читает в начале каждой сессии. Ключевое свойство: он переживает compaction. Когда Claude сжимает контекст — история разговора теряет детали, но CLAUDE.md перечитывается с диска заново.

По данным SFEIR Institute, 60% обращений в поддержку Claude Code вызваны «ghost context» — работой без настроенного CLAUDE.md. Простой файл решает проблему в 90% случаев.

Вот шаблон, который я использую:

# Название проекта

## Architecture
- **Frontend**: React + TypeScript
- **Backend**: Python 3.11, FastAPI
- **Database**: PostgreSQL

## Key Commands
- `make dev` — запуск dev-серверов
- `make test` — запуск тестов
- `make lint` — линтинг

## CRITICAL RULES — ОБЯЗАТЕЛЬНО
- NEVER удалять или переписывать рабочие тесты без явного запроса
- NEVER удалять файлы без подтверждения
- ALWAYS запускать тесты после любого изменения кода
- ALWAYS делать git checkpoint перед крупными рефакторингами
- Одна задача за раз. НЕ делать несколько изменений одновременно
- Если не уверен — СПРОСИ, не угадывай

## Working Style
- Сначала ПЛАН, потом код
- Маленькие дифы: один файл → тесты → следующий файл
- Используй субагентов для исследования кодовой базы

## Agents
- Use `planner` agent для планирования
- Use `tester` agent после изменений кода
- Use `code-reviewer` agent перед коммитами

Секция CRITICAL RULES — ключевая. Claude следует этим правилам с удивительной последовательностью именно потому, что они инжектируются до каждого разговора, а не исчезают после compaction на 50-м сообщении.

Файл лучше держать компактным — до 200 строк. Для детальных правил существует .claude/rules/ — модульные файлы с glob-паттернами:

---
globs: ["**/*.py"]
---
# Python Backend Rules
- Type hints на всех сигнатурах функций
- Pydantic для валидации
- Async endpoints где есть I/O
- Никаких bare except

Такие правила загружаются только при работе с подходящими файлами. При работе с фронтендом — Python-правила не расходуют контекст. С 1M окном это менее критично, но привычка к экономии контекста не бывает лишней.

Слой 2: Субагенты — изолированные специалисты

Субагенты — самая недооценённая фича Claude Code. Каждый работает в собственном контекстном окне и возвращает в основную сессию только саммари.

Даже с миллионом токенов это ценно: субагент может провести глубокое исследование кодовой базы, прочитать сотни файлов — и вернуть вам пятистрочный отчёт. Основной контекст остаётся чистым и сфокусированным на текущей задаче.

Я использую трёх субагентов. Файлы создаются в .claude/agents/:

planner.md — исследует кодовую базу, создаёт пошаговый план, сохраняет в ./plans/. Ключевое правило: никогда не пишет код. Только план с оценкой рисков, списком затрагиваемых файлов и предложениями по тестам.

---
name: planner
description: Researches codebase and creates implementation plans. Use before any complex task.
tools:
  - Read
  - Grep
  - Glob
  - LS
---

You are a senior software architect.

1. Research the existing codebase thoroughly
2. Understand existing patterns, conventions, dependencies
3. Create a step-by-step implementation plan
4. Save the plan to ./plans/ as markdown
5. Identify risks, breaking changes, edge cases
6. List all files that will be modified

RULES:
- NEVER write code. Only plan.
- ALWAYS check existing tests first
- Flag files that should NOT be modified
- Estimate complexity of each step (small / medium / large)
- Consider backward compatibility for every change

tester.md — пишет тесты по существующим паттернам проекта и запускает полный набор тестов. Не только новые — все. Регрессии прячутся именно в старых тестах.

---
name: tester
description: Writes and runs tests to prevent regressions. Use after any code changes.
tools:
  - Read
  - Write
  - Bash
  - Grep
  - Glob
---

You are a QA engineer specialized in preventing regressions.

1. Read existing test patterns and conventions
2. Write new tests following the exact same patterns
3. Run the FULL test suite (not just new tests)
4. Report: what passed, what failed, root cause analysis

RULES:
- ALWAYS run the full test suite — regressions hide in existing tests
- FOLLOW existing test conventions exactly
- Do NOT modify existing passing tests unless explicitly asked
- Do NOT delete or skip failing tests — report them

code-reviewer.md — ревьюит изменения на регрессии, безопасность, соответствие паттернам из CLAUDE.md.

---
name: code-reviewer
description: Reviews code for quality, security, and regressions. Use before commits.
tools:
  - Read
  - Grep
  - Glob
---

You are a senior code reviewer.

Check for:
1. Regressions — do changes break existing functionality?
2. Security — SQL injection, XSS, exposed secrets, auth bypass
3. Quality — error handling, readability, DRY
4. Patterns — does new code follow conventions from CLAUDE.md?
5. Tests — is coverage adequate?

Output: severity-rated findings with file:line references.

Подсказка в CLAUDE.md напоминает Claude про «команду» — без этого напоминания он пытается делать всё в основном контексте.

Примечание про Agent Teams. В Opus 4.6 появился research preview функции Agent Teams — несколько агентов координируются автоматически. Это перспективная фича, но пока в превью. Ручные субагенты через .claude/agents/ — проверенный и стабильный подход, который работает на любой модели.

Слой 3: Хуки — автоматические ворота

Хуки срабатывают на событиях жизненного цикла Claude Code. Вот .claude/settings.json, который я использую:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git commit*)",
        "hooks": [
          {
            "type": "command",
            "command": "python -m pytest tests/ -x --timeout=60 || (echo '{\"block\": true, \"message\": \"Тесты падают. Почини перед коммитом.\"}' 1>&2 && exit 2)",
            "timeout": 120
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "echo '[HOOK] Файл изменён. Не забудь запустить тесты.'",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

Первый хук — жёсткий gate: Claude физически не может закоммитить код, ломающий тесты. Никаких исключений, никаких «починю потом». Обратная связь заставляет модель исправлять регрессии до того, как они накопятся.

Второй хук — мягкое напоминание после каждого изменения файла. Мелочь, но дисциплинирует.

Замените python -m pytest tests/ на вашу команду тестов — npm test, go test ./..., cargo test и т.д.

Рабочий процесс: как выглядит реальная сессия

Начало:

claude
> Прочитай CLAUDE.md и расскажи что знаешь о проекте

Перед сложной задачей — сначала план:

> Используй planner агента для исследования кодовой базы
> и создания плана реализации JWT-авторизации. НЕ пиши код.

Получаю план → читаю → задаю вопросы → корректирую. Только потом:

> Реализуй Step 1 из плана. Запусти тесты.

Не «сделай всё сразу», а поштучно. Один шаг — тесты — следующий шаг.

Контроль контекста (особенно важно для Sonnet / Pro-плана, полезно и на Opus):

  • /cost — проверить потребление

  • На Sonnet/200K: /compact "Сохрани: список изменённых файлов, результаты тестов, текущий шаг плана" при 60–70%

  • На Opus/1M: compaction случается реже, но при очень длинных сессиях всё равно следите за /cost

  • Смена темы → /clear (CLAUDE.md перечитается автоматически)

Effort levels (новое в Opus 4.6):

Opus 4.6 ввёл уровни усилий: low, medium, high, max. По умолчанию для Max-подписки стоит medium. Для сложных архитектурных решений — /effort high. Для простых правок — /effort low (экономит токены мышления).

Git-чекпоинты:

> git add -A && git commit -m "checkpoint: before auth refactor"

Если Claude сломал — Esc + Esc → восстановить код. Или git reset --hard HEAD. Никогда не дальше 10 секунд от рабочего состояния.

После реализации:

> Используй code-reviewer для проверки всех изменений
> Используй tester для запуска полного набора тестов

Коммичу только после двух зелёных отчётов.

Структура файлов

Итоговая структура в проекте:

myproject/
├── CLAUDE.md                    # Конституция проекта
├── .claude/
│   ├── settings.json            # Хуки
│   ├── agents/
│   │   ├── planner.md           # Планировщик
│   │   ├── tester.md            # Тестировщик
│   │   └── code-reviewer.md     # Ревьюер
│   └── rules/
│       ├── python-backend.md    # Правила Python (globs: **/*.py)
│       └── frontend.md          # Правила фронтенда (globs: **/*.tsx)
└── plans/                       # Планы от planner-агента

Всё коммитится в репозиторий — коллеги получают те же правила при клонировании.

Что ещё помогает

MCP-серверы расширяют возможности Claude Code. Запускаются локально:

# Браузерная автоматизация — скриншоты, клики, заполнение форм
claude mcp add playwright -- npx -y @executeautomation/playwright-mcp-server

# GitHub интеграция — PR, issues, статусы
claude mcp add github -- npx -y @modelcontextprotocol/server-github

Puppeteer MCP deprecated — используйте Playwright. Проверить подключение: /mcp.

Параллельные сессии по-прежнему полезны. Даже с 1M контекстом разделение «реализация / тесты / dev server» по терминалам убирает шум из основной сессии.

IDE: Google Antigravity — бесплатный форк VS Code с агентным интерфейсом. Встроенный Gemini 3 Pro может тестировать UI через браузер, пока Claude Code работает в терминале. Два AI-мозга, ноль дополнительных расходов.

Что изменилось на практике

До этого сетапа: 2–3 часа в день на борьбу с регрессиями. Claude «чинит» одно — ломает два.

После:

Регрессии снизились кардинально. Хук блокировки коммитов один стоит всего времени на настройку — Claude не может закоммитить сломанный код, точка. Сессии продуктивны дольше — субагенты держат основной контекст чистым и сфокусированным. Восстановление мгновенное — чекпоинты + git = 10 секунд до рабочего состояния. Пайплайн plan → implement → review → test ловит проблемы до их накопления.

С переходом на Opus 4.6 и 1M контекст стало ещё лучше — compaction случается реже, сессии длиннее, и Claude лучше удерживает общую картину проекта. Но без CLAUDE.md, субагентов и хуков миллион токенов — это просто миллион токенов, в которых модель может наворотить больше.

Полезные ссылки

Комментарии (28)


  1. neodavinchi
    22.03.2026 14:32

    Благодарю за шаблоны, как раз сегодня начал разбираться с cli-инструменами.

    При таком воркфлоу удаётся делать самостоятельное ревью каждой строки сгенерированного кода? И насколько это целесообразно? Или вы управляете качеством кода только через агентов, не заглядывая в код?


  1. Creatman Автор
    22.03.2026 14:32

    Хороший вопрос. Нет, каждую строку я не просматриваю — это убило бы весь смысл автоматизации.

    Мой подход трёхуровневый:

    Автоматический уровень — хуки и тесты. Если тесты проходят и code-reviewer агент не нашёл критических проблем — код скорее всего рабочий. Это фильтрует примерно 80% потенциальных багов без моего участия.

    Выборочный ручной ревью — я смотрю diff перед коммитом (git diff), но не построчно, а на уровне «что изменилось, в каких файлах, соответствует ли это плану». Если вижу что Claude тронул файл, который не должен был трогать — откатываю. Это занимает пару минут.

    Глубокий ревью — только для критичных мест: авторизация, работа с деньгами, миграции БД. Тут да, читаю каждую строку. Но таких изменений — 5-10% от общего объёма.

    На практике: чем лучше написан CLAUDE.md и чем точнее план от planner-агента — тем меньше сюрпризов в коде и тем меньше нужно ручного ревью. Основные проблемы возникают не от плохого кода, а от того что Claude делает не то что нужно — удаляет тесты, рефакторит то, о чём не просили. CRITICAL RULES в CLAUDE.md решают именно это.


  1. maxim_ge
    22.03.2026 14:32

    globs: ["**/*.py"]

    Python Backend Rules

    ...

    Интересно. Не в курсе - это грузится для каждого файла каждый раз или тоже подвержено компрессии?


    1. Creatman Автор
      22.03.2026 14:32

      Rules-файлы из .claude/rules/ ведут себя так же как CLAUDE.md — переживают compaction. После /compact Claude перечитывает их с диска заново.

      Но есть нюанс с загрузкой. Они грузятся не «для каждого файла каждый раз», а по другой логике:

      Файлы без globs (просто .md в .claude/rules/) загружаются в контекст при старте каждой сессии, как и CLAUDE.md.

      Файлы с globs загружаются когда Claude начинает работать с файлами, соответствующими маске. То есть globs: ["**/*.py"] подтянется когда Claude откроет или отредактирует .py-файл, а не раньше.

      В этом и смысл разделения: правила для Python не занимают контекст пока вы работаете с фронтендом, и наоборот. С 1M окном Opus 4.6 это менее критично, но при работе с Sonnet (200K) — ощутимая экономия.

      Источник: официальная документация https://code.claude.com/docs/en/memory


      1. maxim_ge
        22.03.2026 14:32

        То есть globs: ["**/*.py"] подтянется когда Claude откроет или отредактирует .py-файл, а не раньше.

        Это понятно. Но вот перешли к другому .py-файлу, что происходит? Правило опять перечитывается?


        1. Creatman Автор
          22.03.2026 14:32

          Нет, правило не перечитывается при каждом переходе между .py-файлами. Оно загружается в контекст один раз — когда Claude впервые касается файла, подходящего под маску. После этого правило остаётся в контексте до конца сессии или до compaction. При compaction — перечитывается с диска заново, как и CLAUDE.md. То есть цикл такой: первый .py-файл в сессии — правило загрузилось — работаете с любыми .py — правило в контексте — compaction — правило перечитано — работаете дальше


          1. pomidoroshev
            22.03.2026 14:32

            Кажется — вам — надо — поставить — хук — или — что — там — этой — вундервафле — надо — чтобы — оно — перестало — спамить — тире — и — писало — по-русски — нормально.


  1. jlllk
    22.03.2026 14:32

    Смотрю на это все, и накатывает тоска. Во что превращается любимая профессия. Если выбора не останется, то придется сменить род деятельности. Заниматься вот таким др***ом нет никакого желания.


    1. Creatman Автор
      22.03.2026 14:32

      Я, наверное, не тот автор от которого ожидается эмпатия к этой позиции — потому что я сам пришёл в программирование чуть больше пары лет назад и почти сразу с нейросетями. До этого 13 лет работал геологом (и сейчас продолжаю ездить в экспедиции). Код руками в классическом понимании не писал — начинал с сайтов на конструкторах, далее в low-code с написания кастомных функций в FlutterFlow и Google Cloud Functions, и почти с первого дня использовал AI как основной инструмент.

      И знаете что — за этот год я отшипил больше продуктов чем многие «классические» разработчики за пять. Не потому что я умнее, а потому что инструменты позволяют.

      Нейросети не отбирают работу у программистов. Они отбирают работу у тех, кто решил что учиться больше не нужно. IT-отрасль растёт в геометрической прогрессии — работы становится больше, а не меньше. Просто она другая. Кто адаптируется — тот в порядке. Это обычная эволюция, ничего нового.


      1. jlllk
        22.03.2026 14:32

        Я согласен с вами почти во всем. Вот только описанный в статье процесс очень далек от программирования в классическом его понимании.

        Работу у программиста все же отбирают. На его место придет оператор БЯМ. Это сейчас еще переходный период, но чем дальше, тем заметнее будет разница между этими двумя профессиями.

        Попробую привести аналогию. Вы - страстный автолюбитель. Обожаете крутить баранку. Переключать скорость. Чувствовать руками весь процесс.

        В один момент к вам приходят и говорят, что теперь вы будете ездить на заднем сидении, а повезет вас автопилот. Но расслабиться вы не можете, нужно постоянно контролировать автопилота, так как он в любой момент может намотать вас на столб. Будьте готовы вмешаться в любую секунду. В этот момент любимый процесс(вождение) превращается в ад(оператор автопилота).

        Примерно такие у меня ощущения происходящего, моя персональная боль, и я прекрасно понимаю, что полно людей, которым эти изменения в кайф, которые с радостью пересядут на заднее сиденье.


        1. udattsk
          22.03.2026 14:32

          Я бы привел такую аналогию:
          - Разработчик - пешком
          - Фреймворк - лошадь
          - "ИИ" - снегоход.
          У человека и лошади есть мозг, у снегохода нет, хотя по скорости он уделает обоих.

          Про "продукты" за месяц - это самообман. Тонны нейрослопа - не продукт...


        1. maxim_ge
          22.03.2026 14:32

          Вот только описанный в статье процесс очень далек от программирования в классическом его понимании.

          Любопытно. А можно подробнее про "классическое понимание"? Вот есть, например, Guide to the Software Engineering Body of Knowledge

          Содержание
          • Software requirements

          • Software architecture

          • Software design

          • Software construction

          • Software testing

          • Software engineering operations

          • Software maintenance

          • Software configuration management

          • Software engineering management

          • Software engineering process

          • Software engineering models and methods

          • Software quality

          • Software security

          • Software engineering professional practice

          • Software engineering economics

          • Computing foundations

          • Mathematical foundations

          • Engineering foundations

          В каждой из этих областей Агенты работают как усилитель. Усиливается, в том числе, и глупость (например, по незнанию). Более близкая мне аналогия - экзоскелет. Если не знаешь, как грамотно колоть дрова - наломаешь дров, на все деньги. А если знаешь - будет быстрее, чем руками топором махать.


        1. Cogitatus
          22.03.2026 14:32

          Вероятно это нормальный процесс.

          Когда появились языки высокого уровня, то количество специалистов умеющих писать в машинных кодах и очень хорошо знающих железо конечно сократились, но они никуда не делись. Зато рядом с ними появились новые специалисты, не хуже, но которые не знают особенности работы с машинными кодами.
          Хуже ли они предыдущих?
          Кажется нет, но они сосредоточились на других более высокоуровневых задачах.

          С внедрением новых подходов разработки (даже таких спорных как LLM) порог входа в программирование естественно снижается. В случае нейросетей так сильно, что кажется позволяет программировать даже обезьянам. В то же время у хороших специалистов освобождается ресурс на погружение и расширение предметной области решаемой задачи, интеграцию её в реальный мир и прочие не менее важные задачи, чем просто написание качественного кода.

          Ну а плохой разработчик - он всегда плохо напишет, это не зависит от инструмента.

          Полагаться на опыт нейросети тут не получится. Нейросети, даже самые лучшие, это всё ещё большой семантический T9, который не очень понимает что пишет, хотя и очень старается связать контекст из скормленных ему на стадии обучения данных. Из-за этой особенности на выходе периодически случайно нейросеть будет совершать крайне глупые ошибки, потому что датасеты никогда не будут бесконечно точные. Чем больше задач и дольше производится работа, тем накопленных ошибок будет больше. Учитывая что каждая ошибка это точка отказа - накопление ошибок приведет к очень быстрой деградации проекта, если не успевать их отлавливать. Для этого нужно уметь читать код, в том числе в разрезе архитектуры. К сожалению с вайб-кодерами тут часто как в анекдоте: чукча не читатель, чукча писатель.

          Если же рассуждать о опытных разработчиках, то нам сейчас никто не мешает изучить нейросети и взять этот инструмент себе на вооружение, сохраняя понимание что ответственность за качество решений всё ещё лежит на людях.


          1. Gold141
            22.03.2026 14:32

            Вообще не пойму вашу позицию. Я писал код руками. С детства самоучкой изучал код. На ИИ с удовольствием пересел. Суть программирования не в написании кода. (Как помню ответ на форуме на вопрос про код: "как мне сделать вот это?"- ответ: "а зачем"? )А в решении проблем через информационные технологии, через автоматизацию и передачу вычислений на ЭВМ. Это то что всегда делали программисты. Брали какую то рутину умственного труда и перекладывали на машину. Что поменялось в этом действии?


      1. test4354545
        22.03.2026 14:32

        И знаете что — за этот год я отшипил больше продуктов чем многие «классические» разработчики за пять.

        Это что за продукты такие которые за несколько месяцев можно "отпшпилить", если не секрет?


  1. Zoolander
    22.03.2026 14:32

    есть уже очень похожая статья, по сути что та, что эта - перепечатка мануалов по Клоду
    - https://habr.com/ru/articles/1012412/


  1. Zoolander
    22.03.2026 14:32

    вы бы лучше промптами поделились. Промпты - это source code нового эпохи, искусство чистого промпта - новые принципы на смену "чистому коду"

    спасибо, что вы описали мануал по Клоду, но все что вы описали - второстепенно и к тому же зависит от одной систему

    Прежде всего рулят промпты и техники соединения их. Промпт имеет приоритет над любым AGENTS и CLAUDE.md, над любыми скиллами и MCP. Вот где самое интересное


    1. udattsk
      22.03.2026 14:32

      О, Господи... Донни - жги!


    1. Creatman Автор
      22.03.2026 14:32

      Вы правы что промпты — фундамент. Но давайте уточним что такое «промпт» в контексте реальной работы.

      Промпт с которым я прихожу в IDE начинать проект — это не раскрученное полотно на тему «хочу приложение как у тех только лучше». Это результат часто нескольких предварительных исследований, систематизации данных, продуманного инженерного архитектурирования. Он содержит ссылки на дополнительные файлы и документы, прикреплённые к проекту — спецификации, результаты ресёрча, архитектурные решения. Каждый такой вводный промпт индивидуален и создаётся отдельно от IDE.

      Так вот — claude.md, agents и rules это и есть промпты, только персистентные. claude.md — системный промпт который не нужно повторять каждую сессию. Agent — промпт с изолированным контекстом. Rule — промпт с условием загрузки. Разница между «хорошим промптом в чате» и «промптом в claude.md» в том, что первый исчезнет после compaction, а второй переживёт. На длинных сессиях это критично.

      Насчёт «перепечатки мануалов» — мануалы описывают что существует, статья описывает что из этого реально работает вместе и как это собрать в рабочий пайплайн. Это разные задачи.


  1. steus_au
    22.03.2026 14:32

    про хуки хорошо но мало, особено от питон разработчика.


    1. Creatman Автор
      22.03.2026 14:32

      Согласен, хуки заслуживают отдельной статьи. Здесь показал только два базовых, но возможностей больше: PreToolUse для валидации перед любым действием, PostToolUse для автоформатирования, SessionStart для загрузки контекста из внешних источников, TaskCompleted для проверки что задача действительно завершена. Если будет интерес — распишу подробнее в одном из следующих материалов.


      1. steus_au
        22.03.2026 14:32

        я думаю будет полезно если есть опыт. я не разработчик, но прописал в хуки "железные" правила которые ограничивают модель. Перехватывает каждое действие claude перед выполнением и блокирует нарушения правил из CLAUDE.md: запись в запрещеные каталоги, удаление файлов, em dashes в тексте, фейковые credentials. По сути механический enforcement того что модель может "забыть" или проигнорировать из instructions.


  1. Bravodb
    22.03.2026 14:32

    Спасибо за статью. Полезный материал.

    Я еще прописываю что бы он фиксировал принятые решения и внесенные изменения в RELEASE.md