Fix a Failing Test on Your Own Machine From a Chat
The shortest useful coding task for an agent is a test that already fails. The repro is written, the goal is unambiguous, and the check for "done" runs in seconds. This is that run end to end, on a laptop the code never leaves.
Turn on two capabilities, not all of them
A computer you pair yourself refuses shell and file access until you allow them on the machine. Coding needs those two and nothing else:
idapt-computer service policy enable remote-shell
idapt-computer service policy enable remote-files
Each prints Applied. and a running daemon picks it up with no restart. Skip full-control: it also grants admin operations and desktop control, which this workflow never uses. The computer's Dashboard shows every capability as Allowed or Blocked, so you can check your work.
The prompt
Open Skills, pick idapt Code, choose Use in new chat, and send one message that names the machine, the path, and the outcome:
On my workstation computer, in ~/work/checkout-api:
pnpm test paymentsfails on the retry case. Reproduce it, find the cause, fix it, re-run that test file, and show me the diff.
Three facts do the work: which computer, which directory, and what "done" means. Leave any of them out and the skill asks before it touches anything.
What the agent does
- Confirms the ground. Which computer, which operating-system user its commands run as, the Git branch and status, and any
AGENTS.mdor contributor instructions the repository ships. - Reproduces first. It runs your failing command before editing, so the fix is aimed at the real failure rather than at the stack trace you pasted.
- Reads before writing. It opens the code paths the test touches and follows the conventions already in the file.
- Re-runs the narrow check. The one test file, not the full suite, so the loop stays short.
- Reports. Files changed, commands run with their exit codes, the current Git state, and what it did not verify.
Work already sitting in your worktree is treated as yours. The skill will not reset, stash, or check out over it.
Stop where you want to stop
The run ends at the outcome you named. "Show me the diff" leaves Git alone. "Commit these changes" makes a local commit. "Push the branch" uses the credentials already on the machine. "Open a pull request" uses an installed gh or glab and reports the URL. If that CLI is missing, you get the pushed branch and the link to open the request yourself.
For a token that should not live on the laptop, put it in Secrets and name it in the message: Git credentials and Secrets covers the one-command injection.
Pick the model per task, not per product
The skill is the workflow; the model is a choice you make in the normal picker and can change on the next turn. On a machine with a capable GPU, a local model can run the loop with the code never leaving the building. Everything else stays identical, which is the point.
Good to know
- The agent reads and writes through the shell and filesystem, so an editor is optional and never part of the loop.
- A command reaches whatever its operating-system user reaches. For an unfamiliar repository, run this on a cloud computer instead of your laptop.
- There is no visual diff-review pane. The diff comes back in chat, and
git worktreeis available when you want the change isolated on disk. - Long installs and long test suites keep running after you close the tab; the results are in the chat when you come back.
Try it on the next red test
Grab the next failing test in a repository you know, allow the two capabilities, and send the three facts. The idapt Code quickstart has the full setup, and From Prompt to Deployed Site on a Cloud Computer is the same loop scaled up to a running site.
Found this helpful? Share it: