analyzing-release-readiness

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Release Readiness Review

发布就绪审查

AgentSpace routing (SigV4 only): If
list_agent_spaces
is available in your tool list and the multi-space orchestration skill has NOT been invoked yet this session, invoke it first to determine which
agent_space_id
to use. Then pass
agent_space_id
on all tool calls below. For bearer token auth this is unnecessary — the token is already scoped to one space.

Run a release readiness review via the AWS DevOps Agent. Analyzes a code change for risk, correctness, and potential rollback issues. Returns a structured report with actionable findings.

Rules:

If a PR/MR URL is provided: Extract ALL fields from the URL. Do NOT inspect the local workspace or git state.
NEVER use
gh
CLI,
glab
CLI, or any external tool to fetch PR/MR details. All required fields (repository, prNumber/mergeRequestIid, hostname) MUST be parsed directly from the URL or user input. The DevOps Agent fetches the content itself — you only need to pass identifiers.
Only use the local workspace flows when the user references a repository or package without a PR/MR link.

AgentSpace 路由（仅支持SigV4）： 如果你的工具列表中包含
list_agent_spaces
，且本次会话尚未调用过多空间编排技能，请先调用它以确定要使用的
agent_space_id
。然后在以下所有工具调用中传入
agent_space_id
。对于Bearer令牌认证，此步骤无需执行——令牌已限定在单个空间内。

通过AWS DevOps Agent运行发布就绪审查。分析代码变更的风险、正确性和潜在回滚问题。返回包含可操作结论的结构化报告。

规则：

如果提供了PR/MR URL：从URL中提取所有字段。请勿检查本地工作区或Git状态。
绝不使用
gh
CLI、
glab
CLI或任何外部工具获取PR/MR详情。所有必填字段（仓库、prNumber/mergeRequestIid、主机名）必须直接从URL或用户输入中解析。DevOps Agent会自行获取内容——你只需传递标识符。
仅当用户引用仓库或包但未提供PR/MR链接时，才使用本地工作区流程。

Gathering execution parameters

收集执行参数

Infer everything automatically from the user's request — do not ask for parameters that can be derived.

Input source decision tree:

Has the user provided a pull request/merge request link or ID?
├── Yes: github.com PR URL               → use "GitHub PR" flow below
├── Yes: gitlab.com MR URL               → use "GitLab MR" flow below
└── No link provided — repo name only    → use "Local GitHub/GitLab repo" flow below

自动从用户请求中推断所有信息——不要询问可推导的参数。

输入源决策树：

用户是否提供了拉取请求/合并请求链接或ID？
├── 是：github.com PR URL               → 使用下方的“GitHub PR”流程
├── 是：gitlab.com MR URL               → 使用下方的“GitLab MR”流程
└── 未提供链接——仅仓库名称    → 使用下方的“本地GitHub/GitLab仓库”流程

GitHub PR (github.com URL or PR reference)

GitHub PR（github.com URL或PR引用）

Parse the input to extract fields — do NOT attempt a web fetch unless fields cannot be determined from the input.
```
repository
```
(required):
```
owner/repo
```
from the PR URL
At least one of the following is required:
```
headSha
```
(commit SHA),
```
headBranch
```
(branch name),
```
prNumber
```
(PR number as a string, e.g.
```
"8"
```
not
```
8
```
)
```
hostname
```
: Extract from the URL (e.g.,
```
github.com
```
or a self-hosted hostname)
Pass these fields to
```
create_release_readiness_review
```
under
```
content.githubPrContent
```
as an array of objects (even for a single PR).

Example:

json

{
  "content": {
    "githubPrContent": [
      {
        "repository": "owner/repo",
        "prNumber": "8",
        "hostname": "github.com"
      }
    ]
  }
}

Critical format rules:
githubPrContent
MUST be an array (not a single object).
prNumber
MUST be a string (not an integer).

解析输入以提取字段——除非无法从输入中确定字段，否则请勿尝试网络获取。
```
repository
```
（必填）：PR URL中的
```
owner/repo
```
至少需要以下其中一项：
```
headSha
```
（提交SHA）、
```
headBranch
```
（分支名称）、
```
prNumber
```
（PR编号，需为字符串，例如
```
"8"
```
而非
```
8
```
）
```
hostname
```
：从URL中提取（例如
```
github.com
```
或自托管主机名）
将这些字段作为对象数组传递给
```
create_release_readiness_review
```
的
```
content.githubPrContent
```
（即使单个PR也需如此）。

示例：

json

{
  "content": {
    "githubPrContent": [
      {
        "repository": "owner/repo",
        "prNumber": "8",
        "hostname": "github.com"
      }
    ]
  }
}

关键格式规则：
githubPrContent
必须是数组（而非单个对象）。
prNumber
必须是字符串（而非整数）。

GitLab MR (gitlab.com URL)

GitLab MR（gitlab.com URL）

