/arn-code-batch-cve-fix

name: arn-code-batch-cve-fix
description: >-
  This skill should be used when the user says "fix CVEs", "patch vulnerabilities",
  "apply security patches", "resolve security advisories", "batch CVE fix",
  "patch dependencies", "fix security findings", "remediate CVEs",
  "apply CVE fixes", "batch fix vulnerabilities", "resolve vulnerability tickets",
  "arness CVE fix", "arn-code-batch-cve-fix", "fix all open CVE tickets",
  "cleanup resolved CVE proposals", or wants Arness to apply per-group dependency
  bumps for previously-triaged CVEs and open per-group pull requests that close
  their corresponding sub-issues. Reuses arn-code-batch-implement worker isolation
  verbatim, opens PRs targeting the configured Security branch, and offers an
  interactive post-merge cleanup of fully-resolved past CVE proposals. Interactive
  only — no proposal mode, no headless write path; every PR is human-reviewed and
  every archive move is confirmed via AskUserQuestion. Requires that
  arn-code-batch-cve-scan has produced triage records and sub-issues.

Arness Batch CVE Fix

Apply per-group fixes for previously-triaged CVEs, open per-group pull requests targeting the configured `Security branch:`, and optionally archive fully-resolved past CVE proposals. This skill consumes the triage records, sub-issue numbers, and parent-issue handle produced by `arn-code-batch-cve-scan` and dispatches one worker per group inside a pre-created git worktree.

**Key architectural constraint:** This skill is a sequencer — it MUST NOT duplicate sub-reference logic. All procedural detail lives in `references/`. Worker isolation (worktree setup, isolation check, cleanup-on-failure) is INHERITED from `arn-code-batch-implement/references/worker-instructions.md` — this skill's own `worker-instructions.md` DELEGATES to that source-of-truth and documents only the per-group fix scope.

**Interactive-only** (per spec FR §30). There is no `--mode=` argument. There is no proposal artifact. There is no headless / scheduled fix path. Every PR is human-reviewed at creation time; every past-plan archive is confirmed via `AskUserQuestion`. The auto-apply boundary (see `references/auto-apply-boundary.md`) controls whether the worker drives the dependency bump itself (when all 5 conditions are met) or pauses for human application — the worker still always opens a PR for review.

Pipeline position:

arn-code-batch-cve-scan (triage records + parent + sub-issues)
                  │
                  ▼
        **arn-code-batch-cve-fix**
        ┌─────────┴────────────┐
        │ form groups          │
        │ apply auto-apply gate│
        │ dispatch workers     │
        │ open per-group PRs   │
        │ post-fix cleanup     │
        └──────────────────────┘
                  │
                  ▼
        Per-group PRs targeting <Security branch>
        (each PR contains `Closes #N` per sub-issue)
                  │
                  ▼ (after merge — polled or --cleanup-resolved)
        Past-plan cleanup (interactive archive of resolved CVE_<ts>/)

---

Step 0: Ensure Configuration

Read `${CLAUDE_PLUGIN_ROOT}/skills/arn-code-ensure-config/references/step-0-fast-path.md` and follow its instructions. This guarantees `## Arness` is configured with Arness Code fields.

After ensure-config completes, extract from `## Arness`:

• **Security scanning** — `enabled | none | skip`. If `none` or `skip`, inform the user: "Security scanning is set to `<value>`. Update the `Security scanning:` field in `## Arness` to `enabled` to run this skill." STOP.
• **Security branch** — branch name or `auto`. If `auto`, resolve via `git symbolic-ref --short refs/remotes/origin/HEAD`. This branch is used in THREE places throughout the skill:

1. Worker worktree baseline: `git worktree add <path> <security-branch>` 2. Auto-apply gate CI baseline check: `gh run list --branch <security-branch>` (see `references/auto-apply-boundary.md`) 3. PR target: `gh pr create --base <security-branch>` (see `references/pr-body.md`)

• **Plans directory** — base path for locating past CVE proposals during cleanup.
• **Issue tracker** — `github | jira | none`. Drives `Closes #N` syntax (GitHub) vs. Jira issue-link payload.
• **Platform** — `github | jira | none`. Drives `gh` vs. Atlassian-MCP for PR creation.
• **Git** — must be `yes`. If `no`, inform the user: "Batch CVE fix requires git for worktree-based parallel execution. Set `Git: yes` in `## Arness` or apply fixes manually." STOP.

If `Security branch:` is missing, Layer 2c will have prompted the user via `AskUserQuestion` and written the chosen value (see Phase 5 wiring). This skill consumes the field — it does not write it.

Resolve a worker count cap: mirror `arn-code-batch-implement`'s `≤5 concurrent workers` policy. If more than 5 groups are formed, batch them into successive waves of 5.

---

Step 1: Ingest Scan Output

The fix skill consumes the handoff produced by `arn-code-batch-cve-scan`. Two equivalent intake paths are supported (whichever is present wins; if both, the explicit invocation argument wins):

• **JSON file on disk** — default path: the most-recent `CVE_SCAN_PROPOSAL.json` under `<Plans directory>/CVE_*/` (excluding the archive subdirectory — see `references/cleanup-resolved.md` for the archive location convention). The proposal contains the parent-issue handle, the sub-issue numbers, and the full triage records per CVE.
• **Invocation argument** — explicit `--proposal-path=<absolute-path-to-CVE_SCAN_PROPOSAL.json>`. Overrides auto-discovery.

If no proposal is found and none is supplied, inform the user: "No CVE scan proposal found under `<Plans directory>/CVE_*/`. Run `/arn-code-batch-cve-scan` first to discover and triage CVEs." STOP.

Validate the proposal:

• The proposal's `parentIssue` field must be a still-open issue (query via `gh issue view <N> --json state` or Jira MCP equivalent). If closed, inform the user and ask whether to proceed against the closed par