Skip to content
cccskills
FreePublished on GitHub

watchdog

Design OpenRig watchdog policies for stalled or drifting agent work. Choose a small wake-up message, a refocus, or a broader alignment check, and separate monitoring frequency from notification frequency using evidence about owners and artifacts.

OriginalShow the original description

Use when configuring `rig watchdog` policies, authoring wake/refocus/alignment-checkpoint messages, or choosing the right intervention level for a stale-owner situation. The 3-level continuity-check stack (wake / refocus / alignment-checkpoint), the discipline that prevents cadence pollution and bureaucracy theater, and the artifact-pool loop-edge pattern for evidence-aware waking.

See how to install

Good for

  • Choosing an intervention for an inactive task owner
  • Drafting messages that correct workflow drift
  • Separating monitoring and notification intervals
  • Waking downstream agents when artifacts are ready

Files included (1)

  • SKILL.md5.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Watchdog

Continuity checks are timed or evidence-triggered interventions that keep an agent workflow from going idle, drifting, or entering needless bureaucracy. They operationalize the refocus doctrine.

Use this when

  • Authoring a watchdog policy for a long-running rig (artifact-pool edges, stale-owner detection, periodic reminders).
  • Choosing the intervention level for a stale-owner situation: is this a wake, a refocus, or an alignment checkpoint?
  • Drafting wake/refocus/alignment-checkpoint message text that prevents cadence pollution and bureaucracy theater.
  • Deciding cadence — scan vs wake intervals, conservative vs aggressive nudging.

Don't use this when

  • The agent is actively working and closing artifacts. Prefer no-op.
  • The intervention is masking bad startup or workflow design — fix the underlying cause, don't compensate via watchdog.
  • The work has a clear next-action handoff already in queue. Use queue nudges instead of a watchdog policy.

The 3-level intervention stack

LevelGoalWhenWhat it does
WakeRestart motionOwner appears idle, stale, blocked, or missing a next handoffSmall liveness nudge — does NOT reframe the work
RefocusCorrect driftOutput shows mode drift, approval regression, weak stop-condition reasoningMedium alignment nudge — re-centers on role, north star, current approved workstream, coordination mode, stop conditions; does NOT interrupt valid work
Alignment checkpointRebuild shared mapPhase boundary, lifecycle mutation, product-intent decision, confusing contradictionLarger deliberate pause — agent runs full refocus before proceeding

cron, timers, and rig watchdog are scheduling substrates. They should NOT imply that every tick means the same semantic action. The intervention level is chosen by evidence, not cadence.

Current best practice for refocus message text

A well-shaped refocus message:

  • Starts with: finish current action first.
  • Names the intervention kind: wake, refocus, or alignment checkpoint.
  • Names the current approved workstream or says none is known.
  • Says what continuity means: continue, verify, hand off, or explicitly park.
  • Names stop conditions: scope/risk/posture changes, failed gate, contradictory evidence, or no continuity chain naming a sensible next step.
  • Does NOT convert itself into a fresh approval gate.
  • Does NOT wake delivery seats unless an approved workflow exists and the owner is stale.

Failure modes (7; verbatim)

  1. Cadence is too frequent and pollutes the workstream.
  2. Watchdog wakes the wrong seat instead of the stale owner.
  3. Refocus text is too rule-shaped and creates brittle behavior.
  4. Watchdog compensates for bad startup or workflow design instead of revealing it.
  5. Refocus is misread as a new top-priority task and interrupts the current action.
  6. Refocus becomes bureaucracy theater: an already-approved workflow stops for re-approval.
  7. Repeated static nudges teach agents to answer the reminder instead of progressing the artifact.

Artifact-pool loop edges (the first evidence-aware pattern)

The first evidence-aware watchdog use that should remain small and explicit:

  • Consumer-pool wake: if a ready artifact exists, wake the consumer loop head.
  • Producer-edge repair: if upstream completion exists but the downstream artifact is missing, wake the producer loop head.

Scan cadence and wake cadence are separate. Worked example (the numbers are illustrative; the scan-vs-wake separation is the durable rule): scan every 30 seconds, wake at most every 600 seconds while work remains actionable.

This is not a generic workflow engine. It's a guardrail against cold pools and missing edge artifacts.

Active surface

Daemon rig watchdog is the active host coordination surface for new work. History records only loud evaluations (sent / terminal); quiet skip reasons are NOT recorded — POC parity so agents are not woken about scheduler polls.

Future shape (current limit)

The mature primitive should be evidence-aware: inspect durable queue/workflow state, pane activity, transcript/context growth, and known workstream frontier; classify the intervention as no-op / wake / refocus / alignment-checkpoint; prefer no-op for active owners; render message text from the active orientation graph instead of hard-coding static policy.

Until queue substrate, activity state, and lifecycle evidence are fully productized at this level of granularity: keep config-layer use small and explicit, prefer one workflow watchdog plus targeted exception handling over many per-seat nag loops.

See also

  • refocus skill — the doctrine this primitive operationalizes; full and light trace templates
  • queue-handoff skill — durable handoff via queue items; watchdog is complementary (watchdog wakes; queue routes)
  • looping-workflows skill — operating discipline for self-driving rig-shaped loops; uses watchdog policies for loop edges

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

agent-browser

FreeSummary

Automate website interactions through a command-line browser tool. Navigate pages, fill forms, extract text, save screenshots or PDFs, reuse login sessions, and compare page states to check the effects of actions or website changes.

  • Automating form entry and submission
  • Extracting page text and saving screenshots
  • Comparing page appearance before and after changes
mvschwarz/openrig7.8KUpdated Oct 19, 2026

Design and maintain applications where OpenRig agents help run the system. Organize instructions, shared state, and artifact checks, then trace unexpected behavior to the code, skill, or schema that needs repair.

  • Designing an application operated by OpenRig agents
  • Organizing instructions and shared application state
  • Tracing unexpected behavior to its source
mvschwarz/openrig7.8KUpdated Oct 19, 2026

Design and run bounded procedures in environments where current conditions are uncertain. The skill separates agent judgment from precise tool actions, verifies each effect, and records checkpoints so interrupted work can resume from observed evidence.

  • Designing procedures for environments with varying conditions
  • Resuming interrupted operations from verified evidence
  • Deciding whether an agent or ordinary code should control a procedure
mvschwarz/openrig7.8KUpdated Oct 19, 2026

agent-starters

FreeSummary

Create reusable starting configurations that combine an agent’s role, startup context, and source history. The skill guides registry entries, checks whether their sources are current, and manages their progression from initial capture to recommendation or retirement.

  • Create reusable startup context for an agent role
  • Refresh an agent workspace from an existing starter
  • Check a starter’s source history and freshness
mvschwarz/openrig7.8KUpdated Oct 19, 2026

Guides the design and review of agent startup context, including role files and links to authoritative records. It helps identify stale guidance, missing updates, overloaded startup files, and instructions that lose the purpose of the work.

  • Designing startup files for a new agent
  • Reviewing stale guidance used by running agents
  • Separating role information from reusable procedures
mvschwarz/openrig7.8KUpdated Oct 19, 2026

Configure selected OpenRig command permissions in Claude Code or Codex at the agreed project or user scope. Preserve existing restrictions, verify that settings load and behave as intended, and record additions so they can be removed later.

  • Configuring command permissions before launching an agent team
  • Reducing repeated approvals for selected rig commands
  • Adding permission rules within a chosen project scope
mvschwarz/openrig7.8KUpdated Oct 19, 2026

See all skills by mvschwarz

Report a problem with this skill