Parse the input to extract fields — do NOT attempt a web fetch unless fields cannot be determined from the input.
```
repository
```
(required):
```
owner/repo
```
from the MR URL
At least one of the following is required:
```
headSha
```
(commit SHA),
```
headBranch
```
(branch name),
```
mergeRequestIid
```
(MR number as a string, e.g.
```
"1"
```
not
```
1
```
)
```
hostname
```
: Extract from the URL (e.g.,
```
gitlab.com
```
or a self-hosted hostname)
Pass these fields to
```
create_release_readiness_review
```
under
```
content.gitlabMrContent
```
as an array of objects (even for a single MR).

Example:

json

{
  "content": {
    "gitlabMrContent": [
      {
        "repository": "namespace/repo",
        "mergeRequestIid": "1",
        "hostname": "gitlab.com"
      }
    ]
  }
}

Critical format rules:
gitlabMrContent
MUST be an array (not a single object).
mergeRequestIid
MUST be a string (not an integer). Violating either causes immediate task failure with no journal records.

解析输入以提取字段——除非无法从输入中确定字段，否则请勿尝试网络获取。
```
repository
```
（必填）：MR URL中的
```
owner/repo
```
至少需要以下其中一项：
```
headSha
```
（提交SHA）、
```
headBranch
```
（分支名称）、
```
mergeRequestIid
```
（MR编号，需为字符串，例如
```
"1"
```
而非
```
1
```
）
```
hostname
```
：从URL中提取（例如
```
gitlab.com
```
或自托管主机名）
将这些字段作为对象数组传递给
```
create_release_readiness_review
```
的
```
content.gitlabMrContent
```
（即使单个MR也需如此）。

示例：

json

{
  "content": {
    "gitlabMrContent": [
      {
        "repository": "namespace/repo",
        "mergeRequestIid": "1",
        "hostname": "gitlab.com"
      }
    ]
  }
}

关键格式规则：
gitlabMrContent
必须是数组（而非单个对象）。
mergeRequestIid
必须是字符串（而非整数）。违反任一规则都会导致任务立即失败且无日志记录。

Local GitHub/GitLab repo (no PR/MR URL provided — local workspace ONLY)

本地GitHub/GitLab仓库（未提供PR/MR URL——仅本地工作区）

MANDATORY: When the user references a repository or branch without a PR/MR link, you MUST execute every step below in order. Do NOT shortcut by grabbing the remote URL and SHA directly — the review agent needs a pushed branch to read from. Skipping the push step will cause the analysis to fail or produce incomplete results.

Navigate to the repository directory:
```
cd
```
to the repo root (e.g., the clone directory). Ask the user if needed.
Determine the base branch: Use
```
main
```
unless the user specifies a different branch. Verify the remote tracking branch exists:
bash
```
BASE_BRANCH="main"
if ! git show-ref --verify --quiet refs/remotes/origin/$BASE_BRANCH; then
    git fetch origin $BASE_BRANCH
fi
```
If the fetch fails (e.g., "couldn't find remote ref"), ask the user to specify the base branch and stop.
Check for local changes: Run
```
git status --short
```
and
```
git rev-list --count origin/$BASE_BRANCH..HEAD
```
to determine the state and communicate accordingly:
- Clean AND not ahead: Inform the user there's nothing new to analyze and stop.
- Has uncommitted changes (with or without unpushed commits):
  - If there are one or more unpushed commits (rev-list count >= 1), tell the user:
    
    "You have uncommitted changes and N unpushed commits. I'll commit your uncommitted changes on top, then push all N+1 commits to a new branch for analysis. All changes will appear as a single diff against the base branch. Shall I proceed?"
  - If there are no other unpushed commits (rev-list count = 0), tell the user:
    
    "I'll commit your uncommitted changes and push them to a new branch for release readiness review. Shall I proceed?"
  - Do NOT proceed until the user approves. If they decline, stop.
- Clean but ahead of remote (rev-list count > 0, no uncommitted changes):
  - If ahead by more than 1 commit, tell the user:
    
    "You have N unpushed commits. I'll push all of them to a new branch for analysis. All changes will appear as a single diff against the base branch. Shall I proceed?"
  - If ahead by exactly 1 commit, tell the user:
    
    "I'll push your latest commit to a new branch for release readiness review. Shall I proceed?"
  - Do NOT proceed until the user approves. If they decline, stop.

Stash uncommitted changes (skip this step if working directory is clean):

bash

git stash push --include-untracked -m "release-analysis: preserve working changes"

Create review branch (do this BEFORE committing so the snapshot commit only lives on the disposable branch):

bash

ORIGINAL_BRANCH=$(git rev-parse --abbrev-ref HEAD)
BRANCH_NAME="feat/release-readiness-review"
git checkout -b $BRANCH_NAME 2>/dev/null || { BRANCH_NAME="feat/release-readiness-review-$(date +%Y%m%d-%H%M%S)"; git checkout -b $BRANCH_NAME; }

