Claude Prompt for Work Log.md

A developer created a detailed specification for a Work Log generator that automatically compiles engineering work from GitHub, Linear, and Notion into a structured document with themes, monthly timelines, and project planning sections. The tool supports both update and regenerate modes, integrating new data since the last generation date.

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