daily-work-summary

name	daily-work-summary
description	Use when asked to summarize what one person or a small set of GitHub identities did over a recent time window, especially daily work reports across org repos. Produces a plain-language activity summary grouped by shipped, closed/replaced, in progress, and planning work, with source links appended to each item.

Daily Work Summary

Use this skill to answer questions like:

• what did this person do in the last 24 hours?
• give me a daily summary for osolmaz/dutifulbob
• what the hell did this guy do bro?
• summarize their work yesterday across this org

Workflow

1. Define the scope before collecting data.

• Identify the time window using concrete timestamps.
• Identify whether multiple GitHub usernames are one person or separate people.
• Identify the orgs/repos to include.
• Respect explicit exclusions such as no comments, only merged, only openclaw org repos, or include closed.

2. Query GitHub with gh, not the GitHub connector.

• Prefer gh search prs and gh search issues for broad discovery.
• Search both --author and --involves when the user expects all activity, but do not automatically report old third-party items that only had label/comment churn.
• Use --owner <org> or repo qualifiers when the user gives an org/repo boundary.
• Fetch details with gh pr view or gh issue view when state, merge status, author, title, timestamps, labels, or URLs are unclear.

Create a local collection artifact before writing the summary:

• Create a temporary folder under /tmp, for example /tmp/daily-work-summary-YYYY-MM-DD-USER.
• Save the raw search outputs, enriched PR/issue details, and final candidate classification there. Use JSON, JSONL, Markdown, or another easy-to-inspect text format.
• The artifact must include enough evidence to audit inclusion decisions: repository, number, title, URL, state, author, created/updated/closed/merged timestamps, mergedBy, labels, closing issue references, relevant comments/reviews by the target identity, relevant automation metadata, and why the item is included, grouped, or excluded.
• Use this artifact as the reference for the final summary. Do not write the final summary directly from ad hoc terminal output.
• Before writing the final summary, verify the artifact folder exists and contains the enriched candidate/classification file. If the artifact is missing, stop and create it; do not produce a summary from memory or terminal scrollback.
• Do not include the /tmp artifact path in the final summary unless the user asks for audit details.

Useful starting commands:

gh search prs --owner ORG --author USER --updated ">=YYYY-MM-DDTHH:MM:SSZ" --json repository,number,title,state,isDraft,author,createdAt,updatedAt,closedAt,url
gh search prs --owner ORG --involves USER --updated ">=YYYY-MM-DDTHH:MM:SSZ" --json repository,number,title,state,isDraft,author,createdAt,updatedAt,closedAt,url
gh search issues --owner ORG --author USER --updated ">=YYYY-MM-DDTHH:MM:SSZ" --json repository,number,title,state,author,createdAt,updatedAt,closedAt,url
gh search prs automerge --owner ORG --commenter USER --match comments --updated ">=YYYY-MM-DDTHH:MM:SSZ" --json repository,number,title,state,author,updatedAt,url
gh pr view PR --repo ORG/REPO --json number,title,state,author,createdAt,updatedAt,closedAt,mergedAt,mergedBy,url,body,closingIssuesReferences,comments,reviews,labels

3. Decide what counts as reportable work.

Include:

• PRs authored by the target identity in the window.
• PRs merged, closed, or materially updated in the window when they belong to the target identity.
• Replacement/follow-up PRs generated by automation when they clearly replace or land the target identity's work.
• Issues opened by the target identity when they are planning, prompt requests, triage requests, or task requests.
• Closed or merged work when the user asks for closed work or a full daily report.
• PRs by other authors that the target identity explicitly merged, approved, or routed into merge automation.
• Merge-command comments such as @clawsweeper automerge, @clawsweeper approve, /merge, or equivalent maintainer approval commands.

Exclude unless the user asks:

• Raw commit links as report items or trailing sources.
• Comments as standalone activity.
• Comments that only ask for review, explain status, add proof, or discuss implementation.
• Old third-party PRs/issues that only changed because of label churn, bot comments, or review routing.
• Draft-only bookkeeping that does not reflect a concrete work item.
• Per-user attribution when the user says multiple identities are one person.
• PRs that merely mention the target identity in bot review prose, "likely related people" sections, changelog credit, commit attribution, or broad search text.

Effective ownership rules:

• Treat broad search results as candidates, not facts. Before including a PR, verify it with gh pr view --json comments,body,author,mergedBy,mergedAt,closingIssuesReferences.
• Include a third-party PR only when the target identity directly commented a merge/approval command, directly reviewed or approved it, directly merged it, or a replacement PR body explicitly says automerge was requested by that identity.
• If the user asks for "PRs I merged", include PRs the user routed into automerge only after verifying the actual automerge command or replacement metadata. Do not infer ownership from org-wide merged PR lists.
• For automation replacement flows, group the source PR, replacement PR, and linked issue as one work item. Use the replacement PR as the effective landed PR, but keep the source PR link for provenance.
• Distinguish activity counts when asked: comment instances are actual command/comment occurrences by the target identity; PR records are source/replacement/open PRs; work items are grouped user-visible tasks.

4. Verify suspicious gaps.

