dev-verify: Скилл проверки и анализа задач

--- name: dev-verify description: Этот навык следует использовать, когда пользователь запрашивает "dev-verify", "実装の検証" (проверка реализации), "完了チェック" (проверка завершения), "verify implementation" (проверка реализации), "全テスト実行" (запуск всех тестов), "run all tests" (запуск всех тестов), "dev-verify auth" (dev-verify аутентификация). Он проверяет состояние завершения всех задач в рамках плана, а также согласованность тестов, сборки и линтинга, и выводит отчет. argument-hint: '<plan-name>' --- # Dev Verify Проверяет состояние завершения всех задач в рамках плана, выполняет полный набор тестов, сборку, линтинг и проверку размера файлов, и выводит отчет в `docs/dev/plans/<plan-name>/reports/`. ## Предпосылки ### Положение в цепочке навыков `dev-*` ``` dev-context → dev-plan → dev-impl → [dev-verify] ↘ dev-debug ``` ### Формат аргументов ``` /dev-verify <plan-name> ``` ## Рабочий процесс ### Шаг 1: Проверка завершения задач Считывает все файлы задач из `docs/dev/plans/<plan-name>/tasks/` и проверяет значение `status` в метаданных. - Если все задачи имеют статус `done` → переходит к Шагу 2. - Если есть задачи со статусом `pending` / `in_progress` → сообщает пользователю список незавершенных задач и запрашивает подтверждение продолжения (AskUserQuestion). ### Шаг 2: Запуск всех тестов Получает команду для запуска тестов из `docs/dev/context.md` и выполняет все тесты. ```bash # Получить команду из раздела Test Framework файла context.md <test-command> ``` Записывает результаты тестов: количество пройденных, не пройденных и пропущенных тестов. ### Шаг 3: Проверка покрытия кода Получает команду для проверки покрытия и пороговое значение из раздела Test Framework файла `docs/dev/context.md` и измеряет общее покрытие проекта. 1. Измеряет общее покрытие проекта с помощью команды Coverage Command. 2. Извлекает процент покрытия для каждого пакета и сравнивает его с пороговым значением. 3. Обрабатывает `[no test files]` как 0%. 4. Записывает пакеты, не достигшие порогового значения, в раздел Issues Found. ### Шаг 4: Проверка сборки Если есть языки программирования или этапы сборки, выполняет команду сборки (полученную из context.md). Пропускает этот шаг, если используется интерпретируемый язык без этапов сборки. ### Шаг 5: Запуск линтинга Если в файле context.md указана команда линтинга, выполняет ее. В противном случае пропускает этот шаг. ### Шаг 6: Проверка размера файлов (правило в 500 строк) Проверяет количество строк в файлах, измененных или созданных в рамках плана (полученных из раздела Files каждого файла задачи): ```bash wc -l "$(git rev-parse --show-toplevel)/<относительный путь к файлу>" ``` Если файл содержит более 500 строк, записывает предупреждение. ### Шаг 7: Сводка по статусу Агрегирует отчеты об уверенности для всех задач в плане: - 🟡 Список элементов с обоснованными предположениями (рекомендуется проверка пользователем). - 🔴 Список элементов, для которых требуется дополнение логики ИИ (требуется проверка человеком). Явно предупреждает, если есть элементы с меткой 🔴. ### Шаг 8: Вывод отчета Выводит результаты проверки в файл `docs/dev/plans/<plan-name>/reports/verify-YYYY-MM-DD.md`. ```markdown # Отчет о проверке - YYYY-MM-DD ## План: <plan-name> ## Сводка | Элемент | Результат | |------|--------| | Задачи | X/Y завершено | | Тесты | Z пройдено, W не пройдено, V пропущено | | Покрытие | X/Y пакетов выше порога (порог: 80%) | | Сборка | OK / NG / N/A | | Линтинг | OK / NG / N/A | | Правило в 500 строк | OK / X файлов превышают лимит | ## Статус задач | ID | Название | Статус | |----|-------|--------| | 001 | ... | done | | 002 | ... | done | ## Результаты тестов [Сводка результатов выполнения тестов] [Если есть не пройденные тесты, подробности] ## Результаты покрытия | Пакет | Покрытие | Порог | Результат | |-----------|----------|------|------| | internal/handler | XX.X% | 80% | OK / NG | [Подробности пакетов, не достигших порога (если есть)] ## Проверка размера файлов [Список файлов, превышающих лимит в 500 строк (если есть)] ## Сводка по уверенности ### 🟡 Обоснованные предположения (требуется проверка) - [Файл](путь) — [Что нужно проверить] ### 🔴 Дополнение логики ИИ (требуется проверка человеком) - [Файл](путь) — [Причина, по которой требуется решение] ## Обнаруженные проблемы [Подробности обнаруженных проблем] ## Рекомендации [Предложения по следующим действиям в случае проблем] - Тесты не пройдены → рекомендуется использовать `/dev-debug`. - Файл превышает лимит в 500 строк → рекомендуется рефакторинг с помощью `/dev-impl`. - Остались элементы с меткой 🔴 → рекомендуется ручная проверка соответствующих файлов. ``` ### Шаг 9: Очистка Docker Проверяет наличие файлов `docker-compose.yml` или `docker-compose.yaml` в корне проекта. Если они существуют: 1. Выполняет команду `docker compose down` для остановки контейнеров. 2. Сообщает пользователю, если остановка не удалась (без блокировки процесса). ## Правила и ограничения - Если файл context.md не существует, сообщает об этом и выполняет проверку в максимально возможной степени. - Отчет выводится даже в случае неудачных тестов (без прерывания процесса). - Если файл отчета уже существует, он перезаписывается только если дата отличается. - Запуск тестов выполняется непосредственно в Bash, а не в дочернем агенте (для получения полного вывода в отчет). - Если для какого-либо пакета не достигнуто пороговое значение покрытия, устанавливается флаг VERIFY_ISSUES_FOUND. - Если команды линтинга/сборки отсутствуют в файле context.md, этот шаг пропускается и в отчете указывается N/A. - Команды Bash должны использовать **абсолютные пути** в корне проекта (получаемые с помощью `$(git rev-parse --show-toplevel)`).