Skip to content

Work your Jira issues from an agent

Add the Teamwork Graph CLI (twg) to a workbench and your coding agent can work your Atlassian board directly. You say “implement ACME-1234” and the agent pulls the Jira issue, reads its description and comments, and gets to work, instead of you copy-pasting the ticket into the prompt. Adding twg writes its skills straight into the agents in the container, so Claude Code (or OpenCode) reaches for Jira, Confluence and Bitbucket on your behalf. It costs one Atlassian API token.

There are two routes to the same board, and this guide takes the CLI one. The other is the Atlassian Rovo MCP connector, also one command to add. Which one fits is a question of sign-in: twg authenticates with an API token you paste into your env file and stays inside the container, while the connector signs in interactively once from inside the container and talks to a remote endpoint. If your site has API tokens turned off, the connector is your route; if it forbids OAuth apps, twg is.

This guide assumes a coding agent is already in the workbench. If not, add one first - Claude Code is used here, and OpenCode works the same way. Then follow along: add twg, set the token, apply, and hand your agent a ticket.

The Atlassian feature bundles three tools; you want only twg here, so add its variant:

Terminal window
monoceros add-feature acme atlassian/twg

That turns on twg and leaves Rovo Dev and Forge off (they come later, if you want them). The yml gets the feature with just that tool enabled, and acme.env gets the Atlassian keys to fill in:

features:
# ... the claude-code feature from before, still here ...
- ref: ghcr.io/getmonoceros/monoceros-features/atlassian:1
options:
rovodev: false
twg: true
forge: false
instance: ${ATLASSIAN_INSTANCE}
email: ${ATLASSIAN_EMAIL}
apiToken: ${ATLASSIAN_API_TOKEN}
rovodevToken: ${ATLASSIAN_ROVODEV_TOKEN}
bitbucketToken: ${ATLASSIAN_BITBUCKET_TOKEN}

You can pull this in at init too, when you first create the workbench: monoceros init acme --with-features=claude,atlassian/twg. Either way it takes effect on the next apply.

twg authenticates from an Atlassian API token, so it is signed in the moment the container starts - there is no interactive login step. For Jira and Confluence you need three values: your site host, your account email, and a scoped Atlassian API token with Teamwork Graph as the app.

Fastest for the token: this pre-filled link opens the create form with Teamwork Graph and every scope selected - create it as is and copy the value (Atlassian shows it once), or step Back to the start to rename or trim the scopes. For the manual click-through, see Create the tokens on the Atlassian feature page.

The env file lists a key per token the feature knows about, so you will see ATLASSIAN_ROVODEV_TOKEN and ATLASSIAN_BITBUCKET_TOKEN there too. Leave them empty: Rovo Dev and Bitbucket are off in this workbench, and each token belongs to a different Atlassian app, so one value cannot serve all three.

Then store the three values. For one workbench, put them in acme.env:

acme.env
ATLASSIAN_INSTANCE=yoursite.atlassian.net
ATLASSIAN_EMAIL=jane@example.com
ATLASSIAN_API_TOKEN=ATATT...

To reuse the same account across every workbench, put them in the global monoceros-config.env pool instead - the yml’s ${…} placeholders resolve from acme.env first, then from the global pool, so set them once there and every workbench picks them up.

Bring the feature up:

Terminal window
monoceros apply acme

Open a shell and ask twg to check itself. twg doctor resolves the token, hits the API, and reports what it found:

Terminal window
monoceros shell acme
Terminal window
$ twg doctor
✓ Authenticated successfully.
Resolved auth
Endpoint: https://api.atlassian.com/graphql
User: jane@example.com
Site: yoursite.atlassian.net
TWG token: present
Bitbucket token: missing
Connectivity
Status: ok
Token: valid
Message: Authenticated successfully. API token is valid for the configured endpoint.

Authenticated successfully with your site and email is the whole check. A missing Bitbucket token is fine here - you set that one only if you also work Bitbucket repos.

This is the payoff. Point the agent at the project you want it to work in with --in, hand it a Jira key, and let it do the rest:

Terminal window
monoceros run acme --in projects/myapp -- claude "Implement ACME-1234"

Claude reads the issue through twg - its description, its acceptance criteria, its comments - and starts working against the code in that project. The same works from a shell session (monoceros shell acme, cd projects/myapp, then claude), or with the Claude desktop app attached to the workbench over SSH; see Claude Code for that setup. OpenCode gets the skills too - it takes the opening prompt via --prompt rather than as a bare argument:

Terminal window
monoceros run acme --in projects/myapp -- opencode --prompt "Implement ACME-1234"

twg is the CLI layer your agent uses, but the Atlassian feature carries two more tools that share the same account and token:

  • Rovo Dev (acli rovodev) is Atlassian’s own AI coding agent. Add it with monoceros add-feature acme atlassian/rovodev.
  • Forge CLI (forge) builds and deploys Atlassian Forge apps, authenticated from the same email and token with no forge login. Add it with monoceros add-feature acme atlassian/forge.

Adding a variant to a workbench that already has Atlassian is additive: it turns that tool on and leaves the others as they are. Or add all three at once with the bare monoceros add-feature acme atlassian. The Atlassian feature page covers each tool and its options in full.

  • Atlassian feature - the full feature, its variants, the two-token auth model, and every option.
  • Git and repositories - the Bitbucket scoped token, and cloning Bitbucket repos into the workbench.
  • Claude Code - attach the desktop app to the workbench over SSH.
  • monoceros run - run a one-off command (like handing the agent a ticket) inside the workbench.