Skip to main content

Get started · 4 min read

Getting Better Results with Revolte

A prompt gives Revolte the intent for the work—not a complete implementation spec. State the outcome clearly and the proposed plan needs less correction.

01
Context
Files, errors, references, or prior decisions Revolte should see
02
Goal
The outcome stated as a concrete change
03
Constraints
What must stay unchanged and what is out of scope
04
Done when
Tests or observable checks that prove the result

Give Revolte the outcome, the constraints that matter, and a way to verify the result. Leave implementation to the agent. Only prescribe files, commands, or specific steps when they genuinely affect correctness.

Feature, contained scopeName the surface, data scope, and output format.
Too vague
Add a way to export data.
Export what, from where, and in which format are all undefined.
Usable
Add a CSV export button to the Reports page that downloads the currently filtered table in the column order shown on screen.
Surface, data scope, and format are named without unnecessary structure.
Feature, open-ended scopeDescribe the outcome, surface, user role, and expected behavior.
Too vague
Add patient vitals to the dashboard.

Also maybe show the trend or something. Not sure exactly what format — talk to design maybe? The doctor screens need it I think.
Which vitals, which dashboard, which role — all undefined. “Talk to design” is not something the agent can act on.
Usable
Add a vitals panel to the physician dashboard showing the last 7 days of HR, SpO2, and BP for the selected patient.

Pull from GET /patients/:id/vitals. Match the existing card layout used in the labs section. Include loading and empty states.
Role, data source, visual contract, and edge cases all covered without prescribing implementation.
Bug fixName the symptom, reproduction path, expected behavior, and verification.
Too vague
The medication list is broken for some patients.

It’s been reported a few times. Sometimes it loads sometimes it doesn’t. Can you look into it and fix whatever the issue is?
No reproduction steps, no error signal, no definition of fixed. “Look into it” puts all scoping on the agent.
Usable
The medication list throws a 500 on GET /patients/:id/medications when the patient has no active prescriptions. The UI shows a blank screen instead of an empty state.

Fix the API to return an empty array in that case. Add an empty state to the MedicationList component. Add a test for the zero-prescription path.
Symptom, endpoint, root cause hypothesis, UI behaviour, and test coverage all defined.
RefactorBound the scope, preserve behavior, and define the improvement.
Too vague
The appointment booking flow is messy and hard to maintain.

There’s a lot of duplicated logic across the components. Please clean it up and make it more reusable. Keep it working obviously.
”Messy” and “reusable” are subjective. No scope boundary, no success condition.
Usable
Extract the slot-availability logic duplicated across BookAppointment.tsx, RescheduleModal.tsx, and FollowUpFlow.tsx into a shared useSlotAvailability hook.

Behaviour must stay identical — existing tests should still pass. Add unit tests for the hook itself.
Scope is bounded to three files. Success criterion is existing tests passing plus new hook tests.
UI / compliance requirementSpecify placement, required states, validation, persistence, and conventions.
Too vague
We need to add consent stuff to the onboarding.

Legal said it’s required. Something about data usage and maybe a terms checkbox. Make it look good and not annoying.
No screen location, no copy, no required fields, no persistence target. “Not annoying” is not a design spec.
Usable
Add a consent step to the patient onboarding flow (between profile setup and the dashboard redirect).

Show two checkboxes: data processing consent and terms acceptance — both required to proceed. Persist consent status to PATCH /patients/:id/consent. Use the existing StepLayout component and form validation patterns.
Placement, required fields, API target, and component conventions all specified.

Context: [files, errors, references, or prior decisions]
Goal: [the change stated as an outcome]
Constraints: [what must not change or is out of scope]
Done when: [tests or observable checks]
1

Be opinionated — replace “improve performance” with a measurable target or concrete behavior.

2

Give it a checkpoint — make the scope small enough that you can review the plan and result.

3

Close the loop — define how Revolte and your team can verify that the outcome works.

4

Choose the right workflow — use AI Chat for discovery and iteration; use Jira Workflow for a prepared task.


  • A whole-codebase review with no target. “Review this repository and improve it” needs a scope, not more adjectives. See Ways teams use Revolte for how to turn it into focused sessions.
  • A purely subjective request with no reference. “Make this feel more premium” gives Revolte nothing concrete to match. Add a screenshot, competitor screen, design system, or existing page as the reference.
  • A project too large for one plan. A multi-week migration is a sequence of reviewable checkpoints, not one prompt. See Writing tasks Revolte can execute.