GitHub Monitor

Monitor one or more GitHub repositories and send low-noise alerts with configurable policy modes (major_only, balanced, verbose). Use when setting up recurri...

Security Scan

The skill's instructions generally match a GitHub monitor, but there are missing operational details (GitHub auth, notification delivery, and state-file location) that make the runtime requirements unclear and potentially inconsistent with the claimed purpose.

Purpose & Capability

The name/description claim GitHub repo monitoring and the SKILL.md describes exactly that (releases, recent commits, merged PRs, severity policies). However, the doc omits discussion of GitHub authentication (GITHUB_TOKEN) for private repos or higher rate limits and does not specify how notifications are delivered—yet it references external channels (telegram/slack/feishu/discord). For public repo, unauthenticated API usage is feasible but limited; for private repos or robust operation, an auth token would be required.

Instruction Scope

Instructions are focused on scanning GitHub public APIs, maintaining a local state file, deduping, and sending alerts/digests. They do not instruct the agent to read unrelated files or secrets. Concern: the SKILL.md assumes the existence of a notification delivery mechanism (notify_target, channel ids) but gives no instructions or env variables for how to authenticate to those messaging services—this is an operational gap that grants broad discretion to the platform or integrator.

Install Mechanism

There is no install spec and no code files—this is instruction-only, so nothing will be downloaded or written by an installer. Lowest install risk.

Credentials

The skill declares no required env vars or primary credential. This is consistent for lightweight public-repo monitoring, but inconsistent with its notification and private-repo use cases. The SKILL.md implies access to external messaging channels and potentially private GitHub data, yet does not request any credentials (GITHUB_TOKEN, SLACK_WEBHOOK, TELEGRAM_TOKEN, etc.). That mismatch is a gap that should be clarified before use.

Persistence & Privilege

always:false and autonomous invocation allowed (normal). The skill requires persisting a state file (example path: /root/.openclaw/workspace/memory/repo-watch/multi-repos.json). Persisting state is expected, but the example absolute path under /root may not be appropriate for all runtimes and could indicate assumptions about filesystem layout/permissions—confirm the intended writable location and access controls.

What to consider before installing

This skill is an instruction-only GitHub monitor and mostly coherent for monitoring public repositories, but you should confirm a few things before installing: - Authentication: If you need private-repo monitoring or to avoid GitHub rate limits, provide a GITHUB_TOKEN; the SKILL.md does not request one but will need it. Clarify whether OpenClaw supplies GitHub credentials or the skill expects you to set them. - Notifications: The doc mentions telegram/slack/feishu/discord and a notify_target id, but it doesn't specify how to authenticate/send messages. Determine which notification mechanism your OpenClaw instance will use and whether you must supply webhook tokens or channel credentials. - State file location and permissions: The example path is under /root. Ensure the runtime has permission to read/write that path, or choose a safer, writable path scoped to the agent. Consider encrypting or restricting access to the state file if it will contain sensitive metadata. - Rate limiting & retries: Unauthenticated GitHub API calls are heavily rate-limited; for reliable operation configure auth and verify retry/backoff behavior in your execution environment. - Testing: Run with a small repo list and verbose logging first to confirm notification wiring and dedup behavior; verify the first-run rule (do not backfill historical events) is implemented correctly. If you cannot confirm where notifications will be sent or how authentication is provided, treat the skill as incomplete and do not enable it for private repositories or sensitive channels.

Build one-cron multi-repo monitoring with deduplication, severity routing, and low-noise notifications.

Quick setup

Collect:

• repos: list of owner/repo
• policy_mode: major_only | balanced | verbose
• check_interval: recommended 2h
• timezone: e.g. America/New_York
• daily_digest_time: e.g. 21:00
• notify_target: user/channel id
• state_file: e.g. /root/.openclaw/workspace/memory/repo-watch/multi-repos.json

Use one isolated cron job to monitor all repos.

Data sources per repo

Check with GitHub public APIs each run:

1. Latest release
2. Recent commits (last 50, filtered by run window)
3. Recently merged PRs (filtered by run window)

Policy modes

1) major_only

• Notify only P0 events
• Skip P1/P2 notifications

P0 signals:

• New release
• PR keyword hit: breaking|migration|security|auth

2) balanced (default)

• P0/P1 immediate notify
• P2 daily digest

P1 keyword examples:

• gateway|config schema|tooling|memory|cron|session|channel|provider|search|index|install|auth flow

3) verbose

• P0/P1 immediate
• P2 also immediate (or short-window batched)

Severity scoring recommendations

Do not rely on title keyword only; combine signals:

• Title/body keyword hit
• Label hit
• Changed paths weighting:
  • higher weight: core/, gateway/, agent/, runtime/
  • lower weight: docs/, tests/, examples/

Baseline + notification window (critical)

Track notification cursors in state to avoid backfilling old events:

• installed_at: skill first-run time
• last_checked_at: last successful scan time
• last_notified_at: last time user was notified

Rules:

1. On first install/run, initialize all three to now and do not send historical events.
2. Each run only evaluates events in (last_checked_at, now].
3. Notify only for events newer than last_notified_at.
4. After sending any alert/digest, set last_notified_at = now.
5. After successful scan, set last_checked_at = now.

Noise control

• Dedup fingerprint: repo + event_type + event_id/hash
• Silent when no new events
• Merge same-run alerts into one message grouped by repo
• Keep digest queue for P2 in state (pending_daily)

Reliability

• Retry transient API failures with exponential backoff
• If repeated failures, send one degradation alert
• Send one recovery alert when healthy again
• Persist state at end of successful run

Suggested OpenClaw cron behavior

• One job for all repos (easy scaling)
• Add/remove repos by editing list only
• Preserve one state file for dedup across restarts

Output mode (default: brief impact summary)

Default output must be concise and decision-oriented, not event-by-event long list.

Use this fixed structure:

1. 本窗口结论（是否有关键变化）
2. 对用户可能影响（3-5 条，按优先级）
3. 建议动作（最多 3 条）
4. 详情入口：回复“看详情”再展开事件清单

Impact-first grouping (preferred):

• 配置/兼容性风险（breaking、config schema、auth、gateway）
• 通知/渠道行为变化（telegram/slack/feishu/discord/channel）
• 会话与路由变化（session/dispatch/provider/tools）
• 稳定性/性能修复（timeout、race、retry）
• 文档/测试类（低优先）

Detailed mode (on-demand)

Only when the user explicitly asks “看详情/展开/给清单”, output event-level details with links.