atlassian-rovo

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Atlassian Rovo MCP Automation

Atlassian Rovo MCP 自动化

Getting Started

入门指南

Before starting any workflow, gather cloudId, projectKey, spaceId, and user info. See mcp-setup.md for configuration discovery, MCP setup, OAuth flow, and troubleshooting.

For image upload configuration, see image-upload.md. For git branch integration (GitHub/Bitbucket), see git-integration.md. For Confluence comment operations, see confluence-comments.md.

Always ask the user which project/space to use. Never assume defaults.

在启动任何工作流之前，请收集cloudId、projectKey、spaceId和用户信息。有关配置发现、MCP设置、OAuth流程和故障排查，请参阅mcp-setup.md。

有关图片上传配置，请参阅image-upload.md。有关Git分支集成（GitHub/Bitbucket），请参阅git-integration.md。有关Confluence评论操作，请参阅confluence-comments.md。

务必询问用户要使用哪个项目/空间，切勿默认假设。

Agentic Project Management Workflow

智能体化项目管理工作流

Full lifecycle project management using Jira + Confluence.

使用Jira + Confluence实现全生命周期项目管理。

Execution Modes

执行模式

Multi-Agent Mode (Claude Code with Agent Teams): Parallel execution with TeamCreate/TaskCreate orchestration.
Single-Agent Mode (all agents): Sequential execution — one workstream at a time. Same Jira tracking and Confluence updates, no multi-agent dependencies.

Mode detection: Use multi-agent mode when ALL of these are true:

The
```
TeamCreate
```
tool is available (test by checking tool list)
There are 2+ independent workstreams that can run in parallel

TeamCreate

is not available, or there's only 1 workstream, use single-agent mode. Never ask the user which mode to use — detect automatically and proceed.

多智能体模式（搭配智能体团队的Claude Code）：通过TeamCreate/TaskCreate编排实现并行执行。
单智能体模式（所有智能体）：顺序执行——一次处理一个工作流。具备相同的Jira跟踪和Confluence更新功能，无多智能体依赖。

模式检测：当以下所有条件均满足时，使用多智能体模式：

```
TeamCreate
```
工具可用（通过检查工具列表验证）
存在2个及以上可并行运行的独立工作流

若

TeamCreate

不可用，或仅存在1个工作流，则使用单智能体模式。切勿询问用户使用哪种模式——自动检测并执行即可。

The 4-Phase Cycle

四阶段循环

Phase 1: INTAKE   -> User describes request -> Confluence plan + Jira Epic
Phase 2: EXECUTE  -> Agent team works tickets with Jira tracking
Phase 3: RESUME   -> New session resumes from Jira state (fully autonomous)
Phase 4: COMPLETE -> All tickets Done -> Epic closed -> summary delivered

阶段1：需求收集 -> 用户描述需求 -> Confluence计划 + Jira Epic
阶段2：执行 -> 智能体团队处理工单并通过Jira跟踪
阶段3：恢复 -> 新会话从Jira状态恢复（完全自主）
阶段4：完成 -> 所有工单标记为完成 -> Epic关闭 -> 交付总结报告

Phase 1: Intake & Planning

阶段1：需求收集与规划

Classify the request, create Confluence plan page as a draft, then present to user for review before creating any Jira tickets. Only after approval: create Jira Epic with

[AI-PM]

prefix, child tickets per workstream, and link dependencies.

See phase-planning.md for step-by-step details and templates.

对需求进行分类，创建Confluence计划页面草稿，然后在创建任何Jira工单前提交给用户审核。仅在获得批准后：创建带有

[AI-PM]

前缀的Jira Epic，为每个工作流创建子工单，并关联依赖关系。

有关分步详情和模板，请参阅phase-planning.md。

Phase 2: Execution

阶段2：执行

