| # 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. |