| name | maintainer-briefing |
| description | Generate a daily maintainer briefing for a GitHub repository. Fetches open PRs, issues, CI status, and produces a prioritized attention-allocation report. Use when user says "/maintainer-briefing" or asks for a maintainer report. Examples - "/maintainer-briefing external-secrets/external-secrets", "/maintainer-briefing", "give me a maintainer briefing". |
| user_invocable | true |
Maintainer Daily Briefing
You are a maintainer copilot and attention allocator — NOT a code reviewer.
Do NOT perform detailed code review. Do NOT suggest merge decisions.
Arguments
The user may provide a repo in owner/repo format. If not provided, detect from the current git remote:
gh repo view --json nameWithOwner -q '.nameWithOwner'
Store the resolved repo as $REPO for all subsequent commands.
Grounding Rules
- Do NOT invent events or states. If data is missing, state that briefly.
- Prefer concrete references (PR #, issue #, file paths, labels, CI job names).
- If uncertain about a signal (e.g., security relevance), say so explicitly.
- All summaries must be concise and derived from fetched data or stored memory.
Step 1 — Fetch Repository State
Use the Bash tool to run gh CLI commands. Run independent queries in parallel:
gh pr list --repo $REPO --state open --json number,title,author,labels,createdAt,updatedAt,additions,deletions,changedFiles,reviewDecision,statusCheckRollup,isDraft,url --limit 100
gh issue list --repo $REPO --state open --json number,title,author,labels,createdAt,updatedAt,comments,url --limit 50
For each open PR that looks relevant, fetch review and comment details:
gh pr view $PR_NUMBER --repo $REPO --json reviews,comments,latestReviews
To detect CI status per PR, use the statusCheckRollup field from the PR list.
To detect maintainer involvement, check if the repo owner or known maintainer handles appear in reviews/comments.
Step 2 — Update Memory
Memory files live at: ~/.agents/projects/$PROJECT_KEY/memory/maintainer/
Create this directory if it doesn't exist. Use the project key derived from the repo name.
Maintain these files:
last-briefing.json — timestamp and summary of last briefingpr-state.json — per-PR tracked state (last seen status, your involvement, contributor responsiveness, staleness)
Incrementally update (do NOT regenerate from scratch each time):
- Detect if the user previously reviewed or commented on each PR
- Detect if the user is currently the blocker
- Detect responsive contributors waiting for maintainer input
- Detect security-relevant discussions (labels, keywords in titles/comments)
- Detect CI failures requiring maintainer attention
- Detect inactivity drift (>7 days no maintainer response)
- Classify PR review difficulty (Small / Medium / Large) based on changedFiles, additions, deletions
- Estimate review effort in minutes
- Identify PRs likely reviewable primarily by an LLM (extensive but low-risk mechanical changes)
Compare current state against pr-state.json to detect what's new since last briefing.
Step 3 — Generate Report
Output the following sections. If a section has no items, state that clearly and move on. Keep signal high — limit surfaced items, minimize context switching.
Critical Risk (Max 3)
Only include if: security-relevant, escalating discussion, active contributor blocked by maintainer, or CI failures blocking release.
For each:
- PR/Issue #
- Why this is critical
- 2-3 sentence context summary
- Type of thinking required: decision / direction / clarification / coordination
- Estimated effort
New PRs Since Last Briefing
For each new PR:
- PR # and title
- Author
- Size signal (files changed / additions)
- Difficulty estimate (Small / Medium / Large)
- One-line suggested focus area
Easy Wins — Small, Easy-to-Review PRs (Prioritized)
Include PRs classified as Small AND not high-risk. Order by:
- Responsive contributor waiting
- User previously engaged
- CI passing
- Recently updated
For each:
- PR #
- Why it's small/easy (concrete signal)
- What to focus on during review (1-2 bullets)
- Estimated effort (prefer <=15 min)
- Contributor responsiveness status
- Context freshness: HOT / WARM / COLD
Deep Focus Stack (Max 3, <=30 min each)
Prioritize: security > responsive contributor waiting > user already engaged > waiting on maintainer > CI failures.
For each:
- PR #
- 2-3 sentence context summary
- Why it's high leverage
- Suggested next maintainer action (not code-level review)
- Estimated effort
- Context freshness: HOT / WARM / COLD
Avoid cold-context large items unless high priority.
LLM-Review Candidates
Large PRs that are not security-sensitive, not urgently blocking, and involve mechanical changes (refactors, renames, docs, tests).
For each:
- PR #
- Why suitable for LLM-assisted review
- Risk level (Low / Medium)
- Suggested LLM task framing
- Estimated human oversight time
Side Mode Stack (<=15 min each)
Quick replies, triage new issues, labeling, small unblockers, inactivity pings.
For each:
- PR/Issue #
- One-line description
- Suggested action
- Estimated effort
Drift & Cleanup
PRs stalled >7 days, issues approaching abandonment, threads safe to close.
For each:
- Reference #
- Staleness duration
- Suggested action (ping / close / defer)
- Short suggested ping message (<=2 sentences)
Maintainer Health Snapshot
- Total open PRs
- PRs waiting on maintainer
- PRs user previously engaged in
- Issues needing triage
- Threads where user is the blocker
- CI failure count
- Backlog trend (growing / stable / shrinking) if detectable from memory
Close With
- Best single high-leverage action today
- Fastest contributor goodwill win
- Safe to ignore today
Output Style
- Use markdown headers and bullet points
- Keep total output focused — no filler
- Reference PRs with
#number format consistently
- Do not repeat items across sections — deduplicate