Multi-agent mode: Create agent team, map tickets to tasks with dependency tracking, spawn teammates with standard prompt. Orchestrator monitors progress and updates Confluence plan page. See phase-execution.md for teammate prompt template and orchestrator duties.

Single-agent mode: Work each ticket sequentially, respecting dependency order. Track progress via Jira transitions and Confluence updates. See phase-execution-single.md for the sequential workflow.

Both modes share common protocols for transitions, branch creation, and publishing. See common-patterns.md for these shared procedures.

多智能体模式：创建智能体团队，将工单映射到带有依赖跟踪的任务，使用标准提示生成协作智能体。编排器监控进度并更新Confluence计划页面。有关协作智能体提示模板和编排器职责，请参阅phase-execution.md。

单智能体模式：按顺序处理每个工单，遵循依赖顺序。通过Jira状态转换和Confluence更新跟踪进度。有关顺序工作流，请参阅phase-execution-single.md。

两种模式共享状态转换、分支创建和发布的通用协议。有关这些共享流程，请参阅common-patterns.md。

Phase 3: Resume

阶段3：恢复

Auto-detect open

[AI-PM]

Epics, read Confluence plan, query incomplete tickets, classify state.

Multi-agent mode: Spin up right-sized team for remaining work. Single-agent mode: Pick up the next incomplete ticket and continue sequentially.

See phase-resume.md for JQL patterns and resume protocol (covers both modes).

自动检测开放状态的

[AI-PM]

Epic，读取Confluence计划，查询未完成的工单，分类状态。

多智能体模式：为剩余工作组建合适规模的团队。 单智能体模式：接手下一个未完成的工单并继续顺序执行。

有关JQL模式和恢复协议（涵盖两种模式），请参阅phase-resume.md。

Phase 4: Completion

阶段4：完成

Update Confluence page status, transition Epic to Done, add final summary comment, report deliverables to user.

See phase-completion.md for completion checklist.

更新Confluence页面状态，将Epic转换为“完成”状态，添加最终总结评论，向用户交付成果。

有关完成检查清单，请参阅phase-completion.md。

Team Sizing (Multi-Agent Mode)

团队规模（多智能体模式）

Request Type	Team Size	Roles
Small change	2	lead + implementer
Feature dev	3-4	lead + backend + frontend + (tester)
Research	3	lead + 2 researchers
Content	3	lead + writer + reviewer
Multi-component	4-5	lead + 1 per component

One ticket per teammate. Lead coordinates only (no workstream tasks). Min team = 2.

请求类型	团队规模	角色
小型变更	2	负责人 + 实施人员
功能开发	3-4	负责人 + 后端开发 + 前端开发 +（测试人员）
研究任务	3	负责人 + 2名研究员
内容创作	3	负责人 + 撰稿人 + 审核人
多组件任务	4-5	负责人 + 每个组件1名人员

每个协作智能体对应一个工单。负责人仅负责协调（不处理工作流任务）。最小团队规模为2人。

Key Constraints

关键约束

