Understand current coverage (optional)
Before writing anything, ask Revolte to map what the feature does and how much of it is already tested — useful when you didn’t write the code yourself. Read through the summary it returns; the plan in the next step is only as good as the gaps identified here.
Turn gaps into a test plan
With the gaps identified, have Revolte turn them into a concrete, prioritized plan before any tests get written. Skim the plan and reorder or drop anything that doesn’t match what you’d actually prioritize — it’s the checklist the next step implements against.
Adjust the plan (optional)
If a priority looks off or a scenario’s missing, say so before anything gets implemented — it’s a lot cheaper to fix here than after the tests are written. Skip this if the plan already looks right.
Approve and implement
Once the plan looks right, approving it is enough — Revolte already has the plan from the session, so there’s no need to restate it.
What Revolte does
While that runs, here’s what to expect in the session before you’re asked to review anything — Revolte works through it in stages:
- Analyzes the feature — what it does and what it depends on.
- Reviews existing coverage — what’s tested today and where the real gaps are.
- Plans scenarios — critical paths, edge cases, and failure modes worth covering.
- Writes the tests — matching your project’s existing structure and conventions.
- Verifies — runs the suite, fixes failures, and confirms coverage actually improved.
Continue iterating
Once the suite lands and you’ve checked coverage actually improved, stay in the same session and go after the scenarios that matter most for reliability:Or point Revolte at the suite itself rather than new coverage: