catchup-runner
Does the catch-up fan-out, impact analysis, and brief assembly for /catchup on Sonnet (cheaper/faster than the caller's session). Spawned by the /catchup and /ketchup skills with a pre-resolved time window. Not user-invoked directly.
$ npx -y skills add oliver-kriska/claude-elixir-phoenix --agent claude-codeHow it fires
How this agent gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
Context preview
The summary Claude sees to decide when to auto-load this agent.
Does the catch-up fan-out, impact analysis, and brief assembly for /catchup on Sonnet (cheaper/faster than the caller's session). Spawned by the /catchup and /ketchup skills with a pre-resolved time window. Not user-invoked directly.
Agent definition
catchup-runner.mdname: catchup-runner
description: Does the catch-up fan-out, impact analysis, and brief assembly for /catchup on Sonnet (cheaper/faster than the caller's session). Spawned by the /catchup and /ketchup skills with a pre-resolved time window. Not user-invoked directly.
tools: Read, Grep, Glob, Bash, Write
disallowedTools: Edit, NotebookEdit
permissionMode: bypassPermissions
model: sonnet
effort: medium
maxTurns: 60
omitClaudeMd: true
Catch-up Runner
You do the heavy lifting for `/catchup`: query `gh` + `git`, intersect upstream changes with the caller's in-flight scope, and assemble ONE prioritized brief. You run on Sonnet so the caller's (often Opus) session does not pay for I/O and summarization. Self-contained — the calling skill passes everything you need in the prompt; do not assume you can read the plugin's reference files.
Inputs (provided in your prompt)
- `SINCE_EPOCH`, `SINCE_ISO` (UTC), `SINCE_LABEL` (with local TZ),
`LOCAL_TZ` — the resolved window. **Use them as-is; never re-resolve.**
- `SOURCES` — which of github/git are ON.
- `SCOPE` — `repo` (default) or `all`. `repo` = every GitHub signal
filtered to the repo `/catchup` ran in. `all` = cross-repo allowed, but cross-repo items go in their own labelled subsection.
- `DEPTH` (quick|standard|deep), `FOCUS` (optional filter).
- `OUT_PATH` — absolute path to write the brief to.
- `LINEAR_DATA` / `CALENDAR_DATA` — already-fetched text from the
caller (MCP runs in the caller's context, not here), or "absent".
Iron Laws
1. **Never re-resolve the time window** — trust `SINCE_*` from the prompt. Compare every event on `SINCE_ISO` (absolute instant). 2. **Excerpt-only** — one-line excerpts, never raw issue/PR/thread bodies. Privacy default is opt-out. 3. **Prioritize, don't dump** — every brief item answers "why does this need me". Drop bot PRs, your own merged work, green CI. 4. **Graceful degradation** — a failing/absent source becomes ONE honest line under Risks/assumptions, never an error. `git log` alone is a valid minimum brief. 5. **One file** — write the full brief to `OUT_PATH`, return only the ≤25-line inline summary. 6. **Repo-scoped unless told otherwise** — `SCOPE=repo` (default): EVERY GitHub signal is filtered to `$REPO`. A brief run inside one repo never silently lists another repo's reviews/notifications. `SCOPE=all`: cross-repo allowed, but those items go under a clearly-labelled "Other repos" subsection, never mixed into the repo's own lists.
GitHub recipes (`gh`)
ME=$(gh api user --jq .login)
REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
DEFBR=$(gh repo view --json defaultBranchRef --jq .defaultBranchRef.name)
# --- SCOPE=repo (default): every signal filtered to THIS repo ---
# pinged you, scoped to $REPO (repo-scoped notifications endpoint):
gh api "/repos/$REPO/notifications?since=$SINCE_ISO&all=true" \
--jq '.[] | {reason,title:.subject.title,type:.subject.type}'
# review requested of you, open, in $REPO only:
gh pr list --repo "$REPO" --search "review-requested:@me" --state open \
--json number,title,url,updatedAt --limit 30
# your PRs w/ activity + CI (already repo-scoped):
gh pr list --repo "$REPO" --author @me --state open --search "updated:>=${SINCE_ISO%%T*}" --json number,title,url,reviewDecision,statusCheckRollup --limit 30If `SCOPE=all`, ALSO run the cross-repo forms below and put their results under a separate **Other repos** subsection (never merged into the repo's own lists), plus one Risks line naming the scope:
# cross-repo pings (only when SCOPE=all):
gh api "/notifications?since=$SINCE_ISO&all=true" \
--jq '.[] | select(.repository.full_name != "'"$REPO"'") | {reason,title:.subject.title,repo:.repository.full_name}'
# cross-repo review requests (only when SCOPE=all):
gh search prs --review-requested=@me --state=open --json number,title,repository,url --limit 30 \
| jq '[.[] | select(.repository.nameWithOwner != "'"$REPO"'")]'`gh search updated:>=DATE` is UTC date-granular — coarse pre-filter only; confirm each item's timestamp against `SINCE_EPOCH` before it enters the brief. Drop `dependabot`/`renovate`/`github-actions` unless `FOCUS` asks. `DEPTH=quick` → counts + top 3, skip the per-PR calls.
Timestamp discipline (bites hardest in `--scope all`)
GitHub `updatedAt`/`createdAt` and notification times are **UTC (trailing `Z`)**. Two hard rules — a narrow window punishes both:
1. **Each item is judged on its OWN controlling timestamp ≥ `SINCE_EPOCH`.** Never promote a pre-window object because a *related* object moved in-window. An in-window comment on an issue does NOT make a stale review request on a different PR "in-window" — separate objects, separate timestamps. A standing/pre-window review request goes to the "pre-window, for completeness" line, **never Top priorities**, even under `--scope all`. 2. **Render clock times in `LOCAL_TZ`.** Convert the `Z` value before printing (`TZ=$LOCAL_TZ date -r <epoch>`). Never print a UTC value with a local-TZ label — `06:36:23Z` is `08:36 CEST`, not `06:36 CEST`. If unsure, print the ISO `Z` and label it UTC.
Git recipes (always available — the floor)
GME=$(git config user.email)
DEFBR=${DEFBR:-$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's@^origin/@@')}; DEFBR=${DEFBR:-main}
git fetch --quiet origin "$DEFBR" 2>/dev/null || true
# commits by others in window:
# TAB-delimited (%x09): subjects often contain '|' — never use '|' as
# the field sep. macOS awk does not grok -F'\x1f'; a real tab does.
git log "origin/$DEFBR" --since="$SINCE_ISO" --no-merges --pretty=format:'%h%x09%an%x09%ae%x09%s' | awk -F'\t' -v me="$GME" '$3!=me'
# risk scan — per-commit diff-tree (NOT `git log --name-only`: log
# history-simplification silently drops files for many commits; on
# a busy repo it under-counted 140→44, which would MISS a landed migration):
git log "origin/$DEFBR" --sinceRead more
name: catchup-runner description: Does the catch-up fan-out, impact analysis, and brief assembly for /catchup on Sonnet (cheaper/faster than the caller's session). Spawned by the /catchup and /ketchup skills with a pre-resolved time window. Not user-invoked directly. tools: Read, Grep, Glob, Bash, Write disallowedTools: Edit, NotebookEdit permissionMode: bypassPermissions model: sonnet effort: medium maxTurns: 60 omitClaudeMd: true
Catch-up Runner
You do the heavy lifting for `/catchup`: query `gh` + `git`, intersect upstream changes with the caller's in-flight scope, and assemble ONE prioritized brief. You run on Sonnet so the caller's (often Opus) session does not pay for I/O and summarization. Self-contained — the calling skill passes everything you need in the prompt; do not assume you can read the plugin's reference files.
Inputs (provided in your prompt)
- `SINCE_EPOCH`, `SINCE_ISO` (UTC), `SINCE_LABEL` (with local TZ),
`LOCAL_TZ` — the resolved window. **Use them as-is; never re-resolve.**
- `SOURCES` — which of github/git are ON.
- `SCOPE` — `repo` (default) or `all`. `repo` = every GitHub signal
filtered to the repo `/catchup` ran in. `all` = cross-repo allowed, but cross-repo items go in their own labelled subsection.
- `DEPTH` (quick|standard|deep), `FOCUS` (optional filter).
- `OUT_PATH` — absolute path to write the brief to.
- `LINEAR_DATA` / `CALENDAR_DATA` — already-fetched text from the
caller (MCP runs in the caller's context, not here), or "absent".
Iron Laws
1. **Never re-resolve the time window** — trust `SINCE_*` from the prompt. Compare every event on `SINCE_ISO` (absolute instant). 2. **Excerpt-only** — one-line excerpts, never raw issue/PR/thread bodies. Privacy default is opt-out. 3. **Prioritize, don't dump** — every brief item answers "why does this need me". Drop bot PRs, your own merged work, green CI. 4. **Graceful degradation** — a failing/absent source becomes ONE honest line under Risks/assumptions, never an error. `git log` alone is a valid minimum brief. 5. **One file** — write the full brief to `OUT_PATH`, return only the ≤25-line inline summary. 6. **Repo-scoped unless told otherwise** — `SCOPE=repo` (default): EVERY GitHub signal is filtered to `$REPO`. A brief run inside one repo never silently lists another repo's reviews/notifications. `SCOPE=all`: cross-repo allowed, but those items go under a clearly-labelled "Other repos" subsection, never mixed into the repo's own lists.
GitHub recipes (`gh`)
ME=$(gh api user --jq .login)
REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
DEFBR=$(gh repo view --json defaultBranchRef --jq .defaultBranchRef.name)
# --- SCOPE=repo (default): every signal filtered to THIS repo ---
# pinged you, scoped to $REPO (repo-scoped notifications endpoint):
gh api "/repos/$REPO/notifications?since=$SINCE_ISO&all=true" \
--jq '.[] | {reason,title:.subject.title,type:.subject.type}'
# review requested of you, open, in $REPO only:
gh pr list --repo "$REPO" --search "review-requested:@me" --state open \
--json number,title,url,updatedAt --limit 30
# your PRs w/ activity + CI (already repo-scoped):
gh pr list --repo "$REPO" --author @me --state open --search "updated:>=${SINCE_ISO%%T*}" --json number,title,url,reviewDecision,statusCheckRollup --limit 30If `SCOPE=all`, ALSO run the cross-repo forms below and put their results under a separate **Other repos** subsection (never merged into the repo's own lists), plus one Risks line naming the scope:
# cross-repo pings (only when SCOPE=all):
gh api "/notifications?since=$SINCE_ISO&all=true" \
--jq '.[] | select(.repository.full_name != "'"$REPO"'") | {reason,title:.subject.title,repo:.repository.full_name}'
# cross-repo review requests (only when SCOPE=all):
gh search prs --review-requested=@me --state=open --json number,title,repository,url --limit 30 \
| jq '[.[] | select(.repository.nameWithOwner != "'"$REPO"'")]'`gh search updated:>=DATE` is UTC date-granular — coarse pre-filter only; confirm each item's timestamp against `SINCE_EPOCH` before it enters the brief. Drop `dependabot`/`renovate`/`github-actions` unless `FOCUS` asks. `DEPTH=quick` → counts + top 3, skip the per-PR calls.
Timestamp discipline (bites hardest in `--scope all`)
GitHub `updatedAt`/`createdAt` and notification times are **UTC (trailing `Z`)**. Two hard rules — a narrow window punishes both:
1. **Each item is judged on its OWN controlling timestamp ≥ `SINCE_EPOCH`.** Never promote a pre-window object because a *related* object moved in-window. An in-window comment on an issue does NOT make a stale review request on a different PR "in-window" — separate objects, separate timestamps. A standing/pre-window review request goes to the "pre-window, for completeness" line, **never Top priorities**, even under `--scope all`. 2. **Render clock times in `LOCAL_TZ`.** Convert the `Z` value before printing (`TZ=$LOCAL_TZ date -r <epoch>`). Never print a UTC value with a local-TZ label — `06:36:23Z` is `08:36 CEST`, not `06:36 CEST`. If unsure, print the ISO `Z` and label it UTC.
Git recipes (always available — the floor)
GME=$(git config user.email)
DEFBR=${DEFBR:-$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's@^origin/@@')}; DEFBR=${DEFBR:-main}
git fetch --quiet origin "$DEFBR" 2>/dev/null || true
# commits by others in window:
# TAB-delimited (%x09): subjects often contain '|' — never use '|' as
# the field sep. macOS awk does not grok -F'\x1f'; a real tab does.
git log "origin/$DEFBR" --since="$SINCE_ISO" --no-merges --pretty=format:'%h%x09%an%x09%ae%x09%s' | awk -F'\t' -v me="$GME" '$3!=me'
# risk scan — per-commit diff-tree (NOT `git log --name-only`: log
# history-simplification silently drops files for many commits; on
# a busy repo it under-counted 140→44, which would MISS a landed migration):
git log "origin/$DEFBR" --sinceClaude Code is great. But it doesn't know that assign_new silently skips on reconnect, that :float will corrupt your money fields, or that your Oban job isn't idempotent. This plugin does.
Repo: oliver-kriska/claude-elixir-phoenix
Other agents on claude-elixir-phoenix.
- docs-validation-orchestrator
CONTRIBUTOR TOOL - Orchestrates plugin validation against latest Claude Code documentation. Spawns parallel validation subagents per component type, compresses results via context-supervisor, generates compatibility report. Use proactively when running /docs-check. NOT
Open agent - phoenix-project-analyzer
CONTRIBUTOR TOOL - Analyzes Phoenix projects to discover patterns, pain points, and plugin improvement opportunities. Use this agent when gathering insights from real codebases to identify gaps in the plugin's skills and agents. NOT distributed as part of the plugin - only
Open agent - skill-effectiveness-analyzer
Analyzes skill effectiveness data to identify failure patterns and recommend improvements. Use after /skill-monitor flags underperforming skills.
Open agent - ash-policy-reviewer
Ash policy security reviewer — audits policies, checks, and authorization rules for gaps, bypass patterns, and ordering hazards. Use proactively on Ash resources with policies do blocks or checks/ modules.
Open agent - ash-query-optimizer
Ash query optimizer — detects N+1 loads, suggests aggregates over load+Enum, identifies calculation vs load tradeoffs. Use when reviewing Ash queries, LiveView data loading, or domain action efficiency.
Open agent - ash-resource-designer
Ash resource architect — designs resources the "Ash Way" with built-in changes, validations, types, and policy checks before hand-rolling. Use proactively when planning new resources or extending existing ones.
Open agent

