Exploring TWG CLI in Practice: Four Use Cases for your Daily Operations

[#1]

4 Useful TWG CLI patterns I tested after the Team '26

After Atlassian unveiled the Teamwork Graph CLI at Team '26 and put it into Open Beta, I spent a few days running it against real and demo environments to see what sticks. This post collects four patterns which I found quite useful for the daily operation, with the actual commands, the kind of risk or insight each one surfaces, and what I learned along the way.

What is the Teamwork Graph and why does TWG CLI matter

Teamwork Graph is Atlassian's enterprise context graph. It continuously maps people, content, activities, and relationships across Jira, Confluence, Bitbucket, JSM, Goals, Projects, and a growing list of third party integrations like Slack, GitHub, Google Drive, and Salesforce. It is the layer that lets Rovo answer questions like "who works on what across products" without you wiring the connections by hand.

Until Team '26, the graph was only accessible through Rovo or in product surfaces. TWG CLI exposes the same context to any coding agent and to plain shell scripts. One binary, unified access to roughly 380 commands across the Atlassian portfolio, no separate REST authentication per product.

For anyone who has previously scripted reports by stitching together Jira API calls, Confluence searches, and Bitbucket queries, the cost of asking diagnostic questions drops dramatically. What used to be a small script project is now a one liner.

Setup recap

On macOS or Linux:

curl -fsSL https://teamwork-graph.atlassian.com/cli/install | bash

 On Windows (Powershell):

irm https://teamwork-graph.atlassian.com/cli/install.ps1 | iex

After install, twg login for authentication and twg skills install to wire the agent skill into your coding agent of choice (Claude Code, Codex, Cursor, Gemini CLI, and others).

Use Case 1: Team Workload Footprint

What it does: For a specific person, aggregate their cross product activity over the last 30 days, then have Claude flag overload signals.

twg work query --scope user --account-id <accountId> --since 30d --output json --agent-fields @compact | claude "Flag this person's load across Jira, PRs, Confluence. Identify overload patterns and single points of failure."

PowerShell quoting note: @compact must be wrapped in single quotes ('@compact') because the @ symbol is interpreted as PowerShell's splatting operator and the literal value gets eaten.

Risk it surfaces: Capacity cliff, single point of failure on a critical contributor, burnout signals you would otherwise only spot at the next 1:1.

Practitioner insight: work query does not just return what the person authored. It traverses the graph and returns pages where they are mentioned as Driver or Approver, issues where they are tagged, comments where they are addressed. That makes it a much richer footprint view than any product specific report. The catch: the time window matters, because the graph tracks relationship events, not the full assignment state. If you want the complete picture of who is currently sitting on what, combine with jira workitem query --jql "assignee = ..." for the assignment state.

Use Case 2: Stuck Work Detection

What it does: Find all issues in In Progress status that have not been updated in 14 days, then have Claude cluster them by likely root cause.

twg jira workitem query --jql "statusCategory = 'In Progress' AND updated < -14d" --output json --agent-fields @compact | claude "Group by project and assignee. Identify systemic blockers vs individual stalls. Suggest unsticking priorities."

Risk it surfaces: Hidden blockers, cycle time degradation, missing escalation paths. An In Progress issue that has not moved in two weeks is almost always an external dependency, a knowledge gap, or quiet abandonment. None of those resolve themselves.

Practitioner insight: This pattern is more valuable than the usual "show me old issues" report because it filters on statusCategory = 'In Progress' specifically. Items in To Do are expected to sit. Items in Done are fine. Items in In Progress that do not move are the operational risk. The updated < -14d threshold is also tunable to your team's actual tolerance.

Use Case 3: Critical Ownership Gaps

What it does: List unresolved critical and highest priority issues that have no assignee.

twg jira workitem query --jql "priority in (Highest, Critical) AND assignee is EMPTY AND statusCategory != Done" --output json --agent-fields @compact | claude "Group by project. Highlight ownership gaps where critical work has no owner. Suggest routing based on recent project activity."

Risk it surfaces: SLA breaches waiting to happen, ambiguous escalation paths, the classic "everyone assumed someone else owned it" pattern. Especially common in handovers, in shared queues, or in new projects that have not finished setting up assignment automation.

Practitioner insight: Looks trivial, produces high signal output. A Critical issue without an assignee is almost never intentional. It is usually the result of a deleted account, a workflow misconfiguration, or a user creating issues outside their normal project. The Claude step is what makes the output useful as a report, because it can summarize where the gaps cluster across multiple projects in a single readout.

Use Case 4: Documentation Freshness Audit

What it does: Find Confluence pages that have not been modified in 180 days, then have Claude rank them by operational criticality based on title and space.

twg confluence search query --cql "lastModified < now('-180d') AND type = page" --output json | claude "Group by space. Identify likely stale runbooks, processes, and onboarding docs. Prioritize by space criticality. Flag pages where title implies operational relevance (runbook, SOP, postmortem, oncall)."

Risk it surfaces: Documentation rot, slow incident response, new joiners being pointed at outdated SOPs.

Practitioner insight: 180 days is a reasonable starting threshold but I tune it per space. Engineering runbooks should probably not go untouched longer than 90 days. HR onboarding might be fine at a year. The Claude pass is what turns the list from a raw page dump into a triage report.

Note: In my case, I passed the results from the TWG CLI directly into Claude Code. Of course, other AI models can be used just as well.

Useful references: 

• https://support.atlassian.com/organization-administration/docs/what-your-agent-can-do/
• https://support.atlassian.com/organization-administration/docs/choosing-between-twg-cli-and-rovo-mcp/
• https://support.atlassian.com/organization-administration/docs/what-is-twg-cli/

Open question to the community

These four cover team workload, stuck delivery work, ownership gaps, and stale documentation.

What patterns are you running, or planning to run, with TWG CLI? Curious what is working in your environment that I have not thought of yet.

I am looking forward to your feedback.

Greetings,
Alex

[Josh]

Excellent article, @Alexander Nilsson . I really appreciate the practical use cases.

[Fazila Ashraf]

Fantastic! Highlighting use cases is awesome, as users often have the tools but have a hard time finding ways to benefit from them.

@Alexander Nilsson , if i understand the article correctly, 'what it does' is the prompt to be used and the twg command is only a reference insight on what is called internally by the AI harness tool? 

[Alexander Nilsson]

Hi Fazila,

Great question, and thanks for reading so closely. The structure is actually the other way around, so let me clarify.

The twg ... part is the real command. You run it yourself in your shell, it queries the Teamwork Graph and returns the json. It is not just a reference to something the AI calls internally.

The pipe | then hands that json over to claude, and the quoted text right after claude is the actual prompt. So the AI receives two things at once: the json context from TWG CLI and my instruction on what to do with it.

The "What it does" line is only my plain language summary of the use case for the reader. It is not part of the command and not the prompt.

I think the confusion is understandable, because there are really two modes here. In the patterns I show, I run the twg command manually and pipe the output into Claude Code, as I noted at the bottom of the article. But once you run" twg skills install", your coding agent can also issue these twg commands itself, and in that case the CLI genuinely does get called by the harness. The examples above are the manual pipe version, so the commands shown are exactly what I typed.

Happy to go deeper on either mode if that is useful.

Greetings,
Alex

[Philipp Sendek _catworkx_]

Amazing write up and very detailled and informative, as usual @Alexander Nilsson👏