git:20260725.7dfa442 to git:20260911.eb3bd31

---

name: wise-supervise

description: >-

Attach a supervisor / watchdog loop to a running team of background agents and

keep them on task — automates the manual "ping all your subagents, are you

still on track?" nudge. Reads the team's members, actively probes each for its

status, nudges any that are idle-but-unfinished or off-goal, and escalates a

worker that stays stuck (TaskStop + surface). When the team's workers write

heartbeats it also arms a background `stale-workers` Monitor to catch ones hung

mid-turn. Invoked as `/wise-supervise` (bare alias) or `/wise:wise-supervise`

(canonical), optionally with a team name. Use when the user says "ping all my

subagents", "are my agents stuck", "supervise the team", "watch the agents",

"nudge the stuck workers", "check my subagents are on track", or types

`/wise-supervise`.

argument-hint: "[team-name]"

allowed-tools: Read, Bash(python3:*), SendMessage, Monitor, TaskList, TaskGet, TaskOutput, TaskStop

---

# /wise-supervise — keep a running team of agents on task

## Why this skill exists

Background teammates **go idle after every turn** and then wait forever unless

someone messages them. So a workflow or ad-hoc team can stall not because a

worker failed but because nobody told it what to do next — and today the only

fix is the user typing "ping all your subagents, verify they're on track." This

skill is that nudge, automated and repeatable: it probes the team, prods the

stuck members, and escalates the ones that stay stuck.

It runs the shared supervisor routine in

`${CLAUDE_PLUGIN_ROOT}/references/supervise-loop.md` — read that first; this

skill is the standalone, attach-to-any-team entry point for it. The workflow

engine runs the same routine automatically for `type: supervised-prompt` steps.

## Invocation

```

/wise-supervise # supervise the single active team (or ask which)

/wise-supervise ticket-pr-run # supervise a named team

/wise:wise-supervise <team> # canonical namespaced form

```

The positional, if present, is the team name. Anything else is ignored prose.

## Procedure

### 1. Resolve the team

If a team name was given, use it. Otherwise read which teams exist and pick the

single active one; if there is more than one, ask the user which to supervise

(this is the one allowed prompt — the rest of the loop is decision-free unless a

worker needs a human call). Read the team's members from its config:

```

Read ~/.claude/teams/<team-name>/config.json

```

The `members[]` array gives each teammate's `name` (always address members by

name) and `agentType`. The team-lead entry is you / the conductor — supervise

the worker members, not yourself.

### 2. Pick the detection mode

`run.dir` (and thus a `workers/` heartbeat dir) is only known when a workflow

run hands it to you — e.g. the conductor invoking the loop for a

`supervised-prompt` step. A **standalone** `/wise-supervise <team>` typed by the

user has no run context, so it has no `run.dir` and falls through to the legacy

path. Concretely:

- **Heartbeat-aware** — `run.dir` is known AND a `workers/` heartbeat dir exists

under it (a team spawned under the `supervised-prompt` contract): arm the

supervisor Monitor per `supervise-loop.md §3` so workers hung mid-turn surface

on their own, AND active-probe (below).

- **Legacy / ad-hoc team** (the standalone default, e.g. `ticket-pr-run` with

`engineer-1/2/3`, spawned before the heartbeat contract): no `run.dir` / no

heartbeat files, so out-of-band hung detection isn't available — use **active

probing** as the primary mechanism.

### 3. Active-probe round

`TaskList` to see each member's current task + status. Then `SendMessage` every

member that is not `completed` a status-check (the template in

`supervise-loop.md §6`): ask for ONE line — `PROGRESS:` / `BLOCKED:` / `DONE:` —

and tell them to continue. Their replies arrive automatically as turns.

Classify each reply against the member's task goal (`TaskGet`):

- on track / `PROGRESS:` / `DONE:` → leave it; reset its nudge count.

- idle with no reply, or `in_progress` with no progress → it's the

idle-and-forgotten case: re-nudge with the next concrete instruction.

- `BLOCKED:` → surface the blocker; resolve it or escalate to the user.

- off-goal (doing something other than its task) → redirect with a corrective

message naming the actual task.

### 4. Escalate the persistently stuck

Walk the ladder in `supervise-loop.md §7`, tracking a per-worker nudge count:

status-check → directive re-nudge → `TaskStop` and surface to the user.

(Respawn-on-fail belongs to the workflow path, which still holds the worker

spec; for an attached ad-hoc team, stop the hung worker and report it so the

user — or the owning run — can re-dispatch.)

### 5. Loop until settled

Repeat probe → classify → nudge/escalate until every member's task is

`completed` or `failed`, the user stops the supervision, or no member has made

progress across two full rounds (the no-progress safety catch — stop and report

rather than nudge forever). Then `TaskStop` any Monitor you armed and give the

final summary.

### 6. Final line

```

SUPERVISE: team=<name> members=<m> nudged=<n> stuck=<s> done=<d>

```

## Guardrails

- Read-and-nudge only — never do a worker's task yourself, never edit files or

run git on their behalf. You coordinate; they work.

- One Monitor at most, and always `TaskStop` it before exiting — a leaked

Monitor keeps polling a finished team.

- The first nudge is a question, not a kill. Never `TaskStop` a worker on its

first quiet round — it may be inside one long legitimate tool call.

- Do not `SendMessage {type: shutdown_request}` unless the user asks to shut the

team down — supervising a team is not the same as ending it.

- Never invoke another wise action skill. Never shell out to `claude -p` or any

external agent CLI.