Claude Code skill: Generate Notion activity reports for git repos

SKILL.md

name	notion-repo-report
description	Generate a Notion activity report for a git repo covering a time period (default 24h). Includes a human-friendly summary, detailed workstream breakdown with GitHub links, open PR activity, and stats. Optionally publish under a specified Notion parent page.
triggers	notion report repo report activity report what happened in the repo daily report generate report

Notion Repo Activity Report

Generate a structured Notion page summarizing recent git activity for any repo. The report has two layers: a plain-English summary (what a stakeholder would write) and detailed technical breakdown with GitHub links.

Step 1: Determine Parameters

Ask or infer:

• Time period: default "24 hours ago", accept "since Monday", "last week", "last 3 days", etc.
• Repo: use current working directory. Detect the GitHub remote with git remote get-url origin to build links.
• Notion parent page: ask the user where to put it. Search Notion if needed to find the right parent.

Step 2: Gather Git Data

Run these commands to collect raw data:

# Parse GitHub org/repo from remote
git remote get-url origin | sed -E 's|.*github.com[:/](.+/.+?)(\.git)?$|\1|'

# Commits in the time period (on main/default branch)
git log --since="<PERIOD>" --pretty=format:"%h %an %ad %s" --date=short

# Detailed file changes per commit
git log --since="<PERIOD>" --stat --pretty=format:"%h %s%n"

# Overall diff stats
git diff $(git log --since="<PERIOD>" --reverse --pretty=format:"%h" | head -1)^..HEAD --stat 2>/dev/null

Fetch merged PRs:

gh pr list --repo <ORG/REPO> --state merged --limit 20 --json number,title,mergedAt,author,url

Fetch open PRs with recent activity:

gh pr list --repo <ORG/REPO> --state open --json number,title,author,url,createdAt,updatedAt,headRefName,additions,deletions,changedFiles,labels,draft

Filter both to activity within the time period.

Step 3: Analyze and Group

Review the commits, merged PRs, and open PRs. Group them into workstreams -- logical themes of work. Common patterns:

• Feature work (new pages, new modules, new APIs)
• Refactoring / redesign
• Bug fixes
• Documentation / ops
• Infrastructure / CI
• Merge/integration work

For each workstream, identify:

• What changed at a high level (1-2 sentences a non-engineer could understand)
• Key commits and PRs (both merged and in-progress)
• Key files changed (with GitHub links)

Step 4: Write the Summary

Write 4-6 bullet points in plain English. Each bullet should:

• Start with a bold label
• Explain what happened in terms a stakeholder (not just an engineer) would understand
• Avoid jargon where possible -- say "shielded address" not "Orchard receiver pool type"
• Be honest about status (tested, live, in progress, planned)
• Include in-progress work if it's significant

Example style:

- **Full design refresh** -- the pool dashboard, login, onboarding, workers, payouts,
  and blocks pages were all redesigned with a new dark premium look
- **Testnet live** -- the pool is running at testnet.onbedrock.org with real miners
  able to register and log in
- **Shielded payouts (in progress)** -- PR #19 adds transaction building for native
  ZEC payouts, currently under review

Step 5: Build the Notion Page

Create the page using mcp__claude_ai_Notion__notion-create-pages under the chosen parent.

Page Structure

Title: "<Repo name> Activity Report -- <start date> to <end date>"

## What Happened
[4-6 plain-English bullet points from Step 4]
[One-line stats: X commits, Y PRs merged, Z open PRs active, W files changed (+A/-B lines). Contributors: ...]

---

## Pull Requests Merged
[Table with columns: PR (linked to GitHub), Title, Author, Merged date]

---

## Open Pull Requests
[Table with columns: PR (linked to GitHub), Title, Author, Status (draft/review/etc), +/- lines]
[Include a 1-line description of what each open PR does and its current state]

---

## Workstream N: <Name>
[1-2 sentence description]
[Bullet list of changes]
[Note any open PRs that are part of this workstream]
**Key files:** [linked to GitHub blob/tree URLs on the main branch]

[Repeat for each workstream]

---

## Bug Fixes & Ops
[Bullet list, each linking to the relevant commit on GitHub]

---

## Branch Merges
[If any merge commits exist, describe what was merged and by whom]

---

## Stats
[Table: Commits, PRs merged, Open PRs active, Files changed, Lines added, Lines removed, Contributors]

GitHub Link Formats

Use these patterns (replace <ORG>, <REPO>, <BRANCH>):

• PR: https://github.com/<ORG>/<REPO>/pull/<NUMBER>
• Commit: https://github.com/<ORG>/<REPO>/commit/<SHA>
• File: https://github.com/<ORG>/<REPO>/blob/<BRANCH>/<PATH>
• Directory: https://github.com/<ORG>/<REPO>/tree/<BRANCH>/<PATH>

For Notion markdown, use [text](url) for inline links.

Notion Table Format

Use Notion's XML table format:

<table header-row="true">
<tr>
<td>Column 1</td>
<td>Column 2</td>
</tr>
<tr>
<td>value</td>
<td>value</td>
</tr>
</table>

Step 6: Confirm

Return the Notion page URL to the user.

Tips

• If the repo has a testnet or staging URL, mention it in the summary with a working link
• If there are test credentials or demo access, include them in a "How to Try It" section
• When in doubt about grouping, fewer workstreams is better than many small ones
• The summary bullets are the most important part -- stakeholders may only read those
• Open PRs matter -- they show what's coming next and where review is needed
• Don't pad the report with filler. If it was a quiet day, say so.