# Claude Prompt for Work Log.md

> Source: <https://gist.github.com/justinrmiller/a2b2ef48afbedf742d4fd91fa3c46ba4>
> Published: 2026-07-09 06:38:17+00:00

| # Generate / Update a Work Log | |
| You are generating (or updating) a **Work Log** — an evergreen summary of one person's | |
| engineering work, sourced from GitHub pull requests, Linear tickets, and Notion docs. | |
| It is both **thematic** (high-level themes) and **chronological** (a month-by-month | |
| timeline). Follow this spec. | |
| ## Configuration | |
| Fill these in before running: | |
| - `GITHUB_USER` — the PR author to query on GitHub. | |
| - `REPOS` — the list of repositories to sweep (owner/name), plus any repo that should be | |
| scope-limited (e.g. "only items relevant to project X"). | |
| - `LINEAR_TEAM` — the Linear team key to pull projects/tickets from. | |
| - `LINEAR_USER` — the Linear user whose authored/assigned issues to include. | |
| - `NOTION_PAGE` — the destination Work Log page id/URL (omit for a fresh page). | |
| - `NOTION_USER` — the Notion user id whose authored docs to fold in. | |
| - `NOTION_SPACE` — the workspace/teamspace to scope the doc search to. | |
| - `START_DATE` — the date the work history begins. | |
| Use whatever tools are available for each source — a connected MCP server, an official | |
| CLI, or the REST API. The commands below are illustrative, not required. | |
| - **GitHub:** query **merged and open** PRs by `GITHUB_USER` across `REPOS`. Skip | |
| closed/unmerged PRs unless notably exploratory (mark those `*(closed/exploratory)*`). | |
| For example, with the `gh` CLI: | |
| `gh search prs --author GITHUB_USER --repo <repo> --sort created --limit 100 --json number,title,url,state,createdAt,mergedAt,closedAt` | |
| - **Linear:** pull projects and tickets from `LINEAR_TEAM` that `LINEAR_USER` authored, | |
| was assigned, or assembled (e.g. list-projects / list-issues operations). Capture id, | |
| title, status, and blocking relationships. | |
| - **Notion:** fold in docs authored by `NOTION_USER` in `NOTION_SPACE` (e.g. search / | |
| fetch operations). If `NOTION_PAGE` is set, that is the page to update. | |
| ## Mode | |
| - **Update (default):** fetch the current page, read the `Last Generated` footer date, and | |
| integrate everything new **since that date** into the existing structure. Do NOT append a | |
| dated changelog block — weave items into the matching thematic/monthly sub-sections and | |
| preserve hand-written prose. | |
| - **Regenerate:** a clean rebuild from scratch following the structure below. | |
| ## Output structure | |
| 1. **Intro** — one-line summary of scope (repos + work since `START_DATE`), a `PR counts:` | |
| line with per-repo counts, and any static bio block (resume, education, languages, | |
| talks) carried forward unchanged. | |
| 2. **## Themes** — 5–7 bullets, each a bolded theme name + em-dash + one-sentence summary. | |
| Derive themes from the actual PR/ticket clusters, not a fixed list. | |
| 3. **## Monthly Timeline** — newest month first, grouped by repository within each month. | |
| - `## <Month Year>` heading, with a one-line italic summary of that month's highlights. | |
| - `### <Repo>` sub-headings under each month. | |
| - Each PR is a bullet: `- [#NNN](url) — <concise, outcome-focused title> (TICKET-ID)`. | |
| Include the tracker ticket id in parens when the PR references one. For repos other | |
| than the primary one, use `[repo #NNN](url)` link text. | |
| - Mark open PRs `*(in review)*`. Group closely related PRs on one bullet with comma- | |
| separated links when they form one logical unit. | |
| 4. **## Project planning (Linear)** — a short intro of any project assembled/led, then | |
| `### Tickets` (each `- [TICKET-ID](url) — title *(status/notes)*`) and a `### Supporting` | |
| list (labels created, planning artifacts, etc.). | |
| 5. **## Notion** — internal docs authored, grouped into logical sub-sections (e.g. Guides & | |
| Operations, Benchmarks, Reference/API Docs, Notes & Essays). Each is | |
| `- [Title](url) — short description`. | |
| 6. **Footer** (italic): `*Last Generated YYYY-MM-DD from GitHub PRs (author: GITHUB_USER) | |
| and Notion. Organized by month.*` — set the date to today. | |
| ## Style rules | |
| - Titles are outcome-focused and concise — describe what the change accomplishes, not the | |
| raw PR title. Keep a professional, terse voice. | |
| - Use em dashes (—) between a link and its description. | |
| - Don't invent PRs, tickets, or docs — only include what the sources return. If a source is | |
| unreachable, note the gap rather than guessing. | |
| - Sort months newest-first; within a repo section, roughly newest-first by created date. | |
| - Preserve horizontal rules (`---`) between major sections. | |
| ## Steps | |
| 1. Fetch the current page (if updating) and note the last-generated date and structure. | |
| 2. In parallel, sweep GitHub (all repos), Linear (the team), and Notion (docs since the | |
| last date). | |
| 3. Reconcile: for update mode, diff against what's already on the page; for regenerate, | |
| build fresh. | |
| 4. Draft the markdown, recompute per-repo PR counts, refresh themes if the balance of work | |
| shifted, and bump the footer date. | |
| 5. Write it back to the destination page — or output the markdown for review first if asked. |