security-patch

Verify, fix, and deploy minimal patches for security vulnerabilities in production systems.

Updated Apr 13, 2026
One-click install
npx skills add https://github.com/scoots31/engineering-playbook --skill security-patch-scoots31
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: security-patch
Source: https://github.com/scoots31/engineering-playbook/tree/main/skills/security-patch
Command: npx skills add https://github.com/scoots31/engineering-playbook --skill security-patch-scoots31

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a CVE or vulnerability report lands, teams often patch blindly, bundle unrelated changes, or ship fixes without confirming the exposure is actually closed — creating false confidence while the system remains exploitable. ## Core Features & Use Cases - Exposure Verification: Confirms whether the codebase actually uses the vulnerable code path before patching anything, avoiding wasted effort on non-exposed CVEs. - Minimal Fix Discipline: Applies only the change that closes the vulnerability — no refactoring, no bundled changes — with standardized commit message formats for traceability. - Mandatory Verification & Urgent Deploy: Reproduces the attack vector before and after the fix, audits for the same pattern elsewhere, and deploys immediately with post-deploy production verification. - Use Case: A critical CVE is published for a dependency in your production API. Use this Skill to confirm your code path is exposed, upgrade to the patched version, verify the exploit no longer works, and deploy the same day. ## Quick Start A critical CVE was just published for one of our dependencies — walk me through confirming our exposure, applying the minimal fix, and deploying it today.

Frequently Asked Questions about security-patch

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I respond to a CVE affecting my production application?

First confirm your codebase actually uses the vulnerable code path — many CVEs don't apply to specific usage patterns. Then apply the minimal fix, reproduce the attack vector to verify closure, and deploy immediately rather than waiting for a scheduled release.

How to verify a security patch actually closes the vulnerability?

Reproduce the attack vector in a non-production environment before patching, then confirm it fails after the fix is applied. Also audit the codebase for the same vulnerability pattern in other locations, and verify the fix took effect in production.

Should I patch a CVE if my code doesn't use the vulnerable feature?

No — if the vulnerable code path isn't exercised by your application, document that determination explicitly and close the issue. Patching unexposed code wastes effort and can introduce unnecessary risk.

What if no patched version exists for a vulnerable dependency?

Look for a documented workaround or disable the vulnerable feature entirely. If the exposure is critical and no clean fix exists, escalate immediately rather than shipping a partial fix that creates false confidence.

Why shouldn't security patches be bundled with other changes?

Bundling makes it harder to isolate regressions if something breaks after deployment. A security patch should ship alone with a minimal footprint so any post-deploy issue can be traced directly to the fix.