test-blindspots — скилл для Claude Code: проверка тестов
Ищет важные пробелы, которые не выявляет зелёный набор тестов, и проверяет их небольшими экспериментами. Нужен, когда важно понять, что именно тесты подтверждают для конкретного изменения.
npx skills add Neeeophytee/finding-unknowns-skills --skill test-blindspots -a claude-codeЧто делает test-blindspots
Скилл сопоставляет требования, изменённый код и утверждения тестов, чтобы найти конкретное непроверенное допущение. Затем предлагает небольшой эксперимент, который различает правильное и неправильное поведение, и запускает его в пределах задачи. Для проверки предпочитает реальный компонент, если сомнение вызвано подменой границы мок-объектом.
Результат разделяет подтверждённые дефекты, риски без проверки и вопросы к спецификации; отдельно фиксируются проверенные доказательства и то, что осталось вне исследования. Если найден сбой, скилл сохраняет минимальный воспроизводимый пример и добавляет регрессионный тест, когда это входит в задачу. Он не исправляет рабочий код и не выдаёт гипотетический сценарий за дефект. Проверки с внешними побочными эффектами и производственными данными требуют явного разрешения.
Какие задачи решает
- найти поведение, которое зелёные тесты не проверяют
- проверить ожидания потребителей изменённого компонента
- отличить подтверждённый дефект от непроверенного риска
- сохранить минимальный пример сбоя для регрессионного теста
Примеры запросов агенту
- Проверь, что зелёные тесты не подтверждают для этого изменения, и предложи точечные проверки.
- Найди непроверенные переходы в изменённом компоненте и проверь их без обращения к производственным данным.
- Для подтверждённого сбоя сохрани минимальный воспроизводимый пример и добавь регрессионный тест.
Как установить test-blindspots
1Через Skills CLI (Vercel)
npx skills add Neeeophytee/finding-unknowns-skills --skill test-blindspots -a claude-code2Вручную: положить файлы
~/.claude/skills/test-blindspots/SKILL.mdПапка скилла целиком; для одного проекта — .claude/skills/test-blindspots/
1Через Skills CLI (Vercel)
npx skills add Neeeophytee/finding-unknowns-skills --skill test-blindspots -a codex2Вручную: положить файлы
.agents/skills/test-blindspots/SKILL.mdДля всех проектов — ~/.agents/skills/
1Через Skills CLI (Vercel)
npx skills add Neeeophytee/finding-unknowns-skills --skill test-blindspots -a cursor2Вручную: положить файлы
.cursor/skills/test-blindspots/SKILL.mdCursor читает и .agents/skills/, и .claude/skills/
1GitHub CLI
gh skill install Neeeophytee/finding-unknowns-skills test-blindspots2Вручную: положить файлы
.github/skills/test-blindspots/SKILL.md1Через Skills CLI (Vercel)
npx skills add Neeeophytee/finding-unknowns-skills --skill test-blindspots -a gemini-cli2Командой платформы
gemini skills install https://github.com/Neeeophytee/finding-unknowns-skills --path skills/test-blindspotsВручную: положить файлы
.devin/skills/test-blindspots/SKILL.mdСтарый путь .windsurf/skills/ тоже читается
Через Skills CLI (Vercel)
npx skills add Neeeophytee/finding-unknowns-skills --skill test-blindspots -a opencodeClaude.ai
Упакуйте папку в zip и загрузите в Settings → Capabilities → Skills
По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов
Вопросы о test-blindspots
Как установить test-blindspots в Claude Code?
Выполните npx skills add Neeeophytee/finding-unknowns-skills --skill test-blindspots -a claude-code. Файл скилла находится по пути ~/.claude/skills/test-blindspots/SKILL.md.
Что делает скилл test-blindspots?
Он сравнивает поведение, требования и проверки, чтобы выявить значимые пробелы в тестах. Для каждого выбранного пробела проектирует и запускает ограниченную исследовательскую проверку.
Исправляет ли test-blindspots найденные дефекты?
Нет: скилл сохраняет воспроизводимый пример и может добавить регрессионный тест, если это входит в задачу. Исправлять рабочий код он не должен.
Исходный текст
SKILL.md · MIT
--- name: test-blindspots description: Find consequential behavior that a passing test suite does not establish, using focused exploratory checks. Use when the user asks what green tests miss or wants confidence in test coverage for a specific change. Not a general code review, routine test run, or debugging workflow for an already failing test. --- # Test blindspots Passing tests establish their assertions under their setup. The gap to investigate is where the implementation and its tests share the same untested assumption. ## Steps 1. Establish the intended behavior and scope from the request, specification, changed code, callers, and relevant tests. Run the relevant baseline when possible. If it is already failing, report that limitation rather than describing it as green. 2. Compare important behavior with what the tests actually assert. Look for a concrete gap: a mock replacing the boundary being claimed, an untested transition, a missing consumer expectation, or an invariant only exercised on the happy path. Choose by consequence and evidence, not by a generic checklist or coverage percentage. 3. For each selected gap, state the question and design a small exploratory probe that can distinguish correct from incorrect behavior. Use existing tooling and isolated data. Prefer the actual component over a mock when the mock is the source of uncertainty. 4. Execute the bounded probes within scope. Record observed behavior and the requirement it contradicts. If intended behavior is unclear, report a specification question; if execution is unavailable, report an untested risk. Neither is a confirmed defect. 5. For a confirmed failure, preserve a minimal reproducer. Add a focused regression test when test edits are within the task's scope; verify that it fails for the intended reason. Report any deliberately failing reproducer separately from the baseline. Do not silently repair production code. 6. Finish with confirmed defects first, then consequential untested risks or specification questions, the evidence for each, and what was not examined. Finding no consequential gap is a valid result. ## Guardrails - Do not equate low coverage with a defect, or green tests with exhaustive correctness. A hypothetical scenario alone is not a finding. - Preserve existing tests and assertions. Do not weaken a test, expand the refactor, or install an unrelated testing framework to produce a result. - Keep probes away from production data and external side effects unless explicitly authorized. State when a local fixture cannot represent the real boundary. - Keep this proportional to the change. Stop when further exploration is unlikely to alter the user's decision.
© Neeeophytee · MIT · Neeeophytee/finding-unknowns-skills