Jira Workbench

From Jira intent to merged pull request - in one panel.

A GitHub Copilot app canvas that turns your Jira backlog into a work queue for Copilot sessions, then traces each result back to the Jira issue it came from.

tests License: MIT Node 20+ Dependencies: none Jira: read-only canvas

Quickstart · Install · Guide · Contributing · Security

Overview

This Copilot App canvas connects requirements in Jira, agents running in Copilot App sessions, and code landing in GitHub pull requests.

Jira Workbench helps you understand what needs your attention next and kick off agentic work in Copilot App from one panel. It works from observed evidence (session state, pull request state, and checks) rather than from the Jira status column.

The execution queue: work grouped by what it needs from you

Features

Feature	Description
Execution queue	Work is grouped into Needs me, Running, PRs to review and Available to start. An issue still in "To Do" with an active session appears under Running.
Launch from an issue	One click turns a Jira issue into an editable, hash-verified brief. Missing acceptance criteria and unresolved blockers are shown as warnings you must acknowledge before implementation starts.
Traceability	Each issue links to its sessions, branches, pull requests and checks, with the evidence for every link. Links are never inferred from similar titles or branch names.
Hierarchy view	Epics, stories and subtasks by Jira parent link, with status and sprint filters. Missing parents stay visible, and parent cycles are reported.
Per-project statuses	The status filter lists each project's own Jira workflow statuses, grouped by category, including custom steps such as "PR Waiting" that no issue is in yet.
Read-only canvas	The gateway allows only Jira reads. The canvas never edits, transitions or comments on issues, and never changes sprints. Status changes are delegated to sessions you launch: an issue session moves its issue to In Progress, and a confirmed Update Jira session corrects statuses across the project using that project's own workflow (for example "PR Waiting" for work in an open pull request). Issue sessions put the issue key in commits so Jira links them, and comment once through a Smart Commit only when you opt in.
No dependencies	Plain JavaScript. It installs as a plugin or a folder copy and needs no build step.

Quickstart

