diff --git a/workflows/cve-fixer/.ambient/ambient.json b/workflows/cve-fixer/.ambient/ambient.json
index a3203f42..800d227f 100644
--- a/workflows/cve-fixer/.ambient/ambient.json
+++ b/workflows/cve-fixer/.ambient/ambient.json
@@ -2,7 +2,7 @@
   "name": "CVE Fixer",
   "description": "Automate remediation of CVE issues reported by ProdSec team in Jira by creating pull requests with dependency updates and patches",
   "systemPrompt": "You are a CVE remediation assistant for the Ambient Code Platform. Your role is to help users remediate CVE issues that have been reported by the ProdSec team in Jira by automatically creating pull requests with fixes.\n\nKEY RESPONSIBILITIES:\n- Guide users through the CVE remediation workflow for Jira-tracked vulnerabilities\n- Execute slash commands to perform specific security tasks\n- Find CVE issues opened by ProdSec team in Jira\n- Implement secure fixes that resolve vulnerabilities without breaking functionality\n- Create pull requests with dependency updates, patches, and comprehensive test results\n\nWORKFLOW METHODOLOGY:\n1. FIND - Find CVEs already reported in Jira for a component\n2. FIX - Implement remediation strategies (dependency updates, patches, code changes, PR creation)\n\nAVAILABLE COMMANDS:\n/cve.find - Find CVEs reported in Jira for a specific component\n/cve.fix - Implement fixes for discovered CVEs and create pull requests\n\nOUTPUT LOCATIONS:\n- Create all Jira CVE findings in: artifacts/cve-fixer/find/\n- Create all fix implementations in: artifacts/cve-fixer/fixes/\n\nNote: Commands will guide you through required setup steps on first use. If the user's component is not in component-repository-mappings.json, direct them to the \"Team Onboarding\" section in README.md.",
