agentic-process-monitor

Solid

Monitor background processes from Claude Code using sentinel files, heartbeat liveness, and subagent polling. Best practices and.

AI & Automation 73 stars 10 forks Updated yesterday MIT

Install

View on GitHub

Quality Score: 84/100

Stars 20%
62
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Agentic Process Monitor Patterns for monitoring background processes from Claude Code — detecting success, failure, timeout, and hung processes, then returning results to the main context to drive the next action. **Companion skills**: `devops-tools:pueue-job-orchestration` (remote/queued work) | `devops-tools:distributed-job-safety` (concurrency) --- > **Self-Evolving Skill**: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed — fix this file immediately, don't defer. Only update for real, reproducible issues. ## Architecture: Sentinel + Heartbeat + Agent ``` Main Context Monitor Agent (subagent) ───────────── ────────────────────── 1. Start work (Bash run_in_background) └─ work wrapper writes sentinel files 2. Launch Agent (poll every 15s) ────► poll loop: 3. Continue other work .status exists? → return result .heartbeat stale? → kill, return error elapsed > max? → kill, return timeout 4. Agent returns ◄──────────────────── detected outcome 5. Act on result (next step / retry / abort) ``` **Why this architecture**: The main context stays lean (no polling tokens burned). The subagent handles all the waiting. If the subagent itself fails, the main context can recover by checking sentinel files directly. --- ## Sentinel Protocol The work process writes 4 files to ...

Details

Author
terrylica
Repository
terrylica/cc-skills
Created
9 months ago
Last Updated
yesterday
Language
Shell
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

monitor-agent-thread

Monitor a live or recent Claude Code or Codex thread from the other product using local append-only session logs, safe event extraction, Git/worktree evidence, and recurring heartbeats. Use when the user asks to watch, babysit, follow, monitor, check progress on, or notify them about another Claude Code/Codex session, including Claude-to-Codex and Codex-to-Claude monitoring.

0 Updated 4 days ago
BryceEWatson
AI & Automation Listed

monitors

Durable event-triggered watchers: watch a source, detect a change, and fire an agent, a routine, or a notification. The cross-agent layer — agents watching sources (the fleet, other agents) and reacting. Triggers on: 'watch for', 'monitor', 'when X changes run Y', 'notify me when', 'poll until', 'fire an agent on', 'watch the fleet', 'watch CI'.

0 Updated today
phnx-labs
AI & Automation Listed

agent-delivery-canary

This skill should be used when building monitoring for a self-hosted always-on agent (OpenClaw/Olu, Hermes/Chuka, or a future one) that must catch failures the agent itself cannot report — silent non-delivery of a scheduled turn, a wedged or crash-looping gateway, or a fault already broken at baseline. Covers the delivery-canary pattern (agent-owned cron job + an out-of-process root verifier reading the log), the agent/verifier trust split, mutual liveness via tailnet-only health documents each host publishes and its peer watches, and persistent-state escalation that replaces transition-only alerting. Built and verified on both `dfw` (OpenClaw) and `hermes` (Hermes) on 2026-09-04. Trigger phrases include "delivery canary", "agent monitoring", "silent non-delivery", "turn dispatch bug", "canary verifier", "peer watch", "mutual liveness", "agent health endpoint", "tailscale serve health json", "transition-only alerting", "today > 0 && prev == 0", "persistent state escalation", "agent crash loop unnoticed", "who

1 Updated yesterday
jackson2w