You need an Atlassian connection in Copilot (the app's Atlassian Rovo connector or an Atlassian MCP server) and a signed-in gh CLI. The install guide covers each prerequisite, how to check the install, updating, uninstalling, and troubleshooting.

Install the plugin. This repository is its own plugin marketplace:

copilot plugin marketplace add Sentry01/jira-workbench
copilot plugin install jira-workbench@jira-workbench

Start a new Copilot session. A session loads plugins when it starts, so the session you installed from will not see the canvas.
In the new session, ask Copilot:

Open the jira-workbench canvas

Open it from a session like this. Opened from Canvases in the app's sidebar, it has no session behind it and cannot reach Jira.
Use the pickers along the top to choose your Jira site, a Jira project, and the Copilot repository to work in.

Important

The Jira project and the Copilot repository are chosen separately. A Jira project ID is not a Copilot project ID. The arrow between the pickers is the mapping you create, and it is saved, so you set it once per project.

When a new release is published, the panel shows Update available. One click updates the plugin and restarts the panel on the new release.

For a full walkthrough with screenshots, see the user guide.

Other ways to install

From a git clone (for contributors). The panel updates it with a fast-forward pull:

git clone https://github.com/Sentry01/jira-workbench.git
ln -s "$PWD/jira-workbench/com.github.copilot/extensions/jira-workbench" ~/.copilot/extensions/jira-workbench

As a one-off copy. Ask Copilot to install the canvas extension from https://github.com/Sentry01/jira-workbench/tree/main/com.github.copilot/extensions/jira-workbench. The panel reports newer builds, but a copy can only be updated by installing it again.

Keep only one install, because two register the jira-workbench canvas twice. To move from a clone to the plugin without losing your saved data, see Switching from a git clone. After a clone or copy install, ask Copilot to reload extensions.

To share your copy as a private gist, run share_extension (scope user, name jira-workbench). The artifacts/ folder is never shared.

Tracing an item end to end

flowchart LR
    B["Jira<br/>work item"] --> C["Copilot<br/>session"]
    C --> D["Branch"]
    D --> E["Pull<br/>request"]
    E --> F["Checks"]

Select any row, and the inspector shows the whole chain in three numbered steps:

Jira work item - the issue and its Jira status, shown independently of the steps below.
Copilot sessions - every session on the item, each with Open session. You can also link a session you started elsewhere.
Pull requests & checks - pull requests found in session metadata and verified on GitHub, with their reported checks.

Jira, sessions and GitHub each keep their own freshness timestamp, so a session refresh never marks old pull request data as newly verified. Refresh the source you doubt.

An idle agent, an open pull request and a missing check result are different states. None of them means the work is done.

What it does not do

No Jira writes from the canvas. The canvas never edits, transitions or comments on issues, never creates them, and never changes sprints. Status changes are delegated to sessions you launch. An issue session moves only its own issue to In Progress when it starts implementing (after plan approval in Plan mode). Update Jira starts one confirmed session that makes status-only fixes across the project, picks target statuses from the project's own workflow, and never reopens Done issues. An issue session puts its issue key in its branch, commits and pull request title, and writes one Smart Commit #comment in its final commit only when you tick Smart Commit comment in the brief. These limits are set by the session's prompt and are not technically enforced; see Security.
No fan-out. One confirmed launch creates exactly one session.
No auto-merge or auto-approve. Review actions open the real Copilot surface, and you decide.
No pending action shown as finished. A pending request is labeled as pending. A launch with no session receipt after 15 minutes is marked as unknown, stops blocking new work, and can be cleared.
None of your private data in the source. The source embeds no tokens, and none of your Jira domains, project IDs, repository names or user paths. Authentication stays with the Atlassian MCP connection and the GitHub CLI.

Documentation

Document	Contents
Install	Prerequisites, Atlassian MCP setup, plugin install, checking the install, updating, switching from a clone, uninstalling, troubleshooting
Guide	Setup, the daily loop, launch briefs, traceability and troubleshooting, with screenshots
Behavior reference	Execution semantics, freshness rules, the read-only boundary, known prototype limits
Contributing	Setup, the verification commands, and the rules reviewers check
Security	Private reporting, design boundaries, and where your local data lives
Verification	The three browser harnesses, what CI runs, and the shared synthetic fixture

Requirements

The Copilot app, with extension canvases and the SDK tools.execute API, plus the copilot CLI to install the plugin.
An authenticated Atlassian connection: the Copilot app's Atlassian Rovo connector, or an Atlassian MCP server whose name contains atlassian or jira, or both. For an MCP server, the v2 endpoint (https://mcp.atlassian.com/v2/mcp) is recommended; v1 also works. Sign in with /mcp auth atlassian; the app signs in its connector.
Your code repository added as a project in the Copilot app.
The gh CLI, signed in, for GitHub.com pull request reads.
Node.js 20 or newer, only to run the tests.

Layout

com.github.copilot/extensions/jira-workbench/   The installable canvas; this is what you share
  extension.mjs              Entry point; declares the canvas and its actions
  lib/                       Gateway, model, execution classifier, briefs, store, server, updater, plus:
    connection.mjs           The one supervisor of the Atlassian MCP connection
    workbench.mjs            Panel state; hands launches and traces to the two modules below
    launches.mjs             Launch briefs, requests, receipts, and their expiry
    trace.mjs                Session and pull request evidence for each work item
    view-model.mjs           The panel's pure display rules, unit-tested and served to the UI
    validate.mjs             Shared identifier rules (repository, session ID, issue key, ...)
    runtime.mjs              Shared, time-bounded helpers for Copilot runtime calls
  ui/                        Canvas renderer
  test/                      A node:test suite: no framework, no dependencies
assets/preview.png           The plugin listing image; docs/screenshots.mjs regenerates it
docs/                        Install guide, user guide, screenshots, and their generator
verification/                Browser harnesses and the shared synthetic fixture

Contributing

Issues, questions and first impressions are welcome, including "this confused me". Start with CONTRIBUTING.md. Everything runs with node, and there is nothing to install:

node --test com.github.copilot/extensions/jira-workbench/test/*.test.mjs

By participating you agree to the Code of Conduct.

Local data

Repository mappings, UI preferences, trace links, reviewed briefs and launch receipts are stored in $COPILOT_HOME/extensions/jira-workbench/artifacts/.local/state.json. A disposable warm-start cache of the Jira catalog and recently loaded hierarchies sits next to it in cache.json, so a new session opens on your last project straight away.

Both files describe your private work. They are git-ignored and excluded from share_extension; never commit or publish them. Every screenshot in this repository is generated from a synthetic demo fixture, not from real Jira, session or repository data.