vibe-testlisted

Blast-radius-aware test generation for vibe-* projects. Traces every file a change touches, maps the full dependency graph, and writes complete test coverage across the entire blast radius — component tests, integration tests, and E2E tests. Extends existing tests in-place. Writes from scratch where none exist. Triggers on "test:" prefix, "write tests for", "test this feature", "add test coverage", "what needs testing", "test the blast radius", "coverage is missing", "write regression tests". Runs automatically at the end of vibe-add-feature and vibe-fix-bug sessions. Always use when any code has changed and test coverage must be verified or created. Never skips files. Never assumes untouched means unaffected.
aakashdhar/vibe-skill · ★ 7 · Testing & QA · score 68

Install: claude install-skill aakashdhar/vibe-skill

# Vibe Test Skill Blast-radius-aware test generation. Traces the full dependency graph of any change, maps every affected file, and writes complete coverage — component, integration, and E2E. No gaps. No assumptions. Everything the change could have touched gets tested. > **Autonomous / headless mode.** At startup resolve the settings with > `python3 ~/.claude/skills/vibe-mode/scripts/vibe_state.py mode`. If `vibe_mode` is > `autonomous`, every "wait", "ask", "confirm" and approval step in this skill follows > vibe-mode's `references/HEADLESS.md` §2 instead: take the recommended option, accept your > own draft after one self-check, log each choice to `vibe/DECISIONS.md`, never ask the > user, and stop — writing `vibe/.run_state.json` — only when a person is genuinely required. **Runs in agent mode (Claude Code / Cursor). Requires filesystem access.** --- ## The principle this enforces A change is only complete when everything it could affect is verified. Direct changes are obvious. Indirect consumers are where regressions hide. This skill does not ask "what should I test?" It asks "what could this break?" — then tests all of it. **Assertions come from the intended behaviour, not from the code.** Derive what a unit *should* do from the spec / acceptance criteria / bug report — ideally before reading the implementation — and assert that. A test written by mirroring what the code currently does is a tautology: it passes by construction and can never catch the code being