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
Make the requested change small and explicit, preserve a recoverable starting version and check real behaviour afterwards. Ask GetRuthless to explain the affected code before proposing edits and to identify any additional changes as extra scope.
Record the behaviour you want to keep
A model cannot preserve a working feature it has never been shown. Before asking for an improvement, describe the useful behaviour nearby. In a notes app, changing the editor layout should preserve saving, loading existing notes and keeping each account’s notes separate. These are concrete behaviours, not a vague instruction to “avoid regressions”. A regression is simply something that used to work and no longer does.
Use your building tool’s history or checkpoint feature to identify a recoverable version. Check what the restore includes: code history may not recover changed data. Work in a development or test version with invented data. Bring a redacted excerpt of the relevant code, your exact requested outcome and observations from the starting version.
Ask GetRuthless to bound the change
Open GetRuthless chat and paste the prompt below. The hosted chat cannot inspect your local repository by default, so supply the relevant context and tell it what is missing. Ask for a short explanation of which files or functions seem involved before it drafts a change. If it cannot establish the connection, provide another narrow excerpt rather than asking it to guess.
Review the proposed scope. A new dependency, storage change or authentication rewrite may be far larger than a layout adjustment. Ask why it is required and whether a smaller approach meets the same outcome. Do not treat a large patch as automatically more complete. Once the plan fits, apply it through your building tool’s normal workflow and inspect its actual change summary.
Plan the smallest change for this outcome: [specific result]. Here is the relevant redacted code and current behaviour: [paste]. These behaviours must keep working: [list]. My recoverable starting version is recorded, and I will test in [environment]. Explain the affected path before suggesting edits. Do not refactor unrelated code, change storage or permissions, or add dependencies without identifying the reason and extra scope. Give focused before/after user checks and say what evidence is missing. Do not claim tests ran unless I provide their actual results.Example: one improvement with nearby checks
Example output: “Change the note editor spacing in its view file. Preserve the existing Save handler and note-loading calls. Check typing, saving and reloading a test note at narrow and wide screen widths. If the suggested edit touches the storage function, explain why before applying it.” This example sets a useful boundary without pretending every file outside it is irrelevant.
After the edit, compare the changed files with the plan. Ask GetRuthless to explain unexpected changes using the actual diff, which is the before-and-after text of the edits. Remove credentials before sharing it. A statement that the code compiles is useful, but it does not prove the visible action or saved result still works.
Verify the change and preserve failed evidence
Repeat the same user steps you recorded before editing. Include the requested improvement and the nearby working behaviours. Record actual outcomes instead of marking everything passed because no error appeared. For the notes app, a saved message without a persistent note is a failed check.
Small task: write one sentence describing a reason to restore the earlier version. For example, “If a saved note vanishes after reload, return to the checkpoint and investigate the save path.” When a check fails, keep its steps and result. Ask for a focused diagnosis; stacking broad changes on an unexplained failure makes it harder to learn which change caused the problem.
Common questions
Can a prompt guarantee no bugs?
No. Clear scope reduces avoidable misunderstandings, but actual code review and behaviour checks are still needed. The important claim is what you verified in the version you tested.
Should I ask for a complete rewrite?
Only when a specific, supported reason makes the existing approach unsuitable. For a small change, first establish whether a focused edit can meet the outcome while preserving the working paths.
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.