Топ-советы по Claude Code от Бориса Черни и не только: гайд на 56k звёзд — что реально работает, а что мимо

[Dreams_and_magic]

Я прописал так: graphify сразу, если не нашёл - ищет подробные описания в md файлах в отдельной папке. Это ускорило понимание, чего собсвенно хотят и где искать, но в 1% случаев всё равно путается, приходится руками показывать, где и что.
У меня маленькие объёмы, CpenCode оболочка + DeepSeek (или аналогичные от китайцев). Много подробных описаний и файлов с планированием, но в итоге не всё по плану идёт. А из того, что пошло по плану, много что выбрасывается в корзину под предлогом "я уже хочу по-другому" :)
ИМХО спорить про нужность RAG это бессмысленно, т.к. зависит от объёмов кода и языка. Миллион строк на C# и 5000 строк на Python это две разных вселенные. А ещё есть микросервисы и прочие распределённые структуры, это знание тоже надо как-то отобразить в дереве знаний.

А проблема "гниения контента" это вообще из другой оперы, я пока что универсального подхода не нащупал, прогресс изменений и исправлений в сессии - в текстовые файлы сохранять или ещё как? Бесит, когда нейросеть ломает уже отлаженное тяжким трудом, потому что ничерта не помнит:)

[capjdcoder]

а чего ссылку-то на репо не дали? На ваши куча, а на обсуждаемый как в формате кода?

[Dhwtj]

https://github.com/shanraisshan/claude-code-best-practice

Но я ничего не понял. Если найдете хороший скилл планирования скажите

[Dhwtj]

все 13 методологий, при всей их разности, сходятся к одному скелету — Research → Plan → Execute → Review → Ship

А где модный intent, указание приоритетов, проверка гипотез, постановка задачи? Очень грубый скелет. Для разработки не годится.

Вот. Простите за нейрогенерацию:

Скелет описывает исполнительный конвейер, а не инженерное мышление. Он начинается с момента, когда задача уже есть. А самое дорогое и непригодное для автоматизации - что происходит до Research:

- откуда взялась задача (intent),
- почему она важнее других (приоритеты),
- что мы вообще не знаем и должно быть проверено до плана (гипотезы),
- какой результат считается «тем самым» (критерий, форма).

Это не Research в их смысле. Их Research = «сбор фактов о коде под уже принятую цель». Твой research = «а та ли это цель». Разные уровни, они второй пропускают, потому что он не делегируется (см. твой прошлый вывод).

Плюс скелет линеен, а реальная разработка - это цикл с возвратами на переопределение задачи. У них Review/Ship в конце, то есть петля замыкается на «правильно ли сделали», а не «то ли делали». Самой важной петли - назад к intent - нет.

Так что да: грубый скелет, и грубый осознанно. Он годится для задач, где смысл уже зафиксирован снаружи (человеком). Это конвейер сборки, не конструкторское бюро. Маркетинг продаёт его как второе, продаёт первое.

Тогда по хорошему на входе должен быть чек-лист готовности. Если не готова задача - иди, человек, думай. И это правильная инверсия: не агент решает intent, а gate проверяет, что человек его уже решил.

Чек-лист готовности (до Research):
- Сформулирован intent: зачем, чья боль, что будет, если не делать.
- Критерий результата: как пойму, что сделано «то самое» (не «тесты зелёные»).
- Решения уже приняты: что переписать / что адаптировать / целевая структура. Не вопросы агенту, а данность.
- Контракты/инварианты, которые нельзя нарушать.
- Явные не-цели: чего НЕ делать (антискоуп от расползания в адаптеры).
- Открытые гипотезы помечены и закрыты до плана, либо вынесены за скоуп.

Если не заполнено - агент не стартует, а возвращает: «иди думай». Именно отказ, не попытка достроить за тебя. Это и лечит проблему ранней уверенности LLM в готовности к старту.

По сути это Definition of Ready, только не для скрам-доски, а как hard gate перед агентом. Разница принципиальная: у людей DoR рекомендация, тут это предусловие, нарушение которого = отказ исполнять.

Интересно, что ни одна из 13 методологий это не ставит впереди - потому что это снижает «вау, оно само», а продают именно его.

[AiZen_13]

Graphify не пробовал, но на днях как раз просил codex замерить скорость поиска через rg и через индекс phpstorm (через mcp) - через rg раз в 100 быстрее оказалось 😐

[Genius_Russian_Coders]

По поводу ветки про Research → Plan → Execute → Review → Ship: у нас intent и приоритеты вынесены в слой-классификатор до Plan. Он определяет тип задачи (баг/фича/рефакторинг) и меняет всю стратегию выполнения. Без этого агент валит всё в одну кучу.