openclawbb/openclaw-subagent-supervisor

OpenClaw Subagent Supervisor

Use this skill to run evidence-driven supervision over OpenClaw subagents.

The goal is not to let a worker free-run and repeat its claims. The goal is to:

• define the task cleanly
• inspect real progress
• catch empty planning and fake completion
• force concrete delivery
• accept only verified results
• report only checked facts to the user

Core rule

Do not trust status words like “done”, “fixed”, or “blocked”. Trust evidence.

For subagent work, evidence usually means:

• files changed
• commands run
• tool traces
• test/build/runtime results
• explicit remaining gaps

When to use it

Use this skill when the task is:

• complex and multi-step
• likely to drift into planning instead of execution
• important enough to require acceptance, rework, or independent review
• better split into supervisor + worker rather than handled directly in the main session

Do not use it for:

• tiny direct fixes
• simple reading or Q&A
• tasks the main session can finish faster than supervising

Supervisor workflow

1. Define the job before spawning

Before calling sessions_spawn, make the task concrete:

• objective
• expected deliverables
• verification method
• completion bar
• constraints/boundaries
• required final report format

Good worker prompts usually include:

• current context
• numbered tasks
• limits on scope
• required verification
• exact final report shape

2. Spawn the worker

Use sessions_spawn for the implementation run.

For strong prompts, prefer instructions like:

• audit current state
• find one meaningful remaining gap
• implement the smallest coherent fix
• add or adjust focused tests
• run verification
• end with files changed, commands/results, and remaining gaps

3. Run a 2-minute first inspection

Use sessions_history(includeTools=true).

Check whether the worker has started doing real work:

• read files
• inspect code
• run commands
• identify a concrete change path

Warning signs:

• only restating the task
• long planning with no tool use
• broad redesign talk without narrowing scope

If it is drifting, steer immediately.

4. Run a 5-minute progress gate

Check again with sessions_history(includeTools=true).

Look for:

• real edits or concrete implementation
• verification in progress or planned precisely
• a specific blocker with clear local context

At this gate:

• if it is moving, let it continue
• if it is fuzzy, use sessions_send or subagents(action=steer) to tighten the task
• if it is obviously spinning, kill and respawn with a sharper prompt

Do not poll constantly. Inspect at meaningful gates.

5. Treat blockers as testable claims

When a worker says it is blocked, force clarity:

• what exact step is blocked?
• what has already been verified?
• is the issue missing info, permissions, environment, or approach?
• what is the next smallest action?

If it cannot answer clearly, the problem is usually drift, not a real blocker.

6. Accept work with four-evidence review

Do not accept completion without all four categories.

Evidence 1: change evidence

• which files changed
• what changed in each

Evidence 2: execution evidence

• which commands ran
• what the results were

Evidence 3: outcome evidence

• tests/builds passed
• endpoint/UI/runtime behavior changed as intended

Evidence 4: boundary evidence

• what remains undone
• what risks or uncovered edges still exist

If one category is missing, the task is not accepted yet.

7. Add a critic when confidence matters

Spawn a critic or second pass when:

• impact is large
• release readiness matters
• security/stability is involved
• the worker moved fast but trust is not high enough
• you suspect hidden gaps despite a plausible report

The critic should review, not re-implement.

Default tool mapping

• sessions_spawn → assign implementation
• sessions_history(includeTools=true) → inspect evidence
• sessions_send → light correction
• subagents(action=steer) → strong correction
• subagents(action=kill) → stop loss
• sessions_list → only when you need to locate or debug a run; do not loop on it

Reporting rule

When replying to the user, report only facts you have checked:

• verified gap
• verified fix
• verified files changed
• verified commands/results
• verified remaining risks

Do not forward worker self-assessment as truth.

Read the SOP and templates when needed

• Read references/supervisor-sop.md when you need the full operational checklist.
• Read references/templates.md when you need copy-ready worker, critic, rework, or user-report prompts.
• Read references/quick-reference.md when you only need the compact flow.

One-line operating principle

Spawn work. Inspect evidence. Steer drift. Kill waste. Accept on proof.