Menu
Synthesize recent PR activity into a cross-PR net-effects briefing
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Full implementation lifecycle with adversarial review using subagents
Address PR review feedback and verify independently
Draft and create a GitHub issue from a description, investigation, or conversation context. Use when a problem is too large for a quick fix, when you want to propose a change for later, or when the user asks to "file an issue", "create an issue", "draft an issue", "open a ticket", or "log this for later". Also useful when another skill (like tune) determines a change is too large and needs to be tracked as an issue instead.
Merge a PR and update upstream GitHub issues with progress
Validate a PR against PR standards before requesting review
Health-check the LifeOS persona layer (files load, /chat matches the Telegram bots per persona, no personal values leak into committed persona files, frontmatter valid) and open every persona doc in Sublime for editing.
| name | catchup |
| description | Synthesize recent PR activity into a cross-PR net-effects briefing |
Arguments: $ARGUMENTS
Parameters (order-independent, all optional):
me (only your PRs), others (everyone except you), or omit for allMerged PRs in the window:
!A="${ARGUMENTS:-}"; H=$(echo "$A" | grep -oE '[0-9]+' | head -1); H=${H:-24}; F=$(echo "$A" | grep -oiE '\b(me|others)\b' | head -1 | tr A-Z a-z); case "$F" in me) AF="author:@me";; others) AF="-author:@me";; *) AF="";; esac; gh pr list --state=merged --search="merged:>=$(date -u -v-${H}H +%Y-%m-%dT%H:%M:%S)Z ${AF}" --json number,title,author,mergedAt,body,additions,deletions,changedFiles --limit 50 2>/dev/null || echo "GH_ERROR"
Open/changed PRs in the window (created or updated):
!A="${ARGUMENTS:-}"; H=$(echo "$A" | grep -oE '[0-9]+' | head -1); H=${H:-24}; F=$(echo "$A" | grep -oiE '\b(me|others)\b' | head -1 | tr A-Z a-z); case "$F" in me) AF="author:@me";; others) AF="-author:@me";; *) AF="";; esac; gh pr list --state=open --search="updated:>=$(date -u -v-${H}H +%Y-%m-%dT%H:%M:%S)Z ${AF}" --json number,title,author,createdAt,updatedAt,body,additions,deletions,changedFiles,labels --limit 50 2>/dev/null || echo "GH_ERROR"
Git stats for the window:
!A="${ARGUMENTS:-}"; H=$(echo "$A" | grep -oE '[0-9]+' | head -1); H=${H:-24}; SINCE=$(date -u -v-${H}H +%Y-%m-%dT%H:%M:%S); COMMITS=$(git log --since="$SINCE" --oneline origin/main 2>/dev/null | wc -l | tr -d ' '); STATS=$(git log --since="$SINCE" --shortstat origin/main 2>/dev/null | grep "insertion\|deletion" | awk '{for(i=1;i<=NF;i++){if($i~/insertion/)ins+=$(i-1);if($i~/deletion/)del+=$(i-1)}} END {printf "%d added, %d removed", ins+0, del+0}'); echo "commits=$COMMITS $STATS"
Project context for understanding what changed:
!cat AGENTS.md
You are producing a net-effects briefing — not a PR-by-PR changelog. The reader wants to understand what's different about the codebase now compared to N hours ago.
Check the arguments above to determine the author filter. If others was specified, note in your briefing header that this covers changes by other contributors (not the person running the skill). If me was specified, note it covers only the runner's own changes. If no filter, cover all contributors.
If either PR list shows GH_ERROR, report that gh failed (likely auth or network) and stop.
Scan both PR lists. If there are zero PRs in both lists, say so and stop.
Group PRs into two buckets:
For each merged PR, read its description carefully. Extract:
If a PR description is too terse to understand the scope, fetch the diff summary:
gh pr diff <number> --stat
For particularly important or large PRs, fetch the full diff to understand the actual changes:
gh pr diff <number>
Use your judgment — not every PR needs a full diff read. Focus effort on PRs with large insertion counts, schema changes, or architectural implications.
Produce the following sections. Use concise, direct language. No filler.
A compact stats line at the top of the briefing. Use the git stats and PR data provided above to produce a single line like:
12 commits, 6 PRs merged, +4,713 / -128 lines
Include: commit count, merged PR count, lines added/removed. If an author filter is active, note it (e.g., "by @user" or "by others").
Group changes by theme/area, not by PR. Merge related PRs into a single narrative. For each theme:
Themes should be whatever emerges naturally from the changes — examples: "Sync pipeline", "Search & indexing", "CRM / entity resolution", "API endpoints", "MCP tools", "Documentation", "Tooling", "Test coverage". Don't force categories that don't exist.
For each theme above, explain in plain language how the system's behavior or capabilities changed at a high level. Write this for someone who hasn't looked at the code — they want to know what the system can do now that it couldn't before, what works differently, or what's more reliable/faster/safer.
Examples of the right level of abstraction:
Avoid restating the "what changed" section — focus on the so what.
For each open PR updated in the window:
If there are no open PRs, omit this section.
Optional section — include only if warranted. Flag items like:
If nothing warrants attention, omit this section entirely.
#N (GitHub will auto-link them)Stop and tell the user when:
gh commands fail (auth, network, or unexpected errors)date -v syntax; it won't work on Linux)