monitors

Files (1)

• SKILL.md

SKILL.md (first lines)

# Inspect and cancel MR Guardian monitors

Claude Code starts one monitor per session, but only the one holding the
instance lock actually polls and acts. The others stand by. This skill answers
"which session is doing the work?" and lets the user hand that work to a
different session.

## Listing

With no arguments, or when the user asks which session is monitoring:

```bash
"${CLAUDE_PLUGIN_ROOT}/bin/gitlab-mr-guardian" \
  --plugin-data-dir "${CLAUDE_PLUGIN_DATA}" \
  monitors
```

Render `MONITORS_LISTED` as a small table: PID, version, session id (the first
8 characters are enough), working directory, and role. Mark the entry whose
`is_me` is true as the current session.

Two things deserve a callout when present:

- **`role: "polling"` on an older `version` than the others.** That is why an
  upgraded plugin can keep running old code: the upgrade only takes effect when
  a monitor from the new version holds the lock. Point out that cancelling the
  old one lets a newer session take over.
- **`orphaned: true`.** The Claude session that owned this monitor is gone but
  the process survived. It is safe to cancel.

An empty list means no monitor is registered — background monitoring is either
off (`/gitlab-mr-guardian:start` turns it on) or no session is open.

## Cancelling

Only when the user asks for it. The plugin never stops a monitor on its own.

```bash
"${CLAUDE_PLUGIN_ROOT}/bin/gitlab-mr-guardian" \
  --plugin-data-dir "${CLAUDE_PLUGIN_DATA}" \
  monitors cancel <pid or session id>
```

A session id prefix works as long as it is unambiguous. Before running it, show
the user which monitor will be stopped. After `MONITOR_CANCELLED`, tell them a
standby monitor picks up the lock within about 30 seconds; if none exists, no
polling happens until a session starts one.

The command refuses rather than guesses: an unknown target, an ambiguous
prefix, a process whose identity cannot be verified on this platform, a process
that no longer looks like a guardian monitor, or the current process itself all
produce an error and change nothing. Report the reason as given — these guards
exist because PIDs get recycled and signalling the wrong process is worse than
doing nothing.

`MONITOR_CANCEL_PENDING` means SIGTERM was delivered but the process was still
running after ten seconds, usually because it is finishing a cycle. Suggest
listing again shortly rather than escalating.

From MisterRaindrop/gitlab-mr-guardian, Apache-2.0.

More from MisterRaindrop/gitlab-mr-guardian