> ## Documentation Index
> Fetch the complete documentation index at: https://docs.paradime.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Jira change request agent

> Build a DinoAI agent that picks up Jira change request tickets, validates each request against your warehouse data, and opens a PR or escalates the ticket.

The Jira change request agent watches a Jira ticket type, works out which file in your repo each ticket is about, and checks the request against your warehouse data before touching anything. Every ticket ends in one of two states: a pull request linked to the ticket and ready for review, or an escalation comment with the specific question a human needs to answer. You build it entirely in the Agent UI (no YAML) and run it daily with Bolt's native **Run Paradime DinoAI Agent** command (no API keys).

This pattern fits any queue where tickets describe changes to code that lives in a predictable place: per-customer SQL logic, mapping tables, configuration files, or dbt™ models owned by a support or operations team.

<Note>
  **Prerequisites**

  * [Jira connected](/integrations/jira) so the agent can list tickets, comment, and change statuses.
  * Your repository connected so the agent can branch, commit, and open PRs.
  * A warehouse connection the agent can query read-only (it validates requests with `run_sql_query`).
  * Optional: [Slack connected](/integrations/slack) for run summaries.
  * Your Jira workflow must allow moving tickets from **Open** to **In Progress**, and from there to **Ready for Review** and **Needs Review** (or your equivalents). If a status isn't reachable, the agent's transitions will fail.

  Estimated time: 20 minutes.
</Note>

## Steps

<Steps>
  <Step title="Agree the conventions">
    The agent needs three conventions it can rely on. This guide uses example values; swap in your own everywhere they appear in the next step.

    | Convention                  | Example used in this guide                                                                                                                                     |
    | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
    | Which tickets to pick up    | Issue type `Change Request` in status `Open`                                                                                                                   |
    | How a ticket maps to a file | The ticket title starts with the entity name before `//` (for example `acme-corp // exclude test accounts`), and the code lives at `sql/<entity>/` in the repo |
    | Ticket lifecycle            | `Open` → `In Progress` (agent working) → `Ready for Review` (PR opened) or `Needs Review` (agent blocked)                                                      |

    Putting the ticket key in the branch name and PR title means Jira's GitHub integration links the PR to the ticket automatically.
  </Step>

  <Step title="Build the agent in the Agent UI">
    In the **Agent** app, open **Agents**, select **New agent**, then **Start from scratch**. See [Build an agent in the UI](/guides/programmable-agents/build-in-the-agent-ui) for a tour of the builder. Fill in the fields:

    **Name**: `jira-change-request-agent`

    **Role**:

    ```text theme={"system"}
    Change request maintainer. You turn "Change Request" Jira tickets
    into review-ready pull requests, and escalate tickets you cannot
    resolve with confidence.
    ```

    **Goal**:

    ```text theme={"system"}
    1. List all Jira issues of type "Change Request" in status "Open".
       If there are none, stop.

    2. For each ticket, one at a time:
       a. Move the ticket to "In Progress".
       b. Identify the target: the entity name is the ticket title text
          before "//", and its code lives at sql/<entity>/ in the repo.
       c. Read the current code for that entity. If it does not exist,
          treat the ticket as blocked (step f).
       d. Draft the change the ticket describes. If the ticket is
          ambiguous, run read-only SQL against the warehouse to inspect
          the relevant tables and infer the intent. Record what you
          queried and what you found.
       e. If you are confident: create a branch
          change/<TICKET-KEY>-<short-desc>, apply the change, commit,
          push, and open a PR titled "<TICKET-KEY>: <summary>". The PR
          body must explain what changed, why the data supports it
          (citing the tables and columns you checked), and any
          assumptions under an "Open questions" heading. Move the
          ticket to "Ready for Review" and comment the PR link on it.
       f. If you are not confident after checking the data: do NOT open
          a PR. Comment on the ticket with what you found and the
          question a human needs to answer, then move the ticket to
          "Needs Review".

    3. Post a summary of every ticket and its outcome to Slack.
    ```

    **Backstory**:

    ```text theme={"system"}
    You are a careful maintainer, not a creative one. Only ever edit the
    files that belong to the entity named in the ticket, and match their
    existing style. Never invent tables or columns: verify every object
    you reference exists via a read-only query. Never write to the
    warehouse. When the ticket and the data disagree, or the data cannot
    support the request, that is a "Needs Review" outcome, not a guess.
    One ticket = one branch = one PR.
    ```

    **Model**: leave **Auto** selected.

    **Allowed tools** (everything else is refused, see the [Tools Reference](/products/dino-ai/programmable-agents/tools-reference)):

    * `get_jira_issue`, `list_jira_issues`, `update_jira_issue`, `add_jira_comment`
    * `read_file`, `write_file`, `search_files_and_directories`, `ripgrep_search`
    * `run_sql_query`
    * `run_terminal_command`
    * `post_slack_message`

    **Output**: pick the Slack channel for run summaries, or leave empty (messages then land in the Bolt run logs; also remove `post_slack_message` and the Slack step from the Goal).

    <Info>
      If the code lives in a different repository than the one connected to your workspace, add `list_accessible_repos` and `clone_additional_repo` to the allowed tools and prepend a Goal step telling the agent to clone that repo and work inside the clone. The agent can clone any repository your GitHub integration grants access to.
    </Info>
  </Step>

  <Step title="Deploy and test it with a chat">
    Select **Deploy**, then **Just here**: the agent is saved to the workspace and live immediately. (Once it settles, redeploy via **Open a pull request** to version-control the definition, see [Creating Agents in the App](/products/dino-ai/programmable-agents/creating-agents-in-the-app).)

    With one known-good ticket in **Open** status, hover the agent card, select **Chat**, and send: `Process the open Change Request ticket queue end to end.` Confirm the status transitions, the branch and PR, and the ticket comment all land before scheduling it.
  </Step>

  <Step title="Schedule it with Bolt">
    On the **Agents** page, hover the agent card and select **Schedule**. This opens a new [Bolt schedule](/guides/paradime-101/running-dbt-in-production-with-bolt/creating-bolt-schedules) with the **Run Paradime DinoAI Agent** command already added and the agent pre-selected.

    1. **Task**: `Process the open Change Request ticket queue end to end.`
    2. Select **Save command**, set the [trigger](/guides/paradime-101/running-dbt-in-production-with-bolt/understanding-schedule-types-and-triggers) to a cron such as `0 9 * * 1-5` (weekdays at 9 AM), and deploy.

    The command runs natively inside Paradime, so there are no API keys or environment variables to configure. The agent exits cleanly on an empty queue, so a daily run costs nothing when there are no tickets.
  </Step>