-  "startupPrompt": "Greet the user and introduce yourself as a CVE remediation assistant. Explain that you help remediate CVE issues reported by ProdSec in Jira by creating pull requests. Mention the two commands: /cve.find to discover CVEs and /cve.fix to implement fixes. If this is their first time, point them to README.md Team Onboarding for setup. Suggest starting with /cve.find and ask what they'd like to work on.",
+  "startupPrompt": "Greet the user and introduce yourself as a CVE remediation assistant. Explain that you help remediate CVE issues reported by ProdSec in Jira by creating pull requests. Mention the three commands: /onboard to add a new component, /cve.find to discover CVEs, and /cve.fix to implement fixes. If this is their first time or their component is not yet onboarded, suggest starting with /onboard. Otherwise suggest /cve.find and ask what they'd like to work on.",
   "results": {
     "Jira CVE Issues": "artifacts/cve-fixer/find/**/*.md",
     "Fix Implementations": "artifacts/cve-fixer/fixes/**/*"
diff --git a/workflows/cve-fixer/.claude/commands/cve.find.md b/workflows/cve-fixer/.claude/commands/cve.find.md
index 688284be..7dd87d6a 100644
--- a/workflows/cve-fixer/.claude/commands/cve.find.md
+++ b/workflows/cve-fixer/.claude/commands/cve.find.md
@@ -54,13 +54,46 @@ Report: artifacts/cve-fixer/find/cve-issues-20260226-145018.md
 
 2. **Verify Jira Access**
 
-   Secrets may be injected by the Ambient session, a secrets manager, or an MCP server — do NOT rely solely on bash env var checks. Instead, attempt a lightweight test API call and let the response determine whether credentials are available.
+   **ALWAYS check for a Jira MCP server first** before attempting any curl/env var approach.
+
+   **2.1: Check for Jira MCP server — follow these exact steps in order**
+
+   **Step A**: If `mcp__session__refresh_credentials` is in the deferred tools list, call it now.
+   This activates workspace integrations including Jira.
+
+   **Step B**: Immediately after (or if no refresh was needed), attempt to fetch the Jira
+   tool directly using `select:` syntax — do this regardless of whether you think it exists:
+
+   ```
+   ToolSearch: select:mcp__mcp-atlassian__jira_search
+   ```
+
+   **Step C**: If Step B returns the tool schema → use it for all Jira queries. Done.
+   Print: "✅ Using mcp__mcp-atlassian__jira_search"
+
+   **NEVER run a generic keyword ToolSearch like "jira search atlassian" or "jira MCP".
+   Generic searches return unrelated tools and cause false "not found" conclusions.
+   The `select:` syntax either returns the exact tool or nothing — use only that.**
+
+   If `select:mcp__mcp-atlassian__jira_search` returns nothing → the tool is not available
+   in this session. Proceed to Step 2.2 (curl fallback).
+
+   **2.2: Fallback — curl with credentials (always attempt, even if bash says vars are unset)**
+
+   If no Jira MCP tool is available, attempt the curl auth call regardless of whether the
+   bash env var check shows the vars as set or not. Ambient secrets can be injected at the
+   curl level even when not visible to shell variable checks — the only reliable test is the
+   actual API call response.
 
    ```bash
    JIRA_BASE_URL="https://redhat.atlassian.net"
-   AUTH=$(echo -n "${JIRA_EMAIL}:${JIRA_API_TOKEN}" | base64)
+   AUTH=$(echo -n "${JIRA_EMAIL}:${JIRA_API_TOKEN}" | base64 | tr -d '\n')
+
+   # Diagnostic only — do NOT stop if these are "no"
+   echo "JIRA_API_TOKEN in bash env: $([ -n "${JIRA_API_TOKEN}" ] && echo yes || echo no)"
+   echo "JIRA_EMAIL in bash env: $([ -n "${JIRA_EMAIL}" ] && echo yes || echo no)"
+   echo "Attempting Jira API call regardless..."
 
-   # Retry once on network failure (curl exit code 000 = timeout/no response)
    for ATTEMPT in 1 2; do
      TEST_RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" -X GET \
        --connect-timeout 10 --max-time 15 \
@@ -74,29 +107,22 @@ Report: artifacts/cve-fixer/find/cve-issues-20260226-145018.md
    ```
 
    - **HTTP 200** → credentials valid, proceed
-   - **HTTP 401** → credentials missing or invalid. Note: `/rest/api/3/myself` returns 401 for all authentication failures — there is no separate 403 for this endpoint. Only now inform the user:
-     - Check if `JIRA_API_TOKEN` and `JIRA_EMAIL` are configured as Ambient session secrets
-     - If not, generate a token at https://id.atlassian.com/manage-profile/security/api-tokens and export:
-
-       ```bash
-       export JIRA_API_TOKEN="your-token-here"
-       export JIRA_EMAIL="your-email@redhat.com"
-       ```
-   - **HTTP 000 after retry** → persistent network issue — inform user and stop
-
-   **Do NOT pre-check env vars with `[ -z "$JIRA_API_TOKEN" ]` and stop.** The variables may be available to the API call even if not visible to the shell check (e.g. Ambient secrets injection).
+   - **HTTP 401** → credentials truly not available or expired. Only now stop and inform user:
+     configure `JIRA_API_TOKEN` and `JIRA_EMAIL` as Ambient workspace secrets or export them
+   - **HTTP 000 after retry** → network issue — inform user and stop
 
 3. **Query Jira for CVE Issues**
 
-   a. Set up variables (AUTH already set from Step 2):
+   a. Set up variables:
 
    ```bash
    COMPONENT_NAME="[from step 1]"
    JIRA_BASE_URL="https://redhat.atlassian.net"
-   # AUTH already constructed in Step 2 — reuse it
+   # If using MCP (Step 2.1): pass JQL directly to MCP tool — no AUTH needed
+   # If using curl (Step 2.2): AUTH already constructed in Step 2 — reuse it
    ```
 
-   b. Construct JQL query and execute API call:
+   b. Construct JQL query and execute via MCP or curl:
 
    ```bash
    # Normalize component name with case-insensitive lookup against mapping file
diff --git a/workflows/cve-fixer/.claude/commands/cve.fix.md b/workflows/cve-fixer/.claude/commands/cve.fix.md
index 2226be90..e3cd5c7b 100644
--- a/workflows/cve-fixer/.claude/commands/cve.fix.md
+++ b/workflows/cve-fixer/.claude/commands/cve.fix.md
@@ -3,6 +3,12 @@
 ## Purpose
 Implement secure remediations for prioritized CVEs through dependency updates, patches, code changes, or compensating controls. This command executes the actual fixes that eliminate vulnerabilities.
 
+## Mandatory Execution Rule
+
+**EVERY step in the Process section below MUST be executed in order. NO step may be skipped, abbreviated, or assumed complete without actually running it.**
+
+If a step produces no output (e.g., no `.cve-fix/` folder found, no tests discovered), log that result explicitly and continue. Do not silently skip any step.
+
 ## Execution Style
 
 **Be concise. Brief status + final summary only.**
@@ -33,6 +39,11 @@ Summary:
 
 1. **Load CVEs from Find Output or User-Specified Jira Issue**
 
+   **Supported flags:**
+   - `--automerge` — After creating each PR, enable GitHub's automerge so the PR merges automatically once all required checks pass. Off by default — the user must explicitly opt in.
+
+   Parse this flag before processing Jira issues. Store as `AUTOMERGE=true/false`.
+
    **Option A: User specifies one or more Jira issues**
    - If user provides one or more Jira issue IDs (e.g., `/cve.fix RHOAIENG-4973` or `/cve.fix RHOAIENG-4973 RHOAIENG-5821`):
      - Process each issue independently -- extract CVE ID and component from each
@@ -202,15 +213,28 @@ Summary:
 
    If `PUSH_ACCESS` is `false` or the push fails:
    ```bash
-   # Create a fork under the authenticated user's account
-   gh repo fork "$REPO_FULL" --clone=false
-
    FORK_USER=$(gh api user --jq '.login')
    FORK_REPO="${FORK_USER}/${REPO_NAME}"
 
-   # Add fork as a remote
+   # Create fork if it doesn't exist yet
+   gh repo fork "$REPO_FULL" --clone=false 2>/dev/null || true
+
+   # Sync fork branches with upstream — REQUIRED to ensure fix branches
+   # are based on current upstream code, not a stale fork.
+   # This syncs all branches in the fork with the upstream repo.
+   echo "Syncing fork ${FORK_REPO} with upstream ${REPO_FULL}..."
+   gh repo sync "${FORK_REPO}" --source "$REPO_FULL" --branch "$TARGET_BRANCH"
+
+   if [ $? -ne 0 ]; then
+     echo "⚠️ Fork sync failed — fix branch may be based on stale code. Proceeding with caution."
+   else
+     echo "✅ Fork branch ${TARGET_BRANCH} synced with upstream"
+   fi
+
+   # Add fork as a remote and fetch the synced branch
    cd "$REPO_DIR"
-   git remote add fork "https://github.com/${FORK_REPO}.git"
+   git remote add fork "https://github.com/${FORK_REPO}.git" 2>/dev/null || true
+   git fetch fork "$TARGET_BRANCH"
 
    # Push fix branch to fork, PR targets the original repo
    git push fork "$FIX_BRANCH"
@@ -258,11 +282,34 @@ Summary:
    ```
 
 4.5. **Load Global Fix Guidance from `.cve-fix/` Folder**
-   - Runs ONCE after all repos are cloned, BEFORE any fixes. Builds a global knowledge base from `.cve-fix/` folders across all cloned repos.
-   - Check every cloned repo for `.cve-fix/`, read ALL files (e.g., `examples.md`, `config.json`, `dependencies.md`, `pitfalls.md`), and merge into a single context.
-   - Extract: dependency co-upgrades, lock file requirements, version upgrade patterns, branch-specific instructions, known working fix versions, testing requirements, common pitfalls.
-   - Apply this guidance to ALL subsequent steps (5-11). Guidance from any repo applies globally; when conflicts exist, prefer the repo-specific instruction.
-   - If no `.cve-fix/` folders exist, proceed with default strategy.
+
+   **CRITICAL — MANDATORY. Do NOT skip. Must run before any fix is applied.**
+
+   Runs ONCE after all repos are cloned, BEFORE any fixes. Check every cloned repo for
+   a `.cve-fix/` directory and read ALL files inside it. This guidance contains
+   repo-specific fix patterns, known working versions, and pitfalls that directly affect
+   whether the fix will succeed.
+
+   ```bash
+   for REPO_DIR in "${ALL_CLONED_REPOS[@]}"; do
+     CVE_FIX_DIR="${REPO_DIR}/.cve-fix"
+     if [ -d "$CVE_FIX_DIR" ]; then
+       echo "📖 Reading fix guidance from ${REPO_DIR}/.cve-fix/"
+       for FILE in "$CVE_FIX_DIR"/*; do
+         echo "  Reading: $FILE"
+         cat "$FILE"
+       done
+     else
+       echo "ℹ️  No .cve-fix/ folder in ${REPO_DIR} — using default strategy"
+     fi
+   done
+   ```
+
+   - Extract: dependency co-upgrades, lock file requirements, version upgrade patterns,
+     branch-specific instructions, known working fix versions, testing requirements, pitfalls
+   - Apply this guidance to ALL subsequent steps (5-11)
+   - When conflicts exist between repos, prefer the repo-specific instruction
+   - **Always log the result** — either "guidance loaded from X" or "no .cve-fix/ found in any repo"
 
 ---
 > **Steps 5-11 repeat for EACH repository identified in Step 3.**
@@ -527,7 +574,7 @@ This issue can be closed as 'Not a Bug / ${VEX_JUSTIFICATION}' if the above evid
    COMMENT_JSON=$(jq -n --arg body "$COMMENT_TEXT" '{"body": $body}')
 
    # Post comment via Jira API
-   AUTH=$(echo -n "${JIRA_EMAIL}:${JIRA_API_TOKEN}" | base64)
+   AUTH=$(echo -n "${JIRA_EMAIL}:${JIRA_API_TOKEN}" | base64 | tr -d '\n')
    curl -s -X POST \
      -H "Authorization: Basic ${AUTH}" \
      -H "Content-Type: application/json" \
@@ -565,19 +612,43 @@ This issue can be closed as 'Not a Bug / ${VEX_JUSTIFICATION}' if the above evid
 
    **How to check:**
 
+   Two searches are needed — bots like Dependabot and Renovate open PRs that fix the same
+   vulnerability without mentioning the CVE ID, only the package name and version bump.
+
    ```bash
    REPO_FULL="opendatahub-io/models-as-a-service"  # org/repo from mapping
    CVE_ID="CVE-YYYY-XXXXX"
+   PACKAGE="urllib3"  # extracted from Jira summary in Step 1
    TARGET_BRANCH="main"  # from mapping or user input
-
-   # Search open PRs for this specific CVE ID targeting this branch
-   EXISTING_PR=$(gh pr list --repo "$REPO_FULL" --state open --base "$TARGET_BRANCH" --search "$CVE_ID" --json number,title,url,headRefName,baseRefName --jq '.[0]' 2>/dev/null)
+   EXISTING_PR=""
+
+   # Search 1: by CVE ID (catches our own PRs and manually created ones)
+   EXISTING_PR=$(gh pr list --repo "$REPO_FULL" --state open --base "$TARGET_BRANCH" \
+     --search "$CVE_ID" --json number,title,url --jq '.[0]' 2>/dev/null)
+
+   # Search 2: by package name (catches Dependabot/Renovate PRs that don't mention CVE ID)
+   if [ -z "$EXISTING_PR" ] || [ "$EXISTING_PR" = "null" ]; then
+     EXISTING_PR=$(gh pr list --repo "$REPO_FULL" --state open --base "$TARGET_BRANCH" \
+       --search "$PACKAGE" --json number,title,url,author \
+       --jq '[.[] | select(.author.login | test("dependabot|renovate|renovate-bot"; "i"))] | .[0]' \
+       2>/dev/null)
+
+     # Search 3: broad package name search to catch human-opened PRs.
+     # Note: for common package names (e.g. "requests", "yaml") this may
+     # produce false positives. If the matched PR title does not appear
+     # related to the CVE (e.g. it's a feature PR that happens to mention
+     # the package), do NOT skip — use judgment before skipping.
+     if [ -z "$EXISTING_PR" ] || [ "$EXISTING_PR" = "null" ]; then
+       EXISTING_PR=$(gh pr list --repo "$REPO_FULL" --state open --base "$TARGET_BRANCH" \
+         --search "$PACKAGE" --json number,title,url --jq '.[0]' 2>/dev/null)
+     fi
+   fi
 
    if [ -n "$EXISTING_PR" ] && [ "$EXISTING_PR" != "null" ]; then
      PR_NUMBER=$(echo "$EXISTING_PR" | jq -r '.number')
      PR_TITLE=$(echo "$EXISTING_PR" | jq -r '.title')
      PR_URL=$(echo "$EXISTING_PR" | jq -r '.url')
-     echo "⏭️  Skipping $CVE_ID — existing open PR found:"
+     echo "⏭️  Skipping $CVE_ID — existing open PR found (may be Dependabot/Renovate):"
      echo "   PR #${PR_NUMBER}: ${PR_TITLE}"
      echo "   URL: ${PR_URL}"
 
@@ -613,11 +684,13 @@ This issue can be closed as 'Not a Bug / ${VEX_JUSTIFICATION}' if the above evid
      - Proceed with the fix (Step 6 onwards)
 
    **Search strategy:**
-   - Search by exact CVE ID first (e.g., `CVE-2025-61726`) — this is the most reliable match
+   - **Search 1 — by CVE ID**: catches our own PRs and any manually created ones
+   - **Search 2 — by package name filtered to bots**: catches Dependabot/Renovate PRs that bump the vulnerable package without mentioning the CVE ID (e.g. "Bump urllib3 from 1.26.5 to 2.2.3")
+   - **Search 3 — by package name broadly**: catches any human-opened PR for the same package, regardless of author
    - The `gh pr list --search` command searches PR titles and bodies
-   - A single PR may address multiple CVEs (e.g., "fix: cve-2025-61726 and cve-2025-68121") — if ANY of the target CVEs appear in an existing PR, consider all CVEs in that PR as already handled
-   - **IMPORTANT: Only skip for OPEN PRs.** Closed or merged PRs should be ignored — if a previous PR was closed without merging (e.g., it was incorrect or superseded), it is valid to create a new fix PR for the same CVE. The `--state open` flag in the `gh pr list` command ensures only open PRs are checked.
-   - **Stale remote branches**: A previous automation run may have left a remote branch with the same name (e.g., `fix/cve-YYYY-XXXXX-attempt-1`) from a closed PR. If push fails due to a conflicting remote branch, increment the attempt number (e.g., `attempt-2`) or delete the stale remote branch with `git push origin --delete <branch-name>` before pushing.
+   - A single PR may address multiple CVEs — if any of the target CVEs or the affected package appears in an existing open PR, skip creating a duplicate
+   - **IMPORTANT: Only skip for OPEN PRs.** Closed or merged PRs should be ignored — it is valid to create a new fix PR for the same CVE if a previous PR was closed without merging. The `--state open` flag ensures only open PRs are checked.
+   - **Stale remote branches**: If push fails due to a conflicting remote branch from a previous run, increment the attempt number (e.g., `attempt-2`) or delete the stale branch with `git push origin --delete <branch-name>`.
 
    **Example output when PR exists:**
    ```
@@ -982,10 +1055,103 @@ This issue can be closed as 'Not a Bug / ${VEX_JUSTIFICATION}' if the above evid
    **Full test log**: `artifacts/cve-fixer/fixes/test-results/test-run-20260218-143022.log`
    ```
 
+10.5. **Post-Fix CVE Verification**
+
+   **CRITICAL — This step is MANDATORY. Do NOT skip it. Do NOT proceed to PR creation without completing this step.**
+
+   Source-level scanning (Step 5) checks the dependency manifests before the fix.
+   This step verifies the fix actually worked by scanning the **compiled output** after
+   the fix is applied. A source scan can give false negatives (e.g., go.mod updated but
+   toolchain not recompiled, or a transitive dep overrides the fixed version at build time).
+
+   **For Go projects (preferred — binary scan):**
+
+   ```bash
+   echo "Building and scanning binary to verify fix for CVE-${CVE_ID}..."
+   cd "$REPO_DIR"
+
+   # Build the binary with the fixed go.mod
+   go build -o /tmp/fixed-binary-${REPO_NAME} ./... 2>&1
+
+   if [ $? -eq 0 ]; then
+     # Scan the compiled binary — this is the gold standard
+     POST_SCAN_OUTPUT=$(GOTOOLCHAIN="go${TARGET_GO_VERSION}" \
+       govulncheck -mode binary /tmp/fixed-binary-${REPO_NAME} 2>&1)
+     rm -f /tmp/fixed-binary-${REPO_NAME}
+   else
+     echo "⚠️ Binary build failed — falling back to source scan"
+     POST_SCAN_OUTPUT=$(GOTOOLCHAIN="go${TARGET_GO_VERSION}" govulncheck -show verbose ./... 2>&1)
+   fi
+   ```
+
+   **For Python projects:**
+
+   ```bash
+   # Re-run pip-audit on the modified requirements file
+   POST_SCAN_OUTPUT=$(pip-audit -r requirements.txt 2>&1)
+   ```
+
+   **For Node.js projects:**
+
+   ```bash
+   # Re-run npm audit after package.json changes
+   npm install --package-lock-only 2>/dev/null  # regenerate lockfile
+   POST_SCAN_OUTPUT=$(npm audit --json 2>&1)
+   ```
+
+   **Check result — verify scan ran successfully before trusting output:**
+
+   ```bash
+   SCAN_EXIT_CODE=$?
+
+   # If scanner failed (tool missing, network issue, toolchain error), treat as
+   # inconclusive — do NOT assume CVE is fixed. Log and skip PR creation.
+   if [ $SCAN_EXIT_CODE -ne 0 ] && [ -z "$POST_SCAN_OUTPUT" ]; then
+     echo "⚠️ Post-fix scan failed to run (exit code ${SCAN_EXIT_CODE}). Cannot verify fix."
+     echo "⚠️ Skipping PR creation for safety — manual verification required."
+     CVE_STILL_PRESENT=true  # treat as still present to block PR creation
+   elif echo "$POST_SCAN_OUTPUT" | grep -q "$CVE_ID"; then
+     CVE_STILL_PRESENT=true
+   else
+     CVE_STILL_PRESENT=false
+   fi
+   ```
+
+   **If CVE is gone** (`CVE_STILL_PRESENT=false`) → proceed to PR creation ✅
+
+   **If CVE is still present** (`CVE_STILL_PRESENT=true`) → **do NOT create a PR**:
+   - Print: "❌ CVE-YYYY-XXXXX still detected after fix attempt in [repo] ([branch]). Fix was insufficient."
+   - Add a Jira comment using MCP if available, otherwise curl:
+
+     If `mcp__mcp-atlassian__jira_search` was used in Step 2, use the corresponding
+     Jira comment MCP tool. Otherwise fall back to curl:
+
+     ```bash
+     COMMENT_TEXT="Automated fix attempted but CVE still detected after applying changes.
+
+Fix attempted: ${FIX_DESCRIPTION}
+Post-fix scan: CVE still present in ${REPO_FULL} on branch ${TARGET_BRANCH}
+Scan date: $(date -u +%Y-%m-%dT%H:%M:%SZ)
+
+Manual investigation required — the automated fix did not resolve this CVE.
+Possible causes: transitive dependency conflict, incorrect package targeted, or
+the fix requires additional changes beyond a version bump."
+
+     COMMENT_JSON=$(jq -n --arg body "$COMMENT_TEXT" '{"body": $body}')
+     AUTH=$(echo -n "${JIRA_EMAIL}:${JIRA_API_TOKEN}" | base64 | tr -d '\n')
+     curl -s -X POST \
+       -H "Authorization: Basic ${AUTH}" \
+       -H "Content-Type: application/json" \
+       -d "$COMMENT_JSON" \
+       "${JIRA_BASE_URL}/rest/api/3/issue/${JIRA_KEY}/comment"
+     ```
+   - Document in `artifacts/cve-fixer/fixes/fix-failed-CVE-YYYY-XXXXX.md`
+   - Skip to next CVE/branch — do not create PR for this one
+
 11. **Create Pull Requests**
    - **CRITICAL**: You MUST actually CREATE the PRs using `gh pr create` command
    - **CRITICAL**: Create a SEPARATE PR for EACH CVE (NOT combined)
-   - **CRITICAL**: Only create PRs for CVEs that were ACTUALLY FIXED (not for CVEs that were already fixed in Step 5)
+   - **CRITICAL**: Only create PRs for CVEs that passed post-fix verification in Step 10.5 (not for CVEs that were already fixed in Step 5 or where the fix was insufficient)
    - For each CVE fix that was successfully committed and pushed:
      - Generate PR title: `Security: Fix CVE-YYYY-XXXXX (<package-name>)`
      - **Extract Jira issue IDs for this CVE:**
@@ -1074,10 +1240,18 @@ This PR fixes **CVE-YYYY-XXXXX** by upgrading <package> from X.X.X to Y.Y.Y.
 EOF
 )
 
-       gh pr create \
+       PR_URL=$(gh pr create \
          --base <target-branch> \
          --title "Security: Fix CVE-YYYY-XXXXX (<package-name>)" \
-         --body "$PR_BODY"
+         --body "$PR_BODY")
+
+       # Enable automerge if --automerge flag was passed and PR was created successfully
+       if [ "$AUTOMERGE" = "true" ] && [ -n "$PR_URL" ] && [ "$PR_URL" != "null" ]; then
+         gh pr merge --auto --squash "$PR_URL"
+         echo "✅ Automerge enabled on $PR_URL — will merge when checks pass"
+       elif [ "$AUTOMERGE" = "true" ] && [ -z "$PR_URL" ]; then
+         echo "⚠️ Automerge skipped — PR URL is empty (PR creation may have failed)"
+       fi
        ```
      - Capture the PR URL from the command output
      - Save PR URL to fix implementation report
@@ -1155,6 +1329,9 @@ EOF
   - PR URL for the created pull request
 
 - **Already Fixed Report**: `artifacts/cve-fixer/fixes/already-fixed-CVE-YYYY-XXXXX.md` (if CVE confirmed not present via both scan and package check)
+
+- **Fix Failed Report**: `artifacts/cve-fixer/fixes/fix-failed-CVE-YYYY-XXXXX.md` (if post-fix re-scan still detects the CVE)
+  - Fix attempted, post-fix scan output, Jira comment added, manual review required
   - CVE ID, repository, and scan evidence
 
 - **VEX Justified Report**: `artifacts/cve-fixer/fixes/vex-justified-CVE-YYYY-XXXXX.md` (if auto-detected VEX justification added to Jira)
@@ -1222,6 +1399,12 @@ Fix multiple specific Jira issues:
 /cve.fix RHOAIENG-4973 RHOAIENG-5821
 ```
 
+Fix and enable automerge on all created PRs (merges automatically when checks pass):
+```
+/cve.fix --automerge
+/cve.fix RHOAIENG-4973 --automerge
+```
+
 Fix with custom message:
 ```
 /cve.fix Fix open CVEs found in latest scan
diff --git a/workflows/cve-fixer/.claude/commands/onboard.md b/workflows/cve-fixer/.claude/commands/onboard.md
new file mode 100644
index 00000000..c5d8a32f
--- /dev/null
+++ b/workflows/cve-fixer/.claude/commands/onboard.md
@@ -0,0 +1,258 @@
+# /onboard - Onboard a New Component to the CVE Fixer Workflow
+
+## Purpose
+
+Guides a team through adding their component and repositories to
+`component-repository-mappings.json` and opens a PR to the CVE fixer
+workflow repository. The Jira component name must exactly match what is
+used in Jira — this is validated against the Jira API during onboarding.
+
+## Process
+
+1. **Collect Component Information**
+
+   Ask the user for the following, one question at a time:
+
+   a. **Jira component name** — must match exactly what appears in Jira
+      (case-sensitive). Example: `"AI Evaluations"`, `"llm-d"`, `"AutoML"`
+
+   b. **Repos** — for each repo the user wants to add, collect:
+      - GitHub URL (e.g. `https://github.com/org/repo`)
+      - Repo type: `upstream`, `midstream`, or `downstream`
+      - Subcomponent name (optional — only needed if the component has multiple
+        distinct container chains, e.g. `"inference-scheduler"`, `"autoscaler"`)
+
+   c. **Container image names** (optional) — the `rhoai/odh-*-rhel9` container
+      images that map to each repo. These can be left empty and added later.
+
+   Collect all repos before proceeding. Ask: "Do you have more repos to add?
+   (yes/no)" after each repo until the user is done.
+
+2. **Validate Jira Component Name**
+
+   Use MCP if available (preferred), otherwise fall back to curl.
+   Follow the same MCP-first pattern as `cve.find`:
+   - Try `ToolSearch: select:mcp__mcp-atlassian__jira_search` first
+   - If found, use it to search: `component = "${COMPONENT_NAME}" AND labels = SecurityTracking`
+   - If not found, fall back to curl:
+
+   ```bash
+   JIRA_BASE_URL="https://redhat.atlassian.net"
+   AUTH=$(echo -n "${JIRA_EMAIL}:${JIRA_API_TOKEN}" | base64 | tr -d '\n')
+   JQL="component = \"${COMPONENT_NAME}\" AND labels = SecurityTracking"
+   ENCODED=$(python3 -c "import urllib.parse, sys; print(urllib.parse.quote(sys.argv[1]))" "$JQL")
+
+   RESULT=$(curl -s -X GET --connect-timeout 10 --max-time 15 \
+     -H "Authorization: Basic ${AUTH}" \
+     -H "Content-Type: application/json" \
+     "${JIRA_BASE_URL}/rest/api/3/search/jql?jql=${ENCODED}&maxResults=1&fields=key,summary")
+
+   ISSUE_COUNT=$(echo "$RESULT" | jq '.issues | length')
+   ```
+
+   - If component returns results → confirmed, proceed
+   - If 0 results → warn user: "No CVE issues found for component
+     '${COMPONENT_NAME}' with SecurityTracking label. The component name
+     must match exactly what Jira uses. Do you want to proceed anyway? (yes/no)"
+   - If Jira credentials not available → skip validation and proceed with a note
+
+3. **Auto-discover Branch Information**
+
+   For each GitHub repo provided, fetch branch info automatically:
+
+   ```bash
+   for REPO_URL in "${REPOS[@]}"; do
+     REPO_FULL=$(echo "$REPO_URL" | sed 's|https://github.com/||')
+
+     # Verify repo exists
+     gh api repos/${REPO_FULL} --jq '.full_name' 2>/dev/null || {
+       echo "⚠️ Repo not found: ${REPO_URL}"
+       continue
+     }
+
+     # Get default branch
+     DEFAULT_BRANCH=$(gh api repos/${REPO_FULL} --jq '.default_branch')
+
+     # Get active release branches (rhoai-*, release/*, odh-*, stable)
+     ACTIVE_BRANCHES=$(gh api repos/${REPO_FULL}/branches --paginate \
+       -q '.[].name' 2>/dev/null | \
+       grep -E '^(rhoai-[0-9]|release/|odh-[0-9]|stable)' | \
+       sort -V | tail -5)  # keep 5 most recent
+
+     echo "  ${REPO_FULL}: default=${DEFAULT_BRANCH}, active=[${ACTIVE_BRANCHES}]"
+   done
+   ```
+
+   Show the discovered info to the user and ask for confirmation or corrections.
+
+4. **Build Mapping Entry**
+
+   Construct the JSON entry following the existing schema:
+
+   ```json
+   {
+     "<COMPONENT_NAME>": {
+       "container_to_repo_mapping": {
+         "<container-image>": "<primary-repo>"
+       },
+       "repositories": {
+         "<org/repo>": {
+           "github_url": "https://github.com/<org/repo>",
+           "default_branch": "<branch>",
+           "active_release_branches": ["<branch1>", "<branch2>"],
+           "branch_strategy": "TBD — to be updated by component team",
+           "repo_type": "upstream|midstream|downstream",
+           "subcomponent": "<subcomponent-name>",
+           "cve_fix_workflow": {
+             "primary_target": "<default_branch>",
+             "backport_targets": "<active branches comma-separated>"
+           }
+         }
+       }
+     }
+   }
+   ```
+
+   - Omit `subcomponent` if the user didn't provide one
+   - Omit `container_to_repo_mapping` entries if no containers were provided
+   - Show the generated JSON to the user and ask: "Does this look correct? (yes/no/edit)"
+
+5. **Set Up Workflows Repository**
+
+   The mapping file lives in `ambient-code/workflows`. Check write access and
+   fork if needed:
+
+   ```bash
+   WORKFLOWS_REPO="ambient-code/workflows"
+   FORK_USER=$(gh api user --jq '.login' 2>/dev/null)
+
+   # Check write access
+   PUSH_ACCESS=$(gh api repos/${WORKFLOWS_REPO} --jq '.permissions.push' 2>/dev/null)
+
+   if [ "$PUSH_ACCESS" = "true" ]; then
+     # Clone directly
+     git clone "https://github.com/${WORKFLOWS_REPO}.git" /tmp/workflows-onboard
+     REMOTE="origin"
+     PR_HEAD_PREFIX=""
+   else
+     # Fork the repo
+     echo "No write access to ${WORKFLOWS_REPO} — forking..."
+     gh repo fork "$WORKFLOWS_REPO" --clone=false 2>/dev/null || true
+
+     # Sync fork with upstream main
+     gh repo sync "${FORK_USER}/workflows" --source "$WORKFLOWS_REPO" --branch main
+     git clone "https://github.com/${FORK_USER}/workflows.git" /tmp/workflows-onboard
+     cd /tmp/workflows-onboard
+     git remote add upstream "https://github.com/${WORKFLOWS_REPO}.git"
+     REMOTE="origin"
+     PR_HEAD_PREFIX="${FORK_USER}:"
+   fi
+   ```
+
+6. **Apply the Mapping Change**
+
+   ```bash
+   cd /tmp/workflows-onboard
+   git checkout -b "onboard/${COMPONENT_NAME_SLUG}"
+
+   MAPPING_FILE="workflows/cve-fixer/component-repository-mappings.json"
+
+   # Write the new component JSON to a temp file first to avoid shell injection
+   # (component names or JSON values may contain quotes, backslashes, or newlines)
+   echo "$NEW_COMPONENT_JSON" > /tmp/new_component.json
+
+   TODAY=$(date +%Y-%m-%d)
+
+   python3 - "$MAPPING_FILE" "$COMPONENT_NAME" /tmp/new_component.json "$TODAY" <<'PYEOF'
+   import json, sys
+
+   mapping_file = sys.argv[1]
+   component_name = sys.argv[2]
+   new_component_file = sys.argv[3]
+   today = sys.argv[4]
+
+   with open(mapping_file) as f:
+       data = json.load(f)
+
+   with open(new_component_file) as f:
+       new_component = json.load(f)
+
+   data["components"][component_name] = new_component
+   data["metadata"]["last_updated"] = today
+
+   with open(mapping_file, "w") as f:
+       json.dump(data, f, indent=2, ensure_ascii=False)
+       f.write("\n")
+
+   print(f"Added component: {component_name}")
+   PYEOF
+
+   rm -f /tmp/new_component.json
+
+   # Validate JSON
+   python3 -m json.tool "$MAPPING_FILE" > /dev/null && echo "✅ JSON valid"
+
+   git add "$MAPPING_FILE"
+   git commit -m "feat: onboard ${COMPONENT_NAME} to CVE fixer workflow
+
+   Add component-to-repository mapping for ${COMPONENT_NAME}:
+   $(echo "${REPOS[@]}" | tr ' ' '\n' | sed 's/^/- /')
+
+   Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>"
+   git push "$REMOTE" "onboard/${COMPONENT_NAME_SLUG}"
+   ```
+
+7. **Create Pull Request**
+
+   ```bash
+   gh pr create \
+     --repo "$WORKFLOWS_REPO" \
+     --base main \
+     --head "${PR_HEAD_PREFIX}onboard/${COMPONENT_NAME_SLUG}" \
+     --title "feat: onboard ${COMPONENT_NAME} to CVE fixer workflow" \
+     --body "$(cat <<EOF
+   ## Component Onboarding: ${COMPONENT_NAME}
+
+   ### Jira Component
+   - **Name:** ${COMPONENT_NAME}
+   - **Jira query:** \`component = "${COMPONENT_NAME}" AND summary ~ "CVE*" AND labels = SecurityTracking\`
+
+   ### Repositories Added
+   $(for REPO in "${REPOS[@]}"; do echo "- ${REPO}"; done)
+
+   ### Container Mappings
+   $([ -n "${CONTAINERS}" ] && echo "${CONTAINERS}" || echo "None provided yet — to be added once container image names are confirmed.")
+
+   ### Next Steps for Reviewers
+   - [ ] Verify Jira component name matches exactly
+   - [ ] Verify all repo URLs and branch names are correct
+   - [ ] Add container image mappings if missing
+
+   🤖 Generated by CVE Fixer /onboard command
+   EOF
+   )"
+
+   echo "✅ PR created successfully"
+   echo "🔗 Review and merge at: <PR_URL>"
+   ```
+
+8. **Cleanup**
+
+   ```bash
+   rm -rf /tmp/workflows-onboard
+   ```
+
+## Usage Examples
+
+```bash
+/onboard
+```
+
+The command is fully interactive — it will guide you through each question.
+
+## Notes
+
+- The Jira component name is case-sensitive and must match exactly
+- Branch info is auto-discovered from GitHub — review and correct if needed
+- Container image mappings can be added later by re-running `/onboard` or opening a PR directly
+- If you don't have write access to `ambient-code/workflows`, the command will automatically fork the repo and open a PR from your fork
diff --git a/workflows/cve-fixer/README.md b/workflows/cve-fixer/README.md
index a977b0ea..8235e0eb 100644
--- a/workflows/cve-fixer/README.md
+++ b/workflows/cve-fixer/README.md
@@ -99,14 +99,15 @@ Each team member using the workflow needs:
 
 ### Onboarding Steps
 
-1. **Submit Onboarding Request**
-   - Contact the workflow maintainers with your component details
-   - Provide GitHub repository URLs and target branches
-   - Specify upstream/downstream repository structure
-
-2. **Wait for Mapping Update**
-   - Maintainers will add your component to `component-repository-mappings.json`
-   - PR will be created and merged
+1. **Run `/onboard`**
+   - Run the `/onboard` command — it guides you through the process interactively
+   - Provide your Jira component name, GitHub repo URLs, and repo types
+   - The command validates your component name against Jira, auto-discovers branch info,
+     and opens a PR to add your component to `component-repository-mappings.json`
+   - No need to contact maintainers manually — the PR is opened automatically using your credentials
+
+2. **Wait for PR to Merge**
+   - A maintainer will review and merge your PR
    - You'll be notified when ready
 
 3. **Coordinate with ProdSec**
@@ -195,6 +196,27 @@ Discover and catalog CVEs that have been reported by ProdSec team in Jira for a
 - Extracts issue metadata (summary, status, priority, created date)
 - Groups results by status and priority
 
+### `/onboard` - Onboard a New Component
+
+Add your team's component and repositories to the CVE fixer workflow. This command guides you through the process interactively and opens a PR automatically.
+
+**Usage:**
+```bash
+/onboard    # fully interactive — guides you through each step
+```
+
+**What it does:**
+1. Collects your Jira component name, GitHub repos, and optional container image names
+2. Validates the Jira component name against the Jira API
+3. Auto-discovers branch info (default branch, active release branches) from GitHub
+4. Shows you the generated mapping entry for confirmation
+5. Forks `ambient-code/workflows` if you don't have write access, syncs the fork
+6. Opens a PR with your component added to `component-repository-mappings.json`
+
+**Run this before using `/cve.find` or `/cve.fix` for a new component.**
+
+---
+
 ### `/cve.fix` - Implement CVE Fixes
 
 Implement remediations for CVEs discovered in Jira by creating pull requests with fixes.