SDLC Review

Проверять хендоффы Kanban и маршрутизировать проверенные результаты.

Метаданные навыка

Справочник: полный SKILL.md

Навык ревью SDLC

Независимо проверять работу, переданную из прогона реализации Kanban в полосу ревью, а затем одобрять её, запрашивать правки или эскалировать. Навык проверяет результат работы и доказательства к нему; он не подменяет собой работу исполнителя.

Когда использовать

Используйте навык, когда одновременно верны все условия:

• диспетчер запустил вас для задачи, забранной из полосы review;
• исполнитель оформил передачу со статусом review_requested;
• для завершения задачи нужен независимый вердикт.

Не используйте навык для отдельной нижестоящей карточки ревью. Такая карточка — обычная работа по реализации со спецификацией, ориентированной на ревью, и проходит собственный жизненный цикл.

Требования

• Контекст воркера Kanban с идентификаторами текущей задачи и прогона.
• Нативные инструменты Kanban: kanban_show, kanban_comment, kanban_complete, kanban_request_changes и kanban_block.
• Доступ к рабочему пространству через read_file, search_files и terminal, если результат работы — код.
• Исходная спецификация задачи, критерии приёмки, сводка передачи и история прежних прогонов должны быть доступны через kanban_show.

Как запускать

Навык загружается автоматически диспетчером ревью. Начинайте с kanban_show, прежде чем изучать файлы или выбирать вердикт.

1. Прочитайте спецификацию задачи и последнюю передачу review_requested.
2. Изучите сам результат работы и проведите нужную проверку.
3. Выберите ровно один вердикт: одобрить, запросить правки или эскалировать.
4. Зафиксируйте конкретные доказательства в терминальном переходе Kanban.

Краткая справка

Переход «запрошены правки» возвращает задачу исходному исполнителю. Когда тот запрашивает ревью повторно, не указав ревьюера явно, сохранённые данные о ревьюере направляют повторное ревью обратно на тот же профиль ревьюера.

Ракурсы ревью

На каждом раунде меняйте угол, под которым смотрите на работу, вместо того чтобы повторять одну и ту же проверку. Разные, не пересекающиеся ракурсы ловят разные классы дефектов: чтение артефакта «с холодной головой» вскрывает проблемы дизайна и корректности, которые нарратив исполнителя мог бы сгладить; выполнение вскрывает утверждения, которые не воспроизводятся; строгий аудит контракта вскрывает тихий дрейф скоупа. Если на третьем раунде повторить ракурс первого, вы в основном найдёте то же самое, что уже нашли в первом раунде.

Текущий раунд определяйте по истории, которую уже даёт запись задачи: посчитайте записи changes_requested в разделе «Prior attempts on this task» контекста вашего воркера (они же видны как прежние прогоны в kanban_show). Номер текущего раунда ревью — это количество таких записей плюс один. То есть в первом раунде записей changes_requested — ноль, во втором — одна, и так далее.

Базовые обязанности из раздела «Процедура» действуют на каждом раунде; ракурс лишь задаёт, с какой проверки вы начинаете и на чём делаете основной упор.

Смена ракурса для точечных параллельных ревью

Тот же принцип работает и за пределами полосы ревью Kanban. Запуская несколько параллельных ревьюеров через delegate_task, давайте каждому свой ракурс — одному бриф только с дифом, другому с полным контекстом, третьему «забери и запусти», — вместо одинаковых брифов. Одинаковые брифы дают коррелирующие вердикты и дублирующиеся находки; разные брифы при том же бюджете ревью покрывают больше классов дефектов.

Процедура

1. Сориентируйтесь по устойчивой записи задачи

Вызовите kanban_show и определите:

• исходное тело задачи и критерии приёмки;
• последнюю сводку реализации и структурированные метаданные;
• изменённые файлы, идентификаторы коммитов и доказательства тестирования;
• комментарии и решения из прежних прогонов;
• находки из прошлых раундов ревью.

Относитесь к передаче как к утверждению, которое нужно проверить, а не как к доказательству того, что работа сделана верно.

2. Сравните запрошенное поведение с фактически реализованным

