The problem

Software teams now run coding agents (Claude Code, Cursor, Codex) next to Jira, and the two don't talk. Someone copies an issue into a terminal, the agent works for twenty minutes, and the issue says nothing until a pull request shows up. If the agent gets stuck on a decision, nobody watching Jira knows. The issue stops being the place where the work is visible.

What it does

Taskhold is one task list shared by a person and their coding agents. Agents file their work as steps, tick them off, report progress, and stop to ask when they need a decision. Taskhold for Jira connects that list to Jira issues:

  • Hand to my agents. From the Taskhold section of any issue, one click puts the issue on your Taskhold list with its key, summary, description, a link back and an optional note. The next agent session that checks the list picks it up.
  • Watch it work, from the issue. The panel shows which agent took it, its steps as they tick off, a progress bar, what it is doing right now, and refreshes on its own while the agent works.
  • Questions surface where people look. When the agent stops to ask ("allow only our own domain, or the docs subdomain too?"), the question appears on the issue with a link to answer it. Answers stay with the person: the Taskhold API refuses answers from keys, so neither the app nor a bot can answer for you.
  • The summary goes back to Jira. When the agent finishes, its summary shows on the issue, and one button posts it as a Jira comment.
  • Rovo agent "Coding agent dispatcher". In Rovo chat: "Hand this issue to my coding agents", "How is the agent doing on BLW-20?", "What are my agents working on?".
  • Atlassian MCP. The same three actions are MCP tools on Atlassian's MCP server, so an outside agent (Claude Code, Cursor) connected to Atlassian can hand issues to the team's agents and read their progress. An open-source SKILL.md teaches third-party agents when and how to use them.

Teammates who open a handed-over issue see who handed it over and its last known state, never the owner's Taskhold board or key.

How we built it

  • Forge app, UI Kit issue panel (jira:issueContext), rovo:agent, three action modules (hand-to-agents, agent-progress, open-agent-tasks) and a rovo:mcp module exposing them.
  • Each person's Taskhold API key is stored with Forge KVS secret storage, per Jira account, and never sent to the browser. Which task an issue points at is stored in KVS too.
  • Jira REST calls run as the user (asUser), so you can only hand over issues you can see, and the summary comment is posted under your name.
  • Declared egress to taskhold.com only.
  • The logic is a small pure engine with Forge, Jira and Taskhold behind ports, so every flow (connect, hand over, progress, questions, done, comment once, teammate view, bad key, no plan) is covered by tests with fakes, plus a live check against the real Taskhold API.

Challenges

  • Keeping the person in charge. The tempting design lets the Rovo agent answer the coding agent's questions. We deliberately didn't: a decision an agent asks a person for should come from that person.
  • One issue, many viewers. The panel had to work for the person who handed the issue over and for every teammate who opens it, without leaking one person's task list to another.
  • Rovo actions and MCP tools share one implementation, so the answers read well both in Rovo chat and in a terminal agent.

What's next

  • Post each finished step as an issue comment (opt-in), and move the issue to In Review when the agent finishes.
  • Hand over a whole sprint or a JQL filter in one go.
  • Marketplace listing.

Built With

Share this project:

Updates

Submission history