"📝 Список задач Claude Code - схема ""ТРИ ВОЛШЕБНЫХ ПУНКТА"" 1/2 Поделюсь приёмами, которые использую при сеансах ""вайбкодинга"". Когда ""все по науке"", тогда после процесса проектирования агент часами работает над планами реализации и тестовыми стратегиями. Тогда вся его работа происходит по длинным воркфлоу, много этапов и все такое. Но сегодня мы не про AI-SWE, а про ""вульгарный"" вайбкодинг)) Это - о кейсе, когда мы условно в ""свободном"" режиме допиливаем чего то с СС. Для таких кейсов я действую следующим образом: обычно в режиме plan mode (переключается Shift+Tab) обсуждаю с агентом план действий. У моего плана действий для вайбкодинг сессии есть ТРИ обязательных пункта: два в начале, один в конце. 1️⃣ Сначала я прошу сделать ЧЕК-ЛИСТ по выполнению текущего плана в корне проекта со всеми ключевыми деталями для кода и документации. 2️⃣ Следом я прошу через субагента внести изменения в документацию, обновить мемори банк: проанализировать текущие duo файлы по индексу, найти какие файлы нужно обновить/актуализировать, какиу удалить, какие дополнить. То есть для того плана, который я собираюсь реализовать, первым пунктом делается документация - docs first. ▶️ Далее идёт сам план, который мы разработали с агентом. 3️⃣ Последним пунктом плана я прошу взять чек-лист из файла, и запустить субагента на сверку фактических файлов кода и документации с чек-листом, проверить как все реализовано, и исправить недостатки. Наверное, делать typecheck / linit / build - об этом не говорим, это общая гигиена при создании кода. Тестовая стратегия - использовать минималистичный набор тестов только для core functionality. ❓ Зачем такие сложности? Агент при длительном выполнении в основном потоке (тот самый вайбкодинг) может слегка забывать план, отклоняться в стороны, не сделать чего то, или ""лениться"". Чек-лист первым пунктом, когда план ""свеж в памяти"" агента - он помогает зафиксировать важные детали плана, чтобы потом быть ""стержнем"" при выполнении задуманного. ❓ Почему обновление мемори банка вторым пунктом? А не последним? логично было бы сначала сделать код, а потом все документировать! Нет, не логично. И примерной по той же причине, что и чек-лист на первом пункте - агент пока ещё хорошо помнит план и его детали. В конце выполнения в контексте агента будет много всего, и документировать в таком ""смурном"" состоянии - затея не очень хорошая. Если чек-лист важен чтобы агент ВЫПОЛНИЛ план с полными деталями, то документация на втором пункте важна чтобы агент ЗАДОКУМЕННТОВАЛ чего мы тут навайбкодили ""на память"" для последующего использования - что не менее важно. Вам ещё с этим кодом жить! ❓ Если в процессе постоянно говорить ""сверяйся с чек-листом"" - это поможет? Конечно, поможет, - я так и делаю, особенно если агент остановился ""передохнуть"" после значительных этапов. Но можно и в процессе работы ""напоминать"", особенно если дело дошло до компакта. ❓ А зачем тогда финальный чекап по чек-листу? Как ни странно, агент регулярно упускает какие-то детали. Если его ""стегали"" по ходу дела возвращаться к чек-листу, то такого будет меньше - но полностью исключить не выходит. Поэтому проверка в конце очень важна, она позволяет доработать все, и код и документацию - как предполагалось первоначально. ❓ У агента же есть свой список задач! Зачем ему чек-лист? Верно, но я ""синхронизирую"" список задач: когда нужно выполнить план, я прошу взять план и выполнить, и сохранить план себе в TodoWrite (это инструмент записи в список задач агента) - тогда агент часто берет прям структуру моего плана и буквально переносит его в свойс список задач. Вот тут твиттерские нарыли, что агент постоянно возвращается к своему плану работы, буквально постоянно. Это говорит о пользе ""синхронизации"" нашего плана с планом агента: https://x.com/vitransformer/status/1958135188749509016 Ну и напоминалки агенту никогда не помешают, поэтому напоминаем про чек-лист почаще! (... продолжение: https://t.me/deksden_notes/65)"