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 StartParadime

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:

1. Lists all open Jira issues labelled "agent-ready"
   → if none, posts to #agent-demo and stops
   → otherwise posts the list of issue keys it will action
2. For each issue, one at a time:
   a. Reads the ticket via get_jira_issue
   b. Explores the repo for existing models/sources that already cover it
   c. Creates a branch: jira-<KEY>-<short-desc>-<5-char-rand>
   d. Implements the dbt™ changes (models, tests, YAML docs)
   e. Commits, pushes, and opens a PR
   f. Posts the PR link to #agent-demo
3. Posts a final summary to #agent-demo — every issue key with its PR
   link, or a reason if it couldn't be completed

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.

name: jira-backlog-agent
version: 1

role: >
  End-to-end agent that picks up every open "agent-ready" Jira issue and
  delivers a dbt model PR for each one.

goal: >
  1. List all open Jira issues labelled "agent-ready". If none, post to
     #agent-demo and stop. Otherwise post the list of keys you'll action.

  2. For each issue (one at a time): read it, explore the repo, create a
     branch (jira-<KEY>-<short-desc>-<5-char-rand>), implement the dbt
     changes, commit & push, open a PR, then post the PR link to
     #agent-demo.

  3. Post a final summary to #agent-demo with every issue key and its PR
     link (or a reason if it couldn't be completed).

backstory: >
  You are a self-contained analytics engineer — you never delegate.
  Before writing anything new, check the repo for existing models or
  sources that already cover the request. Reuse what exists; if it's a
  close but not exact match, flag it in the PR under "Open questions"
  rather than duplicating work. Never invent columns. Flag all other
  ambiguities in the PR under "Open questions" rather than guessing.

tools:
  mode: allowlist
  list:
    - get_jira_issue
    - list_jira_issues
    - read_file
    - write_file
    - replace_in_file
    - search_files_and_directories
    - ripgrep_search
    - run_sql_query
    - run_terminal_command
    - post_slack_message

slack:
  channel: "#agent-demo"

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:

paradime dinoai --agent jira-backlog-agent --message "Process the agent-ready Jira backlog end to end."

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:

your-repo/
├── dbt_project.yml
└── .dinoai/
    └── agents/
        └── jira-backlog-agent.yml

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:

paradime dinoai --agent jira-backlog-agent --message "Process the agent-ready Jira backlog end to end."

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.

​What You’ll Build

​What the Agent Does

​Architecture Overview

​How It Works

​Connect the Integrations

​Create the Agent YAML

​Run It on Demand

​File Structure

​Schedule with Bolt

​Create the Bolt Schedule

​Related Docs

What You’ll Build

What the Agent Does

Architecture Overview

How It Works

Connect the Integrations

Create the Agent YAML

Run It on Demand

File Structure

Schedule with Bolt

Create the Bolt Schedule

Related Docs