/pentest

name: pentest
description: Activate pentest mode — displays ASCII art, configures session isolation, collects engagement scope, then OWNS the engagement: pre-flight, recon, planning (via the pentester-orchestrator planner), executor dispatch, a time-budget quota loop, aggregation, and report generation.
disable-model-invocation: true
allowed-tools:
  - AskUserQuestion
  - Read
  - Write
  - Task
  - TaskOutput
  - Bash
  - Glob
  - Grep

Output the following ASCII art banner verbatim:

======================================================
|                                                    |
|   ____  _____ _   _ _____ _____ ____ _____        |
|  |  _ \| ____| \ | |_   _| ____/ ___|_   _|      |
|  | |_) |  _| |  \| | | | |  _| \___ \ | |        |
|  |  __/| |___| |\  | | | | |___ ___) || |        |
|  |_|   |_____|_| \_| |_| |_____|____/ |_|        |
|                                                    |
|            M O D E   A C T I V A T E D            |
|                                                    |
======================================================
root@claude:~# [INITIALIZING PENTEST ENVIRONMENT...]
root@claude:~# [READY]

Step 1 — Isolation

Use AskUserQuestion to ask the user:

"Do you want to isolate this session to the pentest plugin only? (Recommended — prevents other plugins interfering with your engagement)"

Present exactly these two options:

• "Yes — isolate me (recommended)"
• "No — keep all plugins active"

If the user selects "Yes — isolate me (recommended)", output the following instruction block verbatim into the conversation:

============================================================
[PENTEST MODE — ISOLATION ACTIVE]

For this session, you MUST operate under these constraints:
- Only invoke agents from the pentest plugin (agents/ directory)
- Only mount skills from the pentest plugin (skills/ directory)
- Ignore agents and skills from all other plugins
- Do not switch to general-purpose tools or non-pentest workflows
- This constraint is active until /pentest:pentest-exit is run or /clear resets the session
============================================================

If the user selects "No — keep all plugins active", output:

Session running with all plugins active. You can still use /pentest:pentest-exit to close the engagement.

Step 2 — Scope Check

Try to Read `.pentest-scope.json`.

**If the file exists and is valid JSON**, extract `target`, `engagement`, `out_of_scope`, `auth`, `timing`, `thoroughness`, and `output_formats` (an array; default to `[]` if absent). For backward compatibility with older scope files: if `timing` is absent but a legacy `window` field is present, use `window` as `timing`. Output this block with real values:

============================================================
PRE-DEFINED SCOPE FOUND
============================================================
Target:       {target}
Engagement:   {engagement}
Out-of-scope: {out_of_scope}
Auth:         {auth}
Time budget:  {timing}
Thoroughness: {thoroughness}
Deliverables: report.md + pentest-report.json{, plus output_formats if any}
============================================================

Then use AskUserQuestion to ask:

"A pre-defined scope was found. How do you want to proceed?"

Present exactly these options:

• "Use pre-defined scope — proceed with the scope above (Recommended)"
• "Enter new scope — ignore pre-defined scope and collect scope now"

If the user selects "Use pre-defined scope":

• Set `target`, `engagement`, `out_of_scope`, `auth`, `timing`, `thoroughness`, `output_formats` from the file.
• Update `.pentest-scope.json` — change the `"status"` field to `"active"` while keeping all other fields identical (drop any legacy `window` field; write `timing` instead).
• Skip directly to Step 3 (Attack Profile).

If the user selects "Enter new scope" OR the file does not exist, collect the scope below.

**Free-text fields — ask each as a plain prompt, NOT via AskUserQuestion.** These accept arbitrary values (real targets are rarely `localhost`), so output the question and wait for the user's typed reply. Ask one at a time, in order:

1. **Target** — "Target URL / IP range — what is the target? (e.g., https://example.com, 10.0.0.81:3000, 192.168.1.0/24)" → `target` 2. **Engagement name** — "Engagement name — what should this engagement be called? (used as the outputs/{name}/ folder, e.g., example-com-2026-06)" → `engagement` 3. **Scope restrictions** — "Out-of-scope — any paths, subdomains, or services to exclude? (e.g., /admin, staging.example.com — or 'none')" → `out_of_scope` 4. **Time budget** — "Time budget — how long should active testing run? This is the QUOTA the engagement will spend (not just a ceiling), excluding report generation. (e.g., 30min, 2h, 8h, until 2026-06-20, or 'unlimited')" → `timing` 5. **Authentication** — "Authentication — are credentials available for authenticated testing? (no — or provide username:password / token)" → `auth`

> This single Time-budget question replaces the previous redundant "testing window" + "max execution time" pair. There is one time concept now: the quota.

Then use AskUserQuestion (genuine multiple choice) to ask thoroughness:

"Thoroughness — How deep should testing go? This affects which attack vectors are tested and how many payloads are attempted per category. (If it exceeds the time budget, the engagement runs breadth-first and reports the effective level.)"

Present exactly these options:

• "Light — surface-level scanning, automated tools only, fast coverage"
• "Medium — standard coverage, common attack paths, mix of automated and manual (Recommended)"
• "Deep — thorough manual testing, complex attack chains, edge cases explored"
• "Full — exhaustive testing, all payloads and vectors, maximum coverage (slowest)"

Store as `thoroughness`.

Then use AskUserQuestion with **multiSelect: true** to ask deliverable formats:

"Deliverable formats — which report art