Audit accomplishments
Personal Claude Code / Cursor agent skills, rules, and config
npx -y skills add paultyng/skill-issue --skill audit-accomplishmentsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when preparing a performance self-reflection, midyear or annual review, promotion packet, or brag document; when asked to collect, mine, gather, or summarize your accomplishments, contributions, or impact over a period; or when assembling cited evidence of work done across GitHub, Jira, Notion, Slack, and local agent histories over the last N months.
SKILL.md
12.0 KB, as published. Nobody here has run it
Audit Accomplishments
Mine a person's contribution evidence across every source where their work lives, over a configurable window, and emit cited achievement summaries for review prep. Collection only — this skill does not draft the review.
Sibling of audit-history: that skill mines sessions to improve agent config; this one mines work across external systems to surface achievements. The local-history + memory discovery is shared — reuse audit-history Phase 1 rather than re-deriving it.
Inputs
- window — default last 6 months. Accept an override as dates (
2026-01-01..2026-06-24) or duration (3 months). Compute concrete start/end dates up front and state them. - sources — default all (below). Accept a subset override.
- taxonomy (optional) — a review template's dimensions / career-level areas, supplied as an arg or a path. When absent, group by discovered theme only; do not invent a rubric.
- output dir — default
./review-material/in the cwd.
Guardrails
- Read-only across every external system. Never post, edit, comment, transition, or mutate.
- Cite everything. Each claim carries a re-fetchable reference (URL,
file:line, ticket id, transcript UUID) so it can be expanded during drafting. - Completion over creation. Weight what was finished in the window (PR merged, issue resolved), not what was opened or merely discussed.
- No invention or embellishment. If a section has no evidence, say so. Stay grounded in what was found.
Phase 1 — Discover identities & sources (mechanical, read-only)
Resolve who the person is on each source and where to look. Do not summarize yet.
- GitHub —
gh auth statusenumerates logged-in hosts/accounts. Record eachhost+login. The person may have multiple (e.g. work + personal); mine all unless overridden. - Jira — call the Atlassian MCP
atlassianUserInfo(server name varies by install) for the account id;getAccessibleAtlassianResourcesfor the cloud id(s). - Notion — get the self user via the Notion MCP (
get-users/ self lookup). - Slack — resolve the logged-in
user_id(the search tool reports it). Mine two axes, since neither alone is complete: (a) authored —from:<@USERID> after:<start>to enumerate the channels the person posts in (a globalfrom:memisses DMs and needs real keywords, not stopwords), then drive Phase 2 per-channel; (b) mentions of the person —<@USERID> after:<start> -from:<@USERID>andto:<@USERID>, surfacing where others defer to, route work to, or @-mention them. Prefer the<@USERID>token over literal-name search — a common first name is noisy and misses @-mentions entirely. - Local agent histories + memory — reuse
audit-historyPhase 1: Claude Code transcripts under~/.claude/projects/*, Cursor under~/.cursor/projects/*, memory under~/.claude/projects/*/memory/. Filter to files modified in the window.
Report a one-screen inventory (accounts found per source, channel count, transcript/memory counts) before proceeding.
Phase 2 — Mechanical raw dump (read-only)
Run read-only queries per source and write raw results to review-material/<source>.*. No interpretation. These are the evidence base and the citation source.
Representative queries (adapt to tool versions; prefer jq -c for JSON):
- GitHub — for each host/account (switch via
gh auth switchorGH_HOST):- Merged in window:
gh search prs "author:@me merged:>=<start>" --json number,title,repository,url,createdAt,closedAt --limit 500 - Opened in window (for in-flight work):
... "author:@me created:>=<start>" - Reviews given:
gh search prs "reviewed-by:@me updated:>=<start>" --json ... - Substantive commits where PR data is thin:
gh search commits "author:@me committer-date:>=<start>" --json ... - Contribution rank (optional — grounds "top/most/primary contributor" claims): only for repos where the person is materially active (derive the repo set from the merged-PR dump above; cap the count to respect rate limits). For each such repo:
gh api repos/{owner}/{repo}/stats/contributors→ per-contributor weekly{w, c, a, d}. Returns HTTP 202 while GitHub computes the stats — retry with backoff until 200. Sum the weeks falling inside the window, then rank the person by commits / additions / deletions. The endpoint caps at the last 52 weeks (fine for the 6-month default; flag the gap for longer windows).- Merged-PR rank: group the window's merged PRs by
user.loginfor a merged-PR-count rank; each PR'sadditions/deletionsgives a line-churn rank. Reviews-per-author is not in the stats endpoint (needs per-PR review listing) — defer. - Ignore bot authors; where feasible exclude generated/vendored paths (they skew additions/deletions). Squash-merge attributes a PR's whole churn to the squash author — note this caveat in the output.
- Iterate gh accounts/hosts as elsewhere in this phase.
- Merged in window:
- Jira —
searchJiraIssuesUsingJql:assignee = currentUser() AND resolved >= "<start>" ORDER BY resolved DESC(primary — completed)(reporter = currentUser() OR assignee = currentUser()) AND updated >= "<start>"(broader activity)
- Notion — search is keyword-based and cannot filter by editor+date directly. Search broadly for likely topics, then
fetchcandidates and keep those whosecreated_by/last_edited_byis the self user and whose edit time is in-window. Capture page title + url + edit date, plus reach + engagement signals (applies to any shared-document source). Record which signal drove the rating:- engagement — comment/discussion volume (
get-comments;fetchwithinclude_discussions). More cross-team discussion ⇒ more relevant. - visibility/audience — lives in a team wiki or org-wide database vs a personal/scratchpad space; shared-to-web; collaborator breadth.
- inbound references (PageRank-style) — how many other docs link to it (search the workspace for the page URL/title). Heavily-referenced docs are load-bearing.
- external corroboration — search Slack for the doc URL to see where it was shared/discussed. Positive-only: Slack retention means absence isn't proof of low reach.
- view/impression counts — not exposed by the Notion API/MCP; rely on the proxies above.
- engagement — comment/discussion volume (
- Slack — three sweeps: (a) authored — per channel from Phase 1,
from:<@USERID> in:<#channel> after:<start>; keep substantive messages (unblocking, explaining, decisions, proposals), drop acks (👍, "thanks", "sgtm") and recurring standups. (b) mentions —<@USERID> after:<start> -from:<@USERID>andto:<@USERID>; this is the richest Collaboration/Influence/Leadership signal (where others route decisions to the person), and afrom:/literal-name pass misses it. (c) praise received — shoutouts / kudos / Bonusly naming the person. Usedetailedoutput to capture resolvable permalinks, not the search tool's raw timestamps. - Local — extract per-transcript work topic + tools + outcomes via
jq(seeaudit-historyextraction patterns). Pull project memory files in-window.
Phase 3 — Fan-out summarization (subagents)
Promote raw dumps into structured achievement cards. Hybrid two-stage:
- Enumerate the work-list per source (cheap; from Phase 2 dumps).
- Fan out summarization subagents only where volume warrants. Subdivide per-artifact (one PR/doc/ticket) for low volume, or per-time-bucket (e.g. per week / per month) when a source has many small items — bucketing keeps each subagent's context tight and preserves chronology.
Each subagent follows subagent-prompt-contract: one-sentence goal, the relevant raw dump pasted inline (do not ask it to re-read this SKILL.md or re-query the source), the card schema below as the output cap, and a Status: prefix line. Use model: haiku for schema-driven extraction, model: sonnet where interpreting impact requires judgment (per subagent-model-routing).
Achievement card schema
- title: <short, outcome-oriented>
- what: <1-2 sentences: what was done>
- impact: <speed | reliability | quality | understanding | cost | scope; quantify if the evidence does>
- timing: <opened YYYY-MM-DD; merged/resolved YYYY-MM-DD> # explicit dates
- evidence: [<re-fetchable refs: PR url, ticket id, Notion url, file:line, Slack permalink, transcript UUID>]
- theme: <discovered grouping>
- dimension: <from supplied taxonomy, if any; else omit>
- rank: <grounded contributor rank when computed: "#1 of N by commits / merged PRs over <window>" with raw numbers; omit otherwise>
- ai_usage: <include ONLY when the work was notably AI/agent-driven; one line on how> # an aspect, not a required field
Phase 4 — Synthesize
In the parent, after subagents return:
- Dedup cross-source. The same work surfaces as a PR and a Jira ticket and a Notion doc and a Slack thread and a transcript. Merge into one card; collect all refs under
evidence. - Group by theme. Cluster cards into a handful of named themes.
- Map to taxonomy (if supplied). Tag each card's
dimension; note which dimensions are well-covered. - Gap-flag. Call out dimensions/themes with thin or no evidence — so the person knows where to add detail or seek opportunities. Do not pad.
- Weight shared docs by reach + engagement. Rank shared-document evidence up when it shows organizational reach/engagement — broad audience, high comment/discussion volume, many inbound links from other docs (PageRank-style), or corroborating Slack shares — and down when narrowly shared, undiscussed, or in a personal scratchpad. Say which signal drove the call; a widely-read, cited, discussed doc is far stronger evidence than a private one. External/Slack signals are positive-only (retention/access gaps mean absence ≠ low reach).
- Ground superlatives with rank. Where a card implies "top / most / primary contributor," attach the computed GitHub rank (
#1 of N by commits / merged PRs over <window>) with the raw numbers. If no rank was computed for that repo, soften the claim — never assert a superlative the stats don't support. - Surface AI-capability examples. Collect cards with an
ai_usageaspect into a dedicated list — concrete examples of AI/agentic work, with citations.
Output
review-material/— per-source raw dumps (retained as the evidence base).review-material/highlights.md— synthesized, grouped, cited cards; a Gaps section; an AI-capability examples section.
Optionally seed reflection with these prompts (answer only from the cards, not invention):
- What did I do that made someone else's job easier?
- Where was there impact — speed, reliability, quality, understanding?
- Which "small wins" might I forget in six months?
Anti-patterns
- Summarizing before the raw dump is written — you lose the citations.
- Relying only on
from:meor literal-name Slack search — misses DMs and @-mentions; also sweep the<@USERID>mention token +to:<@USERID>. - Counting opened/planned work as accomplished — weight completion.
- Asserting "top contributor" or other superlatives without the stats to back them — compute the rank (
stats/contributors+ merged-PR group-by) or soften the claim. - Inventing a rubric when none was supplied — group by theme instead.
- Any write/post/mutate call — this skill is strictly read-only.
- Hardcoding identities, hosts, org names, or level taxonomies — discover them at runtime.
Sources
- Reuses local-history/memory discovery from the sibling
audit-historyskill.