matchai/dotfiles/monthly-perf-checkin

Monthly Performance Check-In

Use this skill to answer “What did you ship?” and “Where do you want to grow?” from evidence. Write concise retrospective performance-check-in prose, not a changelog.

Quick start

When the user names a month, gather the full calendar month with inclusive start and exclusive end boundaries:

April 2026 => 2026-04-01T00:00:00Z through 2026-05-01T00:00:00Z
May 2026   => 2026-05-01T00:00:00Z through 2026-06-01T00:00:00Z

Then produce one paragraph per question. If comparing adjacent months, say whether any wins should move between months.

Evidence gathering workflow

Gather all sources in parallel before drafting.

1. Previous check-ins

• Read the PerfBot DM D0B859HFUV8 (https://vercel.enterprise.slack.com/archives/D0B859HFUV8) with the Slack MCP slack_read_channel tool. It holds every submitted check-in with its rating, "What you shipped", and "Where you want to grow".
• Match the length, voice, and level of detail of recent submissions.
• Do not repeat wins already claimed in an earlier month.
• Follow through on earlier growth areas: say whether the month showed progress on them, and avoid restating the same growth theme without new evidence.
• Note that the form also asks for a self-rating. Show the ratings from recent months for reference, but leave the choice to the user.

Coverage is mandatory. Read every Slack message the user sent during the month and every PR they authored during the month. Sampling, keyword searches, or titles alone do not count. Do not draft until coverage is complete. If a source cannot be read in full (access, rate limits, tool errors), stop and report exactly what is missing instead of drafting from a partial read.

1. Slack

• Use the Slack MCP server tools.
• Page through every message from the user for the month with from:<@USER_ID> after:YYYY-MM-DD before:YYYY-MM-DD (public, private, and DMs), following the pagination cursor until no pages remain. Record the total count.
• Read the full thread for every message that started or replied in a thread with substance: launches, project updates, design discussions, metrics, beta/customer feedback, incidents, and blockers.
• Also read the project channels and coordination channels where the user's work was discussed, including others' messages that credit, request, or depend on the user's work.
• Prefer channel IDs from Linear project metadata when names are missing from cache.
• Follow links to RFCs and planning docs (for example with the Notion MCP server) when they describe the user's work.

1. Linear

• Use the Linear MCP server tools (for example list_issues, list_projects, get_status_updates, list_comments).
• Fetch project metadata, milestones, status updates, and issues updated during the month.
• Treat Linear project updates as high-signal summaries, but verify with GitHub/Slack before making ownership claims.

1. GitHub

• Use gh read-only commands.
• Determine the authenticated login with gh api user --jq .login.
• Search authored PRs created, merged, or updated during the month across all repos. gh search caps results at 100 per query, so split the month into date ranges until every range returns fewer than 100, and record the total count.
• Read the full body of every authored PR from the month, including closed and still-open ones; titles alone are not enough. For PRs with empty or thin bodies, read the diff stat and key changes.
• Search local git history for authored commits in likely repos.

1. Repo history

• For known project repos, inspect merged PRs and commits on main during the month.
• Separate personal contributions from team-wide project movement.
• Note access limitations instead of guessing.

Synthesis rules

What did you ship?

Write one paragraph unless the user asks for bullets. Lead with shipped outcomes, then supporting proof.

Prefer:

• “Shipped X, which enabled Y.”
• “Reduced A from B to C.”
• “Moved Z from prototype to production by landing…”

Avoid:

• Long PR lists.
• Internal implementation detail without outcome.
• Claiming team-wide progress as personal work.
• Saying “worked on” when the question is “shipped.”

Use metrics when verified: latency, coverage, merged PR counts, test counts, cost reduction, milestone completion, launch state.

Where do you want to grow?

Write one retrospective, forward-looking paragraph. Tie growth areas to what the month revealed.

Good growth themes:

• Turning prototype evidence into team-wide alignment.
• Operating production agent systems with stronger observability and rollout discipline.
• Improving reliability for state machines, approvals, streaming, and recovery paths.
• Communicating tradeoffs and migration paths earlier.
• Balancing speed with safety in multi-repo changes.

Avoid generic self-improvement. Do not repeat the shipped paragraph in weaker words.

Month attribution

When work spans months, assign wins by where the outcome landed:

• Prototype built or benchmark proven => prototype month.
• Production integration, rollout, or measured platform impact => integration month.
• PR opened but not merged => usually “in review,” not shipped.
• Local-only work => mention only if it produced a demo, milestone, or clear shipped artifact.

If the user asks whether to “spread wins,” recommend moving only the parts that truly shipped in the later month.

Output style

• Default to one paragraph per question, under ~120 words each unless asked for detail.
• Use first person for the user's review: “I shipped…” for personal work and “helped ship…” for team-wide outcomes.
• Mention repos/projects only when they clarify the shipped outcome.

Verification checklist

Before finalizing, state coverage counts (Slack messages read, threads read, PR bodies read out of total authored), confirm every source was read in full or name exactly what is missing, month boundaries are correct, ownership is clear, shipped outcomes are concrete, growth is retrospective/forward-looking, and any attribution recommendation is explicit.