К основному содержанию
скилл CX Codex

regression-proof — скилл для Claude Code

Скилл ведёт агента через починку бага: сначала тест, который падает на старом поведении, потом фикс, потом тот же тест проходит.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add Neeeophytee/finding-unknowns-skills --skill regression-proof -a claude-code
Открыть на GitHub

Что делает regression-proof

Скилл задаёт порядок работы с сообщённым багом. Сначала агент фиксирует исходное состояние, включая незакоммиченные правки, и воспроизводит сбой на базовой ветке — если получится, отделяя поломку продукта от сломанного окружения тестов.

Дальше добавляется минимальный регрессионный тест, который проходит по реальному падающему пути. Его прогоняют на старом коде и проверяют, что он падает именно по заявленной причине, а не из-за ошибки импорта или отсутствующей зависимости. Потом идёт поиск причины и правка в границах задачи. Тест прогоняется снова на исправленном коде; если фикс существовал раньше теста, сравнение делается в изолированной копии или worktree, а рабочее дерево пользователя не сбрасывается.

В конце проверяется соседнее поведение, которое могло пострадать, и добавляется различающий случай, если неполный фикс проходит воспроизводитель. Ослаблять проверки, менять ожидаемое поведение ради зелёного теста или подменять моком границу, где сидит баг, скилл запрещает. Отсутствующая зависимость или недоступная старая версия — это ограничение проверки, а не доказательство корректности. Локальный воспроизводитель не даёт права на запись в продакшен или посторонний рефакторинг.

Какие задачи решает

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

Примеры запросов агенту

  • Воспроизведи баг из issue и добавь регрессионный тест, который падает до фикса
  • Проверь предложенный фикс: тест должен падать на исходном коде и проходить после правки
  • Почини падение в parser.py и покажи результат теста до и после

Как установить regression-proof

1Через Skills CLI (Vercel)

npx skills add Neeeophytee/finding-unknowns-skills --skill regression-proof -a claude-code

2Вручную: положить файлы

~/.claude/skills/regression-proof/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/regression-proof/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Вопросы о regression-proof

Как установить regression-proof в Claude Code?

Выполните npx skills add Neeeophytee/finding-unknowns-skills --skill regression-proof -a claude-code. Скилл окажется в ~/.claude/skills/regression-proof/SKILL.md.

Что делает regression-proof?

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

Чем regression-proof отличается от обычного аудита покрытия?

Он работает с одним сообщённым багом и его воспроизводителем. Общий аудит покрытия и разработка новых фич в его задачу не входят.

Исходный текст

SKILL.md · MIT
---
name: regression-proof
description: Fix a reported bug with a regression test that demonstrably fails on the original behavior and passes after the fix. Use when implementing a bug fix or checking whether a proposed fix actually addresses a reported failure. Not a general coverage audit or new-feature workflow.
---

# Regression proof

A passing test is evidence for a fix only if it can distinguish the broken behavior from the intended behavior.

## Steps

1. Establish the reported failure, expected behavior, and authorized scope from the request, relevant code, and existing tests. Record the starting state, including uncommitted changes. Run the relevant baseline and reproduce the bug before editing when possible; distinguish a product failure from a broken test environment.
2. Add the smallest regression test that exercises the real failing path and asserts the required outcome. Run it against the original behavior and verify that it fails for the reported reason, not an import error, missing dependency, or unrelated failure. Reuse an existing test if it already demonstrates this.
3. Trace the cause and make a scoped fix when implementation is authorized. For review-only requests, assess the proposed fix without silently changing production code. Preserve the evidence from the original failure.
4. Run the same regression test against the fixed behavior. If the fix existed before the test, compare with the original implementation in an isolated copy or worktree that preserves the relevant starting state. Do not reset the user's working tree. If an equivalent comparison cannot be made, report that limitation rather than claiming a verified before/after result.
5. Check the neighboring behavior most likely to be affected. Where an incomplete fix could pass the reproducer, add a discriminating case. Use reference comparisons, bounded randomized checks, or performance measurements only when the failure mechanism warrants them; record seeds and conditions needed to reproduce results.
6. Finish with the cause, fix or review finding, commands and observed before/after outcomes, adjacent checks, and remaining uncertainty. If the bug cannot be reproduced or expected behavior is unresolved, say what evidence is missing and avoid a speculative fix. Stop once the scoped claim is supported and relevant checks pass.

## Guardrails

- Never weaken assertions, change expected behavior merely to make a test pass, or mock away the boundary responsible for the bug.
- Preserve existing tests and unrelated user changes. Keep comparison artifacts isolated; do not use destructive checkout or reset operations to recreate the original failure.
- A missing dependency or unavailable original version is a verification limitation, not proof of correctness. Keep pre-existing failures separate from regressions caused by the fix.
- Keep execution within the task's authorization. A local reproducer does not authorize production writes, external side effects, or an unrelated refactor.
- A regression test establishes the tested behavior, not the absence of all bugs. This skill does not change the host's reasoning-effort setting.

© Neeeophytee · MIT · Neeeophytee/finding-unknowns-skills

Похожие скиллы

Все скиллы по теме «Тесты и QA» →
improve-codebase-architecture Matt Pocock Скилл ищет архитектурные узкие места в кодовой базе и показывает варианты углубления модулей в HTML-отчёте. Подойдёт для ревью перед рефакторингом. 1 163 035установок design-taste-frontend Leonxlnx Скилл задаёт арт-дирекцию для публичных страниц и рабочих экранов, а затем проверяет результат в браузере по скриншотам. Нужен, когда интерфейс выглядит шаблонным или недоработанным. CX Codex +1 678 700установок tdd Matt Pocock Скилл управляет циклом красный-зелёный в TDD: проверяет, что тесты пишутся до кода, держит их на уровне публичных интерфейсов и не завязывает на внутреннюю структуру. 1 141 062установок skill-creator официальный anthropics Помогает создать новый скилл, доработать существующий и проверить результат через тестовые промпты и оценки. 414 180установок agent-browser vercel-labs Скилл управляет браузером через CLI: открывает страницы, заполняет формы, нажимает кнопки и проверяет веб-приложения. Подходит для задач, где агенту нужно действовать в интерфейсе. CX Codex +1 1 200 000установок prototype Matt Pocock Создаёт временный прототип, чтобы проверить логику, модель состояния или вид интерфейса до работы над основным кодом. 986 201установок

Из того же набора5

Спонсоры проекта

Компании, которые помогают держать аналитику открытой