📝 Список задач 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)