1---
2name: github-morning-brief
3description: "Prepare a daily morning GitHub work brief for a repo/org with actionable priorities: inbox ask-signals (mention/review requested/assigned), open PR triage, project board status counts, CI/security risks, and top 1-3 next actions. Use when the user asks for a morning PM/dev briefing, start-of-day GitHub plan, or daily repo triage summary."
4---
5 
6# GitHub Morning Brief
7 
8Generate a compact, action-first morning brief from GitHub signals.
9 
10## Inputs to collect first
11 
12- `owner/repo` (required)
13- org project number (optional but recommended)
14- horizon: last 24h (default)
15- optional extra risk repo(s) for security alerts
16 
17If something is missing, ask one short question, then continue.
18 
19## Workflow
20 
211. Pull ask-signals from notifications: `mention`, `review_requested`, `assign`.
222. Pull open PR list and identify:
23   - merge candidates (approved + clean + checks green)
24   - fast-review candidates (recent activity, clean mergeability)
25   - blocked PRs (conflicts/failing checks)
263. Pull project board snapshot (status buckets and counts).
274. Pull CI and security risk signals.
285. Produce a short start-of-day plan (1–3 concrete actions with links).
29 
30Use exact command patterns from `references/commands.md`.
31 
32## Output format (recommended)
33 
34- Short briefing paragraph (what matters right now)
35- Ask-signals section with links
36- Project/PR/CI snapshot
37- Risks section
38- `1–3` concrete next actions (priority order)
39- Optional: draft review text for one selected PR
40 
41## Guardrails
42 
43- Keep tone practical and concise.
44- Include direct links for every PR/issue/run mentioned.
45- Do not post comments/reviews/merges automatically unless user explicitly asks.
46- If data is partial (permissions/API failure), state it clearly and still provide best-effort priorities.
47