GitHub Digest

Generate a structured GitHub repo digest with briefing summary, categorized changes (breaking/major features/minor features/bug fixes), community discussions...

Security Scan

The skill's instructions match its stated purpose (generating a GitHub digest) but the SKILL.md requires local tools (e.g., gh, jq) and authenticated GitHub access while the registry metadata omits those requirements — an inconsistency you should verify before installing or running.

Purpose & Capability

The name/description (GitHub repo digest) align with the runtime instructions: the workflow uses the GitHub CLI to list releases, PRs, and issues and formats a digest. However, the SKILL.md requires the 'gh' CLI (and uses 'jq' in examples), but the registry metadata declared no required binaries — this mismatch should be resolved.

Instruction Scope

Instructions are narrowly scoped to querying GitHub data (releases, PRs, issues) and formatting results. They require an authenticated 'gh' session (explicitly listed in SKILL.md) and do not instruct the agent to read unrelated local files or send data to endpoints other than GitHub links. The default repo and parallel execution are implementation details but not scope creep.

Install Mechanism

There is no install spec (instruction-only), so nothing is downloaded or written by the skill itself. This lowers installation risk; however, runtime depends on external CLIs being present on the host.

Credentials

The SKILL.md expects an authenticated 'gh' CLI context (which uses the user's GitHub credentials/token), but the skill metadata lists no required credentials or binaries. While using the user's gh auth is appropriate for querying private or authenticated endpoints, the metadata omission is inconsistent and could lead to confusion about what credentials will be used. The examples also use 'jq' but it's not declared.

Persistence & Privilege

The skill does not request persistent privileges (always is false) and has no install hooks. It does rely on the agent executing shell commands (gh); autonomous invocation is allowed by platform default but not otherwise elevated by this skill.

What to consider before installing

This skill appears to do what it says (produce a GitHub digest), but before using it: 1) confirm you have the gh CLI and jq installed and that the publisher updates the registry metadata to declare those requirements; 2) understand that the skill will run gh commands using whatever account is authenticated in your gh CLI (so it will use your GitHub token/permissions); 3) if you only want public data, test the gh commands manually first to see what they'll return; 4) if concerned about token scope, use a token/account with limited permissions or run on an environment where gh is configured for read-only access; and 5) ask the publisher to clarify the missing metadata (required binaries and whether private-repo access is needed). These steps will reduce risk and resolve the metadata inconsistency.

Generate structured, link-rich GitHub repo digests with a briefing overview and categorized details.

Prerequisites

• gh CLI authenticated (gh auth status)

Workflow

1. Gather Data

Run these gh commands in parallel for the target repo (default: openclaw/openclaw):

# Recent releases (last 5)
gh release list --repo OWNER/REPO --limit 5

# Latest release notes
gh release view TAG --repo OWNER/REPO --json body --jq '.body'

# Recently merged PRs (last 30)
gh pr list --repo OWNER/REPO --state merged --limit 30 \
  --json number,title,author,mergedAt,labels \
  --jq '.[] | "[\(.mergedAt[:10])] #\(.number) \(.title) by @\(.author.login) [\([.labels[].name] | join(","))]"'

# Hot open issues (sorted by comments)
gh issue list --repo OWNER/REPO --state open --limit 30 \
  --json number,title,comments,labels \
  | jq -r '[.[] | {n:.number,t:.title,c:.comments,l:[.labels[].name]}] | sort_by(.c) | reverse | .[0:15] | .[] | "[\(.c)] #\(.n) \(.t) [\(.l | join(","))]"'

Adjust --limit and time range based on user's request (today / this week / this month).

2. Output Format

Structure the digest in this exact order:

📋 Briefing（总览）

A 3-5 sentence executive summary covering:

• What version was released and when
• Core themes (2-3 keywords, e.g. "安全加固、Plugin SDK 开放、工具能力扩展")
• Most impactful change in one line
• Community pulse (what people are discussing)
• Any breaking changes warning

⚠️ Breaking Changes

List each breaking change with:

• What changed
• Migration action required
• Link to docs if available

Skip this section if none.

🏗️ 重大更新 (Major Features)

Significant new capabilities, architectural changes, new integrations. Each item:

• Bold title：one-line description (#PR)

✨ 小功能 / 改进 (Minor Features)

Group by sub-category when there are many (e.g. "Telegram", "CLI", "Plugin SDK"). Each item:

• One-line description (#PR)

🔧 Bug 修复 (Bug Fixes)

Group by area (e.g. "Channel 修复", "核心/安全", "工具/浏览器"). For channel fixes with 5+ items, use a table:

Channel	修复内容	PR
Name	Description	#N

For other fixes, use bullet lists grouped by area.

💬 社区热议 (Community Discussions)

Hot issues sorted by engagement. Each item:

• #N — Title：one-line summary of the discussion

3. Formatting Rules

• Every PR/issue/release MUST have a clickable markdown link
  • PR: [#123](https://github.com/OWNER/REPO/pull/123)
  • Issue: [#123](https://github.com/OWNER/REPO/issues/123)
  • Release: [vTAG](https://github.com/OWNER/REPO/releases/tag/vTAG)
• Use the user's language (detect from their message; default Chinese for Chinese users)
• Bold key terms for scannability
• Omit empty sections silently
• When release notes mention a PR number like (#12345), always convert to a clickable link
• For "Thanks @user" in release notes, link to https://github.com/user