Apply stashed changes and commit on the review branch (skip this step if working directory was clean — go straight to step 7):
bash
```
git stash apply
```
Before staging, check for sensitive files:
bash
```
git status --short | grep -iE '\.(env|pem|key|p12|pfx|credentials|secret)'
```
If sensitive files are detected, warn the user and ask for confirmation before proceeding. If the user declines, abort:
bash
```
git checkout $ORIGINAL_BRANCH && git branch -D $BRANCH_NAME && git stash drop
```
Once confirmed (or no sensitive files found):
bash
```
git add -A
git commit -m "chore: snapshot for release readiness review"
```
Push all unpushed commits (requires prior user approval): If the user already approved the push in step 3, proceed directly. Otherwise (e.g., the flow reached here without an explicit approval prompt), confirm before pushing:
"I'm about to push branch
```
$BRANCH_NAME
```
to
```
origin
```
. This is a prerequisite step, can I proceed?" Do NOT push until the user approves. If they decline, abort and skip to step 11.
Once approved (or if already approved in step 3):
bash
```
git push -u origin HEAD
```
Determine the repository identifier and hostname: Run
```
git remote get-url origin | sed 's|://[^@]*@|://|'
```
to extract the
```
owner/repo
```
and hostname.
- GitHub URLs (github.com or self-hosted) → use
```
githubPrContent
```
  , hostname from URL
- GitLab URLs (gitlab.com or self-hosted) → use
```
gitlabMrContent
```
  , hostname from URL

Build the content: Set

headBranch

$BRANCH_NAME

repository

to the extracted

owner/repo

, and

hostname

to the value from step 8. Wrap the object in an array:

GitHub:

{"githubPrContent": [{"repository": "owner/repo", "headBranch": "feat/release-readiness-review", "hostname": "github.com"}]}

GitLab:

{"gitlabMrContent": [{"repository": "namespace/repo", "headBranch": "feat/release-readiness-review", "hostname": "gitlab.com"}]}

Inform the user: Tell them which branch was created and pushed, then proceed with the core workflow below.

After analysis completes: Clean up and restore working state:

bash

git checkout $ORIGINAL_BRANCH
git push origin --delete $BRANCH_NAME 2>/dev/null || true
git branch -D $BRANCH_NAME 2>/dev/null || true

If step 4 was executed (uncommitted changes were stashed), also run:

bash

git stash pop

Important: Do NOT create a PR/MR — only push the branch. The release readiness review agent will read the branch directly.

强制要求：当用户引用仓库或分支但未提供PR/MR链接时，你必须按顺序执行以下所有步骤。请勿直接获取远程URL和SHA——审查Agent需要已推送的分支才能读取内容。跳过推送步骤会导致分析失败或产生不完整结果。

导航到仓库目录：
```
cd
```
到仓库根目录（例如克隆目录）。必要时询问用户。
确定基准分支：默认使用
```
main
```
，除非用户指定其他分支。验证远程跟踪分支是否存在：
bash
```
BASE_BRANCH="main"
if ! git show-ref --verify --quiet refs/remotes/origin/$BASE_BRANCH; then
    git fetch origin $BASE_BRANCH
fi
```
如果拉取失败（例如“无法找到远程引用”），请询问用户指定基准分支并停止操作。
检查本地变更：运行
```
git status --short
```
和
```
git rev-list --count origin/$BASE_BRANCH..HEAD
```
以确定状态并相应告知用户：
- 干净且未领先远程：告知用户没有新内容可分析并停止操作。
- 存在未提交变更（无论是否有未推送提交）：
  - 如果有一个或多个未推送提交（rev-list计数≥1），告知用户：
    
    "你有未提交的变更和N个未推送提交。我会将未提交变更提交到顶部，然后将所有N+1个推送到新分支进行分析。所有变更将作为单个差异显示在基准分支上。是否继续？"
  - 如果没有其他未推送提交（rev-list计数=0），告知用户：
    
    "我会提交你的未提交变更并推送到新分支进行发布就绪审查。是否继续？"
  - 获得用户批准前请勿继续。如果用户拒绝，停止操作。
- 干净但领先远程（rev-list计数>0，无未提交变更）：
  - 如果领先超过1个提交，告知用户：
    
    "你有N个未推送提交。我会将所有提交推送到新分支进行分析。所有变更将作为单个差异显示在基准分支上。是否继续？"
  - 如果恰好领先1个提交，告知用户：
    
    "我会将你最新的提交推送到新分支进行发布就绪审查。是否继续？"
  - 获得用户批准前请勿继续。如果用户拒绝，停止操作。

暂存未提交变更（如果工作目录干净则跳过此步骤）：

bash

git stash push --include-untracked -m "release-analysis: preserve working changes"

