just-vibeGeneral · apply by default
/test
Add meaningful coverage for specified behavior
Use to implement behavior checks; test-unit, test-integration, test-e2e and test-property own layer-specific methods, coverage identifies gaps and verify runs existing checks.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select test from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv test, /just-vibe test and /jv:test in Claude. See shortcut setup and context examples.
/just-vibe:test Add meaningful coverage for expired invitations and repeated acceptance./just-vibe:test Add tests for duplicate submissions and a legitimate repeated purchase./just-vibe:test Assess test design without the integration environment; do not mark mocks as live coverage.What the agent does
- Inspect existing tests and identify the important gaps.
- Choose the lowest layer (unit, integration or end-to-end) that can observe the contract and add representative cases there, each with an independently derived expected result.
- Run the relevant checks and demonstrate that each new test detects a plausible regression.
Inputs
- behavior to protect, target code, and existing test conventions.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Meaningful behavior coverage at the cheapest reliable layer; no arbitrary coverage quota or whole-suite rewrite.
- 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; behavior to protect, target code, and existing test conventions.
- Prerequisites
- Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
Expected output
- Tests and any necessary fixtures mapped to the requirements they cover, execution results and uncovered boundaries.
How the work is checked
- A realistic behavioral regression fails the new test; harmless internal refactoring does not invalidate assertions.
When to stop or clarify
- Report unavailable services/runners. Avoid tests that merely restate implementation or require live paid endpoints without authorization.
Handling missing context
- Infer
- Resolve the named files, existing scripts, current task and earlier corrections from the conversation and repository.
- Assume
- Use the narrowest interpretation that completes a reversible local task; state a consequential assumption once.
- Ask
- Ask when competing targets or incompatible success conditions would change the result; continue independent inspection first.
Technical guidance
- Evidence
- Identify the behavior at risk, existing test layer and independently known expected result.
- Method
- Choose the lowest layer that observes the invariant, load its testing method and include a meaningful failure case.
- Pitfall
- Mock call assertions or tests mirroring helper logic can pass while behavior is wrong.
- Check
- Verify a plausible bad implementation fails for the intended reason and that the legitimate path passes.
Situational decisions
When the proposed assertion mirrors internal implementation: Replace it with an external invariant or consumer-observable result.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.