Guesstimate my timesheets

What it does

It looks at your calendar, your claude cowork usage, your slack messages, emails etc to estimate your timesheets from the previous week. It uses Roger to get actual timecodes and then outputs a list to you in cowork with reasoning, so it's easy for you to then fill out runn. ta-da!

When to use

• when your memory is bad and your time was fractured

The skill

Produce a guesstimated timesheet breakdown for the user covering the previous Monday–Sunday (the calendar week that just ended), unless they ask for a different week. This is for them to sanity-check and enter into Runn — post the result as a chat message; do not create a Notion page or artifact for it.

Connectors needed: Roger (Runn project lookup), Google Calendar, Slack, and Cowork session history. If one is missing, say so and work from the rest, flagging the reduced confidence.

Step 0: Establish the user's working pattern

Don't assume a Mon–Fri five-day week. Check the week's calendar for non-working-day markers (out-of-office events, "non-working day", part-time patterns, booked leave, bank holidays). A day with no calendar, Slack, or Cowork activity at all is probably also a day off. Skip those days — note them plainly as "day off" with no hours.

Assume a working day is 8 hours unless the user has told you otherwise in this conversation or their preferences.

Step 1: Get valid time categories from Roger

Call Roger's setup-search-runn tool with an empty query to list current Runn projects (search again by client name if the capped list is missing one you expect). Entries look like:

• Client delivery codes, e.g. "AMT-002 Account Management Design" (client Amtivo)
• Business development codes per client, formatted "BD-<CLIENT>-000" — use for pitching, scoping, and proposal work for a prospect or an existing client's next phase
• "PLA-002 Internal Work" (client "Planes ✈️") — internal meetings, 1:1s, admin, ops, skill-building, feedback/reviews. Other PLA codes exist (L&D, new business, marketing) — use the closest fit.

Map everything you find below onto a real project name + code. If something doesn't clearly map to a listed project, label it "Unmapped — needs a Runn project" rather than guessing a code that doesn't exist.

Step 2: Gather signal for each day of the week

For each day:

1. Calendar — list the user's events for that day (00:00–23:59, Europe/London). Note meeting titles, attendees/domains (client email domains indicate which client), and durations. Exclude personal blocks (lunch, "please don't book" holds, travel that isn't for a client) from billable time, but use them to work out the shape of the working day.
   • Attendance rule: treat an unanswered invite as a meeting the user very likely skipped. Check their own RSVP (responseStatus) on every meeting they didn't organise. If it's needsAction, exclude that meeting entirely — don't count it and don't just flag it as thin evidence — unless clear countervailing signal (Slack or Cowork activity placing them in it) says otherwise. declined is excluded; accepted/tentative and self-organised meetings count as attended. If removing a meeting leaves a gap in the day, reapportion those hours per Step 3 rather than leaving them uncounted.
2. Slack — search with query from:<@USER_ID> after:<day> before:<next day>, sorted by timestamp, where USER_ID is the current logged-in user's Slack ID (it's stated in the Slack search tool's description; otherwise look it up from their email with the Slack user search tool). Use message timestamps to gauge spread across the day, not word-count. Channel names and DM participants usually indicate the client, or whether it's internal/BD.
3. Cowork sessions — list recent Cowork sessions (limit 40+) and read the transcript of any that look like they were worked on that day, to see what was actually built and roughly how much back-and-forth it took. Session titles plus Slack links to Claude-made artifacts often date them without a full transcript read.

Step 3: Estimate hours per day

For each working day, the target is a full 8 hours accounted for — people work full days on their working days, so don't scale the total down to match the visible activity window. Use calendar meeting durations as fixed anchors (after the attendance rule), then apportion the rest of the day across whichever projects the Slack and Cowork signal points to, weighted by how much activity each got. If a day's signal is thin, still fill it to 8 hours with your best judgement (weight towards whichever client dominated that day, or Internal/admin for gaps) — and flag those thinly-evidenced hours rather than omitting them.

Round each line item to a whole hour, always rounding UP at or over 15 minutes (1h20 → 2h; only round down if it's a clean hour or a few minutes over). No fractional hours in the output. Each day's line items must sum to exactly 8 hours — verify this before posting.

Step 4: Output — grouped by project code

Runn is organised by project, so group the output by project code (not day by day). Post a chat message with:

• One section per Runn project, ordered by code (client delivery codes first, then BD codes, then PLA/internal, then Unmapped). Header: code + project name — weekly total. Under it, a bullet per day with hours and a one-line reason:

  AMT-002 Account Management Design (Amtivo) — 5h

  • Mon 27: 3h — playback prep + client playback call
  • Tue 28: 2h — design feedback triage with Jake

• A one-line day-sum check so they can trust the maths, e.g. "Day totals: Mon 8 / Tue 8 / Wed 8 / Thu 8 / Fri day off".

• Days off noted plainly (no hours).

• A short flags section: anything Unmapped, ambiguous code choices (e.g. delivery vs BD for the same client), or thinly-evidenced hours, so the user can correct it.

• A one-line reminder that these are estimates from calendar/Slack/Cowork activity, not tracked time, and to adjust before submitting.

Keep the whole thing concise and scannable — this is a working aid for a 5-minute timesheet fill-in, not a report.