Three paths to agents that learn — from CVE skills to feedback loops
⚠️ 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.
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?]
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.]
[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.]
[How to find the dependency and all its usage sites in the project.]
[Show the patterns to look for — version properties, direct declarations, dependency management sections. Include code blocks.]
[What imports, class instantiations, or API calls to search for. These are the sites that need code changes, not just the build file.]
[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].
[THIS IS THE HEART OF THE SKILL. Spend 40%+ of your words here.]
[What to look for at each usage site. What context matters — what types, what patterns, what configurations.]
[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]
[Decision criteria. When to use Option A vs B. What signals in the code tell you which to pick.]
[Tests often use the same dependency. They need the same treatment. Explain any test-specific considerations — e.g., tests that deliberately exercise the vulnerability.]
[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.]
Run these checks:
[build command] — should succeed[test command] — all tests should pass[scan command] (if configured) — CVEs should no longer appear| 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] |
fix: [description of what was fixed]
## 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]
This skill handles:
This skill does NOT handle:
When these cases are detected, flag them for manual review.