| 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:
- Worker worktree baseline:
git worktree add <path> <security-branch>
- Auto-apply gate CI baseline check:
gh run list --branch <security-branch> (see references/auto-apply-boundary.md)
- 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 listcves[]: one or more triage recordssubIssues[]: one or more sub-issue numberskind: 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?
- Launch all
- Select subset
- 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.
