Use cases at a glance
GitHub is where code lives. These six agents automate the triage and reporting tasks that typically live in a spreadsheet, Slack thread, or someone's mental notes. Set them to run on a schedule — every morning, weekly, or on-demand — and get structured reports without opening a dashboard.
🔀 PR Triage
Flag PRs waiting for review longer than 2 days, PRs with merge conflicts, and draft PRs accidentally left open for weeks.
🐛 Stale Issue Alerts
Issues unassigned and untouched past threshold. Flag potential duplicates by title similarity scoring.
📋 Daily Review Queue
Morning summary of all open PRs sorted by age, reviewer assigned, and change size. Identifies what needs attention first.
👥 Contributor Activity
Weekly summary of commits, PRs merged, issues closed per contributor. Track team velocity and workload.
📝 Release Notes
Auto-generate changelog from merged PRs and commits since the last release tag. Parse conventional commits.
🔐 Security Advisory Watch
Alert when GitHub publishes a new advisory for a repo's language ecosystem.
GitHub token setup
Every GitHub agent needs a personal access token (PAT) with read-only repository permissions. Create one in 5 steps:
Creating a fine-grained personal access token
- Go to GitHub Settings:
Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token
- Set expiry: Recommend 90 days. Set a HEARTBEAT reminder to rotate it before expiry.
- Repository access: Select only the repos you want to monitor. OpenClaw only sees what you grant.
- Permissions (read-only): Grant these permissions:
- Contents (read) — to read commits and tags
- Issues (read) — to read issue metadata
- Pull requests (read) — to read PR metadata and review state
- Actions (read) — to read workflow run status (Part 4)
- Metadata (read) — required by GitHub API; grants nothing sensitive
Do not grant write permissions.
- Store in secrets.env: Create or update your
secrets.env file with:
GITHUB_TOKEN=github_pat_xxxxxxxxxxxx
GITHUB_OWNER=your-org-or-username
💡 Fine-grained vs classic tokens: Fine-grained tokens let you grant access to specific repos only. This is much more secure. Classic tokens grant access to all repos your account can access. Always use fine-grained.
PR triage agent
This agent runs every morning (or hourly if you prefer) and flags pull requests needing attention. It checks for:
- PRs waiting for review longer than 2 days with no reviewer assigned
- PRs with merge conflicts blocking merges
- Draft PRs that have been open longer than 7 days
- Open PRs with no comments or commits for 5+ days
Add this to your AGENTS.md:
agents:
pr-triage:
description: "Flag PRs needing attention across monitored repos"
tools:
- github-api
config:
owner: "${GITHUB_OWNER}"
repos:
- "repo-name-1"
- "repo-name-2"
token: "${GITHUB_TOKEN}"
thresholds:
awaiting_review_days: 2 # flag PRs with no review after 2 days
draft_open_days: 7 # flag drafts open longer than 7 days
no_activity_days: 5 # flag PRs with no comments/commits in 5 days
filters:
ignore_labels:
- "on-hold"
- "waiting-for-author"
output:
format: markdown
sections:
- awaiting_review # PR title, author, age, reviewer assigned (if any)
- has_merge_conflicts # PRs with conflict flag set
- stale_drafts # drafts open past threshold
- no_activity # open PRs with no recent activity
include_fields: [title, url, author, age_days, reviewers, label_names, additions, deletions]
sort_by: age_days
Issue monitoring agent
This agent flags stale issues and detects potential duplicates using string similarity scoring:
- Unassigned issues open longer than 7 days
- Issues with no comments in 14+ days
- Potential duplicates (title similarity >75%, configurable)
agents:
issue-monitor:
description: "Flag stale and unassigned issues"
tools:
- github-api
config:
owner: "${GITHUB_OWNER}"
repos: "${MONITORED_REPOS}"
token: "${GITHUB_TOKEN}"
thresholds:
unassigned_open_days: 7 # flag unassigned issues open > 7 days
no_activity_days: 14 # flag issues with no comments in 14 days
stale_days: 30 # label as stale after 30 days of inactivity
duplicate_detection:
enabled: true
similarity_threshold: 0.75 # flag pairs with >75% title similarity
ignore_labels:
- "wontfix"
- "duplicate"
- "on-hold"
output:
format: markdown
sections:
- unassigned_old
- no_recent_activity
- potential_duplicates # pairs of similar issues with links to both
Daily review queue summary
A morning standup summary of all open PRs, grouped by state: waiting for reviewer, in review, changes requested. Sizes PRs as XS/S/M/L based on lines changed:
agents:
review-queue:
description: "Generate morning PR review queue sorted by priority"
tools:
- github-api
config:
owner: "${GITHUB_OWNER}"
repos: "${MONITORED_REPOS}"
token: "${GITHUB_TOKEN}"
output:
format: markdown_table
columns: [pr_title, repo, author, age_days, size_label, reviewers_assigned, status]
size_label_logic: |
XS = <10 lines changed
S = 10-99 lines
M = 100-499 lines
L = 500+ lines
sort_by: [reviewers_assigned_none_first, age_days_desc]
prompt: |
Group PRs into three sections:
1. NEEDS REVIEWER — no reviewer assigned yet (highest priority)
2. IN REVIEW — reviewer assigned, waiting for feedback
3. CHANGES REQUESTED — waiting for author to respond
Prefix each PR title with its size label [XS/S/M/L].
Contributor activity report
Weekly summary of each contributor's commits, PRs merged, issues closed, and code review submissions. Useful for tracking team velocity and workload distribution:
agents:
contributor-activity:
description: "Weekly contributor activity summary"
tools:
- github-api
config:
owner: "${GITHUB_OWNER}"
repos: "${MONITORED_REPOS}"
token: "${GITHUB_TOKEN}"
date_range: last_7_days
output:
format: markdown_table
columns: [contributor, commits, prs_merged, issues_closed, reviews_submitted, lines_changed]
sort_by: prs_merged
note: "Data is per-repo aggregated. Bot accounts are excluded."
schedule: weekly
Release notes from commits
Automatically generate a changelog from the commits and PRs merged since the last release tag. The agent parses conventional commit prefixes (feat:, fix:, chore:) to categorize changes:
agents:
release-notes-generator:
description: "Generate release notes from commits and PRs since last tag"
tools:
- github-api
config:
owner: "${GITHUB_OWNER}"
repo: "${TARGET_REPO}"
token: "${GITHUB_TOKEN}"
since_tag: "auto" # auto = detect last published release tag
conventional_commits: true # parse feat:/fix:/chore:/docs: prefixes
output:
format: markdown
sections:
- "🚀 New Features" # feat: commits and PRs
- "🐛 Bug Fixes" # fix: commits
- "⚡ Improvements" # perf:/refactor: commits
- "📚 Documentation" # docs: commits
- "🔧 Maintenance" # chore:/ci:/build: commits
exclude_from_output:
- merge_commits
- dependabot_prs
include_pr_links: true
include_contributor_credits: true
prompt: |
Write release notes in a friendly, readable tone for a developer audience.
For each feature or fix, write one clear sentence describing what changed and why it matters.
Do not just repeat the commit message — interpret it.
HEARTBEAT templates
Schedule these agents to run automatically using HEARTBEAT.md:
Daily morning standup brief (weekdays 8 AM)
Runs PR triage, review queue, and issue monitoring in one combined report:
heartbeats:
- name: "Daily standup brief"
description: "Morning snapshot of PRs, issues, and blockers"
agents: [pr-triage, review-queue, issue-monitor]
cron: "0 8 * * 1-5" # 8 AM, Monday–Friday
output_file: "reports/standup-{YYYY-MM-DD}.md"
notify: slack # or email, webhook, etc.
Weekly contributor summary (Mondays 9 AM)
heartbeats:
- name: "Weekly team activity"
description: "Contributor commits, PRs merged, issues closed"
agents: [contributor-activity]
cron: "0 9 * * 1" # 9 AM, Mondays
output_file: "reports/contributors-{YYYY-MM-DD}.md"
On-demand release notes
Trigger manually to generate release notes for a specific repo:
heartbeats:
- name: "Generate release notes"
description: "Create changelog from commits since last tag"
agents: [release-notes-generator]
trigger: on_demand
input_required: TARGET_REPO # user specifies repo name
output_file: "releases/{TARGET_REPO}_release_notes.md"
Sample report
Here's what a morning standup brief looks like after the three agents run:
standup-2026-03-25.md
=== STANDUP BRIEF (2026-03-25) ===
PR TRIAGE
————————
3 PRs awaiting reviewer
· #847 "Auth token refresh on 403" (Alex Chen, 3 days) [M]
· #851 "Batch query API endpoint" (Sam Lee, 2 days) [L]
· #848 "Fix sidebar collapse state" (Jamie Park, 2 days) [S]
1 PR with merge conflict
· #849 "Update dependencies" (Bot account)
✗ No stale drafts.
ISSUES
——————
2 stale unassigned issues
· #1204 "Settings page loads slowly on mobile" (7 days)
· #1198 "Export CSV missing timezone info" (14 days)
✓ No duplicate issues detected. 14 issues healthy.
REVIEW QUEUE (sorted by age)
——————————————————————
| Title | Repo | Author | Age | Size | Reviewers |
|---------------------------|------|--------|-----|------|-----------|
| Auth token refresh on 403 | api | Alex | 3d | M | — |
| Batch query endpoint | api | Sam | 2d | L | — |
| Fix sidebar collapse state | web | Jamie | 2d | S | — |
Frequently asked questions
What GitHub API rate limits apply?
5,000 requests per hour with a personal access token. A typical morning triage run across 3 repos uses approximately 50–100 requests. You will not hit limits running hourly checks or even 6 daily briefings.
Can OpenClaw monitor private repositories?
Yes, as long as your PAT has access to them. Fine-grained tokens let you restrict access to specific repos so OpenClaw only sees what it needs to. This is much more secure than using a token with access to all your repos.
How does duplicate issue detection work?
OpenClaw compares issue titles using string similarity scoring (typically cosine similarity on tokenized text). Issues with greater than 75% similarity (configurable) are flagged as potential duplicates. This is not semantic deduplication — very differently worded issues describing the same bug will not be caught. Treat it as a helper tool to run through occasionally, not a guarantee.
Can OpenClaw post comments on GitHub issues or PRs?
Only if you configure a write-enabled token and an explicit write step in your agent config. This is not recommended by default for safety reasons. The recommended pattern is for OpenClaw to output suggestions as a Markdown report and have a human review and act on them.