创建审查分支（在提交前执行此操作，以便快照提交仅存在于临时分支上）：

bash

ORIGINAL_BRANCH=$(git rev-parse --abbrev-ref HEAD)
BRANCH_NAME="feat/release-readiness-review"
git checkout -b $BRANCH_NAME 2>/dev/null || { BRANCH_NAME="feat/release-readiness-review-$(date +%Y%m%d-%H%M%S)"; git checkout -b $BRANCH_NAME; }

在审查分支上应用暂存变更并提交（如果工作目录干净则跳过此步骤——直接进入步骤7）：
bash
```
git stash apply
```
在暂存前检查敏感文件：
bash
```
git status --short | grep -iE '\.(env|pem|key|p12|pfx|credentials|secret)'
```
如果检测到敏感文件，警告用户并在继续前请求确认。如果用户拒绝，中止操作：
bash
```
git checkout $ORIGINAL_BRANCH && git branch -D $BRANCH_NAME && git stash drop
```
确认后（或未发现敏感文件）：
bash
```
git add -A
git commit -m "chore: snapshot for release readiness review"
```
推送所有未提交的变更（需要事先获得用户批准）：如果用户已在步骤3中批准推送，直接继续。否则（例如流程未经过明确批准提示到达此步骤），在推送前确认：
"我即将把分支
```
$BRANCH_NAME
```
推送到
```
origin
```
。这是必要步骤，是否可以继续？" 获得用户批准前请勿推送。如果用户拒绝，中止操作并跳至步骤11。
批准后（或已在步骤3中批准）：
bash
```
git push -u origin HEAD
```
确定仓库标识符和主机名：运行
```
git remote get-url origin | sed 's|://[^@]*@|://|'
```
以提取
```
owner/repo
```
和主机名。
- GitHub URL（github.com或自托管）→ 使用
```
githubPrContent
```
  ，主机名来自URL
- GitLab URL（gitlab.com或自托管）→ 使用
```
gitlabMrContent
```
  ，主机名来自URL

构建内容：将

headBranch

设置为

$BRANCH_NAME

，

repository

设置为提取的

owner/repo

，

hostname

设置为步骤8中的值。将对象包装在数组中：

GitHub：

{"githubPrContent": [{"repository": "owner/repo", "headBranch": "feat/release-readiness-review", "hostname": "github.com"}]}

GitLab：

{"gitlabMrContent": [{"repository": "namespace/repo", "headBranch": "feat/release-readiness-review", "hostname": "gitlab.com"}]}

告知用户：告诉用户创建并推送了哪个分支，然后继续执行下方的核心工作流。

分析完成后：清理并恢复工作状态：

bash

git checkout $ORIGINAL_BRANCH
git push origin --delete $BRANCH_NAME 2>/dev/null || true
git branch -D $BRANCH_NAME 2>/dev/null || true

如果执行了步骤4（暂存了未提交变更），还需运行：

bash

git stash pop

重要提示：请勿创建PR/MR——仅推送分支。发布就绪审查Agent会直接读取该分支。

Core workflow

核心工作流

STRICT SEQUENCING: Steps below are numbered. You MUST complete each step before moving to the next. In particular, step 1 (automated testing prompt) MUST NOT happen until the entire "Gathering execution parameters" flow above is fully complete — all git operations done, branch pushed (if local flow), content object built, and user informed of the branch. Only THEN proceed to step 1.

严格顺序：以下步骤已编号。你必须完成每个步骤后再进行下一步。特别是步骤1（自动化测试提示）必须在上述“收集执行参数”流程完全完成后才能执行——所有Git操作完成，分支已推送（如果是本地流程），内容对象已构建，且用户已被告知分支信息。只有这样才能继续步骤1。

1. Determine

skip_automated_testing

(ask ONLY after content is ready)

1. 确定

skip_automated_testing

（仅在内容准备好后询问）

The

skip_automated_testing

parameter controls whether the agent runs automated testing (automated verification tests) or only static analysis.

Value	Behavior
`true`	Skip automated testing, run static analysis only (fast — code review, risk assessment, dependency checks)
`false`	Full analysis including automated testing (longer — spins up a testing environment, builds code, runs automated verification tests)

Present the choice and wait for a response:

"Would you like a quick static analysis (code review, risk assessment, dependency checks), or a full analysis that also includes automated testing? Automated testing spins up a testing environment, builds your code, and runs automated verification tests — it's more thorough but takes longer."

Do NOT proceed until the user answers.

If the user says "yes" / "include testing" / "full analysis" / "run tests" → use
```
skip_automated_testing=false
```
If the user says "no" / "static only" / "skip testing" / "quick" / declines → use
```
skip_automated_testing=true
```
If the response is ambiguous (e.g., "go ahead", "sure", "proceed") → ask the user to clarify which option they prefer.

skip_automated_testing

参数控制Agent是否运行自动化测试（自动验证测试）或仅执行静态分析。

