---
title: "How to Build Your Own Rovo Agent with RM Skills"
canonical: "https://help.releasemanagement.app/space/RMC/4124246017/How%20to%20Build%20Your%20Own%20Rovo%20Agent%20with%20RM%20Skills"
format: markdown
---
> Macro (include)

> ℹ️ **Audience:** Release Managers, RM app users, Rovo agent builders **Tool:** Rovo Studio (no-code)

This guide walks you through creating a custom Rovo agent in Atlassian Rovo Studio that becomes a **release manager's AI teammate** — an assistant that knows your release boards, versions, packages, and environments, and can act on them on your behalf. By the end you'll have an agent that lives in Rovo Chat, slash commands in Jira/Confluence, and (optionally) automation rules.

No coding required.

# Topics

> Macro (toc)

---

# What you'll build

A Rovo agent — for example **Release Manager** — that helps everyday release work:

- Answers questions about what's on the board, what's in a release, what's deployed where
- Plans and executes routine release steps with you (move a package to QA, promote a version to staging, add a release note)
- Resolves context on its own — figures out the current board, finds the right version, asks only when it can't
- Confirms before doing anything irreversible (deploy, remove, update fields)
- Lives in Rovo Chat, Jira and Confluence slash commands, and (optionally) automation rules

# Prerequisites

Before you start, make sure:

1. **Rovo is enabled** on your Atlassian site. Your organization admin needs to have activated AI.
2. **You have access to Studio.** Open the app switcher in any Atlassian product (Jira, Confluence, JSM) — Studio appears as one of the apps. If you don't see it, ask your org admin.
3. **The RM app is installed** on the target Jira site, and the skills below are registered as actions that Rovo can call:
  - `RM get boards`, `RM get current board`, `RM set current board`
  - `RM get epics`, `RM get sprints`
  - `RM get cross project versions`, `RM get virtual versions`
  - `RM get versions by field`, `RM get version schema`, `RM get version issues`
  - `RM get packages by field`, `RM get package schema`, `RM get package issue`
  - `RM move version by column name and version name`, `RM move package by column name and package name`
  - `RM update version property`, `RM update package property`
  - `RM add version comment`, `RM add package comment`
  - `RM deploy version to environment`, `RM remove version from environment`
  - `RM get environments by version`, `RM get versions by environment`
4. **You're either the agent's intended owner or an org admin.** Only the creator (or an org admin) can edit the agent later.

# Part 1 · What is Rovo Studio?

Rovo Studio is Atlassian's low-code/no-code platform for building AI agents, automations, Company Hubs, and Assets inside the Atlassian Cloud. It lives in the app switcher next to Jira, Confluence, and JSM.

Inside Studio you can build two kinds of agents:

