For the complete documentation index, see llms.txt. This page is also available as Markdown.

Jira Backlog Agent

Automate your analytics engineering backlog with a single DinoAI agent that reads every open Jira issue labelled agent-ready, implements the required dbt™ models with tests and YAML docs, opens a PR for each, and posts status updates to Slack — all from one agent definition, triggered natively inside Bolt.

No orchestrator script, no Python package, no environment-variable plumbing. The agent's goal does the looping: it lists the backlog itself, works each issue one at a time, and posts a final summary. You just point Bolt at it.

Before You Start

Paradime

  • A workspace on the DinoAI plan with DinoAI Agent capabilities enabled. Programmable agents are defined as YAML under .dinoai/agents/<name>.yml in your repository.

Integrations — these must be connected in Paradime before the agent can run:

  • Jira — the agent calls get_jira_issue and list_jira_issues. Connect it under Workspace Settings → Agent Integrations → Jira. See Connecting Jira Cloud to Paradime (or Jira Data Center for self-hosted). Tool details: Jira Tool.

  • Slack — the agent posts status updates to #agent-demo via post_slack_message. See Slack Integration.

  • Git — your repository must be connected so the agent can branch, commit, and call create_pull_request.

What You'll Build

By the end of this guide you'll have:

  • A single jira-backlog-agent DinoAI agent YAML that lists the backlog, implements the dbt™ models, and opens a PR per issue

  • A one-line command to run it on demand from the CLI or the Paradime app

  • A Bolt schedule that runs that same command on whatever cadence suits your team — natively, with no wrapper script

What the Agent Does

Once triggered, the agent runs this sequence within a single session:

The agent never invents a column that isn't in the source. Before writing anything new it checks for existing models or sources that already cover the request — reusing what exists, and flagging close-but-not-exact matches under Open questions in the PR rather than duplicating work or guessing.

Architecture Overview

Unlike a fan-out orchestrator, the whole backlog is handled by one self-contained agent session. There is nothing to deploy alongside it.

How It Works

The Linear version of this pattern needed an external Python orchestrator to fetch issues and fan out one agent session per ticket in parallel. The Jira agent doesn't — the orchestration lives inside the agent's goal. A single session lists the agent-ready backlog and works through it sequentially, so the only thing you run is the agent itself.

The trade-off is sequential vs. parallel: one session processes tickets one at a time. For a typical daily backlog that's the simpler, cheaper choice — no infrastructure, no secrets to manage, nothing to keep in sync with your dbt™ project. If you later need true parallelism across a large backlog, you can fan out with the SDK, but most teams won't need to.

Connect the Integrations

The agent relies on three integrations being connected in Paradime. Set these up once:

Integration
Why the agent needs it
Where to connect

Jira

list_jira_issues, get_jira_issue

Workspace Settings → Agent Integrations → Jira → Connect

Slack

post_slack_message to #agent-demo

Workspace Settings → Agent Integrations → Slack → Connect

Git

branch, commit, create_pull_request

Connected as part of your workspace repository setup

For Jira, pick Jira Cloud or Jira Data Center depending on your environment — the required credentials differ. Once connected, DinoAI can read and list issues on your behalf. See Connecting Jira to Paradime.

Create the Agent YAML

Create the following file in your repository at .dinoai/agents/jira-backlog-agent.yml. This is the only file you need — it defines the agent's role, goal, tools, and Slack output channel.

tools.mode: allowlist means the agent can only call the tools explicitly listed — keeping each session focused and preventing unintended side effects. The get_jira_issue and list_jira_issues tools require the Jira integration; post_slack_message requires Slack; create_pull_request requires Git.

The Slack channel is set to #agent-demo. Update slack.channel — and the channel referenced in the goal — before committing if your team uses a different channel.

Run It on Demand

With the YAML committed and the integrations connected, trigger the agent with a single one-shot CLI command — no script, no setup:

The CLI triggers the agent, streams its progress to your terminal, and exits when it's done. You can also run it interactively (paradime dinoai --agent jira-backlog-agent) or trigger it from the Paradime app. Run it manually once to confirm the backlog is picked up and PRs land as expected before scheduling it.

When there are no agent-ready issues, the agent posts a short note to #agent-demo and stops — so it's safe to run against an empty queue.

File Structure

That single YAML is the entire footprint — it sits in your repo alongside your dbt™ project:

Schedule with Bolt

Because the agent runs from one CLI command, scheduling it is just a Bolt schedule with a single command — no poetry install, no wrapper, no environment variables. The CLI is already authenticated inside Bolt.

Create the Bolt Schedule

Go to Bolt → Schedules and click New Schedule. Name it something like Jira Backlog Agent and add one command under the Commands section:

That's the whole schedule. On each run, Bolt invokes the agent, which lists the current agent-ready backlog and opens a PR for each open issue.

Choose a Schedule Frequency

Pick the cadence that matches how often your team labels new tickets as agent-ready:

Cadence
Cron expression
When it runs

Every day at 9 AM

0 9 * * *

Monday–Sunday, 9:00 AM

Weekdays at 9 AM

0 9 * * 1-5

Monday–Friday, 9:00 AM

Once a week (Monday 9 AM)

0 9 * * 1

Every Monday, 9:00 AM

Twice a week (Mon & Thu)

0 9 * * 1,4

Monday and Thursday, 9:00 AM

Every 6 hours

0 */6 * * *

12 AM, 6 AM, 12 PM, 6 PM

For most teams, weekdays at 9 AM (0 9 * * 1-5) is a good default. The agent exits cleanly when there's nothing labelled agent-ready, so there's no cost to running it on days with an empty queue.

Once saved, Bolt runs the command on your chosen schedule, picking up any new agent-ready Jira issues and opening the corresponding dbt™ model PRs automatically.

Last updated

Was this helpful?