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 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 records + sub-issue numbers from Step 1. Outputs: an ordered list of groups, each carrying:

- `groupId`: deterministic SHA-256 hash of the sorted advisory-id list
- `cves[]`: one or more triage records
- `subIssues[]`: one or more sub-issue numbers
- `kind`: `critical-singleton` | `breaking-singleton` | `bundled`

Critical-severity or breaking-change CVEs land in singleton groups (one CVE per PR). Other CVEs bundle with independence checks, capped at 8 per group for reviewability.

---

## Step 3: Apply Auto-Apply Boundary

Read `${CLAUDE_PLUGIN_ROOT}/skills/arn-code-batch-cve-fix/references/auto-apply-boundary.md` and follow its 5-condition AND-gate. For each group:

- All 5 conditions TRUE → mark the group `auto-apply: true`. The worker will drive the dependency bump itself.
- Any condition FALSE → mark the group `auto-apply: false`. The worker still opens a PR, but it pauses to surface the bump for human application before committing — the PR body explicitly notes "Human-applied" instead of "Auto-applied".

The CI baseline check inside the auto-apply gate uses the configured `Security branch:` (NEVER hardcoded `main`).

If the configured `Security branch:` CI is currently red OR the project's test command is missing, ABORT auto-apply for the entire batch and force `auto-apply: false` on every group. Workers will still run; PRs will still open; but no auto-apply marker will appear in any PR body.

---

## Step 4: Pre-flight Summary

Present the planned groups as a table, similar to `arn-code-batch-implement`'s pre-flight:

```
Batch CVE Fix Pre-flight:

| # | Group ID (first 8) | CVEs | Severity | Auto-apply? | Sub-issues |
|---|--------------------|------|----------|-------------|------------|
| 1 | a3f9bc01           | 1    | critical | yes         | #123       |
| 2 | b71d2ef8           | 5    | high     | no          | #124..#128 |
| 3 | 9e8a4c20           | 8    | medium   | yes         | #129..#136 |
```

Inform the user about worktree location: "Workers run in pre-created worktrees at `.claude/worktrees/arn-batch-cve-<groupId-prefix>/` baselined off `<security-branch>`. Worktrees are preserved until the corresponding PR is merged; cleanup follows the same semantics as `arn-code-batch-implement`."

Inform the user about PR target: "Each PR targets `<security-branch>`. Sub-issues are auto-closed by `Closes #N` lines in the PR body."

Ask (using `AskUserQuestion`):

> **Launch [N] parallel CVE fix workers?**
> 1. Launch all
> 2. Select subset
> 3. Cancel

- **Launch all** — proceed with all groups.
- **Select subset** — present a multi-select (using `AskUserQuestion` with `multiSelect: true`) listing each group by `groupId` prefix + summary. Proceed with selected groups only.
- **Cancel** — exit.

---

## Step 5: Dispatch Parallel Workers

Read `${CLAUDE_PLUGIN_ROOT}/skills/arn-code-batch-cve-fix/references/worker-instructions.md` and follow its dispatch procedure. The worker-instructions file DELEGATES to `plugins/arn-code/skills/arn-code-batch-implement/references/worker-instructions.md` for worktree setup, isolation enforcement, and cleanup-on-failure semantics — this skill never reimplements that logic. The fix-specific reference adds only:

- The per-group fix scope (single CVE for critical/breaking; bundled cap 8 for others).
- Worktree creation baseline: `git worktree add <path> <security-branch>` (NOT a hardcoded base branch).
- PR target: `gh pr create --base <security-branch>`.
- Verification mode selection per `references/verification.md`.
- PR body composition per `references/pr-body.md`.

Spawn workers in parallel per the batch-implement convention. Cap at 5 concurrent workers; batch into waves of 5 if more groups exist.

---

## Step 6: Track Progress

As workers complete, collect their final messages. Each worker should end with `PR: <url>` or `PR: none -- <reason>`. Present a status table as workers finish:

```
| Group ID (first 8) | CVEs | Status | PR | Duration |
|--------------------|------|--------|----|----------|
| a3f9bc01           | 1    | done   | https://github.com/.../pull/501 | 2m 14s |
| b71d2ef8           | 5    | failed -- verification | n/a | 1m 02s |
```

If a worker fails: report the failure, continue tracking other workers, include the failed group in the summary. Cleanup-on-failure semantics (worktree teardown, branch teardown) are inherited from the batch-implement worker-instructions and run automatically inside the worker.

When all workers in the current wave complete, present the summary: **"[N/M] CVE groups fixed successfully."** If additional waves are queued (>5 groups), launch the next wave and repeat.

---

## Step 7: Post-fix Cleanup of Resolved Past Proposals

After all workers complete and PRs are open, invoke the post-fix cleanup sub-step. Read `${CLAUDE_PLUGIN_ROOT}/skills/arn-code-batch-cve-fix/references/cleanup-resolved.md` and follow its procedure.

Trigger paths:

- **Automatic post-merge polling** (default) — for each PR opened in this run, poll `gh pr view --json mergedAt` with a configurable timeout (default 30 days). When a PR transitions to merged, the cleanup-resolved procedure runs against the past-plan directory. Users who never merge see no auto-cleanup — the polling simply expires.
- **Manual invocation** — re-run this skill with `--cleanup-resolved` to skip directly to the cleanup sub-step against the current scan output, regardless of PR merge status.

The cleanup procedure enforces a **two-axis evidence gate** (both axes required) and is INTERACTIVE-ONLY — `AskUserQuestion` confirms every archive move. Archive uses `git mv` (preserving git history); `rm` is NEVER used. See `references/cleanup-resolved.md` for the full procedure including the archive destination path convention.

---

## Step 8: Final Summary

Print the closing summary:

- Per-group status (done | failed)
- PR URLs (or `none -- <reason>`)
- Sub-issues that will be auto-closed on PR merge (the `Closes #N` linkage)
- Parent-issue handle (still open; reviewer-facing context for the merge ceremony)
- Cleanup status (number of past proposals archived, if any)

Inform the user: "Per-group PRs target `<security-branch>`. Review and merge per your team's normal security-branch ceremony. Run `/arn-code-batch-cve-scan` again post-merge to confirm CVE inventory is cleared."

Exit cleanly.