/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", "batch CVE fix", "remediate CVEs",
  "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 CVEs already triaged by arn-code-batch-cve-scan and open one
  human-reviewed PR per group against the configured Security branch.
  Interactive only.
version: 1.0.0
argument-hint: "[--proposal-path=<path>]"
disable-model-invocation: true

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**. 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. 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 parent (`AskUserQuestion`).
• The proposal's `subIssues[]` entries each carry the sub-issue number and the associated triage record. Sub-issues already in `closed` state are skipped (they were resolved out-of-band).

The triage records, sub-issue numbers, and parent-issue handle are now in memory for the rest of the skill.

---

Step 2: Form Groups

Read `${CLAUDE_PLUGIN_ROOT}/skills/arn-code-batch-cve-fix/references/grouping.md` and follow its grouping procedure. Inputs: the open triage rec