Use when asked to orchestrate Shannon autonomous pentesting from Claude Code — configure target, launch scans, monitor progress, compare runs, export reports (PDF / SARIF / HTML), or generate remediation plans. Also handles companion-tool imports (Burp / ZAP / Nuclei / WPScan), workspace queries, scheduled scans, and SLA tracking. Bilingual Thai+English output mapped to OWASP, CVSS, MITRE ATT&CK. Triggers include "pentest", "security audit", "vulnerability scan", "ทดสอบเจาะระบบ", "สแกนช่องโหว...
Scanned 5/27/2026
Install via CLI
Skills Directoryopenskills install pitimon/shannon-pentest---
name: shannon-pentest
description: >
Use when asked to orchestrate Shannon autonomous pentesting from Claude Code —
configure target, launch scans, monitor progress, compare runs, export reports
(PDF / SARIF / HTML), or generate remediation plans. Also handles companion-tool
imports (Burp / ZAP / Nuclei / WPScan), workspace queries, scheduled scans, and
SLA tracking. Bilingual Thai+English output mapped to OWASP, CVSS, MITRE ATT&CK.
Triggers include "pentest", "security audit", "vulnerability scan",
"ทดสอบเจาะระบบ", "สแกนช่องโหว่", "compare findings", "Shannon report".
Full trigger list: skills/shannon-pentest/references/triggers.md
user-invocable: true
allowed-tools: Read, Grep, Glob, Bash, Write, AskUserQuestion
---
# Shannon Pentest — Autonomous Security Testing Orchestrator
สกิลสำหรับ orchestrate [Shannon autonomous pentester](https://github.com/KeygraphHQ/shannon) ผ่าน Claude Code — ตั้งค่า, รัน, ติดตามผล, และวิเคราะห์ report อัตโนมัติ
## นโยบายภาษา (Language Policy)
Output ทั้งหมดใช้ **Thai** เป็น prose หลัก พร้อม **English** สำหรับ technical terms:
- Thai สำหรับคำอธิบาย, ขั้นตอน, คำแนะนำ
- English สำหรับ tool names, commands, code, framework references
- ไม่แปลคำศัพท์เทคนิค เช่น pentest, CVSS, OWASP, exploit, payload
## Quick Decision Tree
เลือก route ตาม user intent:
| User Intent | Route |
| ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| "pentest" / "run Shannon" / "security audit" / "ทดสอบเจาะระบบ" | → Full Workflow (Phase 0→4) |
| "analyze report" / "findings" / "Shannon results" / "ผลการทดสอบ" | → Phase 4: Analyze only (parallel Read strategy) |
| "Shannon config" / "yaml config" / "auth setup" / "ตั้งค่า" | → Config Helper (load `references/config-templates-basic.md`) |
| "validate config" / "check yaml" / "ตรวจ config" | → Phase 2: Config Pre-Validation only |
| "docker error" / "temporal error" / "network error" / "แก้ปัญหา infra" | → Infra Troubleshooting (load `references/troubleshooting.md`) |
| "Shannon error" / "config error" / "API error" / "workspace fail" | → Shannon App Troubleshooting (load `references/troubleshooting-shannon.md`) |
| "Shannon stuck" / "workflow stall" / "ค้าง" / "ไม่เริ่ม" | → Workflow Stalling (load `references/troubleshooting-shannon.md`) |
| "monitor" / "logs" / "status" / "ติดตาม" | → Phase 3: Monitor (offer auto-monitor) |
| "export report" / "generate report" / "สร้าง report" / "deliverables" | → Phase 4 Step 5-6: Report Export & Evidence Packaging |
| "defensive docs" / "สร้างเอกสาร" / "handoff" / "defensive security" | → Phase 5: Defensive Handoff |
| "compare runs" / "diff findings" / "เทียบผล Shannon" | → Session Comparison (load `references/finding-comparison.md`) |
| "Shannon stats" / "history" / "สถิติ" / "ประวัติ" | → Session Analytics (load `references/session-analytics.md`) |
| "engagement" / "client info" / "ข้อมูลโครงการ" | → Engagement Setup (load `references/engagement-context.md`) |
| "export PDF" / "HTML report" / "สร้าง PDF" | → Multi-Format Export (load `references/multi-format-export.md`) |
| "SARIF" / "SARIF report" / "GitHub Security tab" | → SARIF Export (load `references/sarif-export.md`) |
| "create tickets" / "generate issues" / "Jira" / "สร้าง ticket" | → Issue Templates (load `references/issue-templates.md`) |
| "tag finding" / "mark false positive" / "แท็ก" / "remediation status" | → Finding Lifecycle (load `references/finding-lifecycle.md`) |
| "list workspaces" / "query workflow" / "รายการ workspace" | → CLI Workspace Manager |
| "inline defense" / "IR checklist" / "remediation plan" | → Phase 4.5: Inline Defense (load `references/inline-defense.md`) |
| "CI/CD" / "pipeline" / "schedule pentest" / "automated scan" | → CI/CD Integration (load `references/ci-cd-integration.md`) |
| "verify fix" / "retest finding" / "verification report" / "ยืนยันการแก้ไข" | → Remediation Verification (load `references/remediation-verification.md`) |
| "scan template" / "save config" / "load template" / "reuse config" | → Scan Templates (load `references/scan-templates.md`) |
| "suppress finding" / "whitelist" / "ignore finding" / "ซ่อน finding" | → Finding Suppression (load `references/finding-suppression.md`) |
| "correlate findings" / "group findings" / "root cause" / "blast radius" | → Finding Correlation (load `references/finding-correlation.md`) |
| "risk score" / "risk priority" / "business impact" / "risk-sorted" | → Risk Scoring (load `references/risk-scoring.md`) |
| "multi-target" / "campaign" / "scan multiple" / "batch pentest" | → Multi-Target Campaign (load `references/multi-target-campaign.md`) |
| "compliance report" / "SOC 2" / "PCI-DSS" / "HIPAA" / "GDPR" | → Compliance Frameworks (load `references/compliance-framework-reports.md`) |
| "metrics dashboard" / "MTTR" / "vulnerability density" / "security KPI" | → Security Metrics (load `references/security-metrics-dashboard.md`) |
| "assign owner" / "finding owner" / "SLA tracking" / "team assignment" | → Team Remediation (load `references/team-remediation-dashboard.md`) |
| "SLA gating" / "risk gating" / "campaign gating" / "cost planning" | → CI/CD Gating Strategies (load `references/ci-cd-gating-strategies.md`) |
| "risk posture" / "executive report" / "trend analysis" / "security trend" | → Executive Reporting (load `references/security-metrics-dashboard.md`) |
| "import findings" / "Burp import" / "ZAP import" / "Nuclei import" | → External Tool Import (load `references/external-tool-import.md`) |
| "notify" / "Slack alert" / "webhook" / "notification setup" | → Notification Hub (load `references/notification-hub.md`) |
| "schedule scan" / "recurring pentest" / "automated retest" / "cron scan" | → Scheduled Scanning (load `references/scheduled-scanning.md`) |
| "benchmark" / "historical trend" / "year-over-year" / "date range" | → Historical Benchmarking (load `references/historical-benchmarking.md`) |
| "dashboard" / "HTML dashboard" / "security dashboard" / "generate dashboard" | → Standalone Dashboard (load `references/standalone-dashboard.md`) |
| "companion tool" / "Kali tool" / "WPScan" / "WordPress scan" | → Companion Tools Overview (load `references/companion-tools-overview.md`) |
| "fingerprint" / "tech stack" / "CMS detect" / "WhatWeb" | → Tech Fingerprint (load `references/companion-tools-fingerprint.md`) |
| "NCSA" / "NCSA compliance" / "VTS" / "university scan" / "bulk WordPress" | → NCSA Compliance (load `references/companion-tools-ncsa.md`) |
| "XSStrike" / "XSS scan" / "JoomScan" / "Joomla scan" / "Drupal scan" | → CMS/XSS Scanners (load `references/companion-tools-scanners.md`) |
| "Colima" / "Temporal UI" / "port forward" / "8233 not working" | → Docker Runtime (load `references/docker-runtime-detection.md`) |
| "compare findings.json" / "external findings" / "validate coverage" | → External Findings Comparison (load `references/external-findings-comparison.md`) |
## กฎความปลอดภัย (Safety Rules) — MANDATORY
ปฏิบัติตามอย่างเคร่งครัดทุกครั้ง:
1. **NEVER run on production** — ใช้กับ staging/test environment เท่านั้น
2. **Written authorization required** — ต้อง confirm กับ user ว่าได้รับอนุญาตให้ทดสอบแล้ว
3. **Confirm target URL** — แสดง URL ให้ user ยืนยันก่อน launch ทุกครั้ง
4. **No credential storage** — ห้าม Write credentials ลง file ที่ไม่ได้อยู่ใน Shannon config directory
5. **Scope boundaries** — ทดสอบเฉพาะ target ที่ระบุ ห้ามขยาย scope โดยไม่ได้รับอนุญาต
ถ้า user ไม่ยืนยัน authorization → หยุดทันที พร้อมแนะนำให้ขออนุญาตก่อน
---
## CLI Workspace Manager
จัดการ Shannon workspaces โดยตรงจาก CLI:
```bash
# แสดง workspaces ทั้งหมด พร้อม status
cd "$SHANNON_DIR" && ./shannon workspaces
# Query specific workflow — ดู findings ของ workflow เฉพาะ
cd "$SHANNON_DIR" && ./shannon query ID=<workflow-id>
```
หลังแสดง workspace list → เสนอ options:
- **Resume existing** → ข้าม Phase 0-2 ไปที่ Phase 3 (Monitor) หรือ Phase 4 (Analyze) ตาม status (config already validated — ไม่ต้อง re-validate)
- **Start new** → เริ่ม Full Workflow ปกติ (Phase 0→)
| Workspace Status | Action |
| ---------------- | ---------------------------------- |
| `RUNNING` | → Phase 3: Monitor (auto-monitor) |
| `COMPLETED` | → Phase 4: Analyze (parallel Read) |
| `FAILED` | → Troubleshooting + offer new run |
---
## Phase 0: Setup (ตั้งค่าครั้งแรก)
ตรวจสอบ prerequisites ก่อนเริ่ม:
### Checklist
```bash
# 1. Docker installed and running
docker info > /dev/null 2>&1 && echo "✓ Docker running" || echo "✗ Docker not found"
# 1b. Docker runtime detection (Colima vs Docker Desktop)
# → อ่าน references/docker-runtime-detection.md สำหรับ Colima port forwarding workaround
# 2. Shannon repo exists
SHANNON_DIR="${SHANNON_DIR:-$HOME/shannon-tool}"
ls "$SHANNON_DIR/shannon" 2>/dev/null && echo "✓ Shannon found" || echo "✗ Shannon not found at $SHANNON_DIR"
# 3. .env configured
ls "$SHANNON_DIR/.env" 2>/dev/null && echo "✓ .env exists" || echo "✗ .env missing"
# 4. Shannon auto-update check (ถ้า repo มีอยู่แล้ว)
if [ -d "$SHANNON_DIR/.git" ]; then
cd "$SHANNON_DIR" && git fetch --quiet origin 2>/dev/null
LOCAL=$(git rev-parse HEAD 2>/dev/null)
REMOTE=$(git rev-parse origin/main 2>/dev/null || git rev-parse origin/master 2>/dev/null)
if [ "$LOCAL" = "$REMOTE" ]; then
echo "✓ Shannon is up to date"
else
BEHIND=$(git rev-list --count HEAD..origin/main 2>/dev/null || git rev-list --count HEAD..origin/master 2>/dev/null)
echo "⚠ Shannon is $BEHIND commits behind — auto-updating..."
git pull --ff-only 2>/dev/null && echo "✓ Shannon updated" || echo "✗ Auto-update failed (merge conflict?) — ดำเนินต่อด้วย version ปัจจุบัน"
# หยุด containers เก่าเพื่อ rebuild จาก code ใหม่
./shannon stop CLEAN=true 2>/dev/null || true
fi
fi
```
> Auto-update ใช้ `--ff-only` เพื่อความปลอดภัย — ถ้ามี local changes ที่ conflict จะข้ามแล้วแจ้ง user
> หลัง pull ต้อง `./shannon stop CLEAN=true` เสมอ เพราะ Docker containers cache old code
### ถ้ายังไม่มี Shannon
แนะนำ user:
```bash
git clone https://github.com/KeygraphHQ/shannon.git ~/shannon-tool
cd ~/shannon-tool
cp .env.example .env
```
### Auto-configure API Key จาก Claude Code Session
**ขั้นตอน (ทำอัตโนมัติ ไม่ต้องถาม user):**
> อ่าน `references/setup-automation.md` สำหรับ OAuth token extraction + `.env` configuration scripts
สรุป: อ่าน token จาก `~/.claude/.credentials.json` → เขียนลง `$SHANNON_DIR/.env` อัตโนมัติ
ถ้า auto-detect ไม่สำเร็จ → ถาม user ว่ามี `ANTHROPIC_API_KEY` หรือไม่
### AskUserQuestion
ถามก่อนไปต่อ:
1. Shannon directory path (default: `~/shannon-tool/`)
2. Docker running? (auto-detect ก่อน ถามถ้า detect ไม่ได้)
> **ไม่ต้องถามเรื่อง API key** — ใช้ OAuth token อัตโนมัติจาก Claude Code session
เก็บ `SHANNON_DIR` ไว้ใช้ทุก phase ที่เหลือ
---
## Phase 0.5: Engagement Context (ข้อมูลโครงการ — Optional)
> อ่าน `references/engagement-context.md` สำหรับ schema
ถาม user ด้วย AskUserQuestion:
> ต้องการตั้งค่าข้อมูลโครงการ (client, scope, authorization) สำหรับ report headers หรือไม่?
>
> - **Yes** — กรอกข้อมูล client name, project, scope, authorization ref
> - **Skip (Recommended for first run)** — ข้ามไปเลย ตั้งค่าทีหลังได้
ถ้า Yes → ถาม 4+3 คำถาม (client name, project/scope, authorization ref, assessment period + business context จาก `references/risk-scoring.md`) → Write `engagement.json` ลง `$SHANNON_DIR/.shannon-sessions/`
ถ้ามี `engagement.json` อยู่แล้ว → แสดงข้อมูลปัจจุบัน ถามว่าจะ update หรือใช้ต่อ
> ถ้า engagement ครอบคลุมหลาย targets → อ่าน `references/multi-target-campaign.md` สำหรับ campaign setup
---
## Phase 1: Configure (ตั้งค่า Target)
### AskUserQuestion — 4 คำถามหลัก
ถ้ามี scan templates บันทึกไว้ → เสนอโหลด template ก่อนถาม 4 คำถาม:
> อ่าน `references/scan-templates.md` สำหรับ load/save/list/delete operations
1. **Target URL** — URL ของ application ที่จะทดสอบ (e.g., `https://staging.example.com`)
2. **Repository name** — ชื่อ folder ใน `$SHANNON_DIR/repos/` ที่เก็บ source code (ถ้ามี — พิมพ์ "none" สำหรับ black-box assessment)
3. **Auth type** — เลือก: None / Form-based / OAuth / TOTP / API-only
4. **Workspace name** — ชื่อสำหรับ session นี้ (ใช้ resume ได้)
### Smart Target-Type Detection
> อ่าน `references/target-detection.md` สำหรับ web-only vs source-available detection, placeholder README, rules.focus
### Companion Tools (Optional — Phase 1.5)
> หลัง Phase 1 → เสนอ companion tools (WPScan, ffuf, testssl.sh) ผ่าน AskUserQuestion
> อ่าน `references/companion-tools-overview.md` สำหรับ tool catalog + `references/companion-tools-orchestration.md` สำหรับ Phase 1.5 workflow
### ถ้าเลือก Auth type ≠ None
**Auth type = None / Form / TOTP →** อ่าน `references/config-templates-basic.md`
**Auth type = SSO / OAuth / API-only →** อ่าน `references/config-templates-basic.md` + `references/config-templates-advanced.md`
Issue Read calls ใน **message เดียว** (Claude Code จะรัน parallel)
ถามเพิ่ม:
- **Form-based**: Login URL, username, password, success condition (URL หรือ content)
- **OAuth**: Provider, client_id, redirect_uri, scope
- **TOTP**: Login URL, credentials, TOTP shared secret
- **API-only**: Base URL, API key header name, API key value
### Generate Config
สร้าง YAML config file ตาม Shannon schema (`config-schema.json`):
> **สำคัญ:** Shannon ใช้ root keys: `authentication`, `rules`, `pipeline` เท่านั้น
> ห้ามใช้ keys อื่น เช่น `target`, `auth`, `scope`, `options` — จะ error ทันที
> ดู `references/config-templates-basic.md` สำหรับ config examples (no-auth, form-based, TOTP)
> ดู `references/config-templates-advanced.md` สำหรับ SSO, OAuth, API-only, scoped testing
แสดง config ให้ user review ก่อน proceed
---
## Phase 2: Launch (เริ่มทดสอบ)
### Config Pre-Validation
ก่อน launch ต้อง validate config file ทุกครั้ง — 3 ขั้นตอน:
1. **YAML syntax** — `yaml.safe_load()` check
2. **Root keys** — only `authentication`, `rules`, `pipeline` allowed
3. **Value types** — `max_concurrent_pipelines` must be string `"3"` not integer
> ดู `references/config-validation.md` สำหรับ validation scripts + common fixes
> **Token refresh:** OAuth token อัพเดทอัตโนมัติก่อน launch ทุกครั้ง — ดู `references/setup-automation.md` (Pre-Launch Token Refresh)
**ถ้า validation fail → แสดง error + fix suggestion, ห้าม proceed ไป Pre-flight Checks**
### Pre-flight Checks
> อ่าน `references/preflight-checks.md` สำหรับ 5-step pre-flight validation (Docker, repo, config, target, workspace)
### Safety Confirmation
**ก่อน launch ต้อง confirm กับ user เสมอ:**
> ⚠️ กำลังจะเริ่ม pentest:
>
> - Target: `${TARGET_URL}`
> - Workspace: `${WORKSPACE}`
> - Auth: `${AUTH_TYPE}`
>
> ยืนยันว่าได้รับอนุญาตให้ทดสอบ target นี้แล้ว? (Yes/No)
### Launch Command
```bash
cd "$SHANNON_DIR" && ./shannon start \
URL="${TARGET_URL}" \
REPO="${REPO_NAME}" \
CONFIG="./configs/${WORKSPACE}.yaml" \
WORKSPACE="${WORKSPACE}"
```
### Post-launch
แจ้ง user:
- Temporal UI: `http://localhost:8233`
- วิธีดู logs: `./shannon logs`
- วิธีหยุด: `./shannon stop`
---
## Phase 3: Monitor (ติดตามผล)
### เสนอ Auto-Monitor Mode
ถาม user ด้วย AskUserQuestion:
> Shannon กำลังทำงาน — ต้องการให้ auto-monitor หรือไม่?
>
> - **Yes (แนะนำ)** — polling อัตโนมัติทุก 2-5 นาที พร้อม progress indicator
> - **No** — แสดง manual commands ให้ดูเอง
### Auto-Monitor Mode (ถ้า user เลือก Yes)
> ดู `references/monitoring-guide.md` สำหรับ polling scripts ทั้งหมด
> ดู Agent Runtime & Cost Reference ใน `references/monitoring-guide.md` สำหรับค่าประมาณ runtime/cost ต่อ agent
รัน polling loop ทุก 2-5 นาที ตรวจสอบ 4 สิ่ง:
1. **Docker containers** — จำนวน running containers
2. **Log activity** — timestamp ของ log ล่าสุด
3. **summary.json** — completion signal (ถ้าพบ → auto-transition to Phase 4)
4. **Stall detection** — ถ้าไม่มี activity 10+ นาที → เตือน user + ดู `references/troubleshooting-shannon.md` (Workflow stalling section)
### Companion Tool Monitoring
> ถ้ามี companion tools running → poll status ควบคู่ Shannon monitoring
> ดู `references/companion-tools-orchestration.md` → Phase 3: Parallel Monitoring
### Manual Monitor Mode (ถ้า user เลือก No)
> ดู `references/monitoring-guide.md` สำหรับ manual monitoring commands
### Status Interpretation
| Status | ความหมาย |
| ----------- | ------------------------------------------- |
| `RUNNING` | กำลังทำงาน — รอจนเสร็จ หรือดู logs |
| `COMPLETED` | เสร็จสมบูรณ์ — ไปดู report ที่ Phase 4 |
| `FAILED` | ล้มเหลว — ดู logs + troubleshooting |
| `TIMED_OUT` | หมดเวลา — อาจต้องเพิ่ม timeout หรือลด scope |
| `CANCELLED` | ถูกยกเลิก — user หรือ system cancel |
---
## Phase 4: Analyze (วิเคราะห์ผล)
### ค้นหา Report
```bash
SHANNON_DIR="${SHANNON_DIR:-$HOME/shannon-tool}"
# List available reports
ls -la "$SHANNON_DIR/audit-logs/"
# Find latest report for target
ls -lt "$SHANNON_DIR/audit-logs/" | head -5
```
### อ่านและวิเคราะห์ (Parallel Strategy)
อ่าน `references/report-interpretation.md` + `references/report-templates.md` สำหรับ framework การวิเคราะห์
Issue Read calls ใน **message เดียว** (Claude Code จะรัน parallel) — skip `report-templates.md` ถ้า analyze-only (ไม่ต้อง export)
**ใช้ parallel Read เพื่อเร่งการวิเคราะห์ — ทำตาม 4 ขั้นตอนนี้:**
**Step 1: Inventory report files**
```bash
REPORT_DIR="$SHANNON_DIR/audit-logs/<latest-session>"
echo "=== Report Inventory ==="
ls "$REPORT_DIR/summary.json" 2>/dev/null && echo "✓ summary.json"
FINDING_COUNT=$(ls "$REPORT_DIR/findings/" 2>/dev/null | wc -l | tr -d ' ')
echo "Findings: $FINDING_COUNT files"
EVIDENCE_COUNT=$(find "$REPORT_DIR/evidence/" -type f 2>/dev/null | wc -l | tr -d ' ')
echo "Evidence: $EVIDENCE_COUNT files"
ls "$REPORT_DIR/timeline.json" 2>/dev/null && echo "✓ timeline.json"
```
**Step 2: Parallel Read — อ่านไฟล์หลักพร้อมกัน**
Issue Read calls ทั้งหมดใน **message เดียว** (Claude Code จะรัน parallel):
- `summary.json` — ภาพรวมผลลัพธ์
- `timeline.json` — ลำดับเวลาการทดสอบ
- ทุก `findings/finding-*.json` — รายละเอียด vulnerabilities
> **ถ้า findings > 20 ไฟล์** → อ่าน 2 batches:
>
> - Batch 1: summary.json + timeline.json + findings ที่เป็น Critical/High (ดูจาก summary ก่อน)
> - Batch 2: findings ที่เป็น Medium/Low
**Step 3: Evidence — อ่านเฉพาะ validated/critical findings**
อ่าน evidence (screenshots, requests) เฉพาะ findings ที่:
- PoC status = `validated`
- Severity = Critical หรือ High
ไม่ต้องอ่าน evidence ทั้งหมด — ประหยัด tokens
**Step 4: Integrate แล้วสร้าง report**
> ถ้ามี findings >= 3 → รัน finding correlation จาก `references/finding-correlation.md` + risk scoring จาก `references/risk-scoring.md`
> Issue Read calls ทั้ง 2 references ใน **message เดียว** (Claude Code จะรัน parallel)
> ถ้าเป็น campaign (multi-target) → สร้าง aggregate report: cross-target correlation + campaign-level risk score
> ถ้ามี imported findings จาก external tools → merge ก่อนสร้าง report (ดู `references/external-tool-import.md`)
> ถ้ามี companion tool output → parse + merge ผ่าน `references/companion-tools-parsers.md` → import pipeline
หลังจากได้ข้อมูลครบ → สร้าง report ตาม Output Format ด้านล่าง
### Output Format
สร้าง report ตามโครงสร้างใน `references/report-templates.md`:
- **Template 1** (Executive) — สรุป 1-2 หน้า: risk rating, top 3 risks, priority actions
- **Template 2** (Technical) — รายละเอียดทุก finding: CVSS, OWASP, PoC, remediation
- **Template 3** (Compliance) — 7 frameworks (ดู `references/compliance-framework-reports.md`)
> ดู `references/security-metrics-dashboard.md` สำหรับ risk posture score + executive trend summary
| Severity | CVSS Range | Priority |
| -------- | ---------- | -------- |
| Critical | 9.0-10.0 | P0 |
| High | 7.0-8.9 | P1 |
| Medium | 4.0-6.9 | P2 |
| Low | 0.1-3.9 | P3 |
| Info | N/A | — |
### Step 5: Export Report (สร้าง Standalone Report File)
อ่าน `references/report-templates.md` แล้วทำตาม:
1. ถาม user — เลือกรูปแบบ: Executive / Technical / Compliance / All
2. เลือก export format: Markdown (default) / PDF / SARIF / HTML / All
3. สร้าง `audit-logs/<session>/deliverables/` directory
4. Write report file(s) ตาม template — populate จาก Step 1-4
5. Sanitize config (ลบ credentials/tokens) ก่อนใส่ report
> ดู `references/multi-format-export.md` สำหรับ PDF/HTML export pipeline
> ดู `references/sarif-export.md` สำหรับ SARIF v2.1.0 export + GitHub upload
> ถ้าเลือก "All" หรือ PDF+SARIF → Issue Read calls ใน **message เดียว** (Claude Code จะรัน parallel)
### Step 6: Evidence Packaging (สร้าง Archive)
สร้าง deliverables archive ตาม `references/evidence-packaging.md`:
1. สร้าง `evidence/finding-NNN/` directories — เขียน `description.md` + `poc-request-response.txt`
2. สร้าง `package-manifest.json` พร้อม SHA-256 checksums
3. สร้าง tar.gz archive
### Step 7: Session Registry (บันทึกประวัติ)
> อ่าน `references/session-management.md` + `references/finding-lifecycle.md` พร้อมกัน
> Issue Read calls ใน **message เดียว** (Claude Code จะรัน parallel) — ทั้ง 2 ไฟล์ independent กัน (~2,541 words combined)
หลัง analysis เสร็จ → บันทึก session อัตโนมัติ:
1. สร้าง/อ่าน `$SHANNON_DIR/.shannon-sessions/registry.json`
2. Append session record: workspace, target, duration, cost, findings breakdown, finding titles
3. Update target aggregation: first/last tested, session count, cumulative findings
4. ถ้ามี engagement.json → link session กับ engagement context
5. แสดงสรุป: "Session recorded — [N] total sessions for [target]"
ถ้า target มี session ก่อนหน้า → เสนอ finding comparison อัตโนมัติ:
> พบ session ก่อนหน้าสำหรับ target นี้ — ต้องการเปรียบเทียบ findings หรือไม่?
ถ้า Yes → รัน comparison logic จาก `references/finding-comparison.md` แสดง diff table (new/resolved/persistent)
> ถ้ามี notifications config ใน engagement.json → auto-trigger notification (ดู `references/notification-hub.md`)
> เสนอ: สร้าง HTML dashboard (ดู `references/standalone-dashboard.md`) หรือ historical benchmarking (ดู `references/historical-benchmarking.md`)
### Step 8: Finding Lifecycle (แท็กสถานะ findings)
หลัง session registry append → เสนอ finding tagging:
1. ถาม user ด้วย AskUserQuestion multiSelect: เลือก findings ที่ต้องการ tag
2. สำหรับแต่ละ finding ที่เลือก → ถามสถานะ: `confirmed`, `false_positive`, `accepted_risk`, `pending_fix`
3. บันทึก `finding_statuses` ลง registry.json → ใช้ใน comparison runs ถัดไป
4. Cross-run tracking: `remediated` + reappears → flag regression, `false_positive` + reappears → skip
> ดู `references/finding-lifecycle.md` สำหรับ status tags, transition rules, และ remediation status report
> ถ้าต้องการ assign owner + SLA deadline → อ่าน `references/team-remediation-dashboard.md`
ถ้ามี findings ที่ tagged `remediated` หรือ `pending_fix` → เสนอ verification retest:
> อ่าน `references/remediation-verification.md` สำหรับ targeted retest, before/after evidence, และ verification report
ถ้า user tag `false_positive` หรือ `accepted_risk` → เสนอเพิ่มลง whitelist:
> อ่าน `references/finding-suppression.md` สำหรับ cross-session whitelist management
---
## Phase 4.5: Inline Defensive Summary (สรุป Defensive แบบ Lightweight)
Auto-trigger หลัง Phase 4 analysis เมื่อพบ Critical/High findings:
ถ้าไม่พบ Critical/High → ข้าม Phase 4.5, ไป Phase 5 หรือจบ (Medium/Low ไม่ trigger inline defense)
1. ถาม user ด้วย AskUserQuestion: สร้าง inline defensive summary หรือข้าม?
- **สร้าง Inline Defense** → อ่าน `references/inline-defense.md` สร้าง:
- IR checklist (10 items ตาม severity)
- Remediation skeleton (OWASP → fix pattern per finding)
- Compliance quick-map (OWASP Top 10 + NIST 800-53 top 5)
- **ข้ามไป Phase 5** → handoff ไป cybersecurity-pro แทน (full enterprise coverage)
- **ข้าม** → จบที่ Phase 4
2. Output ลง `deliverables/inline-defense/` — 3 files
3. ไม่ต้องการ cybersecurity-pro — เป็น lightweight version สำหรับ quick wins
---
## Phase 5: Defensive Handoff (สร้างเอกสาร Defensive Security)
> อ่าน `references/defensive-handoff.md` สำหรับ manifest schema, document selection matrix, และ user confirmation flow
> ไฟล์นี้มี manifest + prompt generation + clipboard copy ครบ — ไม่ต้อง load reference เพิ่ม (session files / evidence-packaging.md อ่านไปแล้วใน Phase 4 Step 6)
### Trigger
Phase 5 เริ่มทำงานหลัง Phase 4 เสร็จ — ถาม user ผ่าน AskUserQuestion ก่อน proceed
### ขั้นตอน
1. **Pre-check**: ตรวจสอบว่า cybersecurity-pro ติดตั้งอยู่หรือไม่
- `ls ~/.claude/plugins/cache/pitimon-cybersecurity/ 2>/dev/null`
- ถ้าไม่พบ → แสดง install instructions, จบที่ Phase 4
2. **วิเคราะห์ severity** distribution จาก Phase 4 findings
3. **ถาม user** ด้วย AskUserQuestion (ดู template ใน `references/defensive-handoff.md`)
4. ถ้า user confirm → **เขียน `handoff-manifest.json`** ลง `audit-logs/<session>/handoff/`
5. **สร้าง handoff prompt + clipboard copy** — ดู `references/defensive-handoff.md` Steps 4-5:
- Write `handoff-prompt.txt` ลง `audit-logs/<session>/handoff/`
- Auto-copy to clipboard (`pbcopy`/`xclip`), fallback แสดง file path
6. **แจ้ง user** → paste prompt ใน Claude Code เพื่อเริ่ม cybersecurity-pro
---
## Reference Files
อ่าน reference files ตามความต้องการ — อย่าโหลดทั้งหมดพร้อมกัน:
| File | เมื่อไหร่ต้องอ่าน |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| `references/config-templates-basic.md` | Phase 1: Auth = None / Form / TOTP (~900 tokens) |
| `references/config-templates-advanced.md` | Phase 1: Auth = SSO / OAuth / API-only (โหลดเพิ่มเมื่อจำเป็น) |
| `references/config-validation.md` | Phase 2: Config pre-validation scripts + common fixes |
| `references/monitoring-guide.md` | Phase 3: Auto-monitor polling scripts + stall detection |
| `references/report-interpretation.md` | Phase 4: เมื่อวิเคราะห์ report |
| `references/report-templates.md` | Phase 4 Step 5: Export report (3 templates) |
| `references/multi-format-export.md` | Phase 4 Step 5: PDF/HTML export pipeline |
| `references/sarif-export.md` | Phase 4 Step 5: SARIF v2.1.0 export + GitHub upload pipeline |
| `references/issue-templates.md` | Phase 4: Finding → GitHub/Jira issue template generation |
| `references/finding-lifecycle.md` | Phase 4 Step 8: Finding status tags, transitions, tracking |
| `references/inline-defense.md` | Phase 4.5: IR checklist, remediation skeleton, compliance map |
| `references/defensive-handoff.md` | Phase 5: Defensive handoff logic + manifest schema |
| `references/session-management.md` | Session registry, auto-append logic (Phase 4 Step 7) |
| `references/finding-comparison.md` | Finding comparison diff between sessions |
| `references/session-analytics.md` | Session analytics: cost estimation + basic stats (metrics: security-metrics-dashboard.md) |
| `references/engagement-context.md` | Engagement context: client, project, scope |
| `references/ci-cd-integration.md` | CI/CD severity gating policy (basic) — advanced: ci-cd-gating-strategies.md |
| `references/ci-cd-templates.md` | GitHub Actions + GitLab CI YAML pipeline templates |
| `references/evidence-packaging.md` | Evidence archive directory structure + manifest schema |
| `references/remediation-verification.md` | Targeted retest, before/after evidence, verification report |
| `references/scan-templates.md` | Phase 1: Save/load reusable scan profiles |
| `references/finding-suppression.md` | Phase 4 Step 8: Cross-session finding whitelist management |
| `references/finding-correlation.md` | Phase 4 Step 4: Root cause grouping, endpoint proximity, OWASP correlation |
| `references/risk-scoring.md` | Phase 4 Step 4: Custom risk scoring (CVSS+Exploit+BizImpact formula) |
| `references/multi-target-campaign.md` | Campaign orchestration: multi-target sequential scanning + aggregate analysis |
| `references/compliance-framework-reports.md` | Phase 4 Step 5: Compliance reports (OWASP/NIST/ISO/SOC2/PCI-DSS/HIPAA/GDPR) |
| `references/ci-cd-gating-strategies.md` | CI/CD advanced gating: risk score, campaign, SLA, lifecycle, cost planning |
| `references/team-remediation-dashboard.md` | Enterprise workflow: finding ownership, SLA tracking, audit trail, dashboard |
| `references/security-metrics-dashboard.md` | Security KPIs: MTTR, density, cost, risk posture score, executive trend |
| `references/setup-automation.md` | Phase 0 OAuth token extraction + .env configuration |
| `references/target-detection.md` | Phase 1: Smart web-only vs source-available detection + placeholder README |
| `references/preflight-checks.md` | Phase 2: 5-step pre-flight validation (Docker, repo, config, target, workspace) |
| `references/external-tool-import.md` | Import findings from Burp Suite, OWASP ZAP, Nuclei, SARIF into registry |
| `references/notification-hub.md` | Webhook notifications: Slack, Discord, email, generic webhook for scan events |
| `references/scheduled-scanning.md` | Automated recurring scans: cron, GitHub Actions, LaunchAgent, systemd timer |
| `references/historical-benchmarking.md` | Date-range queries, target trends, cross-target comparison, trend forecasting |
| `references/standalone-dashboard.md` | Self-contained HTML dashboard: risk posture, severity chart, trends, SLA status |
| `references/companion-tools-overview.md` | Phase 1.5: Tool catalog, concurrency groups, Docker images, safety classification |
| `references/companion-tools-fingerprint.md` | Phase 1.5: WhatWeb fingerprint, CMS detection, scanner routing |
| `references/companion-tools-scanners.md` | Phase 1.5: Docker commands for all companion tools (WPScan/ffuf/testssl/SQLMap/Nikto/XSStrike/JoomScan) |
| `references/companion-tools-parsers.md` | Phase 4: Python parsers for companion tools → Shannon schema normalization |
| `references/companion-tools-safety.md` | Phase 1.5: Rate limiting, scope enforcement, destructive tool gates |
| `references/companion-tools-orchestration.md` | Phase 1.5/3/4: Workflow orchestration, parallel monitoring, finding merge |
| `references/companion-tools-ncsa.md` | NCSA compliance mapping, control-to-tool matrix, VTS bulk WordPress template |
| `references/docker-runtime-detection.md` | Phase 0: Colima vs Docker Desktop detection, port forwarding workaround |
| `references/external-findings-comparison.md` | Phase 4: Compare Shannon findings with external findings.json for coverage analysis |
| `references/troubleshooting.md` | เมื่อเจอ Docker, Temporal, Network, Platform errors |
| `references/troubleshooting-shannon.md` | เมื่อเจอ Shannon app, config, API, workspace errors |
| `references/triggers.md` | Full activation trigger keyword list (moved out of `description:` to fit CC 1536 cap — Issue #51) |
No comments yet. Be the first to comment!
