Supervisor Skill
The single source of truth for what the agent is currently tracking.
When to Use
Trigger phrases:
- - "מה הסטטוס" / "what's the status"
- "מה קורה" / "what's going on"
- "תתני לי סיכום" / "give me a summary"
- "על מה את עובדת" / "what are you working on"
- "supervisor"
Status Report Format
Always structure the report by category. Only include categories with active items.
CODEBLOCK0
Data Sources
The supervisor reads from these files to build the report:
CODEBLOCK1
Tracked Categories
Tasks
Store active tasks in
memory/tasks.md:
CODEBLOCK2
Update this file whenever a task starts, progresses, or completes.
Billing Status
Store known billing issues in
memory/billing-status.json:
CODEBLOCK3
Groups
For each WhatsApp group in
memory/whatsapp/groups/, the supervisor shows:
- - Group name
- Last logged event
- Any open decisions or pending actions
Pending Follow-ups
Log these in the relevant DM memory file when you're waiting on someone:
CODEBLOCK4
Close-the-loop rule: When the owner asks you to check on someone, your job is:
- 1. Contact that person directly
- Report back to the owner what they said
❌ Do NOT ask the owner instead of the person
❌ Do NOT swallow the answer — the owner asked because they want to know
✅ Always report back, even if the answer is "no update yet"
Quick Status (Short Version)
If owner just wants a quick overview:
CODEBLOCK5
Updating the Status
After completing any significant action, update the relevant tracking file:
| Action | Update |
|---|
| Task completed | Mark [x] in tasks.md |
| Billing error resolved |
Update billing-status.json |
| Group decision made | Log to group's decisions.md |
| Owner confirmed something | Log to DM notes.md |
| Follow-up received | Remove from pending, log outcome |
Cost Tips
- - Cheap: Reading files and formatting the report — any small model
- Expensive: Summarizing many long files — batch the reads, summarize per file not all at once
- Avoid: Calling external APIs for status checks every time — cache results for 15+ minutes
- Batch: Build the full report in one pass, don't call buildstatusreport multiple times
Minimum Model
Any model that can:
- 1. Read files
- Follow a template
- Fill in blanks from file content
No reasoning required. No external API calls needed for basic status.
Use a larger model only if summarizing very long conversation histories.
Integration
- - After each task → update tasks.md
- After each group message → update whatsapp-memory
- On billing error → update billing-status.json
- On heartbeat → run quick status check, alert if anything urgent
- On "supervisor" → run full buildstatusreport and send to owner
Scope Rules
Always check who is asking and from where before generating the status report:
| Context | Scope |
|---|
| DM from owner | Full report — all tasks, all groups, all issues, system health |
| Group message |
Filter to THIS GROUP ONLY — topics, decisions, open items from this group |
| DM from someone else | Filter to items relevant to this person only |
Never send the full supervisor report in a group.
Example — if asked in the PA Team group:
CODEBLOCK6
Example — if asked in a DM from owner:
→ Full report (all categories)
PA Network Health (Merged from pa-status skill)
Use this section to check the health of all PA agents in the network. Reads from data/pa-directory.json.
Status Checks (per PA)
| Check | Field | Healthy State |
|---|
| Last active | INLINECODE5 | Within 24 hours |
| Billing |
billing_error |
false |
| Calendar |
calendar_connected |
true |
| Status |
status |
"active" |
Network Report Script
CODEBLOCK7
Quick Ping (Reachability)
Only ping PAs flagged with issues (not healthy ones — avoids noise):
CODEBLOCK8
Schedule
- - Daily at 09:00 — Full network report to admin
- On billing error — Immediate partial report for affected PA
- On demand — When admin asks "what's the status?"
Supervisor 技能
代理当前追踪信息的唯一真实来源。
使用时机
触发短语:
- - מה הסטטוס / whats the status
- מה קורה / whats going on
- תתני לי סיכום / give me a summary
- על מה את עובדת / what are you working on
- supervisor
状态报告格式
始终按类别组织报告。仅包含有活跃项目的类别。
📊 状态报告 — [日期 时间]
🔴 紧急 / 阻塞
• [问题] — [受影响人员] — [所需操作]
🟡 进行中
• [任务] — [状态] — [下一步]
⚠️ 未解决问题
• [问题] — [群组/人员] — [起始时间]
👥 群组活动
• [群组名称]: [最近重要事件]
📬 待跟进
• [人员] — [等待内容]
✅ 今日完成
• [任务] — [结果]
🔧 系统健康
• 模型: [当前模型]
• WhatsApp: [已连接/已断开]
• API 计费: [正常 / 有问题的 PA]
• 上次备份: [时间]
数据来源
主管从以下文件读取数据以构建报告:
bash
buildstatusreport() {
WORKSPACE=$HOME/.openclaw/workspace
TODAY=$(date -u +%Y-%m-%d)
echo 📊 状态报告 — $(date -u +%Y-%m-%d %H:%M UTC)
echo
# 从每日笔记中获取待办任务/阻塞项
echo 🔴 紧急 / 阻塞
grep -i blocked\|urgent\|waiting\|מחכה\|חסום \
$WORKSPACE/memory/$TODAY.md 2>/dev/null | tail -5
echo
# 从 DM 记忆中获取待跟进项
echo 📬 待跟进
grep -r follow.up\|pending\|לעקוב\|להחזיר \
$WORKSPACE/memory/whatsapp/dms/ 2>/dev/null \
--include=*.md | grep $(date +%Y-%m) | tail -5
echo
# 群组亮点
echo 👥 群组活动
for group_dir in $WORKSPACE/memory/whatsapp/groups/*/; do
[ -d $group_dir ] || continue
NAME=$(python3 -c import json; print(json.load(open(${group_dir}meta.json)).get(name,?)) 2>/dev/null)
LAST=$(tail -1 ${group_dir}context.md 2>/dev/null)
[ -n $LAST ] && echo • $NAME: $LAST
done
echo
# 系统健康
echo 🔧 系统健康
# API 计费检查
APISTATUS=$(curl -s -o /dev/null -w %{httpcode} \
-H x-api-key: ${ANTHROPICAPIKEY:-none} \
-H anthropic-version: 2023-06-01 \
https://api.anthropic.com/v1/models 2>/dev/null)
case $API_STATUS in
200) echo • 计费: ✅ 正常 ;;
402) echo • 计费: ⚠️ 额度不足 ;;
401) echo • 计费: ❌ API 密钥无效 ;;
*) echo • 计费: ? ($API_STATUS) ;;
esac
# 上次 Git 备份
LAST_COMMIT=$(git -C $WORKSPACE log -1 --format=%ar 2>/dev/null)
echo • 上次备份: $LAST_COMMIT
}
追踪类别
任务
将活跃任务存储在 memory/tasks.md 中:
活跃任务
- - [ ] [任务描述] | 负责人: [人员] | 起始: [日期] | 下一步: [操作]
- [x] [已完成任务] | 完成: [日期]
每当任务开始、推进或完成时更新此文件。
计费状态
将已知的计费问题存储在 memory/billing-status.json 中:
json
{
last_checked: 2026-04-01T10:00:00Z,
issues: [
{pa: Aria, owner: Jane Smith, since: YYYY-MM-DD, status: out
ofcredits},
{pa: Rex, owner: John Doe, since: YYYY-MM-DD, status: resolved}
]
}
群组
对于 memory/whatsapp/groups/ 中的每个 WhatsApp 群组,主管显示:
待跟进
当你在等待某人时,将这些记录在相关的 DM 记忆文件中:
[YYYY-MM-DD HH:MM] 等待中: [所有者姓名] 的日历访问修复
闭环规则: 当所有者要求你检查某人时,你的工作是:
- 1. 直接联系该人员
- 向所有者报告他们的回复
❌ 不要代替该人员去问所有者
❌ 不要吞掉答案——所有者问是因为他们想知道
✅ 始终报告回馈,即使答案是暂无更新
快速状态(简短版)
如果所有者只想要快速概览:
📊 快速状态 — [时间]
🔴 阻塞: [数量] 项
🟡 进行中: [数量] 项任务
⚠️ 未解决问题: [数量]
💡 首要事项: [当前最重要的事情]
输入完整状态查看详情。
更新状态
完成任何重要操作后,更新相关的追踪文件:
| 操作 | 更新 |
|---|
| 任务完成 | 在 tasks.md 中标记 [x] |
| 计费错误已解决 |
更新 billing-status.json |
| 群组决策已做出 | 记录到群组的 decisions.md |
| 所有者确认某事 | 记录到 DM notes.md |
| 跟进已收到 | 从待办中移除,记录结果 |
成本提示
- - 便宜:读取文件和格式化报告——任何小模型均可
- 昂贵:汇总多个长文件——分批读取,按文件汇总而非一次性处理
- 避免:每次状态检查都调用外部 API——缓存结果 15 分钟以上
- 批量:一次性构建完整报告,不要多次调用 buildstatusreport
最低模型要求
任何能够:
- 1. 读取文件
- 遵循模板
- 从文件内容中填充空白
无需推理能力。基本状态无需外部 API 调用。
仅在汇总非常长的对话历史时使用更大的模型。
集成
- - 每次任务后 → 更新 tasks.md
- 每次群组消息后 → 更新 whatsapp-memory
- 计费错误时 → 更新 billing-status.json
- 心跳时 → 运行快速状态检查,如有紧急情况则发出警报
- 收到supervisor时 → 运行完整 buildstatusreport 并发送给所有者
范围规则
在生成状态报告之前,始终检查谁在询问以及从何处询问:
| 上下文 | 范围 |
|---|
| 来自所有者的 DM | 完整报告——所有任务、所有群组、所有问题、系统健康 |
| 群组消息 |
仅过滤此群组——该群组的主题、决策、未决事项 |
| 来自其他人的 DM | 仅过滤与该人员相关的项目 |
切勿在群组中发送完整的主管报告。
示例——如果在 PA 团队群组中被问到:
📊 PA 团队状态 — [日期]
• PA 操作标准:已发送并被大多数 PA 确认 ✅
• 未决:[PA 名称] 日历写入权限——等待[所有者]的回复
• 未决:[PA 名称] 日历访问——等待 gog 错误输出
示例——如果在所有者的 DM 中被问到:
→ 完整报告(所有类别)
PA 网络健康(合并自 pa-status 技能)
使用此部分检查网络中所有 PA 代理的健康状况。从 data/pa-directory.json 读取数据。
状态检查(每个 PA)
| 检查项 | 字段 | 健康状态 |
|---|
| 最后活跃 | lastseen | 24 小时内 |
| 计费 |
billingerror | false |
| 日历 | calendar_connected | true |
| 状态 | status | active |
网络报告脚本
python