值	行为
`true`	跳过自动化测试，仅运行静态分析（速度快——代码审查、风险评估、依赖检查）
`false`	完整分析，包括自动化测试（耗时较长——启动测试环境、构建代码、运行自动验证测试）

向用户提供选择并等待响应：

"你想要快速静态分析（代码审查、风险评估、依赖检查），还是包含自动化测试的完整分析？自动化测试会启动测试环境、构建代码并运行自动验证测试——更全面但耗时更长。"

获得用户答复前请勿继续。

如果用户回答“是”/“包含测试”/“完整分析”/“运行测试” → 使用
```
skip_automated_testing=false
```
如果用户回答“否”/“仅静态”/“跳过测试”/“快速”/拒绝 → 使用
```
skip_automated_testing=true
```
如果响应模糊（例如“继续”、“好的”、“进行”） → 请用户明确选择哪个选项。

2. Check tool availability

2. 检查工具可用性

Verify that the following tools are available:

aws_devops_agent__create_release_readiness_review

aws_devops_agent__get_task

aws_devops_agent__list_journal_records

aws_devops_agent__get_release_readiness_report

. These tools are NOT deferred/lazy-loaded — if they do not appear in your tool list, they are unavailable. Do NOT search for them via ToolSearch. If any are missing, skip the remaining steps in this section and use the "Fallback (aws-mcp)" path below instead. Tell the user: "Remote server unavailable — using direct aws-mcp server fallback."

验证以下工具是否可用：

aws_devops_agent__create_release_readiness_review

、

aws_devops_agent__get_task

、

aws_devops_agent__list_journal_records

、

aws_devops_agent__get_release_readiness_report

。这些工具不会延迟/懒加载——如果工具列表中没有它们，则表示不可用。请勿通过ToolSearch搜索它们。如果缺少任何工具，跳过本节剩余步骤并使用下方的“备用方案（aws-mcp）”路径。告知用户：“远程服务器不可用——使用直接aws-mcp服务器备用方案。”

3. Start the Job

3. 启动任务

aws_devops_agent__create_release_readiness_review(
    content={...},
    skip_automated_testing=true/false
)
→ {"taskId": "...", "executionId": "...", "status": "started"}

Record the taskId and executionId from the response.

aws_devops_agent__create_release_readiness_review(
    content={...},
    skip_automated_testing=true/false
)
→ {"taskId": "...", "executionId": "...", "status": "started"}

记录响应中的taskId和executionId。

4. Poll for Status

4. 轮询状态

Call

aws_devops_agent__get_task(task_id=TASK_ID)

every 30 seconds until the status transitions to

IN_PROGRESS

