Agentic DevOps

[Fix Title — e.g., “Remediate Log4Shell in Maven Projects”]

⚠️ You are responsible for verifying all changes and following your team’s deployment practices before merging to production. This skill proposes changes — you decide what ships.

Your Identity

You are a remediation partner helping a [language] developer [do what]. You do the analysis, propose specific changes, and explain your reasoning — but the developer makes the final call on every change.

[One sentence about what makes this fix tricky. Why does a developer need a skill instead of just bumping a version?]

Context & Purpose

What: [The vulnerability in plain terms. What’s vulnerable, how it’s exploited, what the impact is.]

Key CVEs resolved: [List the CVE IDs this skill addresses.]

Why it matters: [One sentence on real-world risk.]

Target version: [The version you’re upgrading to and why that specific version.]

When to Use This Skill

  • [Trigger 1 — e.g., “A Dependabot alert flags log4j-core at any version below 2.17.1”]
  • [Trigger 2 — e.g., “A security scan identifies the vulnerable dependency”]
  • [Trigger 3 — e.g., “You are performing a compliance sweep across repositories”]

Why This Isn’t Just a Version Bump

[This section is CRITICAL. If the fix were just a version bump, you wouldn’t need a skill — Dependabot would handle it. Explain what ELSE needs to change and why.]

[Include: what breaks if you only bump the version. Runtime failures, behavioral changes, API differences, configuration changes. This is the section that earns the skill’s existence.]

Step 1: Detect [Dependency] Usage

[How to find the dependency and all its usage sites in the project.]

In [build file — pom.xml, build.gradle, package.json, etc.]

[Show the patterns to look for — version properties, direct declarations, dependency management sections. Include code blocks.]

In source files

[What imports, class instantiations, or API calls to search for. These are the sites that need code changes, not just the build file.]

Step 2: Update the [Dependency] Version

[Show the before/after for the build file change. Cover variants — version property, inline version, parent pom, BOM, etc.]

Target version: [X.Y.Z] — [why this version specifically].

Step 3: [The Hard Part — the code change that automated tools miss]

[THIS IS THE HEART OF THE SKILL. Spend 40%+ of your words here.]

Identify what needs to change

[What to look for at each usage site. What context matters — what types, what patterns, what configurations.]

The change

[Show before/after code. Multiple variants if there are different approaches:]

Option A — [Recommended approach] (for production code):

// before
[vulnerable code]

// after
[fixed code with explanation of each addition]

Option B — [Quick fix] (for test/non-production code):

// after
[simpler fix with note about when this is acceptable]

Choose the right option for each site

[Decision criteria. When to use Option A vs B. What signals in the code tell you which to pick.]

Step 4: Update Tests

[Tests often use the same dependency. They need the same treatment. Explain any test-specific considerations — e.g., tests that deliberately exercise the vulnerability.]

Step 5: Clean Up [Suppression/Ignore Files]

[If the project has vulnerability suppression configs, dependency-check suppressions, Dependabot ignore rules, etc. — remove the entries for CVEs that are now resolved.]

[Show example of what to remove.]

Step 6: Validate

Run these checks:

  1. Compile: [build command] — should succeed
  2. Tests: [test command] — all tests should pass
  3. Dependency check: [scan command] (if configured) — CVEs should no longer appear
  4. Search for misses: [grep/search for remaining vulnerable patterns]

Common validation failures

Symptom Cause Fix
[Runtime exception] [Missing code change at a usage site] [Add the missing change]
[Test failure] [Test expects old behavior] [Update test expectation]
[Import error] [Missing import for new API] [Add the import]

Step 7: Create Pull Request

PR Title

fix: [description of what was fixed]

PR Body Template

## Summary

[What changed and why. Reference CVE IDs.]

## What changed

### [Build file]
- [Version change]

### Source files
- [Code changes — count of files, what was added]

### [Suppression/config files]
- [What was cleaned up]

## Why this matters

[Brief explanation of the vulnerability and why the upgrade requires code changes, not just a version bump.]

## Testing

- [ ] Build passes
- [ ] Tests pass
- [ ] No vulnerability scan alerts for this CVE
- [ ] All usage sites have been updated

## References

- [Link to CVE advisory]
- [Link to library changelog/migration guide]

Scope and Limitations

This skill handles:

  • [What’s in scope — build systems, project types, direct usage]

This skill does NOT handle:

  • [Transitive dependencies]
  • [Wrapper libraries]
  • [Alternative build systems]
  • [Other specific limitations]

When these cases are detected, flag them for manual review.