Token导航 LogoToken导航TokenDH.com
前端设计执行命令github未标认证来源可访问许可证需确认审计通过

agentic-process-monitorAgent 过程监视器

Agent Skill

agentic-process-monitor 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

774

周安装

31

GitHub Stars

37

下载量

250
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:agentic-process-monitor(Agent 过程监视器)
来源仓库:https://github.com/terrylica/cc-skills
仓库路径:skills/agentic-process-monitor
安装命令:
npx skills add https://github.com/terrylica/cc-skills --skill agentic-process-monitor
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/terrylica/cc-skills --skill agentic-process-monitor

简介

用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息。

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中围绕仓库状态、代码变更或协作事项进行整理。
  • 提供后台进程监控模式,可检测成功、失败、超时或挂起任务。
  • 安装命令:npx skills add https://github.com/terrylica/cc-skills --skill agentic-process-monitor。
  • 注意权限范围、维护状态,避免触发联网、命令执行或文件读写。

SKILL.md

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 a known directory (e.g., /tmp/<project>-monitor/):

FileWhen WrittenPurpose
<step>.pidOn startPID for timeout kill
<step>.heartbeatEvery N seconds during workmtime freshness = alive proof
<step>.statusOn exit (SUCCESS / FAILED)Completion sentinel
<step>.resultOn successStructured output (JSON)

Work Wrapper Template

#!/usr/bin/env bash
set -uo pipefail
STEP="${1:?step name required}"
MONITOR_DIR="${2:-/tmp/monitor}"
mkdir -p "$MONITOR_DIR"

echo $$ > "${MONITOR_DIR}/${STEP}.pid"

# Heartbeat: touch file every 10s in background
(while true; do touch "${MONITOR_DIR}/${STEP}.heartbeat"; sleep 10; done) &
HB_PID=$!
trap "kill $HB_PID 2>/dev/null" EXIT

# === YOUR WORK HERE ===
if your_command --args 2>"${MONITOR_DIR}/${STEP}.log"; then
    echo "SUCCESS" > "${MONITOR_DIR}/${STEP}.status"
    echo '{"key": "value"}' > "${MONITOR_DIR}/${STEP}.result"
else
    echo "FAILED" > "${MONITOR_DIR}/${STEP}.status"
fi

Monitor Decision Tree

The polling agent checks every POLL_INTERVAL seconds (default: 15s):

every POLL_INTERVAL:
  .status exists?
    → read status + result, return to main context
  .heartbeat exists AND mtime stale (> STALE_THRESHOLD)?
    → process hung — kill PID, return "hung" error
  elapsed > MAX_TIMEOUT?
    → timeout — kill PID, return "timeout" error
  otherwise
    → sleep POLL_INTERVAL, continue

Recommended Defaults

ParameterDefaultRationale
POLL_INTERVAL15sBalances latency vs token cost
HEARTBEAT_INTERVAL10sMust be < STALE_THRESHOLD / 2
STALE_THRESHOLD60s6x heartbeat interval = generous slack
MAX_TIMEOUT1800s (30min)Catch infrastructure failures

Circuit Breaker

Prevent repeated failures from wasting compute. Three consecutive crashes or failures → stop and report. Reset counter on any success.

consecutive_failures = 0
MAX_CONSECUTIVE = 3

on failure:
  consecutive_failures += 1
  if consecutive_failures >= MAX_CONSECUTIVE:
    STOP — likely infrastructure, not the work itself

on success:
  consecutive_failures = 0

Agent Self-Healing

If the monitoring subagent fails (context overflow, timeout, crash), the main context recovers:

  1. Check .status file directly — work may have finished while agent was dead
  2. If .status exists → read result, continue normally
  3. If no .status but .heartbeat is fresh → spawn replacement monitor agent
  4. If no .status and .heartbeat is stale → process hung, kill PID, log error

This guarantees the main context never gets permanently stuck.


Anti-Patterns

Anti-PatternWhy It FailsUse Instead
`tail -f \grep -m1`Broken on macOS — pipe buffering prevents grep exit from killing tail, causing permanent hangPoll the log file for markers with grep in a loop
run_in_background aloneTask IDs can expire or become unretrievable; stuck-as-running bug; no intermediate progressSentinel files + agent polling
Poll from main contextEach poll injects output into the context window, burning ~50K tokens per checkDelegate polling to a subagent
Hardcoded sleep timeoutWastes time on fast completions, too short for slow onesPoll interval + max timeout
PID-only liveness checkCannot distinguish a hung process (PID alive, no progress) from a running oneHeartbeat file mtime — hung process stops touching the file
uv run masking stale venvuv run has its own resolution that bypasses broken venv state; console scripts (pytest, ruff) have stale shebangs after repo renameRun uv sync --python 3.13 --extra dev after any repo rename or move

Environment Preflight

Run before entering any autonomous loop. If any check fails, fix before proceeding.

# 1. Python package importable?
uv run --python 3.13 python -c "import your_package" \
  || uv sync --python 3.13 --extra dev

# 2. Console scripts have valid shebangs? (catches post-rename breakage)
uv run --python 3.13 pytest --co -q tests/ 2>/dev/null \
  || uv sync --python 3.13 --extra dev

# 3. External service reachable?
curl -sf "http://localhost:PORT/?query=SELECT+1" \
  || echo "FAIL: start service or SSH tunnel"

Common uv/venv Failures

SymptomRoot CauseFix
ModuleNotFoundError but uv run python -c "import..." worksStale venv — console script shebangs point to old repo pathuv sync --python 3.13 --extra dev
bad interpreter:...old-path/.venv/bin/python3Same — .venv/bin/pytest shebang hardcoded pre-rename directoryuv sync --python 3.13 --extra dev
pip show says not found, uv run says installeduv run resolution bypasses venv pip metadatauv sync reconciles both

Rule: After any repo rename, directory move, or Python version change → always uv sync --python 3.13 --extra dev before running anything.

Post-Execution Reflection

After this skill completes, check before closing:

  1. Did the command succeed? — If not, fix the instruction or error table that caused the failure.
  2. Did parameters or output change? — If the underlying tool's interface drifted, update Usage examples and Parameters table to match.
  3. Was a workaround needed? — If you had to improvise (different flags, extra steps), update this SKILL.md so the next invocation doesn't need the same workaround.

Only update if the issue is real and reproducible — not speculative.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

35.1%
按下载量换算88

Claude

28.84%
按下载量换算72

Cursor

17.46%
按下载量换算44

Gemini CLI

8.72%
按下载量换算22

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

执行命令

安装流程涉及命令执行,可能通过 npx skills add https://github.com/terrylica/cc-skills --skill agentic-process-monitor 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills