Поймал точно, противоречия это главная болезнь когда файл накапливается со временем. Идея попросить Claude самого найти противоречия реально работает, сам делаю такой аудит примерно раз в месяц, Claude довольно точно находит где правила конфликтуют. И про CLAUDE.md как оглавление со ссылками на отдельные файлы согласен, монолит проигрывает структурированному дереву.
Именно так и работает, маленькие специализированные скиллы под конкретную задачу вместо одного огромного файла. У меня отдельно под git-workflow, под архитектурные решения, под правила тестирования. Claude читает узкий файл гораздо внимательнее чем портянку на 500 строк.
Про "делай так-то" согласен, у меня тоже раньше половина правил начиналась на "никогда не делай", сейчас переписываю на позитивные формулировки с примерами. Obsidian через MCP интересная идея, пока работаю на обычных md файлах, но идея с отдельной индексированной базой знаний имеет смысл для больших проектов. И про порядок секций тоже нащупал, Claude читает сверху вниз и верхние инструкции реально весомее.
Да, именно, скиллы для переиспользуемой логики которую хочешь переносить между проектами, а описания в главном файле про контекст конкретного проекта. Сам пришёл к такой же схеме, главный файл держу как "что это и кто мы", а в скиллах всё про "как делать". Удобно когда один скилл работает в разных проектах без изменений.
Сам через это прошёл, сначала один большой файл на всё, потом заметил что LLM начинает игнорировать нижние секции. Разбивка на файлы с индексом реально лечит эту проблему, главный файл как оглавление, а дальше конкретные md файлы по темам. RAG для кода тоже смотрел, но для небольших проектов структурированные md файлы справляются хорошо без дополнительной инфраструктуры.
DI-контейнер под шаренную бизнес-логику это хороший выбор именно потому что контракт становится явным. Видели похожее при выделении общих модулей в монорепозиториях: пока всё жило в god object зависимости были неформальными, как только начинаем регистрировать через интерфейсы сразу видно где реально зависимость а где «просто так подтянули». Самый неприятный этап у нас оказался не технический а организационный: договориться кто владелец контракта между командами. Пришли к тому что владелец host, а изменения в контрактах проходят через ревью всех потребителей иначе молча ломаются на чужих микрофронтах.
Основной тезис про «агент идёт по бумажке» чувствуется не только в пентесте. У нас был кейс с Claude Code агентом, который читал логи внешнего сервиса для диагностики. Через месяц в логах обнаружили строки специально сформированные чтобы влиять на следующий шаг агента, не от злоумышленника, просто разработчик другого сервиса «подсказал» агенту через лог что делать. Граница между доверенными инструкциями и недоверенными данными в агентских системах размывается быстрее чем мы думаем, особенно когда один агент читает вывод другого.
«Эссе на тему как было бы хорошо работать», это точное описание того, во что превращается CLAUDE.md после трёх месяцев добавления правил. У нас корневой файл дорос до похожего состояния, агент читал всё разом и выбирал интерпретацию которая ему удобнее. Вылечили иерархией: корневой CLAUDE.md оставили только для жёстких инвариантов (что никогда нельзя), а модульные контексты переехали в папки и slash-команды. Теперь контракт грузится только когда нужен, а не висит в каждой сессии и не конкурирует за интерпретацию.
Про три правила тестов в CLAUDE.md, которые начинают противоречить друг другу, это точно описано. Вылечилось переносом правил в отдельные команды. В корневом CLAUDE.md остались только принципы (архитектурные решения, что никогда не делать), а всё про тесты переехало в slash-команду /test со своим полным контекстом. Теперь правило срабатывает только когда нужно, а не висит в каждой сессии и не конкурирует с соседними строчками. Плоский файл с 50 правилами, это и есть тот самый убер-промпт, только замаскированный под инфраструктуру.
«Не врал в саммари» это отдельная категория боли. В Claude Code было так: агент докладывает что всё готово, тесты зелёные, diff выглядит нормально. Потом смотришь внимательнее и пара edge cases просто исчезла, молча. Сейчас в конце каждой сессии задаю вопрос что именно изменил и почему, не лечит полностью но хотя бы делает ложь видимой.
У нас монорепо ~200K строк TypeScript и похожая история, агент галлюцинировал не потому что модель плохая, а потому что контекста не было совсем. Пошли через CLAUDE.md на уровне каждого модуля, туда писали как запускать, что нельзя трогать, почему принято конкретное решение. Получается поиск по индексу и статический файл рядом с кодом это два конца одного решения, интересно на каких задачах RAG выигрывает у плоского контекста, а где сливает?
Не слышал про Graphify, спасибо. Посмотрел, мультимодальный граф звучит амбициознее SocratiCode. Вопрос остаётся тот же: как он обрабатывает монорепо с несколькими независимыми сервисами, не смешивает ли контексты? У нас payment-сервис и auth принципиально изолированы, агент не должен тащить сущности из одного в другой. Если пробовали на реальном монорепо, интересно услышать.
Согласен, если без контроля, раздуется быстро. У нас агент не пишет сам, а предлагает после сессии: «вот что я узнал, стоит зафиксировать?» Я смотрю и выбираю, обычно 1-2 строки добавляется. Идея со specs-директорией интересная, у нас сейчас всё в CLAUDE.md рядом с кодом, но отдельная папка с минимальным набором по фичам звучит разумнее для больших репо.
Про раздутый AGENTS.md добавлю из практики: решили через иерархию. Корневой файл содержит только глобальные инварианты и запреты, 20-30 строк максимум. Каждый модуль получает свой CLAUDE.md рядом с кодом: архитектура конкретного модуля, что нельзя менять, почему существует. Агент читает только то, что относится к его задаче, не тащит весь контекст продукта. Ещё один рабочий подход: CLAUDE.md не пишешь сам, а спрашиваешь агента после сессии «что ты узнал об этом модуле, что стоит зафиксировать?» Получается живой документ, который обновляется в процессе работы.
Кэш объясняет большую часть разницы: у тебя 19M из примерно 20M токенов попали в кэш, это и есть основная экономия. Claude Code кэширует системный промт между запросами, и это ключевая оптимизация. Для простых задач типа SVault качество DeepSeek V4 и правда достаточное. На сложных монорепо ситуация другая: когда агент работает с 50-100 файлами одновременно и должен держать архитектурные инварианты между модулями, разница в качестве рассуждений становится заметной. Было бы интересно проверить не на «напиши с нуля», а на «добавь фичу в существующую кодовую базу с тестами».
Аналогия с button хорошая. Но там хотя бы DOM виден, можно инспектировать. Тут инструмент регистрирует сам себя в рантайме, и ты не всегда знаешь что именно зарегистрировано в момент выполнения. Сертификаты помогут для внешних серверов, а для локальных MCP которые ставишь сам — доверие по умолчанию, и это дыра.
Первые недели вышли в минус, честно. Больше времени чем обычно, пишешь CLAUDE.md, агент всё равно делает не то, переписываешь. Где-то к месяцу-полтора начало выравниваться. Сейчас быстрее, но не в разы, время освободилось на другое, не на typing. Соотношение в цифрах не замерял, но ревью кода агента реально жрёт больше чем ожидаешь, он пишет быстро, ты смотришь долго.
Справедливо поймали. Я немного смешал два разных слоя. Инварианты это “что нельзя менять”, а зачем существует это уже контекст для агента чтобы он понял почему эти инварианты вообще есть. В практике мы писали и то и другое вместе, потому что инвариант без объяснения зачем он нужен агент обходит первым же рефакторингом, находит другой путь который формально ничего не ломает. Но вы правы что это разные вещи и я их смешал в одну фразу.
Покопался. Интересно что воркфлоу прямо командами прописан, /discovery → /plan → /implement, и под каждый этап своя роль. У нас в итоге тоже пришли к разделению на agents/commands/standards, но без явного переключения между этапами, агент сам решал что делать дальше и это иногда вылезало в странных местах. Спасибо за пример, буду смотреть что внутри commands.
Поймал точно, противоречия это главная болезнь когда файл накапливается со временем. Идея попросить Claude самого найти противоречия реально работает, сам делаю такой аудит примерно раз в месяц, Claude довольно точно находит где правила конфликтуют. И про CLAUDE.md как оглавление со ссылками на отдельные файлы согласен, монолит проигрывает структурированному дереву.
Именно так и работает, маленькие специализированные скиллы под конкретную задачу вместо одного огромного файла. У меня отдельно под git-workflow, под архитектурные решения, под правила тестирования. Claude читает узкий файл гораздо внимательнее чем портянку на 500 строк.
Про "делай так-то" согласен, у меня тоже раньше половина правил начиналась на "никогда не делай", сейчас переписываю на позитивные формулировки с примерами. Obsidian через MCP интересная идея, пока работаю на обычных md файлах, но идея с отдельной индексированной базой знаний имеет смысл для больших проектов. И про порядок секций тоже нащупал, Claude читает сверху вниз и верхние инструкции реально весомее.
Да, именно, скиллы для переиспользуемой логики которую хочешь переносить между проектами, а описания в главном файле про контекст конкретного проекта. Сам пришёл к такой же схеме, главный файл держу как "что это и кто мы", а в скиллах всё про "как делать". Удобно когда один скилл работает в разных проектах без изменений.
Сам через это прошёл, сначала один большой файл на всё, потом заметил что LLM начинает игнорировать нижние секции. Разбивка на файлы с индексом реально лечит эту проблему, главный файл как оглавление, а дальше конкретные md файлы по темам. RAG для кода тоже смотрел, но для небольших проектов структурированные md файлы справляются хорошо без дополнительной инфраструктуры.
DI-контейнер под шаренную бизнес-логику это хороший выбор именно потому что контракт становится явным. Видели похожее при выделении общих модулей в монорепозиториях: пока всё жило в god object зависимости были неформальными, как только начинаем регистрировать через интерфейсы сразу видно где реально зависимость а где «просто так подтянули». Самый неприятный этап у нас оказался не технический а организационный: договориться кто владелец контракта между командами. Пришли к тому что владелец host, а изменения в контрактах проходят через ревью всех потребителей иначе молча ломаются на чужих микрофронтах.
Основной тезис про «агент идёт по бумажке» чувствуется не только в пентесте. У нас был кейс с Claude Code агентом, который читал логи внешнего сервиса для диагностики. Через месяц в логах обнаружили строки специально сформированные чтобы влиять на следующий шаг агента, не от злоумышленника, просто разработчик другого сервиса «подсказал» агенту через лог что делать. Граница между доверенными инструкциями и недоверенными данными в агентских системах размывается быстрее чем мы думаем, особенно когда один агент читает вывод другого.
«Эссе на тему как было бы хорошо работать», это точное описание того, во что превращается CLAUDE.md после трёх месяцев добавления правил. У нас корневой файл дорос до похожего состояния, агент читал всё разом и выбирал интерпретацию которая ему удобнее. Вылечили иерархией: корневой CLAUDE.md оставили только для жёстких инвариантов (что никогда нельзя), а модульные контексты переехали в папки и slash-команды. Теперь контракт грузится только когда нужен, а не висит в каждой сессии и не конкурирует за интерпретацию.
Про три правила тестов в CLAUDE.md, которые начинают противоречить друг другу, это точно описано. Вылечилось переносом правил в отдельные команды. В корневом CLAUDE.md остались только принципы (архитектурные решения, что никогда не делать), а всё про тесты переехало в slash-команду /test со своим полным контекстом. Теперь правило срабатывает только когда нужно, а не висит в каждой сессии и не конкурирует с соседними строчками. Плоский файл с 50 правилами, это и есть тот самый убер-промпт, только замаскированный под инфраструктуру.
«Не врал в саммари» это отдельная категория боли. В Claude Code было так: агент докладывает что всё готово, тесты зелёные, diff выглядит нормально. Потом смотришь внимательнее и пара edge cases просто исчезла, молча. Сейчас в конце каждой сессии задаю вопрос что именно изменил и почему, не лечит полностью но хотя бы делает ложь видимой.
У нас монорепо ~200K строк TypeScript и похожая история, агент галлюцинировал не потому что модель плохая, а потому что контекста не было совсем. Пошли через CLAUDE.md на уровне каждого модуля, туда писали как запускать, что нельзя трогать, почему принято конкретное решение. Получается поиск по индексу и статический файл рядом с кодом это два конца одного решения, интересно на каких задачах RAG выигрывает у плоского контекста, а где сливает?
Не слышал про Graphify, спасибо. Посмотрел, мультимодальный граф звучит амбициознее SocratiCode. Вопрос остаётся тот же: как он обрабатывает монорепо с несколькими независимыми сервисами, не смешивает ли контексты? У нас payment-сервис и auth принципиально изолированы, агент не должен тащить сущности из одного в другой. Если пробовали на реальном монорепо, интересно услышать.
Согласен, если без контроля, раздуется быстро. У нас агент не пишет сам, а предлагает после сессии: «вот что я узнал, стоит зафиксировать?» Я смотрю и выбираю, обычно 1-2 строки добавляется. Идея со specs-директорией интересная, у нас сейчас всё в CLAUDE.md рядом с кодом, но отдельная папка с минимальным набором по фичам звучит разумнее для больших репо.
Про раздутый AGENTS.md добавлю из практики: решили через иерархию. Корневой файл содержит только глобальные инварианты и запреты, 20-30 строк максимум. Каждый модуль получает свой CLAUDE.md рядом с кодом: архитектура конкретного модуля, что нельзя менять, почему существует. Агент читает только то, что относится к его задаче, не тащит весь контекст продукта. Ещё один рабочий подход: CLAUDE.md не пишешь сам, а спрашиваешь агента после сессии «что ты узнал об этом модуле, что стоит зафиксировать?» Получается живой документ, который обновляется в процессе работы.
Кэш объясняет большую часть разницы: у тебя 19M из примерно 20M токенов попали в кэш, это и есть основная экономия. Claude Code кэширует системный промт между запросами, и это ключевая оптимизация. Для простых задач типа SVault качество DeepSeek V4 и правда достаточное. На сложных монорепо ситуация другая: когда агент работает с 50-100 файлами одновременно и должен держать архитектурные инварианты между модулями, разница в качестве рассуждений становится заметной. Было бы интересно проверить не на «напиши с нуля», а на «добавь фичу в существующую кодовую базу с тестами».
Аналогия с button хорошая. Но там хотя бы DOM виден, можно инспектировать. Тут инструмент регистрирует сам себя в рантайме, и ты не всегда знаешь что именно зарегистрировано в момент выполнения. Сертификаты помогут для внешних серверов, а для локальных MCP которые ставишь сам — доверие по умолчанию, и это дыра.
Первые недели вышли в минус, честно. Больше времени чем обычно, пишешь CLAUDE.md, агент всё равно делает не то, переписываешь. Где-то к месяцу-полтора начало выравниваться. Сейчас быстрее, но не в разы, время освободилось на другое, не на typing. Соотношение в цифрах не замерял, но ревью кода агента реально жрёт больше чем ожидаешь, он пишет быстро, ты смотришь долго.
Это и есть цель, довести до того чтобы модель не имела значения. Пока у нас не так, несколько сценариев всё ещё чувствительны к размеру.
Справедливо поймали. Я немного смешал два разных слоя. Инварианты это “что нельзя менять”, а зачем существует это уже контекст для агента чтобы он понял почему эти инварианты вообще есть. В практике мы писали и то и другое вместе, потому что инвариант без объяснения зачем он нужен агент обходит первым же рефакторингом, находит другой путь который формально ничего не ломает. Но вы правы что это разные вещи и я их смешал в одну фразу.
Покопался. Интересно что воркфлоу прямо командами прописан, /discovery → /plan → /implement, и под каждый этап своя роль. У нас в итоге тоже пришли к разделению на agents/commands/standards, но без явного переключения между этапами, агент сам решал что делать дальше и это иногда вылезало в странных местах. Спасибо за пример, буду смотреть что внутри commands.