本文へ移動
cccskills
無料GitHub で公開

watchdog

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.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md5.8 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.

日本語の概要は準備中です。原文の説明を表示しています。

mvschwarz/openrig6,9412026年10月12日 更新

Use when designing, building, operating, or diagnosing an ongoing application whose live backend or control loop includes OpenRig agents, including applications with a Markdown, YAML, or JSON agent control plane or a thin surface over specialist agent roles.

日本語の概要は準備中です。原文の説明を表示しています。

mvschwarz/openrig6,9412026年10月12日 更新

Use when a bounded real-world procedure has a deterministic happy path but brownfield, variable, or partially knowable state; when an operation must resume from verified evidence; or when deciding whether agent judgment or ordinary code should own a procedure's control loop.

日本語の概要は準備中です。原文の説明を表示しています。

mvschwarz/openrig6,9412026年10月12日 更新

Use when creating, refreshing, packaging, inspecting, promoting, or deprecating a named per-seat starting point — Agent Starter manifest authoring, the 6-state lifecycle (captured → named → inspectable → used → promoted → deprecated), provenance honesty, and refusal rules. NOT a VM image; a managed starting point composed from agent role + startup context + optional native session source + provenance.

日本語の概要は準備中です。原文の説明を表示しています。

mvschwarz/openrig6,9412026年10月12日 更新

Use when designing or auditing how an agent becomes useful after launch — AGENTS.md overlays, role files, skills, rig specs, workflow specs, startup checklists, refocus messages, "rig context" surface. Covers the 4 failure modes that make startup context fail (old rig spec misses current operating mode; current agents never told about new guidance; startup file as dumping ground; orchestrator transmits implementation without preserving product intent).

日本語の概要は準備中です。原文の説明を表示しています。

mvschwarz/openrig6,9412026年10月12日 更新

Use before launching a team during agent-guided setup, or when a user asks to configure OpenRig command permissions, reduce repeated native approval prompts, or apply a selected rig/seat permission policy.

日本語の概要は準備中です。原文の説明を表示しています。

mvschwarz/openrig6,9412026年10月12日 更新

mvschwarz のスキルをすべて見る

このスキルの問題を報告する