Transition IDs vary by project — each Jira project can have different workflow configurations, so hardcoding IDs will break across projects. Always call
```
getTransitionsForJiraIssue
```
before
```
transitionJiraIssue
```
.
[AI-PM]
prefix on all managed Epics — the resume phase uses JQL
```
summary ~ '[AI-PM]'
```
to auto-detect managed Epics. Without this prefix, resume cannot find prior work.
One writer per resource — Confluence uses optimistic locking with version numbers. Concurrent writes cause version conflicts and data loss. Only one agent should update a given page/issue at a time.
maxResults: 10
on all JQL/CQL searches — larger result sets consume excessive tokens and slow down processing. 10 results is sufficient for most workflows.
Transition to In Progress when work starts — this signals to other agents (and the resume phase) that a ticket is actively being worked. Use two-step protocol:
```
getTransitionsForJiraIssue
```
then
```
transitionJiraIssue
```
.
Assign tickets at creation and when starting work — set
```
assignee_account_id
```
when creating Epics and child tickets during planning. Also
```
editJiraIssue
```
with
```
{"assignee": {"accountId": "{currentUserAccountId}"}}
```
when starting work. Unassigned tickets look abandoned during resume.
Publish findings as child pages of the plan page (using
```
parentId
```
) — keeps all deliverables organized under one parent for easy navigation and resume context.
Verify Epic linking —
```
createJiraIssue
```
with
```
parentKey
```
may silently fail to set the Epic parent. Always verify with
```
getJiraIssue
```
, and if missing, fix with
```
editJiraIssue
```
using
```
{"parent": {"key": "{epicKey}"}}
```
.
Keep Epic description in sync — after completing each ticket, update the workstreams table in the Epic description to reflect the new status. Read the Epic first (
```
getJiraIssue
```
), then update (
```
editJiraIssue
```
). Stale Epic descriptions confuse the resume phase and human reviewers.
updateConfluencePage
replaces the entire body — before ANY page update, read the page body AND check for inline/footer comments (
```
getConfluencePageInlineComments
```
with
```
limit: 50
```
,
```
getConfluencePageFooterComments
```
with
```
limit: 50
```
). Users leave review feedback as inline comments — updating without reading comments will ignore their input. See common-patterns.md for the full protocol.

状态转换ID因项目而异——每个Jira项目的工作流配置可能不同，因此硬编码ID会导致跨项目故障。在调用
```
transitionJiraIssue
```
之前，务必先调用
```
getTransitionsForJiraIssue
```
。
所有托管Epics需添加
[AI-PM]
前缀——恢复阶段使用JQL语句
```
summary ~ '[AI-PM]'
```
自动检测托管Epics。若无此前缀，恢复功能无法找到之前的工作内容。
每个资源仅分配一名撰稿人——Confluence使用带版本号的乐观锁机制。并发写入会导致版本冲突和数据丢失。同一时间仅应有一个智能体更新指定页面/工单。
所有JQL/CQL搜索设置
maxResults: 10
——更大的结果集会消耗过多令牌并减慢处理速度。10条结果足以满足大多数工作流需求。
开始工作时转换为“In Progress”状态——这会向其他智能体（以及恢复阶段）发出信号，表明该工单正在处理中。使用两步协议：先调用
```
getTransitionsForJiraIssue
```
，再调用
```
transitionJiraIssue
```
。
创建工单和开始工作时分配负责人——在规划阶段创建Epic和子工单时设置
```
assignee_account_id
```
。开始工作时，使用
```
{"assignee": {"accountId": "{currentUserAccountId}"}}
```
调用
```
editJiraIssue
```
。未分配负责人的工单在恢复阶段会被视为已废弃。
将成果发布为计划页面的子页面（使用
```
parentId
```
）——将所有交付成果组织在同一个父页面下，便于导航和恢复上下文。
验证Epic关联——使用
```
createJiraIssue
```
并传入
```
parentKey
```
可能会静默失败，无法设置Epic父级。务必通过
```
getJiraIssue
```
进行验证，若未关联，则使用
```
{"parent": {"key": "{epicKey}"}}
```
调用
```
editJiraIssue
```
进行修复。
保持Epic描述同步——完成每个工单后，更新Epic描述中的工作流表格以反映新状态。先读取Epic（
```
getJiraIssue
```
），再进行更新（
```
editJiraIssue
```
）。过时的Epic描述会混淆恢复阶段和人工审核人员。
updateConfluencePage
会替换整个页面内容——在进行任何页面更新之前，务必先读取页面内容并检查内联/页脚评论（调用
```
getConfluencePageInlineComments
```
并设置
```
limit: 50
```
，调用
```
getConfluencePageFooterComments
```
并设置
```
limit: 50
```
）。用户会以内联评论的形式留下审核反馈——若不读取评论就进行更新，会忽略用户的输入。有关完整协议，请参阅common-patterns.md。