evening_detective_frontend/.dsh/skills/task-execution/SKILL.md

name, description, whenToUse

name	description	whenToUse
task-execution	Выполняет любую нетривиальную задачу по процессу «план → ревью сеньёром → правки → выполнение → ревью результата → правки» в проекте «Вечерний детектив» (Vue 3.5 + Vite + Pinia + Naive UI). План и результат проверяет субагент в роли senior developer; цикл повторяется, пока не устранены блокирующие замечания. Ниты и уточнения формулировок не блокируют одобрение — фиксируются и могут остаться неисправленными. При неясностях агент задаёт вопросы пользователю. Загружай для реализации фичи, исправления бага, рефакторинга, написания кода или документации, когда задача не сводится к одному тривиальному действию.	Пользователь просит выполнить задачу в проекте «Вечерний детектив» (написать код, починить баг, отрефакторить, задокументировать, что-то исследовать и внедрить) и задача не является тривиальным одношаговым действием. Для тривиальных правок скил можно не применять.

Выполнение любой задачи: план → сеньёр → правки → выполнение → сеньёр → правки

Контекст

Адаптация скила task-execution под проект «Вечерний детектив» (фронтенд). Любая нетривиальная задача выполняется строго по циклу: сначала план, затем ревью плана сеньёром с правками до одобрения, затем выполнение по одобренному плану, затем ревью результата сеньёром с правками, пока не устранены блокирующие замечания. Замечания делятся на блокирующие (исправляются обязательно) и ниты (фиксируются, но не блокируют одобрение и могут остаться неисправленными). На каждом этапе, если что-то неясно, задаются вопросы пользователю.

Проектные конвенции — в AGENTS.md репозитория (структура src/, стиль кода и импортов, дизайн-канон «бумажного детектива», палитра, правила по API-клиентам и сгенерированному коду). Сеньёр и исполнитель сверяются с ним на каждом цикле.

Классификация замечаний

• Блокирующее ([BLOCKER]) — влияет на функциональность, корректность, безопасность, целостность данных, совместимость, достижимость шага плана, ломает сборку/тесты, нарушает конвенции проекта (структура, импорты, палитра и стилистика из AGENTS.md), создаёт регрессию. Такие замечания исправляются все, без исключения.
• Нит ([NIT]) — уточнение формулировки, стиль, типографика, «на будущее», рекомендация без реального риска, альтернатива, которая не меняет поведение. Ниты фиксируются (в файле состояния или todo/), но НЕ обязательны к исправлению и не блокируют APPROVED.
• Метку ставит сеньёр в каждом замечании. Если метка отсутствует или неоднозначна — трактуй замечание как блокирующее (осторожность в пользу качества); при сомнении можно спросить пользователя.

Роли

• Исполнитель — ты (агент). Составляешь план, выполняешь, правишь по блокирующим замечаниям, фиксируешь ниты.
• Сеньёр (senior developer) — отдельный субагент, запускаемый через subagent один раз на задачу и переиспользуемый между раундами через send_message (он помнит свои предыдущие замечания и дельты — не противоречит себе и не перечитывает весь файл состояния каждый раунд). Он не видит наш диалог, поэтому каждый промпт ревью должен быть самодостаточным — но самодостаточность достигается за счёт внешнего файла состояния, а не дублирования всего плана в промпте (см. правило 9). Новый сеньёр создаётся только при смене задачи или переполнении контекста субагента (тогда — со сводкой уже принятых решений).
• Пользователь — источник требований и финальный судья. Ему задаются вопросы при неясностях.

Обязательные правила

