DEV Community

Cover image for Incident Triage Without Context Switching: zoxide workflow notes
arnostorg
arnostorg

Posted on • Originally published at windows-cli.arnost.org

Incident Triage Without Context Switching: zoxide workflow notes

#bash #terminal #cli #productivity

Incident Triage Without Context Switching: zoxide workflow notes

During incident triage, the most expensive context switch is often the dumbest one: finding the right directory under pressure. You already know the command you need to run, but you lose 20–40 seconds jumping across repos, logs, and scripts. Repeat that ten times in one hour and you’ve burned real focus on path trivia.

My opinionated take: if you do incident work from a terminal, zoxide is not optional. It turns navigation into intent. Instead of remembering full paths, you use short cues and let your history guide the jump. That sounds small until your brain is full of timestamps, hostnames, and error codes. Then it becomes a reliability tool.

The minimal setup I actually use

First, check that zoxide is available:

zoxide --version
Enter fullscreen mode Exit fullscreen mode

Then seed one high-value working directory explicitly so the jump target exists immediately:

zoxide add ~/projects/windows-command-shell
Enter fullscreen mode Exit fullscreen mode

I do this for directories I know I’ll hit during triage. Yes, zoxide learns automatically over time, but adding key paths up front removes first-day friction and avoids ambiguous early results.

Query first, jump second

When I’m in “don’t make mistakes” mode, I query before I jump:

zoxide query windows
Enter fullscreen mode Exit fullscreen mode

If the result is what I expect, I jump:

z windows
Enter fullscreen mode Exit fullscreen mode

That two-step pattern is worth it during incidents. query gives you a quick preflight check, and z gives you speed once confirmed. It’s faster than manual cd and safer than blind jumping when names overlap.

A triage workflow that stays in one mental lane

Here’s the loop I optimize for:

  1. Read alert and identify the likely service/repo.
  2. zoxide query <keyword> to verify target path.
  3. z <keyword> to enter.
  4. Run the actual investigation commands.
  5. Repeat with the next keyword, not the next full path.

The key is that navigation becomes deterministic and low-cognitive. You keep your attention on incident signals (error rates, logs, rollbacks), not filesystem archaeology.

For example, if your incident starts in the Windows CLI repo, this sequence gets you moving immediately:

zoxide add ~/projects/windows-command-shell
zoxide query windows
z windows
Enter fullscreen mode Exit fullscreen mode

I like this because it’s explicit, observable, and fast. You can teach it to a teammate in two minutes and it scales from solo debugging to on-call handoffs.

Troubleshooting anecdote: wrong repo jump during an incident call

Real case: I was on a call debugging a regression and typed:

z windows
Enter fullscreen mode Exit fullscreen mode

I landed in an older local clone, not the active repo. Observable symptom: git status showed a clean tree, but I knew there should be local branch changes from earlier that day. I also noticed missing files that had been added recently in the active project.

The fix was straightforward and immediate:

zoxide add ~/projects/windows-command-shell
zoxide query windows
z windows
Enter fullscreen mode Exit fullscreen mode

After re-adding the correct path, query returned the expected directory and z windows started resolving correctly. Incident moved forward, no more navigation drift. Lesson learned: if jump behavior feels “off,” don’t guess—re-seed the intended path and verify with query.

Practical rules that make zoxide reliable under pressure

  • Seed critical repos manually at least once (zoxide add ...) instead of waiting for passive learning.
  • Use zoxide query for preflight when the cost of landing in the wrong directory is high.
  • Use short, stable keywords tied to repo identity (windows here), not temporary ticket names.
  • Treat navigation errors as observable defects: if the path is wrong, fix it immediately in the index and continue.
  • Keep jumps boring so your cognitive budget is reserved for diagnosis and remediation.

This is a small habit change, but it compounds. The shell feels calmer, and incident work becomes less “where am I?” and more “what is failing and why?”

One short cross-shell note: the value proposition is the same whether you spend your day in Bash, PowerShell, or mixed environments. The integration details differ, but the workflow does not: add important paths, query when precision matters, jump by intent, and stay in flow.

Practice this quickly

If you want hands-on drills to build this muscle memory, use the training app here:

zoxide training

Related reading from the same site

References

Top comments (0)