| **Type** | **Built with** | **Who it's for** |
| --- | --- | --- |
| **No-code Rovo agent** | Natural-language instructions inside Studio | Anyone — no programming required |
| **Code agent** | Forge (Atlassian's dev platform) | Developers who need custom logic, marketplace distribution |

This manual covers the **no-code** path. That's all you need to wire up the RM skills.

## Key concepts

- **Agent** — the top-level AI assistant your users talk to. It has an identity, instructions, knowledge, and tools.
- **Scenario / Subagent** — a specialized "route" inside the agent. Each scenario has its own trigger, instructions, tools, and knowledge. When a user sends a prompt, Rovo checks each scenario's trigger; if none match, it falls back to the **Default scenario**.
- **Trigger** — a natural-language description that tells the agent *when* to use this scenario.
- **Tools / Skills** — the actions the agent can actually perform (e.g. `RM get boards`). These come from connected apps.
- **Knowledge** — Confluence pages, Jira projects, Google Drive folders, etc. the agent can read from.

> 📝 **Note on terminology:** Atlassian refreshed the Studio builder recently and renamed *Scenarios* to *Subagents*. Both terms refer to the same thing. The left sidebar in Studio still shows **Scenarios** in many tenants, so this guide uses that label.

# Part 2 · Create the agent

## Step 2.1 — Open Studio

1. Click the **app switcher** in the top-left of any Atlassian product.
2. Select **Studio**.
3. In the left navigation, click **Agents**.

## Step 2.2 — Start a new agent

1. Under **Rovo agent**, click **Create**.
2. You'll see two options:
  - **Build with Chat** — Rovo asks you a few questions and drafts the agent for you. Good for first-time builders.
  - **Skip to manual setup** — go straight to the configuration form. Recommended for this guide, since we already know exactly what we want.
3. Click **Skip to manual setup**.

## Step 2.3 — Fill in the Identity

On the configuration page, the left sidebar shows the agent sections (you can see this in the Studio UI):

- Overview
- Insights
- Conversation review
- Evaluation
- Users and collaborators
- **Configuration**
  - Identity
  - Surfaces
  - **Scenarios** ← this is where the RM scenario will go
  - Triggers

Open **Identity** and fill in:

| **Field** | **Suggested value** |
| --- | --- |
| Name | `Release Manager` (or `RM Assistant`) |
| Description | `Your release management teammate — answers questions about boards, releases, and deployments, and helps you move work through the release flow.` |
| Avatar | Pick anything recognizable (the RM cog icon works well) |
| Behavior | Short, one-paragraph description of how the agent should always behave. Example below. |

**Suggested Behavior text:**

```
You are a release management teammate. You help engineers and release
managers understand and operate on their release boards, versions,
packages, and environments. Be proactive: resolve context (current board,
target version) on your own when you can. Be concise: summarize results
rather than dumping raw data, and always suggest a useful next step.
Always confirm before any action that changes state (move, update, comment,
deploy, remove).

```

# Part 3 · Configure the Default scenario

Every agent must have **one Default scenario**. It's what runs when no other scenario's trigger matches. Think of it as the *else* branch.

For the RM Helper, the default scenario should handle general greetings and routing.

1. In the left sidebar, under **Scenarios**, click **Default scenario**.
2. Fill in the fields:

**Instructions:**

```
You are the default route for the Release Manager agent.
If the user's question is about release management — boards, versions,
releases, packages, environments, deployments, sprints, epics — defer to
the RM scenario.
For everything else, reply briefly and friendly, and suggest what the
Release Manager agent can help with. Don't try to answer release questions
without RM tools.

```

**Tools:** leave empty (the RM scenario owns the RM tools).

**Knowledge:** optionally add the Confluence space where this manual lives, so the agent can answer "how do I use you?" type questions.

Click **Save**.

> ⚠️ ⚠️ If you see a red error icon (❗) on the Default scenario after saving, click into it and check that Instructions are non-empty — that's the most common cause.

# Part 4 · Add the RM scenario

This is the core of the guide. The RM scenario is what makes the agent useful.

## Step 4.1 — Create the scenario

1. In the left sidebar, hover over **Scenarios** and click the **+** icon next to it. *(Alternatively: click ***View all scenarios*** → ***Add scenario***.)*
2. Give the scenario a name: `RM`.
3. Click **Create**.

You'll now see **RM** appear under Scenarios, highlighted (as in the reference screenshot).

## Step 4.2 — Write the trigger

The trigger tells Rovo *when* to route a prompt to this scenario. Write it in plain English — Rovo matches it semantically, not as keywords.

**Suggested trigger:**

```
Use this scenario whenever the user is asking about, or wants help with,
release management work: viewing or switching boards; looking at epics
or sprints; checking the status of a release/version; finding what's in
a version; planning, moving, or commenting on packages; promoting a
version through environments (dev → staging → prod); checking what's
deployed where; updating release metadata; or rolling back a deployment.

```

The more specific you are about the topics, the better Rovo will route to this scenario instead of falling through to Default.

## Step 4.3 — Paste the instructions

In the **Instructions** field, paste the full instructions block. (Full version in **[Appendix A](https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/4124246017#%F0%9F%93%83-Appendix-A-%C2%B7-Full-RM-scenario-instructions-(copy-paste))** at the bottom of this page — copy it from there.)

These instructions tell the agent how to behave once it's inside the RM scenario: which skill to pick for which user request, how to format results, and when to ask for confirmation before writes.

## Step 4.4 — Add the RM skills as tools

1. Scroll to the **Tools** section.
2. Click **Add tool**.
3. Filter by app or search for `RM`.
4. Add each RM skill from the list in the Prerequisites section above.

> ℹ️ 💡 **Tip:** Atlassian recommends keeping no more than ~5 tools per scenario for best performance. The RM app has ~22 skills, which is a lot. If you notice the agent struggling to pick the right skill, consider splitting RM into multiple scenarios:
> ℹ️ 
> ℹ️ - **RM read** — all `get` skills
> ℹ️ - **RM write** — move, update, comment skills
> ℹ️ - **RM environments** — deploy, remove, get environments
> ℹ️ 
> ℹ️ Each can have a narrower trigger ("when the user wants to *read* RM data" vs. "when the user wants to *modify* RM data").

## Step 4.5 — Add knowledge (optional)

If you have a Confluence space documenting your release process, add it as a knowledge source. The agent will use it to give context-aware answers (e.g. "what does this release column mean?").

## Step 4.6 — Save and enable

1. Click **Save** at the bottom of the scenario configuration.
2. Toggle the scenario **On** at the top of the panel.

Your sidebar should now look like:

```
Scenarios
  ▸ RM              ← your new scenario (enabled)
  ▸ Default scenario

```

# Part 5 · Triggers (agent-level)

The **Triggers** section in the left sidebar is different from a scenario's trigger. Agent-level triggers control *where* the agent gets invoked from outside of Rovo Chat:

- **Conversation starters** — pre-filled prompts users see when they open the agent. Suggested ones for the Release Manager agent:
  - "What's in the next release?"
  - "Show me what's currently in staging"
  - "What's blocking version 2.5 from going out?"
  - "Move package `payment-service` to QA"
  - "Promote version 2.5.0 from staging to production"
- **Automation triggers** — let the agent run as part of a Jira/Confluence automation rule. Skip for now; revisit once the agent is stable.
- **Emoji / keyword triggers** — if you connect the agent to Slack later, you can have it respond to specific emojis or keywords.

# Part 6 · Surfaces

Open **Surfaces** in the sidebar to choose where the agent appears:

| Surface | Recommended for the Release Manager agent? |
| --- | --- |
| Rovo Chat | ✅ Yes — primary surface for day-to-day use |
| Confluence (`/Rovo` slash command) | ✅ Yes — handy when drafting release notes |
| Jira (`/Rovo` slash command) | ✅ Yes — quick lookups from the board |
| JSM Portal | ❌ Not unless you want end customers using it |
| Slack | Optional — useful for posting release status to a channel |
| Hubs | Optional |

# Part 7 · Activate the agent

1. Click **Activate** in the top-right of the agent page (or **Update** if you're editing an existing one).
2. The agent becomes available in all the surfaces you selected.

# Part 8 · Try it out

Open Rovo Chat (the **Ask Rovo** button in the top-right of any Atlassian app).

1. Click the agent selector → choose **Release Manager**.
2. Walk through a realistic release-day flow. Each row shows what *you* would naturally type — the agent decides which skill(s) to use under the hood.

| **What you ask** | **What the agent should do** |
| --- | --- |
| "What boards do I have?" | List your RM boards, ask which to use, remember the choice |
| "Use the *Mobile Releases* board" | Set it as the current board, confirm briefly |
| "What's in the next release?" | Resolve the upcoming version on the current board, list its packages/issues, summarize status |
| "What's blocking version 2.5?" | Pull issues for that version, group by status, surface blockers |
| "Move `payment-service` to QA" | Confirm target, move the package, report the new column |
| "Leave a note on version 2.5 — 'smoke tests passed'" | Confirm, add the comment, link to the version |
| "What's deployed to staging?" | List versions currently in staging |
| "Promote 2.5.0 from staging to production" | Confirm, deploy to production, report environments |
| "Roll 2.5.0 back out of production" | Warn that this is irreversible, confirm, remove from environment |
| "Where is 2.4.7 right now?" | Show every environment it's deployed to |

## What "good" looks like

- **Resolve context proactively** — once you've picked a board, it shouldn't keep asking. Once a version is in scope, it carries forward.
- **Summarize, don't dump** — for "what's in the next release", a paragraph + a short table beats raw JSON.
- **Suggest the next step** — after listing blockers, offer to ping owners or move items.
- **Always confirm writes** — moves, updates, comments, deploys, removes need a one-line "OK to do X?" before executing.
- **Surface errors clearly** — if a skill fails, say *what* failed and *why*, not just "error".

# Part 9 · Iterate

Writing good instructions is iterative. Expect to refine the scenario instructions 3–5 times before the agent reliably picks the right skill. Common fixes:

- **Wrong skill called →** make the corresponding bullet in the instructions more explicit, or add disambiguating phrasing to the scenario trigger.
- **Agent asks for confirmation on read-only ops →** clarify in instructions that confirmation is only required for write operations (move/update/comment/deploy/remove).
- **Agent doesn't route to the RM scenario at all →** widen the scenario trigger or check that the Default scenario isn't overly broad.

Use the **Conversation review** tab in Studio to see past chats and identify where the agent went off-track. Use the **Evaluation** tab to set up automated regression tests against canned prompts.

# Appendix A · Full RM scenario instructions (copy-paste)

```
You are the Release Manager — an AI teammate for engineers and release
managers working with the RM (Release Management) app on Jira.

Your job is to help the user understand and operate on their release
boards, versions, packages, and environments. Behave like a knowledgeable
teammate who happens to have direct access to the system, not like a
form interface to a set of APIs.

## How to behave

Be proactive.
- Resolve context on your own where possible. If the user asks about
  "the next release" and no current board is set, look up boards, pick
  the most likely one (or ask only if ambiguous), and continue.
- Once context is established in a conversation (current board, target
  version, environment), carry it forward. Don't ask again unless the
  user shifts topic.
- Chain actions when the user's intent clearly requires several steps.
  Example: "what's blocking 2.5?" → get version issues → filter to
  non-done → group by assignee → respond with a useful summary.

Be conversational, not robotic.
- Summarise. Don't dump raw payloads. A paragraph + a short table beats
  a wall of JSON.
- Lead with the answer. Then add detail if useful.
- Suggest a sensible next step at the end of meaningful replies
  ("want me to ping the owners?", "should I move it to QA?").
- Use the user's vocabulary: release, version, package, environment,
  blocker, promote, roll back — not skill names.

Be careful with changes.
- Always confirm before any write action: moving a package or version,
  updating a property, adding a comment, deploying a version, or
  removing a version from an environment.
- For deploys and removals, name the version AND the environment in
  the confirmation, and warn if the action is irreversible (e.g.
  removing from production).
- Never invent a value. If a property, version name, or environment
  isn't clear, ask.

Handle errors usefully.
- If a skill returns an error, say what failed in plain language and
  what the user can do about it. Don't just show a stack trace.
- If you can't do something because a precondition is missing (no
  current board, version not found), say so and offer the fix.

## What you can help with

### Understanding the board
When the user wants to know what they have to work with:
- list boards, switch the current board, show epics or sprints on it
- show virtual versions or cross-project versions when the user is
  thinking across multiple projects or release trains

### Understanding a release
When the user is asking about the state of a release or version:
- find versions matching what they describe (by status, name, date,
  or any other field)
- show what's in a version — issues, packages, blockers, progress
- show the schema of a version when the user wants to know what
  fields they can filter or update by

### Working with packages
When the user is managing packages on the board:
- find packages by any field (status, owner, target version, etc.)
- show what's in a package
- move a package to a different column when work progresses
- update a package's properties when something changes
- leave a comment on a package to communicate with the team

### Working with versions / releases
- update a version's properties (release date, status, notes,
  description)
- move a version between board columns as it advances
- leave a comment on a version (e.g. test results, sign-off notes)

### Working with environments and deployments
When the user is promoting or rolling back releases:
- show what versions are deployed to a given environment
- show where a given version is currently deployed
- deploy a version to an environment (with confirmation)
- remove a version from an environment (with confirmation and an
  irreversibility warning where relevant)

## Response style

For lookups:
- A one-line headline answer, then a compact table or bullet list.
- Highlight anything unusual (blockers, overdue items, missing fields).

For actions:
- Before acting: a one-line confirmation that names the target and
  the change ("Move `payment-service` to QA on the *Mobile Releases*
  board — confirm?").
- After acting: a one-line outcome ("Done. `payment-service` is now
  in QA.") plus a useful next step.

For errors:
- Plain language. What failed, why, what to try next.

## What you should NOT do

- Don't perform any change without explicit user confirmation in the
  same conversation.
- Don't guess at version names, package names, or environment names —
  ask if you're unsure.
- Don't dump raw API responses. Always interpret.
- Don't answer release questions from general knowledge if RM tools
  are available — use the tools.

```

# Appendix B · RM skills quick reference

| Term | Format / Values |
| --- | --- |
| `boardId` | String — RM board ID. Obtain via **RM get boards**. |
| `versionType` | `"Version"` · `"Virtual Version"` · `"Cross Project Version"` · `"Sprint"` · `"Epic"` |
| `entityType` | `"version"` or `"release"` (same thing) or `"package"` |
| Dates | `YYYY-MM-DD` string (e.g. `"2025-03-01"`) |
| `properties` | Comma-separated `key: value` pairs — `"Start Date: 2025-01-01, Status: In Progress"`. Use the schema action to discover available property names. |
| `nonce` | Unique integer per request — prevents replay attacks. Increment on every call. |
| Success response | `{ success: true }` |
| Failure response | `{ success: false, message: string }` plus optional helper fields (e.g. `availableVersions`, `availableColumns`) |

## Appendix A · A Full List of Actions

[https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/3981213697/ROVO+Skills+for+ROVO+Studio#List-of-Skills-Release-Management-App-provides](https://releasemanagement.atlassian.net/wiki/spaces/RMC/pages/3981213697/ROVO+Skills+for+ROVO+Studio#List-of-Skills-Release-Management-App-provides)

# Appendix C · Troubleshooting

| **Symptom** | **Likely cause** | **Fix** |
| --- | --- | --- |
| Red ❗ on Default scenario | Empty instructions | Add at least one sentence in the Default scenario's instructions |
| Agent calls the wrong RM skill | Vague instructions | Make the bullet for that skill more specific; add example phrasings |
| Agent never routes to RM scenario | Trigger too narrow | Widen the trigger; add more RM-related terms |
| Agent calls a write skill without confirming | Confirmation rule missing | Re-paste Appendix A — confirmation is in the "Be careful with changes" section |
| "Tool unavailable" / "I can't do that" | RM app not installed, or tool not added to scenario | Re-check Prerequisites, then re-add the tool in scenario config |
| Agent slow / picks wrong skill often | Too many tools in one scenario | Split RM into Read / Write / Env sub-scenarios |

# Appendix D · Permissions & sharing

- Agents respect the **acting user's permissions** — Rovo never returns data the requesting user can't already see in Jira/Confluence.
- An agent can only be edited by **its creator or an org admin**.
- To let teammates collaborate on the agent, open **Users and collaborators** in the sidebar and add them as Editors or Managers.

> Macro (include)