ClawHub

Subagent Sheepdog

Other

Launch verification and watchdog discipline for delegated, backgrounded, browser-driven, and long-running tasks. Prevents false "running" claims, clarifies failed_to_start vs failed_after_work_started, and treats heartbeat as a watchdog rather than the main progress loop.

Install

openclaw skills install subagent-sheepdog

Subagent Sheepdog

Use this skill whenever work is:

  • delegated to a subagent or child session
  • launched as a background process
  • driven through browser automation
  • long-running enough that progress reporting matters
  • vulnerable to "ghost delegation" (claimed launch, but no real work underway)

Do not use this skill for tiny direct tasks where startup verification would add noise.

Purpose

This skill prevents a common failure mode in agent systems:

an agent launches something, gets back a session/process/tab handle, and falsely reports that work is running even though startup already failed or never truly began.

It enforces clear state transitions, truthful communication, and watchdog-style recovery behavior.

Core Rule

Do not claim work is running until startup is verified.

A session id, process id, browser tab, or tool handle alone is not proof that work actually started.

Treat the period after launch and before verification as:

  • launching_unverified

Only after verification may the task become:

  • running

If startup fails before real execution begins, classify it as:

  • failed_to_start

If work began and failed later, classify it as:

  • failed_after_work_started

Task States

Use these states consistently:

  • launching_unverified
  • running
  • delayed
  • failed_to_start
  • failed_after_work_started
  • completed

State meanings

launching_unverified

Launch was attempted, but startup health is not yet confirmed.

running

Startup was verified and meaningful execution is underway.

delayed

Work is still running, but later than expected.

failed_to_start

The launch path failed before real work began.

failed_after_work_started

Real work began, then later failed.

completed

Task finished successfully with real output or result.

Required Launch Sequence

Whenever this skill applies, follow this sequence:

  1. Announce launch briefly
  2. Attempt launch
  3. Enter launching_unverified
  4. Verify startup health
  5. If verified, mark running
  6. If not verified, mark failed_to_start
  7. Retry only if the fix is obvious and mechanical
  8. Re-verify before claiming success

Verification Rules By Work Type

A. Subagent / child-session launches

Do not claim success unless you verify at least:

  • the spawn call succeeded
  • the child session actually exists
  • the child is active or otherwise accepted
  • the runtime did not reject the launch immediately

Examples of failed_to_start here:

  • invalid spawn parameters
  • unsupported runtime combination
  • missing thread binding
  • rejected session mode
  • missing required agent/runtime field

B. Background exec / process launches

Do not claim success unless you verify at least:

  • the process exists
  • the process did not immediately exit
  • the working directory is valid
  • the executable exists
  • no immediate fatal startup error is present in the initial result/log

Examples of failed_to_start here:

  • command not found
  • no such file or directory
  • permission denied at startup
  • invalid working directory
  • immediate non-zero exit
  • rejected runtime host/sandbox mismatch

C. Browser-driven work

Do not claim browser work is underway unless you verify at least the relevant part of the path:

  • browser/session exists
  • target page actually loaded
  • expected page or UI element is present
  • no login wall, interstitial, or error page blocked progress

Examples of failed_to_start here:

  • browser opened but target page failed to load
  • redirected to login before task could begin
  • error page prevented interaction
  • required UI element never appeared

If the page loaded and meaningful interaction began before failure, use failed_after_work_started instead.

Heartbeat Behavior

Heartbeat is a watchdog, not the main progress loop.

Use heartbeat to:

  • surface overdue tasks
  • detect stalled work
  • detect ghost delegation
  • catch startup failures that were not properly reported

Do not use heartbeat to:

  • aggressively poll every active task
  • replace direct milestone updates
  • substitute for proper launch verification

Ghost delegation

A ghost delegation is when work was described as launched, but:

  • no real worker exists
  • startup failed immediately
  • browser setup never reached a usable page
  • the agent implied progress without verified execution

Heartbeat should surface that clearly instead of returning a normal all-clear.

Communication Rules

Prefer concise truth over reassuring fiction.

Good launch-phase language

  • “Launching now. Verifying startup.”
  • “Launch attempted; checking whether the worker actually started.”
  • “Startup is being verified before I call this running.”

Good failure language

  • “Startup failed. No work started. Cause: {reason}.”
  • “The launch was rejected before execution began. No work started.”
  • “The browser path failed before meaningful interaction began. No work started.”

Good running language

  • “Verified: work is actually running now.”
  • “Startup is confirmed. First milestone ETA ~{time}.”

Good delayed language

  • “Work is still running, but slower than expected.”
  • “The task is active but behind the original ETA.”

Good late failure language

  • “Work did start, but failed later. Cause: {reason}.”

Bad language

  • “Started successfully” before verification
  • “Working on it” when only a handle exists
  • “It’s analyzing now” before startup health is confirmed
  • any ETA that implies verified execution before verification happened

Retry Policy

Retry only when the fix is obvious and mechanical.

Examples:

  • correcting a known launch parameter
  • switching to the proper thread-bound mode
  • fixing a wrong working directory
  • switching to an available executable/runtime

If retrying:

  1. report the original failure
  2. say you are retrying
  3. return to launching_unverified
  4. verify again before claiming success

Do not loop forever.

Best-Next-Step Rule

When blocked, recommend one best next step instead of dumping a large menu unless the user explicitly asks for options.

Good:

  • “Best next step: switch to one-shot run mode because persistent thread binding is unavailable here.”

Less good:

  • giving 4–6 loosely ranked possibilities without guidance

Generic Example

Bad

“Background worker launched and running now.”

(But only a session id exists; no verification was done.)

Good

“Launch attempted; verifying startup.”

Then either:

  • “Verified: the worker is actually running now.”

or:

  • “Startup failed. No work started. Cause: missing thread binding for session mode.”

Browser Example

Bad

“Opened the browser and I’m working on the site now.”

(But the browser only opened a login wall.)

Good

“Browser launched, but the target workflow did not start. The page redirected to login before the task could begin. No work started.”

Completion Standard

A task should only be described as completed when there is evidence of a real result, such as:

  • output artifacts
  • a verified state change
  • a final summary tied to actual work performed

Summary

This skill teaches a simple discipline:

  • launch carefully
  • verify startup
  • report truthfully
  • use heartbeat as backup
  • distinguish failed launch from failed work

The result is better trust, clearer status reporting, and fewer ghost tasks.