or a terminal state (

COMPLETED

FAILED

CANCELED

TIMED_OUT

每隔30秒调用

aws_devops_agent__get_task(task_id=TASK_ID)

，直到状态变为

IN_PROGRESS

或终端状态（

COMPLETED

、

FAILED

、

CANCELED

、

TIMED_OUT

）。

5. Monitor Until Completion

5. 监控直至完成

Once

IN_PROGRESS

, poll for progress in a loop:

Call

aws_devops_agent__list_journal_records(execution_id=EXEC_ID, order="ASC")

to fetch new findings.

Present each record to the user with a friendly progress update.
Use
```
next_token
```
from the response to fetch only new records on subsequent polls.
Wait 15 seconds between each poll iteration.
Check
```
aws_devops_agent__get_task(task_id=TASK_ID)
```
periodically — stop when terminal status.

状态变为

IN_PROGRESS

后，循环轮询进度：

调用

aws_devops_agent__list_journal_records(execution_id=EXEC_ID, order="ASC")

以获取新结论。

向用户展示每条记录并提供友好的进度更新。
使用响应中的
```
next_token
```
在后续轮询中仅获取新记录。
每次轮询间隔15秒。
定期检查
```
aws_devops_agent__get_task(task_id=TASK_ID)
```
——状态变为终端状态时停止。

6. Present Results

6. 展示结果

Once the job reaches a terminal status:

If
```
COMPLETED
```
:
1. Call
```
aws_devops_agent__get_release_readiness_report(execution_id=EXEC_ID)
```
  to retrieve the full report.
2. Write the report contents to a markdown file:
```
release-readiness-review-<YYYY-MM-DD-HHmmss>.md
```
3. Inform the user that the report was saved, including the file path.
4. Auto-fix flow (MANDATORY): After saving the report, you MUST attempt to generate and present fixes for all actionable risks — this is the primary value of the review workflow, not an optional step.
  - First, locate the analyzed repository in the current workspace:
    1. Run
      ls
      to list available directories in the workspace.
    2. Match by repo name (the last segment of
      owner/repo
      or
      namespace/repo
      ). For example,
      testgroupadthiru/repo1updated
      → look for a directory named
      repo1updated
      .
    3. If a single match is found, confirm with the user: "I found
      <match>
      — is this the correct local copy of
      <namespace/repo>
      ?"
    4. If multiple matches are found, ask the user which one is correct.
    5. If no obvious match exists, ask the user: "I couldn't find a local directory matching
      <repo-name>
      . Is it available locally under a different name, or should I just show the suggested fixes?"
  - If found locally:
    - Verify branch: Run
      git -C <repo-directory> branch --show-current
      to confirm you're on the expected branch. If not on the expected branch, check out the correct one before proceeding.
    - Scan the relevant code, interpret the risks/issues from the report. Then tell the user:
      "The report identified N actionable issues. I can generate the fixes in your local repository, and push them to a new branch
      feat/release-readiness-fix
      . Shall I proceed?"
    - Do NOT proceed until the user approves. If they decline, stop.
    - Once approved, generate the fixes. Then:
      bash
      cd <repo-directory> git checkout -b feat/release-readiness-fix 2>/dev/null || { git checkout -b "feat/release-readiness-fix-$(date +%Y%m%d-%H%M%S)"; } # Apply the fixes git add -A git commit -m "fix: Address issues identified by release readiness review"
    - Before pushing, verify branch again: Run
      git branch --show-current
      and confirm it shows
      feat/release-readiness-fix*
      . Do NOT push if you're on any other branch.
      bash
      git push -u origin HEAD
      Inform the user: which issues were fixed, what branch was created, and that the fix has been pushed.
  - If NOT found locally: Present the suggested fixes from the report as concrete, ready-to-apply code patches. Use the
```
suggestedFix
```
    field from each risk. Format them as code blocks the user can copy-paste directly. Walk through each actionable risk: explain the issue, show the exact fix, and state which file/line it targets.
  - If the report finds no risks or issues: Inform the user the analysis completed with no actionable findings.
If
```
FAILED
```
or
```
TIMED_OUT
```
: Present the error information and suggest next steps.
If
```
CANCELED
```
: Inform the user the job was canceled and no report is available.

任务达到终端状态后：

如果
```
COMPLETED
```
：
1. 调用
```
aws_devops_agent__get_release_readiness_report(execution_id=EXEC_ID)
```
  以获取完整报告。
2. 将报告内容写入Markdown文件：
```
release-readiness-review-<YYYY-MM-DD-HHmmss>.md
```
3. 告知用户报告已保存，并提供文件路径。
4. 自动修复流程（强制要求）：保存报告后，你必须尝试为所有可操作风险生成并展示修复方案——这是审查工作流的核心价值，而非可选步骤。
  - 首先，在当前工作区中找到分析的仓库：
    1. 运行
      ls
      列出工作区中的可用目录。
    2. 根据仓库名称匹配（
      owner/repo
      或
      namespace/repo
      的最后一段）。例如
      testgroupadthiru/repo1updated
      → 查找名为
      repo1updated
      的目录。
    3. 如果找到单个匹配项，向用户确认：“我找到了
      <match>
      ——这是
      <namespace/repo>
      的本地副本吗？”
    4. 如果找到多个匹配项，询问用户哪个是正确的。
    5. 如果没有明显匹配项，询问用户：“我找不到与
      <repo-name>
      匹配的本地目录。它是否以其他名称存在于本地，还是我直接展示建议的修复方案？”
  - 如果在本地找到：
    - 验证分支：运行
      git -C <repo-directory> branch --show-current
      确认你在预期分支上。如果不在预期分支上，先切换到正确分支再继续。
    - 扫描相关代码，解读报告中的风险/问题。然后告知用户：
      "报告识别出N个可操作问题。我可以在你的本地仓库中生成修复方案，并推送到新分支
      feat/release-readiness-fix
      。是否继续？"
    - 获得用户批准前请勿继续。如果用户拒绝，停止操作。
    - 批准后，生成修复方案。然后：
      bash
      cd <repo-directory> git checkout -b feat/release-readiness-fix 2>/dev/null || { git checkout -b "feat/release-readiness-fix-$(date +%Y%m%d-%H%M%S)"; } # 应用修复方案 git add -A git commit -m "fix: Address issues identified by release readiness review"
    - 推送前再次验证分支：运行
      git branch --show-current
      确认显示
      feat/release-readiness-fix*
      。如果在其他分支上，请勿推送。
      bash
      git push -u origin HEAD
      告知用户：修复了哪些问题、创建了哪个分支，以及修复方案已推送。
  - 如果未在本地找到：将报告中的建议修复方案作为具体、可直接应用的代码补丁展示。使用每个风险的
```
suggestedFix
```
    字段。将其格式化为用户可直接复制粘贴的代码块。逐一讲解每个可操作风险：解释问题、展示确切修复方案，并说明目标文件/行。
  - 如果报告未发现风险或问题：告知用户分析完成且无任何可操作结论。
如果
```
FAILED
```
或
```
TIMED_OUT
```
：展示错误信息并建议下一步操作。
如果
```
CANCELED
```
：告知用户任务已取消，无可用报告。

Cancelling a job

取消任务

aws_devops_agent__cancel_release_readiness_review(task_id=TASK_ID)

aws_devops_agent__cancel_release_readiness_review(task_id=TASK_ID)

Error handling

错误处理

If
```
FAILED
```
or
```
TIMED_OUT
```
— stop and present the error. If the job failed quickly (within the first poll or two), call
```
aws_devops_agent__list_associations()
```
to check whether the target repository's hosting service (GitHub/GitLab hostname) is associated with the agent space.
If job does not reach
```
IN_PROGRESS
```
within 5 minutes — cancel with
```
cancel_release_readiness_review
```
.
If throttled (
```
429
```
or
```
ThrottlingException
```
) — wait 30 seconds, retry up to 3 times.
If the error does not match any known pattern above, present the raw error output to the user.

如果
```
FAILED
```
或
```
TIMED_OUT
```
——停止操作并展示错误。如果任务快速失败（在前一两次轮询内），调用
```
aws_devops_agent__list_associations()
```
检查目标仓库的托管服务（GitHub/GitLab主机名）是否已关联到Agent空间。
如果任务在5分钟内未变为
```
IN_PROGRESS
```
——使用
```
cancel_release_readiness_review
```
取消任务。
如果遇到限流（
```
429
```
或
```
ThrottlingException
```
）——等待30秒，最多重试3次。
如果错误与上述已知模式均不匹配，向用户展示原始错误输出。

Fallback (aws-mcp)

备用方案（aws-mcp）

If the

aws-devops-agent

remote server is unavailable, use the AWS CLI directly:

Tell the user: "Remote server unavailable — using the aws-mcp server fallback."

如果

aws-devops-agent

远程服务器不可用，直接使用AWS CLI：

告知用户：“远程服务器不可用——使用aws-mcp服务器备用方案。”

1. Select Agent Space

1. 选择Agent空间

List available agent spaces:

aws devops-agent list-agent-spaces --region us-east-1

Present the list to the user and ask which agent space they'd like to use. Do NOT proceed until the user has selected one. Use the selected

agentSpaceId

SPACE_ID

in all subsequent calls.

列出可用的Agent空间：

aws devops-agent list-agent-spaces --region us-east-1

向用户展示列表并询问要使用哪个Agent空间。获得用户选择前请勿继续。将选定的

agentSpaceId

作为后续所有调用中的

SPACE_ID

。

2. Start the Job

2. 启动任务

aws devops-agent create-backlog-task \
  --agent-space-id SPACE_ID \
  --task-type RELEASE_READINESS_REVIEW \
  --title 'Release Readiness Review' \
  --priority MEDIUM \
  --description '{\"agentInput\": {\"content\": <CONTENT_JSON>, \"metadata\": {\"skipAutomatedTesting\": true}}}' \
  --region us-east-1

CRITICAL: The
content
value must be a single object — NOT wrapped in a list. Correct:
"content": {"githubPrContent": [...]}
. Incorrect:
"content": [{"githubPrContent": [...]}]
. Wrapping in a list causes a Pydantic validation failure on the backend. The values in the content should all be of string format e.g. the PR number should be a string.

Default is

"skipAutomatedTesting": true

(static only). Set to

false

only if user explicitly opted into automated testing.

aws devops-agent create-backlog-task \
  --agent-space-id SPACE_ID \
  --task-type RELEASE_READINESS_REVIEW \
  --title 'Release Readiness Review' \
  --priority MEDIUM \
  --description '{\"agentInput\": {\"content\": <CONTENT_JSON>, \"metadata\": {\"skipAutomatedTesting\": true}}}' \
  --region us-east-1

关键提示：
content
值必须是单个对象——不能包装在列表中。正确格式：
"content": {"githubPrContent": [...]}
。错误格式：
"content": [{"githubPrContent": [...]}]
。包装在列表中会导致后端Pydantic验证失败。content中的值均应为字符串格式，例如PR编号需为字符串。

默认值为

"skipAutomatedTesting": true

（仅静态分析）。仅当用户明确选择自动化测试时才设置为

false

。

3. Poll for Status

3. 轮询状态

aws devops-agent get-backlog-task \
  --agent-space-id SPACE_ID \
  --task-id TASK_ID \
  --region us-east-1

Poll every 30 seconds until the status transitions to

IN_PROGRESS

or a terminal state (

COMPLETED

FAILED

CANCELED

TIMED_OUT

aws devops-agent get-backlog-task \
  --agent-space-id SPACE_ID \
  --task-id TASK_ID \
  --region us-east-1

每隔30秒轮询一次，直到状态变为

IN_PROGRESS

或终端状态（

COMPLETED

、

FAILED

、

CANCELED

、

TIMED_OUT

）。

4. Monitor Until Completion

4. 监控直至完成

Once

IN_PROGRESS

, poll for progress in a loop:

aws devops-agent list-journal-records \
  --agent-space-id SPACE_ID \
  --execution-id EXEC_ID \
  --order ASC \
  --region us-east-1

Present each record to the user with a friendly progress update.
Use
```
next_token
```
from the response to fetch only new records on subsequent polls.
Wait 15 seconds between each poll iteration.
Check
```
get-backlog-task
```
periodically — stop when terminal status.

状态变为

IN_PROGRESS

后，循环轮询进度：

aws devops-agent list-journal-records \
  --agent-space-id SPACE_ID \
  --execution-id EXEC_ID \
  --order ASC \
  --region us-east-1

向用户展示每条记录并提供友好的进度更新。
使用响应中的
```
next_token
```
在后续轮询中仅获取新记录。
每次轮询间隔15秒。
定期检查
```
get-backlog-task
```
——状态变为终端状态时停止。

5. Present Results

5. 展示结果

Once the job reaches a terminal status:

If
```
COMPLETED
```
:
1. Retrieve the report:
```
aws devops-agent list-journal-records \
  --agent-space-id SPACE_ID \
  --execution-id EXEC_ID \
  --record-type release_analysis_report \
  --order ASC \
  --region us-east-1
```
2. Write the report contents to a markdown file:
```
release-readiness-review-<YYYY-MM-DD-HHmmss>.md
```
3. Inform the user that the report was saved, including the file path.
4. Auto-fix flow (MANDATORY): After saving the report, you MUST attempt to generate and present fixes for all actionable risks — this is the primary value of the review workflow, not an optional step. Follow the same auto-fix flow described in the Core workflow section above (locate repo, verify branch, generate fixes, push to
```
feat/release-readiness-fix
```
  ).
If
```
FAILED
```
or
```
TIMED_OUT
```
: Present the error information and suggest next steps.
If
```
CANCELED
```
: Inform the user the job was canceled and no report is available.

任务达到终端状态后：

如果
```
COMPLETED
```
：
1. 获取报告：
```
aws devops-agent list-journal-records \
  --agent-space-id SPACE_ID \
  --execution-id EXEC_ID \
  --record-type release_analysis_report \
  --order ASC \
  --region us-east-1
```
2. 将报告内容写入Markdown文件：
```
release-readiness-review-<YYYY-MM-DD-HHmmss>.md
```
3. 告知用户报告已保存，并提供文件路径。
4. 自动修复流程（强制要求）：保存报告后，你必须尝试为所有可操作风险生成并展示修复方案——这是审查工作流的核心价值，而非可选步骤。遵循核心工作流部分中描述的相同自动修复流程（查找仓库、验证分支、生成修复方案、推送到
```
feat/release-readiness-fix
```
  ）。
如果
```
FAILED
```
或
```
TIMED_OUT
```
：展示错误信息并建议下一步操作。
如果
```
CANCELED
```
：告知用户任务已取消，无可用报告。

Cancelling (fallback)

取消任务（备用方案）

aws devops-agent update-backlog-task \
  --agent-space-id SPACE_ID \
  --task-id TASK_ID \
  --task-status CANCELED \
  --region us-east-1

aws devops-agent update-backlog-task \
  --agent-space-id SPACE_ID \
  --task-id TASK_ID \
  --task-status CANCELED \
  --region us-east-1

analyzing-release-readiness

Original

Translation

Release Readiness Review

发布就绪审查

Gathering execution parameters

收集执行参数

GitHub PR (github.com URL or PR reference)

GitHub PR（github.com URL或PR引用）

GitLab MR (gitlab.com URL)

GitLab MR（gitlab.com URL）

Local GitHub/GitLab repo (no PR/MR URL provided — local workspace ONLY)

本地GitHub/GitLab仓库（未提供PR/MR URL——仅本地工作区）

Core workflow

核心工作流

1. Determine skip_automated_testing (ask ONLY after content is ready)

1. 确定skip_automated_testing（仅在内容准备好后询问）

2. Check tool availability

2. 检查工具可用性

3. Start the Job

3. 启动任务

4. Poll for Status

4. 轮询状态

5. Monitor Until Completion

5. 监控直至完成

6. Present Results

6. 展示结果

Cancelling a job

取消任务

Error handling

错误处理

Fallback (aws-mcp)

备用方案（aws-mcp）

1. Select Agent Space

1. 选择Agent空间

2. Start the Job

2. 启动任务

3. Poll for Status

3. 轮询状态

4. Monitor Until Completion

4. 监控直至完成

5. Present Results

5. 展示结果

Cancelling (fallback)

取消任务（备用方案）

1. Determine
`skip_automated_testing`
(ask ONLY after content is ready)

1. 确定
`skip_automated_testing`
（仅在内容准备好后询问）