/catch-up

name: "catch-up"
description: "Catch the current user up on a period they were away, across their own work or a project, goal, space, epic or topic, using Teamwork Graph across Jira, Confluence, Projects, Goals, Loom, the calendar and connected tools. Answers in the conversation first: what needs the user, decisions made, changes, missed meetings and what is coming up. Every item is dated inside the window and linked to its source. Offers an HTML report on request, styled with the Atlassian Design System, and publication only when Atlassian Artifacts is available and requested. Use for catch me up, what did I miss, returning from leave or holiday, getting back to a project, or /catch-up. To write a project's weekly status update, use status-check."

Catch-up

Give someone back from time away a catch-up in the conversation that they can read in five minutes: what needs them first, what was decided without them, what changed in the work they care about, which meetings they missed and what came out of them, and what's coming up in the next few days. Keep it to the window they were away for, and leave out anything that doesn't change what they do next.

The value of this skill is the judgement a notification inbox, a project's update feed or a Slack unread count can't make: across every tool at once, which of hundreds of changes need you, which were decisions, and which happened while you were out rather than just before.

Load the `teamwork-graph-context` skill first and follow it for gathering context, labelling sources, keeping sensitive content out and optional publishing. This file adds what's specific to a period of time. Apply its "Sensitive content" section strictly. A long window over someone's own work turns up more leave, private messages and people-programme pages than a single day does. Leave out a people-programme page entirely, even as a New row, when its title or excerpt carries a level code, selection or assessment language: not quoting it isn't enough. When the user runs the programme, keep its schedule, its meetings and the user's own actions, in neutral words ("Send the programme update to managers"), and drop only the participant and assessment detail. An optional HTML report is built by `render.py` in this folder (Step 8), which applies the `atlassian-design` skill for you: load that skill only if the script can't run.

This skill selects "Answer-first delivery" in `teamwork-graph-context`: gather and assess, answer in the conversation, then ask whether the user wants an HTML report. Do not write report data, run a renderer or create an artifact unless the user requests an export, HTML report or publication. Use the existing report layout only for that optional export. Offer Atlassian Artifacts publication only after confirming availability; exporting does not authorise publishing.

Connectors

• **Needed:** Jira and Confluence, for most of what changes in a fortnight. If neither is in the site's `products` list (see "Atlassian apps on the site" in `teamwork-graph-context`), say so before building, and say what the page can still show.
• **Helpful, from Atlassian:** Projects and Goals, for status changes, target date moves and recorded decisions. Loom, for meeting recordings and their action items. Bitbucket, for review requests and merged work. Skip the calls for any app that isn't on the site, and list it in the footer as "Not available on this site".
• **Helpful, from other tools:** Slack or Teams, for decisions and asks made in chat. Google Drive or SharePoint, for docs edited while the user was away. GitHub or GitLab, for merged pull requests. Gmail or Outlook, for asks by email.
• **Vendor connectors,** as `teamwork-graph-context` describes. Teamwork Graph comes first, and a connector fills only a known gap:
• The calendar's own connector (Google Calendar or Outlook) for the meetings the user missed and what's coming up (Step 5). Teamwork Graph can't list meetings in a window. Without the connector, missed meetings come only from recordings and notes found in Steps 2 and 3, and the page says recurring meetings may be missing.
• The calendar connector also reads the user's own out-of-office event to set the window when they say "since I've been away" without dates (Step 1).
• Slack, Teams, Gmail or Outlook connectors for a strict date window when the Teamwork Graph search came back empty or too thin inside the window (Step 4), and to read threads that don't hydrate.
• Gmail or Outlook once for email asks when the Teamwork Graph results held no email at all (Step 2).

Budget

A long window means many more candidate changes than a daily brief, so the caps matter more. Each step states its own. In total, unless the user asks for a deeper pass:

• 7 `search` calls: 1 to resolve a named topic, 4 for the third-party sweep (3 terms and the Slack ID), 1 for decisions and 1 for meeting notes
• 2 `getWorkActivity` calls: one for the user's own activity (Step 1), one for mentions and assignments (Step 2)
• 4 JQL queries and 5 CQL queries (1 for comments on the user's pages, 1 for decisions, 2 for page changes, and 1 to list the user's pages when Step 1 didn't)
• 2 `getGraphContext` calls, on the anchor only
• 2 `getPullRequests` calls
• 3 calendar connector calls, and 1 email connector call
• 3 Loom lists and 2 `getLoomObjectsContent` reads (up to 10 recordings each)
• 1 `getPeopleInfo` batch to name editors and authors that records give only as account IDs
• the anchor's `getProject` or `getGoal`, plus up to 5 linked projects or goals

History reads (`listJiraIssueChangelogs`, `listConfluenceContentVersions`, `diffConfluenceContentVersions`) are capped at 8 work items and 6 pages, chosen as Step 7 ranks them. A retry after an input error doesn't count against a cap. Other reads of known objects don't count, but batch them. A run is usually 35 to 50 calls. The footer reports every cap that applied ("Read the history of 8 of 31 changed work items").

##