Orchestrate a penetration test by routing user intent to one or
more of the 25 narrow skills in this pack. Confirms authorization
+ scope FIRST (cluster 5), runs the relevant scan skills (clusters
1-4), then composes findings into the customer deliverables
(cluster 6) plus an integrity-attestable engagement archive
(cluster 5). Backward-compatible with v2 invocations — "pentest",
"security scan", "audit dependencies" still work but now route to
the narrow skills instead of the v2 monolithic scripts.
Use when: starting a security engagement, running an ad-hoc
scan, planning a multi-day pentest, or operating the full
authorization-to-deliverable workflow end-to-end.
Trigger with: "pentest", "security scan", "vulnerability
check", "audit dependencies", "check headers", "find secrets",
"OWASP scan", "security audit".
Instrucciones de origen · Vista previa de solo lectura
name
performing-penetration-testing
description
Orchestrate a penetration test by routing user intent to one or
more of the 25 narrow skills in this pack. Confirms authorization
+ scope FIRST (cluster 5), runs the relevant scan skills (clusters
1-4), then composes findings into the customer deliverables
(cluster 6) plus an integrity-attestable engagement archive
(cluster 5). Backward-compatible with v2 invocations — "pentest",
"security scan", "audit dependencies" still work but now route to
the narrow skills instead of the v2 monolithic scripts.
Use when: starting a security engagement, running an ad-hoc
scan, planning a multi-day pentest, or operating the full
authorization-to-deliverable workflow end-to-end.
Trigger with: "pentest", "security scan", "vulnerability
check", "audit dependencies", "check headers", "find secrets",
"OWASP scan", "security audit".
v3.0.0 of penetration-tester is a 25-skill pack. Each skill is
narrow and heavy-hitter compliant (≥250 LOC scripts, ≥2 reference
docs, 8-field SKILL.md frontmatter). This orchestrator routes
user intent to the right combination of narrow skills.
Cluster 5 + 6 are the v3 additions versus v2. Cluster 5 runs
BEFORE any scan and refuses to proceed if authorization is
missing or scope is malformed. Cluster 6 runs AFTER scans and
produces the deliverable artifacts (vulnerability report, OWASP
coverage report, executive summary, chain-of-custody archive).
Instructions
The orchestrator's job is intent routing — given a user utterance, decide which of the 25 narrow skills to invoke and in what order. Four steps:
Step 1 — Parse the user intent
Match the utterance against the intent-routing table below. The leftmost matching row determines the routing. If no exact match, default to the cluster-1-4 governance-first sequence and pare back based on context.
Step 2 — Run authorization-first
Before any cluster 1-4 scan invocation, run confirming-pentest-authorization. If it emits any CRITICAL finding, HALT — do not invoke any scan skill. The user must resolve the authorization issue before proceeding.
Step 3 — Run the matched skills in order
Invoke each skill from the routing-table row, in the listed order. Each skill emits its findings as JSON/JSONL/markdown via lib/report.py. Persist per-skill output into engagement/findings/<skill>-<date>.jsonl so the cluster 6 skills can consume them.
Step 4 — Compose deliverables
After scan skills complete, run cluster 6 in sequence: mapping-findings-to-owasp-top10, then composing-vulnerability-report, then generating-executive-summary, then recording-pentest-engagement for the chain-of-custody archive.
The v2 monolithic scripts (security_scanner.py,
dependency_auditor.py, code_security_scanner.py) remain in
scripts/ as the underlying engine for the original v2
invocation patterns. The v3 narrow skills re-implement and
extend that logic with the canonical lib/finding.py schema and
the shared lib/report.py output module.
If a downstream user has scripted invocations of the v2 scripts,
those still work. New work should use the narrow skills directly.
The orchestrator's old "Step 1 / Step 2 / Step 3" instructions
in v2 are subsumed by the intent-routing table above. The v2
checks correspond to:
Each skill emits a graceful INFO Finding when an optional
dependency is missing and falls back to a degraded but functional
mode where possible.
Authorization is non-negotiable
The orchestrator REFUSES to invoke cluster 1-4 skills until
confirming-pentest-authorization has emitted no CRITICAL or
HIGH findings against the ROE. The cost of running an authorized
scan is delay until the ROE is verified. The cost of running an
unauthorized scan is potential criminal liability under CFAA
(US), Computer Misuse Act (UK), or equivalent foreign statutes.
For details on the legal framework + ROE structure, see
confirming-pentest-authorization/references/THEORY.md.
Examples
Example 1 — Full engagement, end to end
User: "Run a full pentest on engagements/acme-2026-q2/"
The orchestrator delegates error handling to each invoked skill.
Cluster 5 errors (missing ROE, missing scope) HALT the engagement.
Cluster 1-4 errors (scanner missing, network unreachable) emit
INFO findings and continue. Cluster 6 errors (missing source
findings) emit HIGH operational findings and continue with a
partial deliverable.
Resources
references/OWASP_TOP_10.md — OWASP Top 10 risks (legacy v2
reference; the canonical OWASP table is now in
mapping-findings-to-owasp-top10/references/THEORY.md)
Per-skill THEORY.md + PLAYBOOK.md files under each
skills/<skill-name>/references/
v3.0.0 release notes
Released 2026-06-03. Major changes:
25 narrow heavy-hitter skills replace the v2 3-script monolith
New cluster 5 (engagement governance) and cluster 6 (reporting)
Canonical lib/finding.py + lib/report.py schema across all skills
disallowed-tools defense-in-depth for high-risk patterns (rm, curl, wget, .env edits)
v2 scripts (security_scanner.py, dependency_auditor.py,
code_security_scanner.py) preserved as backward-compatible
scripts under scripts/
Migration: existing v2 invocations continue to work. New work
should use the narrow skills directly. See the backward-compat
table above for the v2 → v3 mapping.
