Analyzing Release Readiness

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.

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

GitHub PR (github.com URL or PR reference)

• 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:

{
  "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).

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:

{
  "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.

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

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.

1. Navigate to the repository directory: cd to the repo root (e.g., the clone directory). Ask the user if needed.
2. Determine the base branch: Use main unless the user specifies a different branch. Verify the remote tracking branch exists:

   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.

1. 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.

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

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

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

   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; }

1. Apply stashed changes and commit on the review branch (skip this step if working directory was clean — go straight to step 7):

   git stash apply

Before staging, check for sensitive files:

   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:

   git checkout $ORIGINAL_BRANCH && git branch -D $BRANCH_NAME && git stash drop

Once confirmed (or no sensitive files found):

   git add -A
   git commit -m "chore: snapshot for release readiness review"

1. 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):

   git push -u origin HEAD

1. 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