Agent Supervision

Supervise another OpenClaw agent with fixed-interval check-ins or ETA-based follow-up. Use when a user asks to督促/监督/催 another agent, schedule recurring progr...

Security Scan

The skill's declared purpose (automated supervision of another agent) matches its instructions and requirements; it asks for a target session identifier and recommends cron-driven use of sessions_send/sessions_history, with no unrelated privileges or installs.

Purpose & Capability

The name/description align with the runtime instructions. The skill legitimately needs a target sessionKey and access to session messaging/history; it does not request unrelated binaries, cloud credentials, or filesystem paths.

Instruction Scope

SKILL.md limits activity to reading recent target messages, classifying progress, sending short supervision messages, and verifying delivery on send timeouts. It does not instruct reading arbitrary files, environment variables, or contacting external endpoints outside the platform's session APIs.

Install Mechanism

Instruction-only skill with no install spec and no code files — nothing is written to disk or downloaded during install.

Credentials

No environment variables or external credentials are requested. The single sensitive input is the target sessionKey (a session identifier), which is appropriate for the purpose but should be treated as a secret since it grants access to another agent's conversation.

Persistence & Privilege

always:false and model invocation allowed (normal). The skill explicitly recommends creating persistent cron jobs (an expected design for supervision). Users should be aware that crons/autonomous supervision will run without ongoing interactive approval and should limit tools and lifetime of such jobs.

Assessment

This skill appears coherent and limited to supervising another agent via session messaging. Before installing or enabling it: 1) Confirm the exact target sessionKey and ensure it points to the intended agent (not a user-facing chat or sensitive channel). 2) Limit allowed tools to only sessions_send and sessions_history as recommended. 3) Use isolated bridge + delivery.mode=none to prevent supervision chatter from leaking into user-facing conversations. 4) Be cautious when creating cron jobs — set explicit TTLs, audit logs, and revoke capability if behavior is unexpected. 5) Treat the sessionKey as a sensitive credential and rotate/revoke access if needed. If you need the skill to access anything beyond session messages (files, external APIs, creds), do not enable it until those requests are explicitly documented and justified.

Run lightweight, evidence-first supervision for another OpenClaw agent.

Prefer short fixed-format messages, low token usage, and minimal tools. Use this skill to keep another agent moving without turning supervision into a long debate.

Quick start

Before wiring any automation, confirm four things:

1. target sessionKey
2. supervision mode: fixed interval or ETA
3. definition of progress
4. escalation threshold

If any of these is missing, ask first.

Required inputs

Collect these before creating supervision:

1. Target session key

   • Usually the other agent's direct session key, for example: agent:boss:feishu:boss:direct:ou_xxx
   • This is the primary identifier needed to read and send messages.

2. Supervision mode

   • every: fixed interval, such as every 10 minutes.
   • eta: let the target report goal + ETA + deliverable, then check at ETA.
   • Hybrid is allowed: fixed interval cron running ETA-aware logic.

3. Progress standard

   • Decide what counts as progress:
     • new deliverable
     • new file/disk evidence
     • new online evidence
     • version increment only
     • blocker changed

4. Escalation rule

   • Example: after 3 stagnant checks, require either new evidence or a blocker list.

5. Delivery policy

   • Prefer isolated bridge cron + delivery.mode=none.
   • Do not assume sessions_send timeout means failure.

What this skill is good for

Use it for:

• recurring progress nudges every N minutes
• ETA-based follow-up where the target must commit to goal + ETA + deliverable
• stagnation detection and escalation
• supervision that must stay out of the user-facing chat
• cross-session messaging where synchronous send timeouts are not a reliable delivery signal

Do not use it when the user only wants a one-off reminder or a human management policy memo with no automation.

Recommended architecture

Use this pattern by default:

• Create a cron job owned by the supervising agent.
• Set sessionTarget=isolated.
• Set delivery.mode=none.
• Allow only the minimum tools needed:
  • sessions_send
  • sessions_history
• Keep prompts short.
• Keep thinking=off and lightContext=true when available.

Why:

• isolated bridge avoids mixing the supervision loop into the live user chat
• no-deliver prevents cron chatter from leaking to the user
• limited tools reduce token and latency cost

