daily-handoff
Use when authoring a daily Slack handoff for the Blackbird team - status-first narrative with indented PR bullets using :merged: / :review: emoji.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when authoring a daily Slack handoff for the Blackbird team - status-first narrative with indented PR bullets using :merged: / :review: emoji.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Use when ingesting, refreshing, listing, searching, or deleting a local corpus with Blackbird code search and `gh blackbird search --fileset`.
Use when reaching for `gh blackbird` (Blackbird code search) for cross-repo lexical, symbol, or semantic search on GitHub — finding callers, ownership, or how systems work without cloning.
Use when creating a GitHub pull request, or when updating an existing PR's title or body so it matches what the code actually does.
Use when authoring or substantially editing a design doc, architecture doc, or subsystem explanation — the "here's what's there and why" companion to an ADR's terse decision record.
Use when creating a repo-tracked multi-agent planning PR for a large project, especially when phases, living docs, parallel agent prompts, and cross-PR coordination are needed.
Use when about to call a library, crate, or framework API you haven't verified, when a dependency's behavior is surprising, when training-data memory might be stale, or when investigating how a dependency actually behaves.
| name | daily-handoff |
| description | Use when authoring a daily Slack handoff for the Blackbird team - status-first narrative with indented PR bullets using :merged: / :review: emoji. |
| user-invocable | true |
Author a daily handoff message for the Blackbird team, formatted for Slack. Output a fenced markdown block the user can copy directly.
A handoff covers activity since the last one — typically the last 24 hours, but extend the window back across weekends and holidays (e.g. on Monday, look back to Friday morning). Ask the user if the lookback window isn't obvious.
Bulleted PRs are always the user's own PRs. :merged: and :review: both refer to PRs the user authored. PRs the user only reviewed/approved/commented on are not bulleted.
Personal-account PRs are excluded. The handoff is for the Blackbird team, so PRs in the user's personal account (tclem/*) are side projects and do not appear anywhere in the handoff (not in the main message, not in the thread). Work in any organization (github/* is typical, but the user occasionally contributes to other orgs too) is eligible. When in doubt about an unfamiliar org, ask the user rather than dropping it. This is separate from the github/github-app thread rule below.
Two sources:
Merged-in-window authored PRs. The reliable query uses --merged-at (catches PRs created earlier but merged during the window):
gh search prs --author=@me --merged \
--merged-at=">=$(date -v-1d -u +%Y-%m-%dT%H:%M:%SZ)" \
--json url,title,repository --limit 100
gh-log can also produce a merged list, but its created: filter misses PRs that were created before the window and merged inside it — prefer gh search --merged-at. Filter the results to drop any PR whose repository.nameWithOwner starts with tclem/.
Still-open authored PRs (for :review: bullets):
gh search prs --author=@me --state=open \
--json url,title,repository,updatedAt --limit 50
Filter to PRs updated in the window or that the user is actively pushing. Drop tclem/* PRs. Drop dependabot / auto-merge noise unless the user calls it out.
Cross-reference with session context — prefer what you already know over re-fetching.
The handoff is status-first, with PRs as supporting evidence — not the other way around. Each top-level bullet is a narrative paragraph about a work stream, blocker, or meta update; PR bullets nest underneath.
@handle and reference channels with #channel.* github-app progress in :thread: (see below).Nest PR bullets under the narrative bullet they support. Use four leading spaces before nested PR bullets; two spaces can render inconsistently in Slack.
* Narrative paragraph for this theme — status, blockers, what's next.
* :merged: [<title>](https://github.com/org/repo/pull/N)
* :review: [<title>](https://github.com/org/repo/pull/N) -> optional inline commentary
:merged: — PR authored by user, merged in window.:review: — PR authored by user, still open.-> will try this out tomorrow, low priority.) is encouraged when useful.tclem/*). These are side projects and are excluded by default from both the main message and the thread. Org-owned repos (github/* and any other orgs the user contributes to) are eligible — only the personal account is filtered. This is distinct from the github/github-app thread rule, which only relocates eligible org PRs into the thread block.commenter: search qualifier includes approvals, so gh-log's "commented on" bucket conflates real discussion with routine approvals — use it only as narrative hints, never as bullets. Verify with gh pr view <url> --comments before framing anything as "discussing."PRs in github/github-app (or any other org repo the user flags for the thread) go in a separate second fenced block for the Slack thread reply. This is only about relocating eligible org PRs into the thread — personal-account PRs (tclem/*) are dropped entirely per the filtering rule above and never appear here. End the main message with:
* github-app progress in :thread:
Two fenced code blocks. The first starts with Handoff::
```
Handoff:
* Meetings / context line (specific if possible).
* <On-call narrative if applicable — how the day went, what landed, what didn't, who helped>.
* <Theme 1 narrative: status, blockers, what's next>:
* :merged: [<title>](https://github.com/org/repo/pull/N)
* :review: [<title>](https://github.com/org/repo/pull/N)
* <Theme 2 narrative, with explicit blockers if any>:
* :review: [<title>](https://github.com/org/repo/pull/N) -> optional inline note
* github-app progress in :thread:
```
Second block for the github-app thread reply, same format.
After producing the two fenced blocks, always save the handoff to the tclem/notes repo without asking first.
Use the user's notes checkout even when the current session is running in another repo. The usual path is:
~/github/notes/notes/
Filename format:
notes/YYYY-MM-DD-handoff-NN.md
Determine NN by finding the highest existing handoff number under notes/notes/ and incrementing it. For example:
find ~/github/notes/notes -name '*-handoff-*.md' -print |
sed -E 's/.*-handoff-([0-9]+)\.md$/\1/' |
sort -n |
tail -1
If the latest file is 2026-05-11-handoff-53.md, the next file is YYYY-MM-DD-handoff-54.md using today's date.
Saved file format:
# Handoff NN
Tags: #handoff #project-tag
<main handoff fenced block, verbatim>
<thread reply fenced block, verbatim>
Infer project tags from the handoff content, e.g. #blackbird, #github-app, #copilot, or other obvious project names. Keep tags lowercase and hyphenated when needed. Preserve both fenced blocks verbatim in the saved file so the note exactly matches what the user can paste into Slack.