Remediation Planner

Converts a security finding, vulnerability, or bug into a prioritized step-by-step remediation plan with effort estimates per step.

What Does It Check?

The skill analyzes the finding to identify the vulnerability class, root cause, and affected component. It then produces an ordered list of steps minimum set needed, no padding that a developer can follow directly.In scope:

Any vulnerability class: injection (SQLi, XSS, SSTI, SSRF), broken access control (IDOR, privilege escalation), authentication issues (JWT, session), cryptographic failures, misconfigurations
Both immediate mitigations (compensating controls) and permanent fixes (root cause)
Hardening steps to prevent recurrence

Out of scope:

Vulnerability discovery use a hunter skill (idor-hunter, xss-hunter, ssti-hunter) for that
Generic security advice unrelated to the specific finding

How It Works

Step 1: Understand the FindingIdentify the vulnerability class, root cause, and affected component from the input. If the input is too vague to produce actionable steps, ask one clarifying question.Step 2: Order Steps by PriorityImmediate fixes first (stop the bleeding), then root cause fixes, then hardening to prevent recurrence. If a step is a temporary compensating control, label it clearly as such.Step 3: Write Each StepTitle + max 2-line description + effort label. No padding, no restating the problem. Steps must be actionable a developer should be able to start implementing without follow-up questions.

Effort Scale

Label	Meaning
Low	Quick config change, one-line fix, or a well-understood patch hours to a day
Medium	Requires code refactoring, moderate testing, or cross-team coordination days to a week
High	Architectural change, significant engineering work, or complex coordination weeks or more

Output

Structured remediation plan with numbered steps, each containing a short action title, 2-line description, and effort label.Example output:

Remediation Plan: SQL Injection in /api/search

Step 1 Replace String Concatenation with Parameterized Queries
Rewrite all database queries using prepared statements or an ORM with parameter binding.
Apply across every database-facing function, not just the reported endpoint.
Effort: Low

Step 2 Add Centralized Input Validation
Introduce a validation layer that enforces expected types and formats before input reaches
the data layer. Use an allowlist approach for structured fields.
Effort: Medium

Step 3 Restrict Database User Permissions
Grant the application's DB user only the permissions it needs. Remove DROP, CREATE,
and admin grants, and create separate read/write roles if the app allows it.
Effort: Low

Step 4 Deploy a WAF Rule as a Compensating Control [temporary]
Add a WAF rule to detect and block common SQL injection patterns while the code fix
is being rolled out. Not a substitute for Steps 1–3.
Effort: Medium

Known Limitations

If the finding is too vague (no vulnerability class, no affected component), one clarifying question will be asked before producing the plan
If no concrete remediation exists (fundamental design flaw), the skill will state that clearly and describe the trade-offs of available mitigations instead
Effort estimates are indicative actual effort depends on codebase size, test coverage, and team familiarity

Metric	Without Skill	With Skill
Turns to complete	2	1
Response tokens	~2,419	~1,052
Total time	44s	22s

Overview

Attack Mindset

Web Application

AI / LLM Security

API Security

Infrastructure

Reconnaissance

Reporting

Compliance

Workflow

Integrations

Remediation Planner

Summary

SKILL.md file