AB safe-refactor
Выполните рефакторинг с сохранением поведения и доказательством сохранения — сначала создайте сеть безопасности (существующие тесты или новые описательные тесты для каждого затронутого пути), зафиксируйте базовый зеленый прогон, затем перемещайтесь небольшими всегда зелеными шагами, где каждый шаг — это одна механическая трансформация, и рассматривайте любое необходимое изменение утверждения как скрытое изменение поведения, которое нужно выявить, а не исправить. Используйте этот навык всякий раз, когда пользователь говорит «сделать рефакторинг», «привести в порядок без изменения поведения», «извлечь это в», «реструктурировать этот модуль», «переименовать это по всей кодовой базе», «встроить это», «разделить эту функцию/класс» или «/safe-refactor» — даже если они явно не говорят «навык рефакторинга». Не используйте для выбора ЧТО рефакторить (используйте improve-codebase-architecture) или для изменений, которые должны изменить поведение (используйте task-executor).
машинный переводПоказать оригиналСкрыть оригинал«Execute a behavior-preserving refactor with a proof of preservation —…»
Execute a behavior-preserving refactor with a proof of preservation — establishes a safety net first (existing tests or new characterization tests over every touched path), locks a baseline green run, then moves in small always-green steps where each step is one mechanical transformation, and treats any needed assertion change as a smuggled behavior change to surface, not fix. Use this skill whenever the user says "refactor this", "clean this up without changing behavior", "extract this into", "restructure this module", "rename this across the codebase", "inline this", "split this function/class", or "/safe-refactor" — even if they don't explicitly say "refactoring skill". Do not use for choosing WHAT to refactor (use improve-codebase-architecture) or for changes that are supposed to alter behavior (use task-executor).
Выполните рефакторинг с сохранением поведения и доказательством сохранения — сначала создайте сеть безопасности (существующие тесты или новые описательные…
Как процесс B 65/100 · Почти готов — слабые места: результат и критерий готовности, входы и предусловия, повторный запуск
Как улучшить
- Свои кейсы (evals/evals.json, 4–6 реальных запросов с ожидаемыми ответами): тогда полная проверка прогонит именно их, а не черновик от модели.
- spec.yaml с триггерными фразами и утверждениями — контракт поведения для CI; `skilltest init` создаст шаблон.
Находки guard · 0
✓ Критических и высоких находок нет
Просканировано файлов: 2. Улики замаскированы. Пометки в серых чипах объясняют, почему серьёзность понижена.
По спецификации Agent Skills
✓ По спецификации Agent Skills замечаний нет
Процессный рейтинг: все десять параметров 65/100
- 0Результат и критерий готовности. Не сказано, что считать результатом
- 0Входы и предусловия. Не сказано, что нужно иметь на входе
- 30Повторный запуск. Изменяющих операций: 10, без проверки текущего состояния
- 60Инструменты и файлы. Используются инструменты (web), но во frontmatter они не объявлены
- 100Шаги. Шагов: 26
- 100Когда включается. Сказано, когда применять и когда не применять
- 100Ошибки и развилки. Развилок: 1, есть раздел про ошибки
- 100Согласованность. Имя и обязательные поля на месте
- 100Стоимость исполнения. Тело инструкции 2030 токенов
- 100Отчётность по ходу. Скилл сообщает о ходе работы
Всё перечисленное измерено по тексту скилла, а не оценено моделью: цифры проверяемы. Вес параметра тем больше, чем чаще из-за него процесс встаёт.
Сигналы качества
- +3Длина description 830: рекомендуется 120–800 символов
- +3Формат ответа не описан: модель каждый раз решает сама
- -212 эмодзи в инструкциях: шум для модели
- +1Лицензия не указана
- +2Инструкции на одном языке
- +5В description 9 примера фраз-триггеров в кавычках
- +4Описание говорит, когда скилл НЕ применять
- +4Структура: 8 заголовков
- +3Пошаговые инструкции: 26 пунктов
- +4Есть примеры (0 блоков кода)
База качества 70; замечания lint вычитаются, сигналы прибавляют до 100. Итог: 88.