> For the complete documentation index, see [llms.txt](https://docs.paradime.io/app-help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.paradime.io/app-help/guides-new/programmable-agents/jira-backlog-agent.md). # 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. {% hint style="info" %} #### Before You Start **Paradime** * A workspace on the **DinoAI plan** with **DinoAI Agent** capabilities enabled. Programmable agents are defined as YAML under `.dinoai/agents/.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](https://claude.ai/app-help/integrations/jira/jira-cloud.md) (or [Jira Data Center](https://claude.ai/app-help/integrations/jira/jira-data-center.md) for self-hosted). Tool details: [Jira Tool](https://claude.ai/app-help/products/dino-ai/tools-and-features/jira-tool.md). * **Slack** — the agent posts status updates to `#agent-demo` via `post_slack_message`. See [Slack Integration](https://claude.ai/app-help/integrations/slack.md). * **Git** — your repository must be connected so the agent can branch, commit, and call `create_pull_request`. {% endhint %} ### 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---<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. ```mermaid flowchart TD A[Bolt schedule\nparadime dinoai --agent jira-backlog-agent] B[jira-backlog-agent\nsingle DinoAI session] C[Jira\nlist / read issues] D[Repo\nbranch, commit, PR] E[Slack\n#agent-demo updates] A --> B B --> C B --> D B --> E ``` ### 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 | {% hint style="info" %} 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](https://claude.ai/app-help/integrations/jira/jira-cloud.md). {% endhint %} #### 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. ```yaml 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---<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" ``` {% hint style="info" %} `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. {% endhint %} {% hint style="info" %} 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. {% endhint %} #### 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: ```bash 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. {% hint style="info" %} 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. {% endhint %} #### 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: ```bash 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 | {% hint style="info" %} 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. {% endhint %} 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. ### Related Docs * [**Programmable Agents — Quick Start** — getting started with DinoAI agents](https://claude.ai/app-help/products/dino-ai/programmable-agents/quick-start.md) * [**Programmable Agents — YAML Configuration** — full reference for agent config options](https://claude.ai/app-help/products/dino-ai/programmable-agents/yaml-configuration.md) * [**Programmable Agents — Tools Reference** — all available tools including `read_file`, `get_jira_issue`, and `post_slack_message`](https://claude.ai/app-help/products/dino-ai/programmable-agents/tools-reference.md) * [**DinoAI CLI** — running agents from the terminal with `paradime dinoai`](https://claude.ai/app-help/developers/paradime-cli/dinoai-cli.md) * [**Jira Integration** — connecting Jira to Paradime](https://claude.ai/app-help/integrations/jira/jira-cloud.md) * [**Slack Integration** — connecting Slack to Paradime](https://claude.ai/app-help/integrations/slack.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.paradime.io/app-help/guides-new/programmable-agents/jira-backlog-agent.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.