/impact-timeline

name: impact-timeline
description: Build a month-by-month career impact timeline across an entire tenure (or any multi-month window), sweeping every available source (GitHub, issue tracker, Slack, Notion, meeting notes like Granola, the company BI/data platform, Datadog, Sentry) one month at a time, then attaching real product/technical/business metrics to every entry in "accomplished X, measured by Y, by doing Z" form. Use this whenever the user wants a tenure retrospective, a departure/offboarding impact record, "everything I did at this company", a promotion or performance-review packet covering many months, a year-in-review, or asks to add metrics/evidence to an existing career document. For a single day/week/month recap, use `/flagrare:standup-report` or `/flagrare:brag-doc` instead; this skill is for the long arc.

Impact Timeline

> **No em-dashes.** Nothing this skill writes may contain an em-dash; use a comma, colon, or parentheses instead. Enforced by a repo hook that flags em-dashes in generated `.md`. See `/flagrare:write-docs`.

Produce a durable, evidence-backed record of a person's impact over a long window (typically a full tenure), month by month, from every system that holds a trace of their work. The output is a single markdown file the person can carry into interviews, reviews, and their next job.

Two properties make this document worth building:

1. **Every month is swept in every source before moving on.** Ticket trackers show what was planned; git shows what shipped; Slack shows judgment, debugging, and unblocking that never became a ticket; meeting notes show praise, decisions, and assignments nobody wrote down elsewhere; the BI platform shows what the work meant to users and money. Any single source alone badly undercounts a year of work. 2. **Every claim carries a "measured by".** The difference between a changelog and an impact record is the Y in "accomplished X, measured by Y, by doing Z". Numbers where they exist, scale qualifiers where they don't, and honest caveats where the data is thin.

Read `references/playbook.md` before starting: it holds the per-source query recipes (exact gh/search syntax, Slack modifiers, meeting-notes questions, BI-platform access patterns) learned from real runs. The workflow below is the spine; the playbook is the muscle.

Phase 0: Setup and identity

Establish before pulling anything:

• **Window**: start and end dates. Verify the claimed start date against the data (first PR, first Slack message); people misremember by days.
• **Identities**: GitHub login, tracker mention name, Slack user ID, work email, meeting-notes account. Watch for imposters: old commits by a similar name/personal email may be a different person entirely. Verify by email, not by first name.
• **Repos**: include archived/deprecated repos explicitly; early-tenure work often lives in a repo that was later retired. Ask, and also look for `_deprecated`/archive directories locally and archived repos in the org.
• **Output file**: create it immediately (e.g. `~/Dev/impact-timeline-export/impact-timeline.md`) and write each month as it completes. Never hold twelve months of findings in memory; a long run can be summarized mid-flight and progressive writes are what protect the work.
• **Reuse config** from the shared `~/.claude/skills/flagrare/config.json` if present (top-level `github_login`, `display_name`, org and tracker keys written by `/flagrare:brag-doc` and `/flagrare:standup-report`) rather than re-asking. Nest anything impact-timeline-specific under `skills["impact-timeline"]` and leave other skills' blocks untouched.

Phase 1: Bulk enumeration (once, up front)

Pull the cheap complete datasets in one pass and bucket by month locally, instead of querying per month:

• All authored PRs (created date, merged date, repo, number, title) via search API, paginated. Save as TSV next to the output file.
• All reviewed PRs (same shape, `reviewed-by:` minus `author:`).
• Monthly counts (created, merged, reviews) to see the shape of the year before writing a word.

These TSVs are also part of the deliverable; keep them in the export folder.

Phase 2: Month loop

For each month, in order, gather then write before advancing. Per month:

1. **PRs** from the TSVs: created that month, merged that month (including ones created earlier), reviews given. 2. **Tracker**: stories owned and completed in the month (completed-date range query). Harvest the related entities the API returns for free: epic names and states, iteration dates, objective names, requesters, severity/priority fields. Epics that closed "done" with the person's stories in them are headline material. 3. **Slack**: one search of the person's own messages for the month. Standup updates reconstruct narratives; #eng-team threads reveal debugging and unblocking; escalations reveal incident work. A second targeted search when something interesting surfaces (an incident, an initiative) is worth it; five searches per month is not. 4. **Meeting notes** (Granola or similar): defer to Phase 3's bulk queries unless a month's other sources hint at something meetings would confirm (an outage, a demo, a decision). 5. **Write the month's section** in the output file: story-of-the-month lead, "What I shipped" with outcome-first bullets, judgment/unblocking blocks, a Refs footnote with every PR/ticket/epic ID. Follow `/flagrare:brag-doc` voice rules (outcome first, own it, name the judgment, no bland enumeration).

Notion tends to be low-yield per month; search it once per initiative (specs, test plans, architecture docs the person authored) rather than per month.

If `~/.claude/skills/flagrare/senior-scan/contributions.log.md` exists, read it once before the loop: `/flagrare:senior-scan` appends dated, already-vetted contributions there (design-review interventions, unblocking threads, RFC comments), which are exactly the amplification evidence a git/tracker sweep cannot see. Fold entries into their mont