Implementation Skill Compliance Review

Проверка соответствия implementation-скилам

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

Перед созданием отчёта полностью прочитать report-template.md и использовать заданные там структуру, значения полей и правила обновления.

Рабочий процесс

1. Прочитать действующие инструкции репозитория.
2. Определить режим и область проверки:
   • явно названные файлы, компонент, слой или операция означают ограниченную проверку;
   • просьба проверить изменения означает проверку diff относительно явно указанной базы, а без неё — незакоммиченных изменений;
   • просьба проверить сервис или проект целиком означает полную проверку.
3. Не угадывать базовую ветку. Запросить её, только если без неё нельзя определить явно запрошенный diff ветки.
4. Читать непосредственные зависимости для понимания, не включая их автоматически в проверенную область.
5. Динамически обнаружить применимые implementation-скилы по актуальному каталогу навыков среды. Если каталог недоступен, искать frontmatter name и description в указанных пользователем каталогах навыков и отметить ограничение обнаружения.
6. Сначала отбирать кандидатов по metadata: назначению, языку, технологии, путям, слою и концепциям. Не поддерживать закрытый перечень имён скилов.
7. Исключать documentation-, creator-, installer-, meta- и review-скилы, а также скилы отсутствующих в области технологий. Суффикс имени использовать только как сигнал, но не как условие.
8. Полностью прочитать SKILL.md каждого кандидата. Читать связанные references, которые сам скил назначает для проверяемой части реализации. После чтения подтвердить применимость или исключить кандидата.
9. Перед содержательным анализом и командами вывести в чат стартовую сводку: режим, область и её основание, выбранные скилы, планируемые проверки, исключения и путь .review/skill-compliance.md. После однозначной сводки не ждать подтверждения.
10. Если область нужно расширить, сначала сообщить отдельную обновлённую сводку.
11. Проверить обязательные требования и явно сформулированные рекомендации. Учитывать предусловия и допустимые варианты правила. Не превращать личное предпочтение в рекомендацию скила.
12. Найти заданные репозиторием lint, type-check и test-команды. Сначала выполнить узкие безопасные проверки; при полном аудите выполнить полный обязательный набор, если он доступен и не требует нового разрешения.
13. Не запускать автоисправление, обновление snapshots/golden-файлов, установку зависимостей, внешнюю инфраструктуру или сетевые сервисы без разрешения.
14. Создавать замечание только при достаточном доказательстве применимости правила и нарушения. Подозрения и недоступные проверки записывать в ограничения.
15. Если два применимых скила конфликтуют, создавать одно замечание со статусом Требует согласования; самостоятельно не выбирать правило.
16. Обновить отчёт по правилам шаблона. При ограниченной проверке не изменять замечания вне области.
17. Проверить корневой .gitignore. Если отдельной строки .review/ нет, предложить пользователю добавить её. Не изменять .gitignore без согласия и не использовать .git/info/exclude вместо проектного правила.
18. Проверить git status и убедиться, что отчёт не добавлен в index.
19. Завершить краткой сводкой: новые и обновлённые замечания, количества по статусам и приоритетам, высокоприоритетные замечания, вопросы согласования, выполненные проверки, ограничения и ссылка на отчёт. Не начинать исправления.

Классификация правил

• Отмечать обязательное правило как Требование.
• Отмечать явно необязательный предпочтительный подход как Рекомендация.
• Создавать замечания о нарушенных рекомендациях с приоритетом Низкий.
• Для требования определять приоритет по практическому влиянию, а не по сложности исправления или уверенности аудитора.
• Не создавать замечание, если допустимое отклонение от рекомендации обосновано в проекте.
• Если источник правила найден, но его обязательность нельзя определить однозначно, создавать замечание со статусом Требует согласования и конкретным вопросом о типе правила.

Доказательства и автоматические проверки

• Указывать точное правило, раздел или пункт и место реализации.
• Описывать наблюдаемое поведение, ожидаемое состояние и практическое последствие.
• Объединять несколько мест только при одной первопричине.
• Считать падение команды замечанием, только если оно доказывает проверяемое нарушение; иначе переносить результат в ограничения.
• Продолжать остальные безопасные проверки после независимого отказа команды.
• Не считать частичный вывод успешным завершением команды.

Границы изменений

Разрешено изменять .review/skill-compliance.md и создавать каталог .review/ для него. Строку .review/ разрешено добавлять в корневой .gitignore только после согласия пользователя. Не исправлять обнаруженные проблемы даже при очевидном решении и не менять .git/info/exclude.