Read file and shell tool activity
Tool activity explains what RX attempted while answering. Read the operation together with its target, output, and resulting project state; the final prose is not a substitute for those checks.
What the basic tools mean
| Tool | What to inspect |
|---|---|
read | Which file and range were read; missing or partial content matters. |
glob | Which pattern and directory were searched; matches are not file contents. |
write | Which file was written and whether the saved bytes match the intended result. |
edit | Which existing text changed; inspect the surrounding file and diff. |
bash | The command, working directory, exit status, and relevant output. A launched process is not automatically a finished task. |
Use /tools inside RX to inspect the installed inventory. These names describe the documented basic set, not every configuration. Ordinary sessions work in the host workspace as described by the distribution documentation.
Review one operation
- Match the tool target to the task's intended file or command.
- Read warnings and errors before accepting the final summary. Where your installed interface offers expansion, inspect details rather than treating a folded line as complete output.
- Check the affected file or command result independently. If output was clipped, keep any existing complete log; do not infer missing lines or rerun a costly action just to recover display text.
Separate activity from success
A file read is context gathering. A write changes project state. A shell invocation may start a process, fail, or finish without satisfying the task. A passing narrow test supports that test, not every workflow in the project.
If the activity differs from the requested scope, stop further work and preserve the current diff. Review host permissions before continuing. The Git diff reference helps interpret tracked changes; inspect untracked additions separately.