Кусочек моего глобального AGENTS.md
## Clarify Before Execution
If the task wording raises any questions, or if strange, unexpected, or ambiguous details arise while working, pause before taking action and ask the user for clarification. When applicable, present the possible answers as explicit options to choose from.
Вчера записывали с Киром @geekylog демо его SDD-пайплана на основе сворма агентов поверх кастомного набора шаблонов для OpenSpec. Видео скоро выйдет на канале, а пока поделюсь одним своим наблюдением.
Классический Spec-driven development (если такая формулировка вообще может быть применима, конечно) предполагает, что пользователь формулирует задачу, модель придумывает вариант решения в виде какого-то документа, который пользователь проверяет и при необходимости корректирует до того, как начнется генерация кода.
Если пользователь действительно знает, чего хочет и готов это подробно описать — подход работает.
Но, во-первых, далеко не всегда сразу понятно, что нужно, а во-вторых, можно забыть (или полениться) расписать все детали. В таком случае модель сгенерирует кучу очевидных решений, среди которых нужно будет найти и исправить то, что противоречит чувству прекрасного пользователя.
Мне гораздо ближе подход grill-me, когда агент, получив максимально лаконичное описание того, что и зачем я делаю, сам задает уточняющие вопросы с подготовленными вариантами ответов и объяснением последствий выбора.
Это позволяет «вспомнить» и принять решения по всем важным вопросам. Причем вместо написания длинного текста с пожеланиями достаточно просто указать номера выбранных вариантов. Более того, иногда предложенные варианты оказываются лучше, чем то, что я представлял в голове до начала работы. А если по какому-то пункту не хватает экспертизы, то можно прямо отсюда отбранчеваться в отдельную сессию и разобраться перед тем, как давать ответ.
Остается только зафиксировать все ответы в документе, и это почти и будет готовая спека. При желании еще можно отправить агента-ревьювера убедиться, что действительно не осталось белых пятен, а в ответах нет взаимоисключающих параграфов.
Конечно, если вы работаете в команде, вам все равно потребуется OpenSpec или что-то подобное, чтобы иметь общий стандарт и удобно мерджить изменения от всех участников. Но вычитывать галюцинации модели уже не придется — все решения приняты.
На следующем этапе мы с Киром нарвались еще на один кейс, где мой промпт был бы полезен — уже в процессе генерации кода.
Исполнитель объявил выполненным требование про ручную проверку функциональности. Ревьювер закономерно спросил: «А руками-то кто проверял?» — и завернул его на доработку.
А так как цикл предполагал, что замечания ревьювера исполнитель должен устранять без участия пользователя, агент пустился во все тяжкие.
Вероятно «if strange, unexpected, or ambiguous details arise while working, pause before taking action and ask the user for clarification» могло здесь сэкономить приличное количество времени и токенов.
В общем, хороший агент, конечно, должен уметь работать автономно, но и при этом понимать, когда пора позвать кожаного.
@devspotting
## Clarify Before Execution
If the task wording raises any questions, or if strange, unexpected, or ambiguous details arise while working, pause before taking action and ask the user for clarification. When applicable, present the possible answers as explicit options to choose from.
Вчера записывали с Киром @geekylog демо его SDD-пайплана на основе сворма агентов поверх кастомного набора шаблонов для OpenSpec. Видео скоро выйдет на канале, а пока поделюсь одним своим наблюдением.
Классический Spec-driven development (если такая формулировка вообще может быть применима, конечно) предполагает, что пользователь формулирует задачу, модель придумывает вариант решения в виде какого-то документа, который пользователь проверяет и при необходимости корректирует до того, как начнется генерация кода.
Если пользователь действительно знает, чего хочет и готов это подробно описать — подход работает.
Но, во-первых, далеко не всегда сразу понятно, что нужно, а во-вторых, можно забыть (или полениться) расписать все детали. В таком случае модель сгенерирует кучу очевидных решений, среди которых нужно будет найти и исправить то, что противоречит чувству прекрасного пользователя.
Мне гораздо ближе подход grill-me, когда агент, получив максимально лаконичное описание того, что и зачем я делаю, сам задает уточняющие вопросы с подготовленными вариантами ответов и объяснением последствий выбора.
Это позволяет «вспомнить» и принять решения по всем важным вопросам. Причем вместо написания длинного текста с пожеланиями достаточно просто указать номера выбранных вариантов. Более того, иногда предложенные варианты оказываются лучше, чем то, что я представлял в голове до начала работы. А если по какому-то пункту не хватает экспертизы, то можно прямо отсюда отбранчеваться в отдельную сессию и разобраться перед тем, как давать ответ.
Остается только зафиксировать все ответы в документе, и это почти и будет готовая спека. При желании еще можно отправить агента-ревьювера убедиться, что действительно не осталось белых пятен, а в ответах нет взаимоисключающих параграфов.
Конечно, если вы работаете в команде, вам все равно потребуется OpenSpec или что-то подобное, чтобы иметь общий стандарт и удобно мерджить изменения от всех участников. Но вычитывать галюцинации модели уже не придется — все решения приняты.
На следующем этапе мы с Киром нарвались еще на один кейс, где мой промпт был бы полезен — уже в процессе генерации кода.
Исполнитель объявил выполненным требование про ручную проверку функциональности. Ревьювер закономерно спросил: «А руками-то кто проверял?» — и завернул его на доработку.
А так как цикл предполагал, что замечания ревьювера исполнитель должен устранять без участия пользователя, агент пустился во все тяжкие.
Вероятно «if strange, unexpected, or ambiguous details arise while working, pause before taking action and ask the user for clarification» могло здесь сэкономить приличное количество времени и токенов.
В общем, хороший агент, конечно, должен уметь работать автономно, но и при этом понимать, когда пора позвать кожаного.
@devspotting