In the previous post I covered how custom slash commands work: markdown files, $ARGUMENTS, frontmatter, namespacing. I promised the devops category as a follow-up. Here it is.

The devops directory has 12 commands. I’m going to focus on the ones that replaced actual documents I used to maintain.

The problem with runbooks

I had runbooks. Confluence pages describing how to deploy, how to check if a deployment went wrong, how to diagnose errors in each app. Some of them were good. Most of them were a few months out of date and I had to mentally patch the diff while following them.

The deploy runbook said “go to the Trigger dashboard and check the deploy status” for a while after I added the MCP integration that lets me do this from the CLI. I kept forgetting to update the document. The document kept lying to me.

Commands don’t have this problem. If I change the tool I use for a check, I update the command file. The command file is what executes. There’s no gap between documentation and behavior.

/deploy

This is the one I use most. Before it existed, deploying Trigger.dev tasks was five separate things I had to do in order, half of them in my head.

The command runs pre-deploy checks in parallel first:

1
2
3
4
5

git status                         # working tree clean?
git log --oneline -5               # what's being deployed?
docker ps | grep trigger           # containers running?
mcp__trigger__list_deploys         # current deployed version
mcp__trigger__list_runs            # recent run status

It presents all of that, then stops and asks me to confirm. The permission hooks enforce this gate automatically, so even if I forget to add a confirmation step, destructive commands still get blocked. Only after I say yes does it SSH to the ARM board and run the actual deploy:

1
2

ssh user@server "cd ~/trigger-deploy && git pull && \
  npx [email protected] deploy --env prod"

Then it waits 30 seconds and runs post-deploy checks: did the new version appear, did the worker register all tasks, are the containers still healthy.

The old runbook was a Confluence page with screenshots that were wrong. This is a 42-line markdown file that does the right thing every time.

/diagnose

This one is more ambitious. It’s a multi-agent pipeline for debugging application errors.

You run /diagnose myapp /var/log/myapp/error.log and it:

  1. Extracts error keywords from the log
  2. Searches Confluence for existing solutions (using a confluence-searcher sub-agent)
  3. If nothing found, launches three agents in parallel: web research, library documentation lookup, codebase search
  4. Feeds everything to an enterprise-app-specialist agent for root cause analysis
  5. Offers to create a Confluence runbook or local markdown file with the findings
  6. Drafts a ticket summary and a short paragraph for the person who reported the issue

That last part saves me the most time. Writing “we identified the root cause as X, applied fix Y, normal service restored” five times a week is exactly the kind of task that benefits from a template. The agent writes it, I read it, I send it.

The command file itself is about 150 lines. It’s more of an orchestration script than a command. But it’s still just a markdown file with numbered steps and tool references.

/trigger-status

A simple status check. Three steps:

1
2
3

docker ps | grep trigger           # container health
mcp__trigger__list_runs            # last 10 runs, pass/fail
mcp__trigger__get_current_worker   # registered tasks

Output is a short table. Containers green or not, run success rate, list of active tasks.

I run this whenever something feels wrong or I want to confirm a fresh deploy registered correctly. Takes about 15 seconds. The old way was opening the Trigger web UI, clicking around to three separate pages, and manually comparing what I expected to see.

/sys-health

Six checks, all parallel:

1
2
3
4
5
6

df -h /                                          # disk
free -h                                          # memory
uptime                                           # load average
docker ps | grep trigger                         # containers
docker ps --filter "health=unhealthy"            # anything broken
ss -tlnp | grep -E ':(80|443|3000|5432|8080)'   # key ports

One compact table as output. Anything above 90% disk or any unhealthy container gets flagged.

This is as simple as commands get. Twenty lines including the heading and usage. I use it as a first step before anything else when something goes wrong.

/app-status

This one is per-application. Each app I support has a profile: name, tech stack, log paths, GitHub label, Confluence space. The command loads the profile for whichever app I pass as an argument and shows:

  • Open GitHub issues with that app’s label
  • Recent Confluence pages in that app’s space (via MCP)
  • Last five diagnosed problems from the local index
  • App profile summary

It’s a quick orientation before starting a debugging session. Instead of opening GitHub, opening Confluence, and checking my notes, it’s /app-status myapp and I have everything in one place.

Client-specific commands

Three commands handle specific clients or environments: one for an AWS account, one for an Azure environment with Kubernetes and MongoDB, one for a production system running on AWS.

These follow the same pattern but with environment-specific context baked in. The Azure one knows about the specific VM names, the firewall rules I need to check, the replica set configuration. I don’t have to remember any of that. The command carries it.

Each of these commands references a client-specific rules file that has things like “always verify UFW status before touching iptables” or “check MongoDB replica set health before restarting any member.” Context that used to live in my head and occasionally got forgotten.

What they replaced

  • A Confluence deploy runbook with outdated screenshots: /deploy
  • A “how to check if something is wrong” mental checklist: /sys-health and /trigger-status
  • A “who handles which app” wiki page I stopped maintaining: /app-status
  • Three client runbook documents, each 2-3 pages: the three client commands
  • The habit of writing incident summaries from scratch every time: /diagnose step 6

The total is about 400 lines of markdown across 12 files. The Confluence pages they replaced were probably 600 lines combined, written once and slowly drifting out of sync.

The difference isn’t the line count. It’s that the commands run. The Confluence pages just sat there.

A pattern that didn’t work

I tried making a single /infra command that would detect context and figure out which environment I was working with. “If there’s a kubernetes config, assume Kubernetes environment. Otherwise check for Docker.”

It was clever and it was unreliable. The detection logic guessed wrong often enough that I had to override it half the time. I split it into the three explicit client commands. More files, less confusion.

The lesson is boring: explicit is better than clever. A command that knows its own context works better than one that tries to infer it.

Next

The Toggl category is eight commands that wrap a time tracking API. Completely different in character from the devops ones. Some of them are so simple they’re almost embarrassing to show.