Using goto and AI Skills to Go Deeper on Remote Problems

I often hit problems that do not show up well from code reading alone. The service is remote, the environment is slightly different from local, and the real clue sits behind one more command: uptime, journalctl, kubectl describe, ps, ss -lntp, df -h, or a project-specific diagnostic.

That is where goto and AI skills fit together well.

What goto solves

source: https://github.com/chinglinwen/goto

goto is a small Go SSH client for interactive login and batch command execution. It grew out of a practical problem: shell glue and expect are fine until they are not. Terminal resize handling, jump hosts, password reuse, and host config quickly become annoying when the workflow is repetitive.

The project keeps a few useful properties together:

• one command for interactive login and batch remote execution
• shared host and credential config
• password and key-based auth
• jump host support
• support for ~/.ssh/config
• batch mode that preserves remote stdout, stderr, and exit status

That last point matters more than it looks. If a remote command runner rewrites output, prefixes lines, or hides the exit code, it becomes much harder to use inside automation or an agent workflow. goto keeps the batch path close to raw SSH behavior, which makes it a good foundation for deeper diagnosis.

Why pair it with AI skills

The interesting part is not “AI writes an SSH command”. The interesting part is that a skill can encode the correct operating rules for a repo and a tool, so the agent stops improvising fragile remote-exec behavior.

In ~/.claude/skills/goto-remote-command/SKILL.md, the skill defines a concrete contract:

• use goto as the project-native remote command runner
• prefer host-first batch mode: goto <host> <cmd...>
• allow stdin-fed commands when no positional command is given
• keep remote stdout on local stdout and remote stderr on local stderr
• return the remote exit status
• avoid mixing local narration into raw command output unless verbose mode is explicitly requested
• keep interactive mode and batch mode separate

This is the part I like most about skills: they compress operational knowledge into something reusable. Instead of reminding an agent every time how a tool behaves, the behavior becomes part of the working contract.

How this helps dig problems deeper

A lot of debugging stalls at the “probably” layer. Probably a bad deploy. Probably a disk issue. Probably a jump host problem. Probably a process crash loop.

Remote execution lets the agent move from guesses to evidence quickly.

For example, a shallow investigation might stop at:

kubectl get pods

A deeper investigation can branch immediately into:

goto app-node-1 'journalctl -u api -n 200 --no-pager'
goto app-node-1 'ss -lntp'
goto app-node-1 'df -h'
goto app-node-1 'ps aux | grep api'

Or for application-specific checks:

goto worker-17 'curl -s localhost:8080/healthz'
goto worker-17 'grep -n "timeout" /var/log/myservice/current'
goto worker-17 'env | sort'

The value is not just command execution. It is the feedback loop:

1. form a hypothesis
2. run the minimum remote command that can falsify it
3. inspect raw output
4. refine the next command
5. continue until the failure boundary is clear

If the agent already knows the goto contract, it can stay focused on the system problem instead of spending tokens rediscovering SSH mechanics.

The skill adds guardrails, not magic

The skill is useful because it is opinionated about the failure modes that waste time:

• check for ~/.ssh/goto.yaml or legacy ~/.goterm/config.yaml before trying commands
• prefer configured jump-host flows when the environment requires them
• remember that -p=<cred> resolves the password, not automatically the user
• keep initcmds out of batch mode
• use verbose mode only when debugging the connection path itself

These are small details, but they are the difference between “the remote command feature exists” and “the remote command workflow is dependable”.

Why this pattern scales

I think this is a good shape for AI-assisted ops and debugging in general:

• the project provides a native tool
• the skill documents the tool’s real contract
• the agent uses the tool consistently
• raw output stays trustworthy enough for deeper reasoning

That combination makes the agent more than a code summarizer. It becomes a better operator.

For remote systems, that usually means better debugging, faster verification, and fewer fake conclusions drawn from incomplete local context.

goto gives the execution path. The skill gives the operating discipline. Together they make it easier to dig until the real problem shows up.