| name | using-perseus |
| description | Use when starting a security conversation to understand the Perseus methodology |
Using Perseus
Overview
Perseus is a rigorous, automated security assessment framework for Claude Code. It transforms the AI into a structured penetration tester.
Core Principle: Methodological rigor over ad-hoc guessing. We do not "look around"; we execute specific phases.
The Workflow
The assessment MUST follow this linear sequence. Do not skip phases.
Phase 1: Reconnaissance (/scan)
Goal: Map the attack surface.
- Action: Run
Skill: perseus:scan (or /scan).
- Output:
deliverables/code_analysis_deliverable.md (Target Knowledge Graph).
- Stop Condition: Do not proceed until you know what to attack.
Phase 2: Vulnerability Analysis (Audit)
Goal: Prove potential vulnerability.
- Action: Run
Skill: perseus:audit.
- Logic: Launch 5 parallel specialists (Injection, XSS, Auth, Authz, SSRF).
- Method: "Negative Analysis" (Source -> Flow -> Sink -> Defense -> Verdict).
- Output: Specialized reports in
deliverables/.
Phase 3: Exploitation (Exploit)
Goal: Verify impact (False Positive Filtering).
- Action: Run
Skill: perseus:exploit.
- Safety: Use SAFE payloads only (
whoami, alert(1), sleep).
- Output: Verified proofs in
deliverables/exploitation_report.md.
Phase 4: Reporting (/report)
Goal: Communicate risk.
- Action: Run
Skill: perseus:report (or /report).
- Output: Final
SECURITY_REPORT.md with executive summary and risk scoring.
Optional: Specialists (/specialist)
Goal: Run all deep-dive specialists in parallel.
- Action: Run
Skill: perseus-specialist (or /specialist).
Engagement Modes
Always select engagement mode before Phase 1. If user does not specify, default to PRODUCTION_SAFE.
| Mode | Intended Environment | Verification Style |
|---|
PRODUCTION_SAFE | Live production | Passive analysis + minimal non-disruptive verification |
STAGING_ACTIVE | Staging/pre-prod | Targeted active verification with throttling |
LAB_FULL | Isolated lab | Full dynamic verification for hard-to-reproduce findings |
LAB_RED_TEAM | Dedicated security lab | Adversarial chain simulation with strict legal scope |
Mode selection rule:
- If environment is unclear, assume production and use
PRODUCTION_SAFE.
- If user requests aggressive testing, require explicit confirmation that target is staging/lab and authorized.
- Record chosen mode in deliverables so report consumers understand test depth.
Critical Rules
- No Hallucinations: Only report vulnerabilities you have verified via Audit or Exploit.
- Safe Mode: Never execute destructive commands (e.g.,
rm, DROP TABLE).
- Evidence-Based: Every finding must cite a specific File:Line or HTTP Request/Response.
- Authorization Gate: Do not run active exploit validation on production without explicit approved test window.
- Stability First: Keep verification low-rate and stop immediately if service degradation appears.
- Lab Isolation for Red-Team Mode:
LAB_RED_TEAM only on isolated test environment with non-production data.
How to Start
If the user asks for a security review, pentest, or audit, ALWAYS start with:
I will use the Perseus methodology to assess this codebase.
Starting Phase 1: Reconnaissance...
[Invoking /scan]