Supervision workflow

1. Read recent target messages

Read only the last 5-8 messages unless the user explicitly wants deeper review.

Look for:

• current task/goal
• ETA promise
• promised deliverable
• new evidence since last check
• repeated explanations without new output

2. Judge status with short codes

Prefer compact states:

• A = plan acknowledged, ETA not due yet
• P = strong progress; new deliverable or new evidence
• W = weak progress; version changed but no meaningful deliverable
• R1/R2/R3 = repeated stagnation
• E4 = forced escalation; next reply must contain evidence or blocker list

Do not reward narrative updates without evidence.

3. Send a short supervision message

Examples:

• [监督] 20:00 | A | 已收计划 | 到点再检查
• [监督] 20:10 | P | 有新增交付 | 继续推进主线
• [监督] 20:10 | W | 仅升版 | 需补有效交付
• [监督] 20:10 | R1 | 无新增交付 | 同卡点
• [监督] 20:20 | E4 | 连续停滞4 | 下一条必须给新增交付或明确阻塞清单

4. Verify delivery on send timeout

If sessions_send returns timeout, do not conclude failure immediately.

Instead:

1. read the target session again
2. inspect the last 3 messages
3. if the supervision text appears, treat delivery as successful

This matters because cross-session sends may time out synchronously while the message still lands.

ETA mode rules

Use ETA mode when the user wants less noisy supervision.

Default rules:

• default ETA window: 10 minutes
• maximum ETA window: 20 minutes
• if the target claims 20 minutes, require a reason
• before ETA: do not pressure, optionally send only A
• at ETA: require either
  • a result with evidence, or
  • a blocker list

Reject vague replies like:

• still pushing
• almost done
• give me more time

unless they also include a concrete blocker and next check promise.

Fixed-interval mode rules

Use fixed interval mode when the user wants hard periodic nudges.

Recommended defaults:

• every 10 minutes
• read target recent 5-8 messages only
• emit one short code message
• avoid long repeated explanations
• if the conclusion did not change, either suppress the repeat or keep it one line

What the skill needs from the user

At minimum, ask for:

• the target sessionKey
• the frequency or ETA policy
• the definition of progress
• the escalation threshold

Without the session key, the skill cannot reliably supervise the other agent.

Minimal cron template

Use an isolated cron with payload like this shape:

{
  "kind": "agentTurn",
  "message": "Read recent target messages, classify A/P/W/R/E4, send one short supervision line, and verify delivery only if send times out.",
  "timeoutSeconds": 120,
  "toolsAllow": ["sessions_send", "sessions_history"],
  "thinking": "off",
  "lightContext": true
}

Operational defaults:

• job timeout: at least 120s, preferably 180s if the prompt contains ETA logic
• payload timeoutSeconds: 60-120s depending on complexity
• do not overstuff the prompt with policy prose

Example user requests

Typical requests that should trigger this skill:

• "每 10 分钟监督另一个 agent 的进展"
• "让他先报 ETA，到点只收结果或阻塞"
• "连续 3 次无进展就升级催办"
• "帮我搭一个 bridge cron 去盯 boss 会话"
• "监督另一个 agent，但不要把噪音发回用户主会话"

Guardrails

• Do not confuse “not finished” with “not working”; check for new evidence.
• Do not force high-cost acceptance actions by default, such as real-person browser validation or screenshots, unless the user explicitly wants them.
• Do not turn supervision into a debate about supervision.
• Push the target back to: current goal, ETA, deliverable, blocker.
• Report facts to the user with evidence, not vibes.

When reporting back to the user

Use this shape:

• task name
• conclusion: success / failure / partial success / no change
• up to 3 evidence bullets
• up to 2 risks
• next step

Keep it short and verifiable.

Public-release notes

For public distribution, keep the positioning generic:

• say another OpenClaw agent, not private agent names
• refer to target sessionKey, not hard-coded personal sessions
• describe reusable patterns, not one-off project history
• avoid embedding private escalation language tied to a specific team

Ship examples, defaults, and guardrails; leave project-specific policy to the caller.