Сопоставьте каждый критерий приёмки с конкретным доказательством в реализации или в результате. Прежде чем решать, нужны ли более глубокие проверки, отметьте пропуски, изменённую семантику и посторонний скоуп.

Для работы с кодом:

1. Используйте read_file и search_files, чтобы изучить изменённые пути и их вызывающий код.
2. Используйте terminal, чтобы просмотреть диф и запустить существующие в проекте точечные тесты, линт, проверку типов или сборку.
3. По возможности воспроизведите заявленный путь отказа и хотя бы один обычный контрольный путь.
4. Проверьте обработку ошибок, граничные случаи, границы конкурентности, сохранность данных, границы безопасности и кросс-платформенное поведение, релевантные изменению.
5. Убедитесь, что тесты проверяют поведение, а не просто снимают снапшот исходного текста или констант.

Для работы без кода:

1. Изучите результат работы целиком, а не только его сводку.
2. Проверьте корректность, полноту, форматирование и происхождение данных.
3. Если это влияет на вердикт, проверьте указанные URL или внешние факты подходящими нативными инструментами.

3. Выберите один вердикт

Одобрить

Одобряйте только когда критерии приёмки выполнены, а доказательств достаточно. Вызовите:

kanban_complete(
    summary="Reviewed and approved. <what was verified>",
    metadata={"review_outcome": "approved", "reviewer_checks": [...]}
)

Укажите точные проверки, которые прошли, и любую ограниченную оговорку, не блокирующую приёмку.

Запросить правки

Используйте для конкретных, исправимых дефектов. Сначала зафиксируйте применимые находки:

kanban_comment(
    task_id="<current-task-id>",
    body="Changes requested:\n1. <file or artifact + defect>\n2. <required correction>",
)

Затем верните ту же задачу исполнителю:

kanban_request_changes(
    reason="<concise summary of the required corrections>"
)

Укажите, где находится дефект, как он воспроизводится, почему он нарушает условия задачи и какой минимальный результат его закроет. Этот переход не использует учёт повторных блокировок.

Эскалировать

Эскалируйте только если ревьюер и исполнитель не могут решить проблему без решения человека или выполнения внешнего условия:

kanban_block(
    reason="escalation: <decision or prerequisite required>"
)

Опишите, какое решение заблокировано и какой минимум информации нужен, чтобы продолжить.

4. Сохраняйте разделение ролей

Не правьте реализацию, выступая ревьюером. Запросите правки и дайте исполнителю подготовить следующий вариант; затем независимо проверьте этот вариант в следующем прогоне ревью.

Подводные камни

• Штамповка: гладкая сводка передачи — не независимое доказательство.
• Ревьюер-исполнитель: если ревьюер правит результат работы сам, это размывает ответственность и ослабляет границу повторного ревью.
• Расплывчатые находки: формулировка вроде «доработать» не даёт исполнителю воспроизводимую цель для исправления.
• Блокировка из-за стиля: не запрашивайте правки из-за придирок на уровне личных предпочтений, если поведение и стандарты репозитория соблюдены.
• Пропуск прежних раундов: повторное ревью должно подтвердить и то, что запрошенные исправления внесены, и то, что ранее проходившее поведение не сломано.
• Блокировки вместо обычной доработки: исправимые дефекты — это kanban_request_changes; kanban_block оставьте для настоящих внешних блокеров или решений человека.
• Завершение без доказательств: в сводке одобрения обязательно должны быть названы проверки и артефакты, которые реально изучались.

Проверка

Перед тем как вынести вердикт, убедитесь:

• kanban_show прочитан для текущей задачи и прогона.
• Каждый критерий приёмки сопоставлен с доказательством.
• Изучен сам результат работы.
• Проведены нужные точечные проверки, либо, если выполнить их было нельзя, зафиксирована явная причина.
• При повторном ревью перепроверены ранее запрошенные правки.
• Учтены посторонние регрессии и изменения скоупа.
• Вердикт использует ровно одно терминальное действие.
• Сводка содержит конкретные доказательства без секретов.
• Ревьюер не редактировал файлы реализации.