YiHui GITHUB MONITOR

Monitor multiple GitHub repos with configurable alert policies for releases, PRs, and security, sending low-noise notifications via scheduled cron jobs.

Security Scan

The skill's instructions mostly match a repo-monitoring purpose, but several operational and access expectations (state file location, notification delivery, and GitHub/notification credentials) are not declared — the mismatch deserves review before installing.

Purpose & Capability

Name/description and SKILL.md align: it is a GitHub repo monitor that polls the GitHub API and sends notifications. However, the skill expects persistent state storage (a state_file path is suggested under /root/.openclaw/...) and delivery to notify targets (telegram/slack/feishu/discord/channel) but the registry metadata declares no required config paths or credentials. Those capabilities are plausible for this purpose but the lack of declared filesystem access and credentials is an inconsistency.

Instruction Scope

SKILL.md instructs the agent to read/write persistent state (installed_at, last_checked_at, last_notified_at, pending_daily) and to initialize state on first-run. It also recommends sending degradation/recovery alerts and delivering notifications to various channel types. Those are within the monitor's scope, but the instructions hard-code an example path under /root and assume the agent can persist and deliver notifications without describing how authentication for GitHub or messaging channels is obtained. The skill does not instruct reading unrelated system files or secrets, but it does require write access to a filesystem location that may be privileged.

Install Mechanism

Instruction-only skill with no install spec or code files — minimal on-disk installation risk. Nothing is downloaded or written by an install step itself; the runtime instructions cause state writes, which is expected behavior for a monitor.

Credentials

Registry metadata declares no required env vars/credentials, but practical operation likely needs: (a) a GitHub token to avoid strict public rate limits when monitoring many repos, and (b) credentials or channel tokens to post to external messaging services. The SKILL.md mentions multiple notification backends but provides no guidance or declared requirements for their credentials. This mismatch could lead to the agent storing or using credentials outside expected metadata or attempt unauthenticated calls with degraded behavior.

Persistence & Privilege

The skill requests persistent state via a state_file and recommends a path under /root/.openclaw/workspace/memory/..., but it does not request always:true or elevated platform privileges. Persisting state is reasonable for deduplication and digests, but using /root paths may be inappropriate on multi-tenant systems. The skill does not request modifying other skills or system settings.

What to consider before installing

This skill appears to be a legitimate GitHub monitor, but there are gaps between what it says it will do and what it declares it needs. Before installing, confirm these points with the author or your admin: - Where will the state file be stored? Prefer a workspace-scoped, non-root path you control; prevent writing to arbitrary /root paths. - How are notifications delivered? Ask which notify_target mapping the platform provides and whether you must supply Slack/Telegram/Feishu/Discord tokens; require explicit documentation and least-privileged tokens for messaging. - Will you provide a GitHub token? Monitoring many repos typically needs an authenticated token to avoid rate limits — only grant a token with repo:public_repo scope (or narrower) and rotate it periodically. - Verify that the agent will not backfill historical events (SKILL.md says it should not); confirm initial-run behavior in practice. If the author can update the skill metadata to declare required config paths and env vars (and allow configuring a non-root state path), the mismatches would be resolved. If you cannot get that assurance, treat the skill as higher risk and restrict its filesystem and credential access.

name: github-monitor

GitHub Monitor

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.