SKILL.md
Exploit Execution & Payload Control
Use When
- A validated primitive exists and the next phase is controlled exploit implementation, payload hardening, chaining, reliability testing, or impact proof.
- The task is explicitly a lab exploit-development exercise with clear boundaries.
Handoff Criteria
- Hand off to CVE, input/protocol, authz, XSS, OOB, or business-logic workflows when the primitive is not yet validated.
- Hand off to reporting when impact proof and reproducibility are complete.
Output Schema
- Exploit plan:
preconditions,primitive,payload strategy,safety guardrails - Execution log:
step,result,evidence - Final capability statement: what attacker can do after exploitation
Instructions
- Require at least one validated security primitive before exploit implementation.
- Choose deterministic payloads with clear rollback or containment strategy.
- Execute in smallest viable sequence to prove impact with minimal disruption.
- Record exact preconditions and environmental dependencies.
- Separate exploit reliability issues from vulnerability existence.
- Produce reproducible commands and evidence suitable for independent verification.
Verification Gate
- Prefer deterministic, low-noise payloads over broad spray strategies.
- Preserve proof artifacts that map directly to attacker capability.
- Stop when impact is proven; avoid unnecessary escalation.
- Claim successful exploitation only from direct capability evidence, not partial side effects.
- Run destructive payloads only when explicitly authorized.
- Check tool status and dependencies before relying on them; if unavailable, use the safest fallback and report the gap.