1. Сначала план — потом выполнение. Не начинай выполнение, пока сеньёр не одобрил план (ответил APPROVED).
2. Ревью плана и результата — только через субагента в роли senior developer (см. шаблоны промптов ниже). Создай сеньёра один раз (первый раунд — subagent с run_in_background: true), далее каждый раунд — send_message тому же субагенту с дельтой. Ответ субагента приходит уведомлением (не синхронно): пока он работает, продолжай независимые шаги, по уведомлению забирай результат.
3. Блокирующие замечания исправляются все, без выбора. Нельзя отбрасывать [BLOCKER] «потому что не согласен»: если не согласен — верни уточняющий вопрос сеньёру или спроси пользователя. Ниты ([NIT]) исправлять не обязательно: зафиксируй их в файле состояния или todo/ и продолжай.
4. Цикл повторяется, пока сеньёр не вернёт APPROVED — и для плана, и для результата. APPROVED достижим при наличии только нитов (сеньёр может вернуть APPROVED (ниты: ...)); блокирует цикл только наличие [BLOCKER].
5. Неясно — спроси. На любом этапе (задача, шаг плана, замечание сеньёра) при неоднозначности задай вопрос пользователю через ask_user_question. Догадки вместо вопросов — ошибка.
6. Отслеживай прогресс через todo_write: план из шага 2 переносится в todo-список, пункты отмечаются по мере выполнения.
7. Профильные скилы (например frontend-dev — база знаний фронтенд-разработчика) — источник правил «как делать» для конкретной задачи. Этот скил управляет процессом «как вести задачу»; оба применяются вместе.
8. Бюджет раундов ревью — 3 на цикл (план и результат отдельно). В шаблонах промптов требуй от сеньёра перечислить все замечания одним списком за один заход с метками [BLOCKER]/[NIT]. После 3 раундов с неисправленными [BLOCKER] остановись и спроси пользователя: продолжать цикл или зафиксировать оставшиеся блокеры как известные ограничения (не растягивай полировку на десятки раундов).
9. Дифф-ревью и внешнее состояние. План, чек-лист и учёт замечаний держи во внешнем файле состояния (например, .dsh/task-plan.md). Промпт ревью содержит: задачу, путь к файлу состояния, короткую дельту «что изменилось с прошлого раза» и git diff изменённых файлов. Не пересказывай ревьюеру весь план и всю историю замечаний — файл состояния он прочитает сам (это его контекст, а не наш).
10. Саморевью до отправки. Перед первым и каждым повторным ревью прогоняй фактические проверки, которые сеньёр всё равно сделает: поведение функций на реальных данных (например, res.error у API-клиентов, computed-значения, типизацию defineProps с PropType<T>), чтение сгенерированного кода (src/api/generated/**), соответствие палитре и стилистике из AGENTS.md, арифметику лимитов. «Ревью результата» отправляй как git diff + выводы проверок, а не как пересказ плана.

Шаги

1. Уточни задачу

Разберись, что именно нужно сделать. Если неясны цель, объём, ограничения или критерии приёмки — задай вопросы пользователю до составления плана.

2. Составь план

План должен содержать:

• Цель и ожидаемый результат;
• Шаги с конкретными файлами, командами и артефактами;
• Проверки — обязательный минимум проекта: npm run type-check → npm run lint → npm run lint:css; при затрагивании сборки/конфигов — npm run build. Для проверки в браузере — dev-сервер (npm run dev) в фоне;
• Критерии готовности — что считается «сделано» (в т.ч. чек-лист раздела 5 AGENTS.md);
• Риски и открытые вопросы (если есть).

Заведи todo-список через todo_write в соответствии с планом.

3. Ревью плана сеньёром

Сохрани план и критерии в файл состояния (например, .dsh/task-plan.md), прогони саморевью (правило 10), затем создай сеньёра (subagent, первый раунд) с промптом по шаблону «Ревью плана» (ниже). Ответ сеньёра приходит уведомлением (правило 2) — по уведомлению забирай результат: либо APPROVED, либо список замечаний с метками.

4. Цикл правок плана

• Есть блокирующие замечания → исправь их в файле состояния (и todo-список), отправь на ревью повторно ТОМУ ЖЕ сеньёру через send_message: в промпт добавь только дельту «что изменилось с прошлого раза» (правило 9).
• Ниты → зафиксируй в файле состояния (раздел «Ниты / известные ограничения») или todo/, не обязательно исправляй.
• Повторяй, пока не получишь APPROVED; после 3 раундов с неисправленными [BLOCKER] — спроси пользователя (см. «Ограничение итераций»).

5. Выполнение

Выполняй строго по одобренному плану, отмечая прогресс в todo_write. Соблюдай конвенции проекта из AGENTS.md (структура src/, импорты, палитра и стилистика, API только через сгенерированные клиенты, UI-контролы — только naive-ui). Если в ходе выполнения стало ясно, что план нужно изменить — не отклоняйся молча: вернись к шагу 3 с обновлённым планом.

6. Ревью результата

Сначала сам проверь результат (прогони проверки из плана: npm run type-check → npm run lint → npm run lint:css → при необходимости npm run build, правило 10), затем отдай его сеньёру по шаблону «Ревью результата» через send_message (тот же субагент): git diff изменённых файлов + выводы проверок. Сеньёр сверяет результат с планом (файл состояния) и критериями, проверяет корректность и соблюдение конвенций проекта (включая дизайн-канон из AGENTS.md).

7. Цикл правок результата

Исправляй блокирующие замечания, повторяй ревью тому же сеньёру через send_message, пока не вернёт APPROVED. Ниты — фиксируй в todo/ или файле состояния, не обязательно исправляй. При каждом повторе сообщай сеньёру только дельту — что изменилось с прошлого раза (правило 9). После 3 раундов с неисправленными [BLOCKER] — спроси пользователя.

8. Финальный отчёт

Кратко сообщи пользователю: что сделано, какие файлы затронуты, как проверялось (какие из npm run type-check / npm run lint / npm run lint:css / npm run build прошли), что план и результат одобрены сеньёром.

Шаблон: промпт «Ревью плана»

План и критерии — в файле состояния (путь ниже); в промпт включай только задачу, путь к файлу, дельту с прошлого раза (если есть) и diff, если правился код.

Ты — senior developer. Оцени план выполнения задачи.

Задача: <текст задачи>
План и критерии готовности: <путь к файлу состояния, например .dsh/task-plan.md> (прочитай сам)
Изменения с прошлого раза: <дельту или «первое ревью»>

Проверь: полноту (нет ли пропущенных шагов), достижимость, корректность
подхода, риски, соответствие конвенциям проекта (AGENTS.md: структура src/,
импорты, палитра и стилистика, API-клиенты), наличие обязательных проверок
(npm run type-check / lint / lint:css / build), отсутствие лишних шагов.

Классифицируй каждое замечание:
- [BLOCKER] — влияет на функциональность, корректность, безопасность,
  целостность данных, достижимость шага, ломает сборку/тесты, нарушает
  конвенции проекта, создаёт регрессию. Такие обязательны к исправлению.
- [NIT] — уточнение формулировки, стиль, типографика, «на будущее»,
  рекомендация без реального риска. Ниты не блокируют APPROVED.

Перечисли ВСЕ замечания одним списком за один заход — включая мелочи и
ниты; не растягивай на несколько раундов.
Ответь СТРОГО одним из двух вариантов:
- APPROVED (можно с пометкой «ниты: ...») — если блокирующих замечаний нет;
- список замечаний, каждое в формате «[BLOCKER]|[NIT] <что не так> → <как исправить>».

Шаблон: промпт «Ревью результата»

Ты — senior developer. Оцени результат выполнения задачи.

Задача: <текст задачи>
План и критерии готовности: <путь к файлу состояния> (прочитай сам)
Результат: git diff изменённых файлов + выводы проверок (npm run type-check /
npm run lint / npm run lint:css / npm run build, при необходимости — dev-сервер)
Изменения с прошлого раза: <дельту или «первое ревью»>

Проверь: результат соответствует плану и критериям готовности, код/текст
корректен, соблюдены конвенции проекта (AGENTS.md: структура, импорты,
палитра и стилистика «бумажного детектива», API только через сгенерированные
клиенты), нет регрессий.

Классифицируй каждое замечание:
- [BLOCKER] — влияет на функциональность, корректность, безопасность,
  целостность данных, ломает сборку/тесты, нарушает конвенции, регрессия.
  Такие обязательны к исправлению.
- [NIT] — уточнение формулировки, стиль, типографика, «на будущее»,
  рекомендация без реального риска. Ниты не блокируют APPROVED.

Перечисли ВСЕ замечания одним списком за один заход — включая мелочи и ниты.
Ответь СТРОГО одним из двух вариантов:
- APPROVED (можно с пометкой «ниты: ...») — если блокирующих замечаний нет;
- список замечаний, каждое в формате «[BLOCKER]|[NIT] <что не так> → <как исправить>».

Ограничение итераций

Если в одном цикле (план или результат) после 3 раундов остаются неисправленные [BLOCKER] — остановись и спроси пользователя: продолжать цикл или зафиксировать оставшиеся блокеры как известные ограничения. Ниты не считаются причиной продолжения цикла: при одних нитах сеньёр возвращает APPROVED (ниты: ...), а исполнитель фиксирует их в файле состояния или todo/.

Критерии готовности

• План составлен и одобрен сеньёром (APPROVED) до начала выполнения.
• Все блокирующие замечания сеньёра по плану устранены; ниты зафиксированы (в плане/todo/) и не блокируют одобрение.
• Результат соответствует плану и критериям готовности, соблюдены конвенции AGENTS.md.
• Все блокирующие замечания сеньёра по результату устранены, получен APPROVED; ниты зафиксированы.
• Пройдены проверки проекта: npm run type-check, npm run lint, npm run lint:css (и npm run build при затрагивании сборки); сгенерированный код (src/api/generated/**) не тронут; git commit/git push не выполнялись.
• Пользователю дан финальный отчёт.