PLAN → ACTION → EVIDENCE works especially well for local computer operations because files, commands, and system state are directly inspectable.
What Desktop Commander adds to a ChatGPT workflow
A local command and filesystem tool layer allows an AI client to work with authorized files, directories, terminal commands, and system information on a computer the user controls. This changes the interaction model: the assistant can inspect a real project and perform permitted operations instead of only describing manual steps.
Start with a filesystem boundary
The first useful control is not a clever prompt. It is a technical boundary. In our test setup, the agent workspace was restricted to a dedicated directory. The important result was not the configuration text itself, but the observed behavior: an allowed path could be read while a path outside the workspace was denied.
Allow work only inside D:\70_AI. Do not depend on “please avoid private files” as the security boundary. Test both an allowed read and an outside read.
Use read-only audit before mutation
For cleanup, diagnostics, code review, or system inspection, start by collecting facts. List files, versions, processes, startup entries, or project structure without changing anything. The audit becomes the baseline for the next PLAN.
Add dry-run for risky local actions
If the next step is deletion, bulk rename, moving files, modifying configuration, or running a command with broad effects, generate a concrete preview first. A useful dry-run lists exact targets and intended operations and confirms that the scope remains inside the allowed workspace.
Execute one bounded action
Prefer small, reversible changes over broad “clean everything” commands. A bounded ACTION is easier to understand, easier to verify, and easier to roll back. For example: edit one CSS token, generate one report, move one known file, or run one diagnostic command.
Verify with a different observation
After the action, do not stop at the tool's success message. Re-read the file, list the directory, compare hashes, inspect the process state, rerun the diagnostic, or open the resulting page. This is evidence: an observable state after execution.
Example: website work
A practical workflow can look like this: locate two website versions, compare their CSS, make a backup, copy only the reusable design-system layer, update the target files, then open the local page and inspect the result. Each transition can be tested: the source exists, the backup exists, the changed CSS is present, all local links resolve, and images decode correctly.
Example: browser + business system
The local tool layer can also participate in a larger workflow where a browser is the action surface. The agent can prepare files and commands locally while the browser operates a web interface. The same rule remains: the final proof should come from the target system state, not from a narrative description of what the agent intended to click.
Common failure modes
- Unlimited scope: giving full filesystem access when one project directory is enough.
- Action without baseline: changing state before recording what existed.
- Broad commands: combining many changes into one hard-to-audit step.
- No dry-run: previewing nothing before destructive operations.
- Self-verification: accepting the same completion message that initiated the action.
A reusable operating loop
- PLAN: task, allowed directories, prohibited actions, success criterion.
- READ: collect baseline facts.
- DRY-RUN: when risk justifies a preview.
- ACTION: one bounded change.
- EVIDENCE: re-read or independently verify the resulting state.
- REUSE: save the successful pattern as a checklist or skill.