• Deep-dig before writing. Build a candidate set from all relevant activity channels: authored PRs/issues, involved PRs/issues, commenter PRs, reviewed PRs, merge-command searches, replacement/automerge metadata, and closed/merged PRs when the user asks for shipped work.
• Do not stop after the first plausible list. Cross-check counts across authored, commented, involved, reviewed, merge-command, and replacement/automerge searches.
• For each candidate in the /tmp artifact, classify it as include, grouped-with, or exclude, with the reason based on verified PR/issue details.
• If the user asks about merged/automerge work, count both command-comment instances and effective landed PRs, then group source/replacement PRs before producing the final summary.
• If the result feels too small, broaden from --author to --involves.
• Check both PRs and issues.
• Check closed/merged states, not only open work.
• If a bot-authored PR appears, inspect labels/title/timeline enough to decide whether it is a real continuation of the person's work or just automation noise.
• Check merge-command activity separately from authored work. Filter out PRs authored by the target identity when the user asks for work from others that the target merged.
• Use commits only as internal evidence to understand branch-only activity. In the final report, link the related PR, issue, branch compare page, or omit the item if there is no good non-commit source.

5. Cluster repeated work into one item.

• If several PRs/issues are the same work item, report them as one bullet.
• Cluster closed/replaced PRs with the replacement PR that landed or remains open.
• Cluster bot follow-up PRs with the human-authored PR they replaced when the relationship is clear.
• Append all source links at the end of the same bullet, in the order that best explains the story.

Output Format

Return only the summary. Do not add a preamble, correction note, explanation, apology, or wrapper sentence such as Here is..., Corrected..., or I found.... Do not include a Scope: line or timestamp-window line unless the user explicitly asks for audit details. Scope and collection window are internal collection context, not report content.

Start with a title in this shape:

# NAME Daily Summary - YYYY-MM-DD

Use the person's real name, username, team name, or short scope label for NAME, based on the user's request. Use a single ISO date for the report date. For rolling windows such as last 24h, use the end date in the user's local timezone. Use a date range such as 2026-05-20..2026-05-22 only when the user explicitly asks for a multi-day summary.

Use concise sections by default:

• Shipped
• Closed / Replaced
• In Progress
• Merged / Approved Others
• Planning

Omit empty sections.

Section rules:

• Put every landed work item under Shipped, regardless of whether the target identity authored it, directly merged it, or routed it through automerge/replacement automation.
• Use Merged / Approved Others only for meaningful target-identity approval or merge-routing activity that did not produce a landed work item in the report window, or when the user explicitly asks to separate approvals from shipped work.
• Do not split a landed source/replacement work item between Shipped and Merged / Approved Others; keep the grouped item under Shipped.

Each bullet must be plain language and append the link at the end:

- Generic embedding-provider contract so plugins can provide embeddings through a shared API. https://github.com/org/repo/pull/123

When multiple PRs/issues are the same work item, keep one bullet and put multiple links at the end:

- Provider-auth startup fix so gateway prewarm waits until after startup. https://github.com/org/repo/pull/456 https://github.com/org/repo/pull/457

Example:

# Onur Daily Summary - 2026-05-22

**Shipped**
- Generic embedding-provider contract so plugins can provide embeddings through a shared API. https://github.com/openclaw/openclaw/pull/84947
- Provider-auth startup fix so gateway prewarm waits until after early startup work. https://github.com/openclaw/openclaw/issues/63229 https://github.com/openclaw/openclaw/pull/85272 https://github.com/openclaw/openclaw/pull/85369
- ACPX status fix so dead/stale helper PIDs stop showing as active, closing the stale-session report. https://github.com/openclaw/acpx/pull/338 https://github.com/openclaw/openclaw/issues/48580 https://github.com/openclaw/acpx/issues/185
- ClawHub publisher-title clipping fix. https://github.com/openclaw/clawhub/pull/2371

**In Progress**
- OpenAI-compatible embeddings through the existing OpenAI plugin, including memory and gateway support. https://github.com/openclaw/openclaw/pull/85269
- Local embedding safety for Apple Silicon: worker isolation, safer fallback behavior, and removal of the proposed `memorySearch.local.gpu` config surface. https://github.com/openclaw/openclaw/issues/44202 https://github.com/openclaw/openclaw/pull/85348
- Passing resolved model/provider runtime through auth, streaming, compaction, and embedded agent runs. https://github.com/openclaw/openclaw/issues/80487 https://github.com/openclaw/openclaw/pull/85373

**Planning**
- ClawSweeper prompt request so config-value additions require maintainer review. https://github.com/openclaw/clawsweeper/issues/171

Style Rules

• Do not say worked on, built a draft, started working on, or other filler that adds no information.
• Prefer nouns and concrete outcomes: OpenAI-compatible embeddings..., Provider-auth startup fix..., ClawSweeper prompt request...
• Summarize the current outcome or intended behavior, not the process history. Do not mention authored/routed/reviewed/re-reviewed, queued commands, multiple review passes, intermediate rejected approaches, pauses, or "linked issue remains open" unless the user explicitly asks for workflow history.
• For in-progress items, state the current technical direction or user-visible goal in one concise phrase. Avoid status narration like revised the approach away from..., queued multiple re-reviews, or left it ready for maintainer judgment.
• Keep bullets short enough to scan.
• Do not quote comments or PR bodies unless the user explicitly asks.
• Do not tag which alias did each item when the aliases are one person.
• If excluding noisy results, add one short note after the list explaining the exclusion.