--- name: task-execution description: Выполняет любую нетривиальную задачу по процессу «план → ревью сеньёром → правки → выполнение → ревью результата → правки». План и результат проверяет субагент в роли senior developer; каждый цикл повторяется, пока замечаний не останется. При неясностях агент задаёт вопросы пользователю. Загружай для реализации фичи, исправления бага, рефакторинга, написания кода или документации, когда задача не сводится к одному тривиальному действию. whenToUse: Пользователь просит выполнить задачу (написать код, починить баг, отрефакторить, задокументировать, что-то исследовать и внедрить) и задача не является тривиальным одношаговым действием. Для тривиальных правок скил можно не применять. --- # Выполнение любой задачи: план → сеньёр → выполнение → сеньёр ## Контекст Любая нетривиальная задача выполняется строго по циклу: сначала **план**, затем **ревью плана сеньёром** с правками до полного одобрения, затем **выполнение** по одобренному плану, затем **ревью результата сеньёром** с правками, пока замечаний не останется. На каждом этапе, если что-то неясно, задаются вопросы пользователю. ## Роли - **Исполнитель** — ты (агент). Составляешь план, выполняешь, правишь по замечаниям. - **Сеньёр (senior developer)** — отдельный субагент, запускаемый через `subagent`. Он **не видит наш диалог**, поэтому каждый промпт ревью должен быть самодостаточным — но самодостаточность достигается за счёт внешнего файла состояния, а не дублирования всего плана в промпте (см. правило 9). - **Пользователь** — источник требований и финальный судья. Ему задаются вопросы при неясностях. ## Обязательные правила 1. **Сначала план — потом выполнение.** Не начинай выполнение, пока сеньёр не одобрил план (ответил `APPROVED`). 2. **Ревью плана и результата — только через субагента в роли senior developer** (см. шаблоны промптов ниже). Запускай его с `run_in_background: false` — следующий шаг зависит от его ответа. 3. **Замечания исправляются все, без выбора.** Нельзя отбрасывать замечание «потому что не согласен»: если не согласен — верни уточняющий вопрос сеньёру или спроси пользователя. 4. **Цикл повторяется, пока сеньёр не вернёт `APPROVED`** — и для плана, и для результата. 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` + выводы проверок, а не как пересказ плана. ## Шаги ### 1. Уточни задачу Разберись, что именно нужно сделать. Если неясны цель, объём, ограничения или критерии приёмки — задай вопросы пользователю до составления плана. ### 2. Составь план План должен содержать: - **Цель** и ожидаемый результат; - **Шаги** с конкретными файлами, командами и артефактами; - **Проверки** (сборка, тесты, линтеры, вёрстка и т.п.); - **Критерии готовности** — что считается «сделано»; - **Риски и открытые вопросы** (если есть). Заведи todo-список через `todo_write` в соответствии с планом. ### 3. Ревью плана сеньёром Сохрани план и критерии в файл состояния (например, `.dsh/task-plan.md`), прогони саморевью (правило 10), затем запусти субагента с промптом по шаблону **«Ревью плана»** (ниже). Сеньёр возвращает либо `APPROVED`, либо список замечаний. ### 4. Цикл правок плана - Есть замечания → исправь план в файле состояния (и todo-список), отправь на ревью **повторно**: в промпт добавь только дельту «что изменилось с прошлого раза» (правило 9). - Повторяй, пока не получишь `APPROVED`; после 3 раундов без `APPROVED` — спроси пользователя (см. «Ограничение итераций»). ### 5. Выполнение Выполняй строго по одобренному плану, отмечая прогресс в `todo_write`. Если в ходе выполнения стало ясно, что план нужно изменить — не отклоняйся молча: вернись к шагу 3 с обновлённым планом. ### 6. Ревью результата Сначала сам проверь результат (прогони проверки из плана, правило 10), затем отдай его сеньёру по шаблону **«Ревью результата»**: `git diff` изменённых файлов + выводы проверок. Сеньёр сверяет результат с планом (файл состояния) и критериями, проверяет корректность и соблюдение конвенций проекта. ### 7. Цикл правок результата Правь по замечаниям, повторяй ревью, пока сеньёр не вернёт `APPROVED`. При каждом повторе сообщай сеньёру только дельту — что изменилось с прошлого раза (правило 9). После 3 раундов без `APPROVED` — спроси пользователя. ### 8. Финальный отчёт Кратко сообщи пользователю: что сделано, какие файлы затронуты, как проверялось, что план и результат одобрены сеньёром. ## Шаблон: промпт «Ревью плана» План и критерии — в файле состояния (путь ниже); в промпт включай только задачу, путь к файлу, дельту с прошлого раза (если есть) и diff, если правился код. ``` Ты — senior developer. Оцени план выполнения задачи. Задача: <текст задачи> План и критерии готовности: <путь к файлу состояния, например .dsh/task-plan.md> (прочитай сам) Изменения с прошлого раза: <дельту или «первое ревью»> Проверь: полноту (нет ли пропущенных шагов), достижимость, корректность подхода, риски, соответствие конвенциям проекта, отсутствие лишних шагов. Перечисли ВСЕ замечания одним списком за один заход — включая мелочи, ниты и потенциальные будущие проблемы; не растягивай на несколько раундов. Ответь СТРОГО одним из двух вариантов: - APPROVED — если замечаний нет; - список замечаний, каждое в формате «<что не так> → <как исправить>». ``` ## Шаблон: промпт «Ревью результата» ``` Ты — senior developer. Оцени результат выполнения задачи. Задача: <текст задачи> План и критерии готовности: <путь к файлу состояния> (прочитай сам) Результат: git diff изменённых файлов + выводы проверок (build/vet/test/race) Изменения с прошлого раза: <дельту или «первое ревью»> Проверь: результат соответствует плану и критериям готовности, код/текст корректен, соблюдены конвенции проекта, нет регрессий. Перечисли ВСЕ замечания одним списком за один заход — включая мелочи, ниты и потенциальные будущие проблемы. Ответь СТРОГО одним из двух вариантов: - APPROVED — если замечаний нет; - список замечаний, каждое в формате «<что не так> → <как исправить>». ``` ## Ограничение итераций Если в одном цикле (план или результат) после **3 раундов** замечания не исчерпались — остановись и спроси пользователя: продолжать цикл или зафиксировать оставшиеся замечания как известные ограничения. ## Критерии готовности - [ ] План составлен и одобрен сеньёром (`APPROVED`) до начала выполнения. - [ ] Все замечания сеньёра по плану учтены. - [ ] Результат соответствует плану и критериям готовности. - [ ] Все замечания сеньёра по результату учтены, получен `APPROVED`. - [ ] Пользователю дан финальный отчёт.