G2 - Always-On PEAK Performance Review Evidence Bank

Performance review self-assessments require recalling six to twelve months of work, but the evidence lives scattered across Asana, Slack, Gmail, meeting notes, Jira and Confluence. Most people write their review from memory in a single painful weekend, under-claim their own impact, and lose credit for real work — especially quantified outcomes that were never captured when they happened. By review season, the numbers that would make the strongest case are unrecoverable.

1. Do the five minutes Claude can't: create a folder, save the attached setup kit into it, create a Claude Cowork project connected to that folder, and connect the tools you actually use (Asana, Slack, Gmail, Google Calendar, Atlassian, Granola or Zoom).

2. Paste the kit's single setup prompt into your first conversation. Claude reads the kit as its build spec, probes every connector, then interviews you for the personal details it needs — name, title, manager, mandate, spelling — looking up what it can itself: it reads your Slack member ID from the connection, proposes your key projects from where your completed tasks actually land, and proposes priority channels from where you actually post, so you confirm instead of hunting for IDs.

3. Watch it build the rest: it writes your personalised instructions file into the folder, creates the append-only Evidence_Log.md and STATE.md, runs the baseline scan across the whole review period (starting today still captures February), generates the first evidence bank document plus a metrics tracker, and reports your three biggest evidence gaps.

4. Approve one permission prompt at the end: if — and only if — the connector tests and baseline passed cleanly, Claude creates the daily scheduled scan itself. If something's broken, it names the fix and waits rather than automating a broken config.

5. From there it runs itself: the daily task appends new evidence with source citations and value tags. Say "refresh" around the 1st of each month to fold the log into the formatted evidence bank, with new items tagged [NEW], and close or consciously drop any still-empty metrics row as the review window approaches.

Setup is one pasted prompt and a short interview — Claude configures itself, fills in its own instructions from your answers, and schedules its own daily automation; after that the system runs itself. The self-assessment gets written from a stocked, source-cited evidence bank instead of memory — months of work that would otherwise be forgotten is captured the day it happens, with the metrics attached, and review-season prep drops from days of archaeology to a drafting session. The system also transfers: the same kit has been adopted by other team members running their own copies for the same review cycle.

Start from the attached setup kit rather than building from scratch — it contains the setup prompt, the instructions template the prompt builds from, the daily-scan spec, and the lessons from six months of running the system. Two design details make the one-prompt setup work: the kit file is saved into the project folder so Claude can read its own build spec, and the personalised configuration is written to a CLAUDE.md in that folder — which every future session and scheduled run loads automatically — rather than asking the user to hand-edit templates. The interview derives answers from the user's own data wherever possible (Slack member ID read from the connection, projects proposed from where completed tasks land, channels proposed from posting activity), so the user confirms rather than hunts.

Note the deliberate gate in the bootstrap prompt: the daily scheduled task is only created if the connector tests and baseline scan pass cleanly, because a daily automation that fails silently is worse than none. Dedupe everything by stable source IDs (Asana task gid, Slack permalink, Jira key, Gmail thread ID) so daily scans never double-log. Pick one source as the chronology anchor — task-tracker completion dates work; Slack timestamps are unreliable. Keep the append-only log separate from the generated document so automation can never corrupt the deliverable. Anchor every scan window to the log's most recent entry rather than a fixed date. Log connector failures as their own entries instead of silently skipping a source. Tag items added since the last document build as [NEW] so review-prep sessions focus on what changed.

Requires the relevant connectors (Asana, Slack, Gmail, calendar, meeting notes) to be authorised, and a scan can silently under-collect when a connector is down — which is why failures are logged rather than skipped, and why the daily automation is only created once checks pass. Scheduled tasks run while the Claude desktop app is open and catch up on next launch, so a machine that stays shut for a week scans nothing until it reopens. The framework, channels and search parameters are company- and role-specific and need adapting before reuse. Evidence quality depends on work leaving traces in tools: undocumented meetings and hallway decisions never enter the log. Daily scans need tightly scoped search parameters or they get slow and noisy.