Learn by using GetRuthless
Keep this guide beside your Ruthless chat. Copy one prompt, add the example it asks for and paste it into “Message Ruthless”. Nothing is sent until you choose to send it.
The short answer
Supply repeatable steps, expected and actual results, the relevant environment and reviewed error text. Ask GetRuthless to distinguish evidence from hypotheses, choose a small diagnostic check and explain a fix against the reproduced cause.
Make the failure concrete
“My app is broken” could mean a blank screen, missing data, a slow request or an unexpected result. Begin with one failure and the shortest route to it. You do not need to diagnose it yourself. A useful report says what a person did and what happened, including the apparently ordinary steps before the failure.
Bring the app version or recent change if known, whether this is a preview or production, the relevant screen, exact reviewed error text and small redacted source excerpts. GetRuthless cannot see your files, browser session or building-tool logs by default. Remove credentials and private customer information. Replace sensitive values consistently so the relationship between the request and response remains understandable.
Investigate in GetRuthless before editing
Open chat and paste the prompt below with your report. Ask for a restatement first: did it understand the same failure? Then ask for a few plausible causes and the evidence for each. A strong answer includes a way to distinguish them. A confident single explanation without supporting evidence is a hypothesis, even if it sounds technical.
Try one safe observation in a test version. This might be checking whether a request was sent, whether a particular function ran or whether the problem occurs only after a known action. Ask for instructions through the controls your building tool actually offers. If you do not understand a suggested command or data change, ask what it does and whether there is a read-only alternative before using it.
Investigate one bug before proposing edits. Steps to reproduce: [numbered steps]. Expected result: [result]. Actual result: [result]. Environment and recent changes: [facts or unknown]. Exact redacted error and relevant source: [paste]. Restate the failure. Separate observed facts from hypotheses. Give up to three likely causes and one safe check that distinguishes them. Wait for my observation before settling on a cause. When evidence supports a fix, explain the smallest change, its risks, how to recover, and how to repeat the original journey plus one nearby working journey.Example: investigate duplicate notes
Example report: “In my test app, one click on Save creates two identical notes. It happens after opening and closing the editor once. I expected one new note. Both remain after reload.” Example response: “Possibilities include two event handlers or two requests from one handler. Check how many save requests are recorded for one click before changing database code.” These are illustrative possibilities, not a diagnosis of every duplicate-record problem.
Return the actual observation to GetRuthless. If there is only one request, the original explanation needs revising. If there are two, the next question is where the second originated. Do not “fix” the symptom by deleting duplicate customer records while leaving the cause unexamined. Keep the investigation focused on the reproduced path.
Check the effect of the repair
Preserve a recoverable starting version before applying a proposed edit. Afterwards, repeat the exact failure sequence with invented data. Check the intended effect: one click should create one saved note that remains after reload. Also check an ordinary existing path, such as editing a note, to catch a nearby regression.
Small task: write a bug report in four lines: steps, expected, actual and evidence. Ask GetRuthless what essential information is missing. If you cannot reproduce the failure, say so and collect conditions rather than claiming a repair succeeded. A useful final record names what changed, what you observed and what remains unverified.
Common questions
Can I send a screenshot?
A reviewed screenshot can show a visible symptom, but include the text, preceding actions and expected result as well. Remove personal information and unrelated screen content first.
What if the first fix does not work?
Keep the failed result, compare it with the predicted outcome and revisit the cause. Do not let repeated guesses expand into an unrelated rewrite. Restore the known version when needed and seek another check for a persistent blocker.
Sources & further reading
The example prompts and workflows are GetRuthless guidance. Source references support the concepts explained; they are not an endorsement of GetRuthless.
Put the guide into practice.
Open Ruthless and choose an available standard or abliterated model suited to your task. Copy a prompt above, add the context it asks for and check the result. You can compare models in the same workspace; see current pricing before sending requests.