/teamwork-graph-context

name: "teamwork-graph-context"
description: "Gather context for a skill from Teamwork Graph through the Atlassian Rovo MCP server, across Atlassian and connected third-party tools such as Slack, Google Drive, GitHub, Zendesk and Salesforce. Falls back on vendor connectors (such as Google Calendar, Gmail or Slack) where the graph has gaps. Labels every source, states every gap, keeps sensitive content out, and confirms structured relationships against product records. Load it from another skill before gathering context, follow that skill's delivery mode, and use its publishing guidance only when publication is requested."

Teamwork Graph context

This is the shared method every skill in this repo uses to gather context and deliver its result. A skill loads it first, then adds what's specific to its job: the anchor, the sources it needs, what the artifact shows and when to stop. Where a skill and this file disagree, the skill wins.

Companion skills mentioned as alternatives or next steps are optional. Check that a suggested skill is installed before offering its slash command. If it is unavailable, describe the next step in ordinary language and use the current host's available capabilities.

Principles

1. **Use the graph to discover and the records to confirm.** Start from one object in Teamwork Graph and walk its relationships. That's how you find connected work, docs and conversations across tools. For structured facts (dependencies and their direction, linked projects, owners, teams, statuses, dates), the product record is the source of truth. Cross-check, and say when the graph and the record disagree. "What the graph doesn't tell you" lists the known gaps. 2. **Keep sensitive content out.** Search can return HR, performance, legal and other confidential documents even for unrelated queries. Never quote, summarise, cite or title them anywhere. See "Sensitive content". 3. **Third-party sources are first-class.** A Slack thread, a Google Doc or a Zendesk ticket counts as much as a Confluence page or a Jira work item. Never call them fallbacks or rank them below Atlassian sources. Label where each fact came from; don't rank sources by vendor. 4. **Linked and found are different.** A relationship stored in the graph or a product record is confirmed. A search hit that looks related is inferred. Keep them apart in the reasoning and in the artifact. 5. **Never invent.** No made-up titles, owners, dates, statuses, quotes or numbers. If something can't be confirmed, say so. 6. **Say what's missing.** A source that wasn't connected, a search that returned nothing, a record that doesn't exist and a check you couldn't run are all results. Show them. 7. **Read-only by default.** Only write (create, edit, link, comment, post) when the skill's job is the write or the user asks, and confirm first. 8. **Fall back on vendor connectors for what the graph can't do.** When Teamwork Graph and the Atlassian product tools can't answer something a skill needs (a day's meetings, recent email, a full Slack thread), use the vendor's own connector if the client has one. See "Vendor connectors". This is about which tool to call, not how much a source counts: a fact read through a vendor connector counts the same as one from the graph.

Sensitive content

Searches surface whatever the user can see, and that includes documents nobody wants in a status report. This rule overrides every skill.

• **Never use these, even when they match:** promotion, calibration or performance review material; training, certification or knowledge-check results that name people; compensation, salary, equity or offer details; disciplinary, PIP or termination records; medical, leave or other personal circumstances; legal holds, privileged advice or litigation; security incidents not yet disclosed; M&A, layoffs or other restricted plans.
• **Never use these either, unless the user asks for them:** private and group direct messages, and board or exec-only material. A Slack direct message's title has no channel name ("[Name] in #") and its URL contains `/archives/D`. A group message's channel name starts with `mpdm-`. A channel whose name says leadership, exec, staff or board, or uses a word or abbreviation for them (`leaders`, `leads`, `lt`, `elt`, `slt`), counts as exec-only material whether or not it's private, since search results don't show a channel's privacy.
• **Spot them early.** Titles and snippets often give them away: "calibration", "promo panel", "promotion packet", "level panel", level codes ("P50 to P60", "L4>L5"), "impact bar", "comp review", "PIP", "Knowledge Check" or "Responses" sheets with scores, "offer letter", "legal privileged", "confidential: do not forward". Don't hydrate a result that looks like one. A page that's otherwise ordinary (a runbook, a design doc) can end in a section that is its author's review or promotion evidence (a closing section headed "… evidence" that isn't test evidence, or one that maps the work to a competency or review criteria): drop that section silently and use the rest.
• **Linked records count too.** A legal or HR project linked to the work can be shown with its status, owner and dates, but never quote its advice or the reasons in its updates. A legal or HR record that's only found by search, such as a counsel review work item that matches the product's name, is left out.
• **When the work is itself a people programme** (a development programme, hiring, a reorg), nearly every result sits next to these categories. Use the programme's design, schedule, owners and actions. Never use participant or candidate lists, who was selected or removed, assessments, ratings, or anyone's level or role move. A notes doc, recording or chat message that mixes the two is usable: drop the sensitive items silently and keep the rest. Results whose titles name the programme (a participant page, a ratings sheet) need the check too. In a footer, say only "Some results weren't used".
• **Leave