Testing · apply by default
/test-regression
Turn a confirmed bug into a lasting behavioral check
Use to prevent recurrence of a confirmed defect; test adds general coverage.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select test-regression from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv test-regression, /just-vibe test-regression and /jv:test-regression in Claude. See shortcut setup and context examples.
/just-vibe:test-regression Turn the confirmed duplicate-credit bug into a failing-then-passing check./just-vibe:test-regression Add regression coverage for duplicate events while allowing distinct events./just-vibe:test-regression Design a regression test when the original failing revision is unavailable.What the agent does
- Identify the original trigger and intended observable behavior from requirements or independent evidence. Choose the lowest layer that can faithfully exercise the boundary; a database mock cannot establish real transaction behavior.
- Construct minimal deterministic inputs and an expected result that does not call the implementation under test. Include the failing boundary and a neighboring valid case; for races, control completion order and assert that the losing path has no forbidden effect.
- Where feasible, run the unchanged test against broken and fixed behavior in an isolated copy or worktree. Preserve unrelated user edits and the real index; do not roll back a dirty working file to perform a sensitivity check.
- Confirm that the negative run fails on the intended assertion, not an import error, missing fixture, timeout or unrelated refactor. Report actual commands and statuses; if the old revision cannot run, explain the remaining evidence gap.
Inputs
- confirmed bug, reproduction, expected behavior, and fixed/broken revisions where available.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- A durable test protecting the actual failure mechanism.
- Writes
- Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.
- Mode
- Apply; confirmed bug, reproduction, expected behavior, and fixed/broken revisions where available.
- Prerequisites
- Defined behavior, existing test conventions/runners, isolated fixtures, and relevant dependencies. Requested bounded verification may use owned isolated fixtures without authorizing product edits or live-system tests. Never test destructive behavior against production by default; distinguish mocked behavior from real integration evidence.
Expected output
- Trigger and independent expected result, test layer, original-defect sensitivity, fixed and neighboring-case results, and unavailable checks.
How the work is checked
- The regression reaches the defective path and rejects its behavior; the fixed path and neighboring valid behavior pass. A syntax/setup failure or a test with no effective assertions is not regression evidence.
When to stop or clarify
- If the old revision cannot run, state that limitation. Do not assert implementation details instead of the user-visible invariant.
Handling missing context
- Infer
- Read behavior contracts, existing runners and test conventions; distinguish fixture setup failure from a behavioral failure.
- Assume
- Use the smallest existing local runner and isolated synthetic fixtures that distinguish the requested behavior. When the method needs a library, runner, container runtime or load tool the project lacks, name the exact package or tool, the files it changes and any download, and add it only when the request authorizes new dev dependencies or tools; label a hand-written generator without shrinking, or a fake in place of a real dependency, as such.
- Ask
- Ask about an unresolved contract that changes the expected result, or the target/load limits before external testing; do not ask the user to choose a runner already configured.
Technical guidance
- Evidence
- Establish the original trigger, broken revision and expected behavior independent of the proposed patch.
- Method
- Add the lowest-layer check that observes the real failure; verify sensitivity in an isolated broken copy when feasible.
- Pitfall
- A missing import or setup timeout on the old revision does not establish regression sensitivity.
- Check
- Record the causal failing assertion or valid-input exception on broken code and a pass on the fix without weakening the expectation.
Situational decisions
When the old revision cannot execute in this environment: Explain the limitation and use the strongest available independent reproduction evidence.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.