</Steps>

<Check>
  After a run, every ticket that was in **Open** ends in **Ready for Review** with exactly one linked PR explaining the change from a data standpoint, or in **Needs Review** with a comment specific enough to answer without re-deriving the context. No ticket is left in **In Progress**. The most likely failure is a Jira transition error, which means a target status isn't reachable from the ticket's current status in your Jira workflow. Check the run transcript in the [agent sessions panel](/products/dino-ai/programmable-agents/agent-sessions).
</Check>

## How it works

The agent's defining behavior is the validation gate: it only opens a PR when it can ground the request in your actual data, and everything else becomes a precise question back to the ticket instead of a guess. That means reviewers only ever see PRs with evidence attached, and unclear tickets surface immediately rather than after a wrong change ships.

```text theme={"system"}
1. List Jira issues: type "Change Request", status "Open"
2. Per ticket:
   a. Transition to "In Progress"
   b. Resolve the entity from the ticket title, locate its code
   c. Draft the change; if ambiguous, read-only SQL to infer intent
   d. Confident   -> branch, PR (key in title and branch),
                     data reasoning in the PR body,
                     transition to "Ready for Review"
   e. Not confident -> comment findings + specific question,
                     transition to "Needs Review"
3. Post run summary to Slack
```

Like the [Jira backlog agent](/guides/programmable-agents/jira-backlog-agent), the orchestration lives inside the agent's Goal: one session works the queue sequentially, so there is no wrapper script or orchestrator to maintain. What this template adds is the status lifecycle (tickets always land in a terminal status) and the escalation path for requests the data does not support.

## Next steps

<CardGroup cols={2}>
  <Card title="Jira backlog agent" href="/guides/programmable-agents/jira-backlog-agent" icon="ticket">
    The label-driven variant: implement dbt™ models from agent-ready issues.
  </Card>

  <Card title="Run an agent with Bolt" href="/guides/programmable-agents/run-an-agent-with-bolt" icon="rocket">
    Everything the Run Paradime DinoAI Agent command can do.
  </Card>

  <Card title="Triggering from Bolt reference" href="/products/dino-ai/programmable-agents/triggering-from-bolt" icon="zap">
    Every field of the command and the run lifecycle.
  </Card>

  <Card title="Tools Reference" href="/products/dino-ai/programmable-agents/tools-reference" icon="wrench">
    What every tool id in the allowlist does.
  </Card>
</CardGroup>


## Related topics

- [Jira backlog agent](/guides/programmable-agents/jira-backlog-agent.md)
- [MongoDB schema drift triager](/guides/programmable-agents/mongodb-schema-drift-triager.md)
- [Jira Tool](/products/dino-ai/tools-and-features/jira-tool.md)
- [Fix errors with Jira](/guides/dinoai-copilot-use-cases/fixing-errors-with-jira.md)
- [Jira](/integrations/jira/index.md)