generated from VLADIMIR/template
add rules
This commit is contained in:
@@ -13,7 +13,7 @@ whenToUse: Пользователь просит выполнить задачу
|
||||
## Роли
|
||||
|
||||
- **Исполнитель** — ты (агент). Составляешь план, выполняешь, правишь по замечаниям.
|
||||
- **Сеньёр (senior developer)** — отдельный субагент, запускаемый через `subagent`. Он **не видит наш диалог**, поэтому каждый промпт ревью должен быть самодостаточным: включай в него всю необходимую информацию (задачу, план, критерии, предыдущие замечания).
|
||||
- **Сеньёр (senior developer)** — отдельный субагент, запускаемый через `subagent`. Он **не видит наш диалог**, поэтому каждый промпт ревью должен быть самодостаточным — но самодостаточность достигается за счёт внешнего файла состояния, а не дублирования всего плана в промпте (см. правило 9).
|
||||
- **Пользователь** — источник требований и финальный судья. Ему задаются вопросы при неясностях.
|
||||
|
||||
## Обязательные правила
|
||||
@@ -25,6 +25,9 @@ whenToUse: Пользователь просит выполнить задачу
|
||||
5. **Неясно — спроси.** На любом этапе (задача, шаг плана, замечание сеньёра) при неоднозначности задай вопрос пользователю через `ask_user_question`. Догадки вместо вопросов — ошибка.
|
||||
6. **Отслеживай прогресс** через `todo_write`: план из шага 2 переносится в todo-список, пункты отмечаются по мере выполнения.
|
||||
7. **Профильные скилы** (например `create-go-module`) — источник правил «как делать» для конкретной задачи. Этот скил управляет процессом «как вести задачу»; оба применяются вместе.
|
||||
8. **Бюджет раундов ревью — 3 на цикл** (план и результат отдельно). В шаблонах промптов требуй от сеньёра перечислить **все замечания одним списком за один заход** — включая мелочи, ниты и потенциальные будущие проблемы. После 3 раундов без `APPROVED` остановись и спроси пользователя: продолжать цикл или зафиксировать оставшиеся замечания как известные ограничения (не растягивай полировку на десятки раундов).
|
||||
9. **Дифф-ревью и внешнее состояние.** План, чек-лист и учёт замечаний держи во внешнем файле состояния (например, `.dsh/task-plan.md`). Промпт ревью содержит: задачу, путь к файлу состояния, **короткую дельту** «что изменилось с прошлого раза» и `git diff` изменённых файлов. Не пересказывай ревьюеру весь план и всю историю замечаний — файл состояния он прочитает сам (это его контекст, а не наш).
|
||||
10. **Саморевью до отправки.** Перед первым и каждым повторным ревью прогоняй фактические проверки, которые сеньёр всё равно сделает: поведение функций на реальных данных (например, `Transliterate("photo.png")`, `http.DetectContentType`, `filepath.Ext("x.PNG?v=2")`), чтение сгенерированного кода (pb.gw.go и пр.), арифметику лимитов. «Ревью результата» отправляй как `git diff` + выводы проверок, а не как пересказ плана.
|
||||
|
||||
## Шаги
|
||||
|
||||
@@ -46,12 +49,12 @@ whenToUse: Пользователь просит выполнить задачу
|
||||
|
||||
### 3. Ревью плана сеньёром
|
||||
|
||||
Запусти субагента с промптом по шаблону **«Ревью плана»** (ниже). Сеньёр возвращает либо `APPROVED`, либо список замечаний.
|
||||
Сохрани план и критерии в файл состояния (например, `.dsh/task-plan.md`), прогони саморевью (правило 10), затем запусти субагента с промптом по шаблону **«Ревью плана»** (ниже). Сеньёр возвращает либо `APPROVED`, либо список замечаний.
|
||||
|
||||
### 4. Цикл правок плана
|
||||
|
||||
- Есть замечания → исправь план (и todo-список), отправь на ревью **повторно**: в промпт добавь предыдущие замечания и что именно изменилось.
|
||||
- Повторяй, пока не получишь `APPROVED`.
|
||||
- Есть замечания → исправь план в файле состояния (и todo-список), отправь на ревью **повторно**: в промпт добавь только дельту «что изменилось с прошлого раза» (правило 9).
|
||||
- Повторяй, пока не получишь `APPROVED`; после 3 раундов без `APPROVED` — спроси пользователя (см. «Ограничение итераций»).
|
||||
|
||||
### 5. Выполнение
|
||||
|
||||
@@ -59,11 +62,11 @@ whenToUse: Пользователь просит выполнить задачу
|
||||
|
||||
### 6. Ревью результата
|
||||
|
||||
Сначала сам проверь результат (прогони проверки из плана), затем отдай его сеньёру по шаблону **«Ревью результата»**. Сеньёр сверяет результат с планом и критериями, проверяет корректность и соблюдение конвенций проекта.
|
||||
Сначала сам проверь результат (прогони проверки из плана, правило 10), затем отдай его сеньёру по шаблону **«Ревью результата»**: `git diff` изменённых файлов + выводы проверок. Сеньёр сверяет результат с планом (файл состояния) и критериями, проверяет корректность и соблюдение конвенций проекта.
|
||||
|
||||
### 7. Цикл правок результата
|
||||
|
||||
Правь по замечаниям, повторяй ревью, пока сеньёр не вернёт `APPROVED`. При каждом повторе сообщай сеньёру, что изменилось с прошлого раза.
|
||||
Правь по замечаниям, повторяй ревью, пока сеньёр не вернёт `APPROVED`. При каждом повторе сообщай сеньёру только дельту — что изменилось с прошлого раза (правило 9). После 3 раундов без `APPROVED` — спроси пользователя.
|
||||
|
||||
### 8. Финальный отчёт
|
||||
|
||||
@@ -71,15 +74,19 @@ whenToUse: Пользователь просит выполнить задачу
|
||||
|
||||
## Шаблон: промпт «Ревью плана»
|
||||
|
||||
План и критерии — в файле состояния (путь ниже); в промпт включай только задачу, путь к файлу, дельту с прошлого раза (если есть) и diff, если правился код.
|
||||
|
||||
```
|
||||
Ты — senior developer. Оцени план выполнения задачи.
|
||||
|
||||
Задача: <текст задачи>
|
||||
План: <план>
|
||||
Критерии готовности: <критерии>
|
||||
План и критерии готовности: <путь к файлу состояния, например .dsh/task-plan.md> (прочитай сам)
|
||||
Изменения с прошлого раза: <дельту или «первое ревью»>
|
||||
|
||||
Проверь: полноту (нет ли пропущенных шагов), достижимость, корректность
|
||||
подхода, риски, соответствие конвенциям проекта, отсутствие лишних шагов.
|
||||
Перечисли ВСЕ замечания одним списком за один заход — включая мелочи,
|
||||
ниты и потенциальные будущие проблемы; не растягивай на несколько раундов.
|
||||
Ответь СТРОГО одним из двух вариантов:
|
||||
- APPROVED — если замечаний нет;
|
||||
- список замечаний, каждое в формате «<что не так> → <как исправить>».
|
||||
@@ -91,12 +98,14 @@ whenToUse: Пользователь просит выполнить задачу
|
||||
Ты — senior developer. Оцени результат выполнения задачи.
|
||||
|
||||
Задача: <текст задачи>
|
||||
План: <план>
|
||||
Критерии готовности: <критерии>
|
||||
Результат: <что сделано: файлы, изменения, выводы проверок>
|
||||
План и критерии готовности: <путь к файлу состояния> (прочитай сам)
|
||||
Результат: git diff изменённых файлов + выводы проверок (build/vet/test/race)
|
||||
Изменения с прошлого раза: <дельту или «первое ревью»>
|
||||
|
||||
Проверь: результат соответствует плану и критериям готовности, код/текст
|
||||
корректен, соблюдены конвенции проекта, нет регрессий.
|
||||
Перечисли ВСЕ замечания одним списком за один заход — включая мелочи,
|
||||
ниты и потенциальные будущие проблемы.
|
||||
Ответь СТРОГО одним из двух вариантов:
|
||||
- APPROVED — если замечаний нет;
|
||||
- список замечаний, каждое в формате «<что не так> → <как исправить>».
|
||||
@@ -104,7 +113,7 @@ whenToUse: Пользователь просит выполнить задачу
|
||||
|
||||
## Ограничение итераций
|
||||
|
||||
Если в одном цикле (план или результат) после **5 раундов** замечания не исчерпались — остановись и спроси пользователя: продолжать цикл или зафиксировать оставшиеся замечания как известные ограничения.
|
||||
Если в одном цикле (план или результат) после **3 раундов** замечания не исчерпались — остановись и спроси пользователя: продолжать цикл или зафиксировать оставшиеся замечания как известные ограничения.
|
||||
|
||||
## Критерии готовности
|
||||
|
||||
|
||||
Reference in New Issue
Block a user