Beginner course · Lesson 2 of 6
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
Choose one action and follow its evidence step by step: the visible control, the code it calls, any request it sends, the receiving code and the saved result. Ask GetRuthless to explain gaps instead of inventing the missing connections.
What you will learn
In the first lesson you made a map. Now you will follow a journey across it. Our notes-app user types “Buy milk” and presses Save. The screen may react immediately, but the visible reaction alone does not tell us whether the note was stored. Understanding the journey helps you ask better questions when something looks successful but disappears later.
A click usually starts a small piece of code attached to a button. That code may check the text, update the screen and send a request. A request is a message asking another part of the system to do something. The reply is a response. In our example, the message might ask the backend to create a note. The response might say it succeeded or explain why it could not.
Bring one narrow trail
Open your building tool and find the screen containing the action. Its file explorer search may help you search for the button label, such as Save. If you cannot find it, ask the building tool to locate the button and name the function it calls without editing anything. Bring your checked project map, the button code, the called function and the receiving code if the tool identifies it.
You can provide small redacted excerpts instead of whole files. Keep function names and the surrounding lines that show their connection. Replace private note text and user details with invented examples. If a request contains a credential or cookie, do not copy that value. Say that authentication information is present without sharing it.
Build a numbered explanation in GetRuthless
Open GetRuthless chat and paste the prompt below with your reviewed excerpts. Ask for an explanation first. A useful answer should follow the actual function names you supplied, rather than describe how notes apps usually work. When the next piece is absent, have it stop the trail there and name the missing evidence.
Read the result beside the files. At each arrow, check that the first function really calls the next one or sends a message to the stated address. A similar name is not proof of a connection. If there are two Save buttons, tell GetRuthless which screen you are testing so it does not trace the wrong route.
Help me follow one action in my app without changing files. I am a beginner. Action: [screen and exact button]. Expected result: [one sentence]. Here is my checked map and redacted code: [paste]. Explain the journey in numbered steps from click to visible response and stored result. Quote the supplied function names at each connection. Explain request and response in everyday language. Mark any missing link unknown. Suggest one harmless observation I can make in my test app to check the trail.Example: Save is a journey
Example output: “1. Save calls handleSave. 2. handleSave passes the text to createNote. 3. createNote sends a request to /notes. 4. The supplied backend function writes a row, then returns its new identifier. 5. The screen adds the returned note to the list.” This is an illustrative trail; your files may use completely different names or save directly through a library.
Now try a harmless invented note in a development or test version you control. Development is the place used to work on changes; production is the version real users rely on. If you do not know which version is open, establish that before experimenting. Observe the confirmation, reload the page and see whether the note remains. Record the actual result, including unexpected behaviour, and ask GetRuthless which part of the trail it supports.
Check what the evidence proves
Small task: label these statements “observed”, “supported by code” or “unknown”: the button changes colour; the backend receives the request; the note survives a reload. A colour change is observed on screen. Backend receipt remains unknown unless you have suitable evidence. A surviving note supports persistence, but does not by itself identify the storage location.
Save your checked numbered trail and one unresolved question. In lesson three, bring the part that writes or reads the note, plus a redacted description of the stored fields. We will use them to understand what data lives where.
Common questions
Must every click send a request?
No. Opening a menu or changing an unsaved draft may happen entirely on the screen. Ask which supplied lines show a request instead of assuming there is one.
Does a success message prove the save worked?
It proves the interface displayed that message. Check the returned result and whether the harmless test item can be read again. A misleading success message is itself useful evidence to report.
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.