Produce a prioritized, actionable test runbook with exact pt generate commands, auth setup notes, and chaining suggestions
Produce a prioritized, actionable penetration testing runbook for the given target. The output is a single enriched batch.yaml manifest — the single source of truth for both script generation and runbook rendering.
Before running this skill, you should have already:
/analyze-spec (or read the spec directly) to identify high-risk endpointspt kb search queries to find matching disclosed reportsIf these haven't been done yet, do them first — the runbook depends on their output.
$ARGUMENTS is a file path, read the spec from specs/.specs/ and build a comprehensive runbook.Gather findings: Review the spec analysis and KB research already done in this conversation. If not done yet, run /analyze-spec and relevant pt kb search queries first.
Extract auth model: Read the securitySchemes section of the spec and determine:
Map findings to templates: For each high-risk endpoint, determine which pt generate template and options to use:
auth-sweep — bulk test every endpoint with no/invalid/valid authidor_ssrf_hint fields → ssrf (field-targeted) + payloads --type ssrfpayloads --type sqli + fuzzcsrfauth-bypass_redirect_hint → redirect + payloads --type redirect_file_upload_hint → upload_mass_assignment_hint fields → fuzz targeting the extra response-only fields_debug_endpoint_hint → auth-bypass (debug endpoints are often unprotected)payloads --type xss + fuzzpayloads --type path-traversal + fuzzSpec hint consumption — when the slim spec includes security hints, map them directly:
| Spec hint | Manifest action |
|---|---|
_ssrf_hint | Add ssrf entry with ssrf-fields set to the flagged fields |
_redirect_hint | Add redirect entry with redirect-params set to the flagged params |
_file_upload_hint | Add upload entry targeting the endpoint |
_mass_assignment_hint | Add fuzz entry targeting the extra response-only fields |
_debug_endpoint_hint | Add auth-bypass entry (debug endpoints are often unprotected) |
Identify chains: Check KB reports for multi-step attacks that connect findings:
Prioritize: Rank by likelihood × impact:
batch.yaml to project rootAlways create batch.yaml fresh. Do NOT read any existing batch.yaml (in the project root, temp/, or anywhere else) before writing. The runbook is generated from the current conversation's analysis — previous manifests are stale and must not influence the output.
Write a single file: batch.yaml (next to config.yaml). This enriched manifest is the single source of truth — it drives both script generation (pt generate batch) and runbook rendering (pt runbook generate).
Use the Write tool to save batch.yaml with this structure:
# Auto-generated by /runbook — review before running
# pt generate batch --manifest batch.yaml
# pt runbook generate --manifest batch.yaml