Files, code, and the terminal
Gideon can work with files, tools, and a terminal in its workspace. Give technical work a clear scope and ask for evidence that matches the requested change.
Point to the right workspace
For hosted Gideon, use files or repositories the remote runtime can access. For an existing project, identify the repository or workspace before starting a code goal. A local directory on your laptop is not automatically available remotely.
Start with diagnosis
Investigate [issue] in [workspace]. Explain the cause before editing. Then make the smallest relevant change, run the focused check that demonstrates the fix, and report changed files and anything you could not verify.
Follow the work
Use the terminal and work view to inspect commands, outputs, and files. Code goals can progress through requirements, design, implementation, verification, and review. The relevant starting stage depends on whether the job is a new build, bug fix, investigation, or another kind of change.
Decide what counts as done
A build passing does not prove every user journey works. Ask for checks tied to the result you need. Review the diff and the actual output. Keep deployment, account changes, and external publication explicit in the brief.
Browser work
Available browser and search tools depend on installed capabilities and runtime support. Ask Gideon what it can access for the current task. Do not assume the old Neo Computer viewer or your local desktop is attached to every Gideon session.