/dependency-map

name: "dependency-map"
description: "Map what a project, goal, epic, team or service depends on and what depends on it, across teams and tools, using Teamwork Graph and Projects and Jira records. Answers in the conversation first with dependency direction, state and source, blocked or at-risk work, stale handoffs, unrecorded dependencies and the owner to contact. Offers an HTML report with the existing SVG dependency diagram on request, and publication only when Atlassian Artifacts is available and requested. Use for dependencies, cross-team blockers, who is waiting on whom, or /dependency-map."

Dependency map

Explain in the conversation, for a piece of work, what it's waiting on, who's waiting on it, which of those links are in trouble, and who to talk to about each. It's written for the person who owns the work and has to chase other teams.

Dependencies live in Projects, Jira links, service catalogues, code and, often, only in a Slack thread. Teamwork Graph helps find them, but its edge names don't all read the same way, it misses some project links, and it skips custom Jira link types. So this skill finds candidates in the graph, then takes direction and status from the product records. The map shows recorded and unrecorded dependencies side by side.

Load the `teamwork-graph-context` skill first and follow it for gathering context, labelling sources, keeping sensitive content out and optional publishing. Its section "What the graph doesn't tell you" matters most here. This file adds what's specific to dependencies.

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:** Projects or Jira, either one. Projects holds project-to-project dependencies, and Jira holds issue dependency links. With only one on the site (see "Atlassian apps on the site" in `teamwork-graph-context`), map from it and say in the footer which kind of dependency wasn't checked. With neither, say so before building: the map can show only dependencies found by search, all of them Not recorded.
• **Helpful, from Atlassian:** Goals, for goal anchors. Teams, for team anchors. Compass, for service anchors and runtime dependencies. Confluence, for plans with a dependencies or risks section.
• **Helpful, from other tools:** Slack or Teams, for handoffs and blockers discussed only in chat. GitHub or GitLab, for code and pull request dependencies. A service catalogue connected to the graph, for runtime dependencies.
• **Vendor connectors,** as `teamwork-graph-context` describes: Slack or Teams, to read a handoff thread in full and check whether its last question was answered (the chat check for stale handoffs). GitHub or GitLab, to read pull request bodies and reviews that the graph returns empty.

Two things to record for every dependency

Keep these separate all the way through, from gathering to the diagram.

• **State:** how it's going. One of Blocked, At risk, Stale handoff, On track, Done or Unknown (see Step 5).
• **Source:** how you know it exists.
• **Recorded:** a DEPENDS_ON or DEPENDED_BY link, or a Jira dependency link, including a custom type, whose meaning and direction are confirmed.
• **Related:** a RELATED link whose direction comes from another record.
• **Not recorded:** found only in chat, a doc or a search.

A Not recorded dependency can be Blocked. If chat says it's blocking, it's Blocked and goes in Needs attention, labelled with where it came from ("from Slack, not recorded").

Step 1: Resolve the anchor

| The user gives you | Anchor | Resolve with | Scope of "our work" | | --- | --- | --- | --- | | An Atlassian project | `AtlassianProject` | `getProject` (use the returned URL or ARI for graph calls) | The project and its tracked Jira work | | A goal | `AtlassianGoal` | `getGoal` with `limits: {projects: 20}` | Its linked projects, each treated as a project anchor (up to 5) | | An epic or work item | `JiraWorkItem` | The key | It and its children | | A Jira space or board | `JiraSpace` | The key | Open epics, plus work due in the next 6 weeks | | A team | `AtlassianTeam` | `searchTeams`, then the team's projects | Its active projects (up to 5) | | A service or component | `CompassComponent` or `ExternalService` | The URL or ARI | The service itself |

Capture the anchor's owner, team (from the record's teams field), short name (the words people use for it in chat), and **need-by date**: the target date, due date or sprint end the anchor is working towards.

• **A month or quarter target** ("October") means the end of that range. Say so: "October, no day set".
• **A need-by date that has already passed** while the anchor isn't done is a finding in itself. Show "passed" in the header. Under the header meta, summarise the anchor's date history from its updates, since each update carries the previous target date ("The target has moved 8 times: May 14, Jul 3 ... Oct 16").
• **No date:** say so. "At risk" checks then use dependency dates and staleness only.

Step 2: Find the edges

Collect edges from each source below. For each one, record which side waits, its source (Recorded, Related or Not recorded), and the record it came from.

Project to project (project anchors)

• Call `getProject` with `include: ["dependencies", "links", "teams", "updates", "highlights"]` and `limits: {dependencies: 20, links: 20, updates: 5, highlights: 20}`. Don't filter by `linkType`. Split the links into work tracking and related yourself, because related links often hold the plan and other docs. This is the source of truth.
• `DEPENDS_ON`: the anchor wait