rtexit-method 0.1.0 → 0.1.1

package/packaged-assets/.agents/skills/rt-attack-chain-builder/SKILL.md

@@ -0,0 +1,476 @@
+---
+name: rt-attack-chain-builder
+description: "Build multi-step attack chains by connecting individual findings into kill chain narratives. Shows how finding A enables finding B enables finding C leading to critical impact. Creates Mermaid flow diagrams and maps each step to MITRE ATT&CK technique. Used in technical report attack chain section and executive narrative."
+---
+
+# rt-attack-chain-builder
+
+## 1. Purpose and When to Use
+
+The attack chain builder is distinct from the kill chain map. The **kill chain map** (`rt-kill-chain-map`) organizes findings into the seven Lockheed Martin phases as a high-level executive artifact. The **attack chain builder** constructs granular, multi-step dependency chains — it proves causality: finding A made finding B possible; finding B exposed the credential that enabled finding C; finding C resulted in the critical impact. This is the technical analyst's tool, not the executive's diagram.
+
+Use this skill when:
+
+- You need to demonstrate that a finding chain represents a complete exploit path, not isolated issues
+- The technical report section on attack chains requires a step-by-step dependency narrative
+- The client's blue team needs to understand exactly which remediations break which attack paths
+- Multiple concurrent chains exist (e.g., one through the web application, one through VPN, one through a compromised contractor laptop) and you need to document each separately
+- You want to show how a LOW finding, when chained with a MEDIUM finding, produces a CRITICAL business impact
+
+**This skill is not for:**
+- Organizing findings by kill chain phase (use `rt-kill-chain-map`)
+- Mapping to ATT&CK tactic coverage breadth (use `rt-mitre-map`)
+- Writing narrative prose for executives without technical diagrams (use `rt-executive-report`)
+
+**Output file:** `_rtexit-output/docs/attack-chains/chain-[CHAIN-ID].md`
+
+**When to run in the engagement lifecycle:**
+
+```
+Recon → Exploitation → Post-Exploitation
+                             ↓
+                   rt-attack-chain-builder
+                             ↓
+            rt-kill-chain-map  +  rt-technical-report
+```
+
+Run after all findings for a given attack path are confirmed in `findings-master.csv`. Never build chains from unconfirmed findings.
+
+---
+
+## 2. Step-by-Step Workflow
+
+### Step 1 — Identify Attack Chain Candidates
+
+Pull all confirmed findings and look for dependency relationships:
+
+```bash
+python3 _rtexit/scripts/finding_tracker.py list --status CONFIRMED
+python3 _rtexit/scripts/finding_tracker.py export --format csv
+```
+
+A dependency relationship exists when:
+- One finding exposes credentials or tokens consumed by a later finding
+- One finding grants network access that makes a later finding reachable
+- One finding leaks architectural information (endpoint, version, internal hostname) that enables a later attack
+- One finding reduces the difficulty of a later exploit (e.g., verbose errors exposing stack trace that simplifies SQLi development)
+
+Group candidate findings into chains. Name each chain with a short label (e.g., `CHAIN-01-Jenkins-to-S3`, `CHAIN-02-IDOR-to-PII`).
+
+**Example finding set for analysis:**
+
+```
+ID      SEVERITY   TITLE                                    MITRE
+F-001   INFO       Subdomain Enum via CT Logs               T1596.003
+F-002   MEDIUM     Swagger UI Exposed on dev-api            T1592
+F-003   LOW        Verbose Error Messages — Django Debug    T1592.002
+F-004   HIGH       IDOR in /api/v1/invoices                 T1212
+F-005   CRITICAL   SQL Injection in /api/v1/search          T1190
+F-006   HIGH       Plaintext DB Password in Error Response  T1552
+F-007   CRITICAL   Full DB Dump via SQLi — 800K Records     T1005
+```
+
+From this set, two chains emerge:
+
+- **CHAIN-01:** F-001 → F-002 → F-005 → F-007 (Recon → API discovery → SQLi → Data exfiltration)
+- **CHAIN-02:** F-002 → F-003 → F-006 → F-004 (API schema → Debug info → Credential leak → IDOR exploitation)
+
+### Step 2 — Define the Chain Step Table
+
+For each chain, produce a dependency table. Every row is a step. The `Enables` column explicitly states what the previous finding provided that made this step possible.
+
+**CHAIN-01 example:**
+
+| Step | Finding | Technique | What the Attacker Gained | Enables Next Step |
+|------|---------|-----------|--------------------------|-------------------|
+| 1 | F-001 — Subdomain Enum via CT Logs | T1596.003 | Discovered `dev-api.acmecorp.com` and `jenkins.acmecorp.com` — 47 subdomains total | Knowledge of the API subdomain directs step 2 |
+| 2 | F-002 — Swagger UI on dev-api | T1592 | Obtained full API schema: all 23 endpoints, parameter names, expected types, authentication model | Endpoint `/api/v1/search` identified as accepting unconstrained string input |
+| 3 | F-005 — SQL Injection in /api/v1/search | T1190 | Blind time-based SQLi confirmed; automated with sqlmap to extract database schema | Database name `acme_prod`, table `customers` identified; dump possible |
+| 4 | F-007 — Full DB Dump — 800K Records | T1005 | Complete dump of `customers` table: full names, email addresses, bcrypt hashes, payment card last-4 digits | Terminal impact — chain complete |
+
+**Rules for the table:**
+- Use real finding IDs and real titles — no paraphrase
+- The `Technique` column must contain a valid ATT&CK technique ID, cross-referenced with `findings-master.csv`
+- The `Enables Next Step` column must be a causal statement, not a description ("Endpoint discovered" is description; "Endpoint discovery directs focus to `/api/v1/search` as the injection candidate" is causation)
+- If a finding in the chain was exploited in multiple ways, split the chain at that point and document both branches
+
+### Step 3 — Identify the Chain's Critical Dependency (Pivot Point)
+
+Every multi-step chain has one step that is the highest-leverage defensive intervention — the pivot point. If the attacker cannot complete this step, the chain collapses entirely.
+
+Identify the pivot by asking: "If we removed this finding, which steps downstream would become impossible (not just harder)?"
+
+Document the pivot:
+
+```
+CHAIN-01 PIVOT POINT: Step 2 (F-002 — Swagger UI Exposed)
+
+Rationale: Without the API schema, the attacker cannot identify /api/v1/search
+as an injection candidate. The endpoint exists but is not guessable from the
+domain structure alone. Removing the Swagger UI exposure collapses steps 3 and
+4 even if the SQL injection vulnerability remains unremediated.
+
+Remediation priority implication: F-002 (MEDIUM severity) has higher chain
+disruption value than F-005 (CRITICAL severity). Remediation sequencing should
+address F-002 first despite its lower standalone CVSS score.
+```
+
+This is one of the most operationally valuable outputs of this skill. It reframes remediation priority away from CVSS score alone and toward chain disruption value.
+
+### Step 4 — Generate the Mermaid Chain Diagram
+
+Produce a Mermaid flowchart showing the dependency chain. Use top-to-bottom flow. Findings are nodes; edges show what each step grants. Color-code by severity.
+
+**Standard template for a single chain:**
+
+````markdown
+```mermaid
+flowchart TD
+    F001["F-001 · INFO
+    Subdomain Enumeration
+    T1596.003
+    Discovers dev-api.acmecorp.com"]
+
+    F002["F-002 · MEDIUM
+    Swagger UI Exposed
+    T1592
+    Full API schema — 23 endpoints"]
+
+    F005["F-005 · CRITICAL
+    SQL Injection /api/v1/search
+    T1190
+    DB schema extracted via sqlmap"]
+
+    F007["F-007 · CRITICAL
+    Full DB Dump — 800K Records
+    T1005
+    customer names, emails, card data"]
+
+    PIVOT[/"PIVOT: Remove Swagger UI
+    → Chain collapses at Step 2"/]
+
+    F001 -->|"Reveals dev-api subdomain"| F002
+    F002 -->|"Exposes /api/v1/search endpoint\nwith parameter types"| F005
+    F005 -->|"DB schema reveals customers table"| F007
+
+    F002 -.->|"Highest disruption value"| PIVOT
+
+    style F001 fill:#1a3a1a,stroke:#4a8a4a,color:#fff
+    style F002 fill:#2d2d1b,stroke:#8b8b2c,color:#fff
+    style F005 fill:#3d0000,stroke:#cc0000,color:#fff
+    style F007 fill:#3d0000,stroke:#ff0000,color:#fff
+    style PIVOT fill:#0a3d0a,stroke:#00cc00,color:#fff
+```
+````
+
+**Color convention:**
+- INFO findings: dark green `#1a3a1a`
+- LOW findings: dark grey `#1a1a2e`
+- MEDIUM findings: dark yellow `#2d2d1b`
+- HIGH findings: dark orange `#3d1a00`
+- CRITICAL findings: dark red `#3d0000`
+- Pivot point node: green `#0a3d0a`
+- Final impact node (last step): brightest red `#ff0000` border
+
+**For multi-branch chains**, use `flowchart TD` with branching paths:
+
+````markdown
+```mermaid
+flowchart TD
+    F002["F-002 · MEDIUM
+    Swagger UI — API Schema"]
+
+    F003["F-003 · LOW
+    Django Debug Mode Active"]
+
+    F005["F-005 · CRITICAL
+    SQL Injection /api/v1/search"]
+
+    F004["F-004 · HIGH
+    IDOR /api/v1/invoices"]
+
+    F006["F-006 · HIGH
+    Plaintext DB Password\nin Error Response"]
+
+    F007["F-007 · CRITICAL
+    DB Dump — 800K Records"]
+
+    F002 -->|"CHAIN-01: Endpoint discovery"| F005
+    F005 -->|"CHAIN-01: Schema dump"| F007
+
+    F002 -->|"CHAIN-02: Auth schema exposed"| F003
+    F003 -->|"CHAIN-02: Error reveals DB password"| F006
+    F006 -->|"CHAIN-02: Credential enables auth bypass"| F004
+```
+````
+
+### Step 5 — Map Each Step to MITRE ATT&CK
+
+For each step in the chain, produce the full ATT&CK annotation. This is more detailed than the chain table — it confirms the technique is correctly classified and provides the reference a SOC or purple team needs.
+
+**Format:**
+
+```
+Step 2 — F-002: Swagger UI Exposed on dev-api.acmecorp.com
+
+  Tactic:    TA0043 — Reconnaissance
+  Technique: T1592 — Gather Victim Host Information
+  Sub-technique: T1592.002 — Software (API documentation exposure)
+
+  Why this technique: The attacker passively retrieved the OpenAPI/Swagger
+  specification from an unauthenticated endpoint. No active exploitation
+  occurred at this step — the information was intentionally published but
+  inadvertently accessible to unauthenticated external parties.
+
+  Detection opportunity: Web server access logs will show GET requests to
+  /swagger-ui/, /api-docs, /openapi.json, or /v2/api-docs from external IPs.
+  A single request retrieving the full schema is sufficient for the attacker —
+  this is a single-event signal, not a pattern signal.
+
+  ATT&CK reference: https://attack.mitre.org/techniques/T1592/002/
+```
+
+Verify each technique ID is current. Use ATT&CK v15 or later. If a finding maps to a deprecated technique, note the current replacement.
+
+Run `rt-mitre-map` before this skill if MITRE annotations are absent from `findings-master.csv` — do not duplicate that work here; reference the output.
+
+### Step 6 — Write the Chain Narrative (Technical Register)
+
+The chain narrative is written for technical readers: SOC analysts, system owners, and architects who will implement the remediations. Unlike the executive narrative in `rt-kill-chain-map`, this narrative uses technical terminology and includes specific artifacts.
+
+**Target length:** 300–500 words per chain.
+
+**Structure:**
+1. Opening sentence: state the starting condition and the terminal impact
+2. Step-by-step walkthrough referencing finding IDs
+3. Pivot point callout
+4. Remediation sequencing recommendation
+
+**Example narrative for CHAIN-01:**
+
+> The attack chain began with passive external reconnaissance and terminated with the exfiltration of 800,000 customer records — a four-step dependency chain in which each finding provided the prerequisite for the next.
+>
+> During reconnaissance, certificate transparency logs exposed 47 subdomains of acmecorp.com (F-001: T1596.003). One of these — `dev-api.acmecorp.com` — was serving an unauthenticated Swagger UI instance that disclosed the complete API schema for the internal application, including all 23 endpoints, parameter names, expected data types, and authentication token format (F-002: T1592). Without F-002, the remaining chain steps require substantially more active enumeration effort and would likely produce alerts.
+>
+> The Swagger schema identified `/api/v1/search` as a string-input endpoint with no documented input constraints. Manual testing confirmed a blind time-based SQL injection vulnerability (F-005: T1190). The `search` parameter was passed unsanitized to a PostgreSQL `ILIKE` query. Using sqlmap with `--technique=T --dbms=postgresql`, the operator extracted the database schema within 40 minutes. The schema confirmed a table named `customers` containing 800,247 rows.
+>
+> The terminal step (F-007: T1005) was a complete table dump executed over seven separate sqlmap `--dump` sessions to avoid triggering rate limits. The exfiltrated data included full names, email addresses, bcrypt-hashed passwords, and payment card last-four digits with expiry dates for all records created before 2025-03-01.
+>
+> **Pivot point — F-002:** Removing the Swagger UI exposure collapses this chain at Step 2. The `/api/v1/search` endpoint cannot be identified from the domain structure alone, and the SQL injection vulnerability (F-005, CVSS 9.1) remains unexploitable without knowledge of the endpoint and its parameter schema. Remediation priority: address F-002 (MEDIUM, CVSS 5.3) before F-005 (CRITICAL, CVSS 9.1) because F-002 has higher chain disruption value. Fixing F-002 alone neutralizes the complete 4-step chain. Fixing F-005 alone reduces terminal impact but leaves three of four steps intact.
+
+### Step 7 — Save the Chain Document
+
+Write the completed chain document to the standard output path:
+
+```
+_rtexit-output/docs/attack-chains/chain-[CHAIN-ID].md
+```
+
+**Example:** `_rtexit-output/docs/attack-chains/chain-01-jenkins-to-s3.md`
+
+**Document structure:**
+
+```
+# Attack Chain [ID] — [Short Label]
+**Engagement:** [REF-YYYY-NNN]
+**Date Completed:** YYYY-MM-DD
+**Operator:** [callsign]
+**Findings Covered:** F-001, F-002, F-005, F-007
+**Terminal Impact:** [one-line statement of highest business impact]
+
+## Chain Step Table
+## Pivot Point Analysis
+## Mermaid Chain Diagram
+## MITRE ATT&CK Annotations (per step)
+## Chain Narrative (Technical Register)
+## Remediation Sequencing
+```
+
+### Step 8 — Log to Autodoc Engine
+
+```bash
+python3 _rtexit/scripts/autodoc_engine.py log \
+  --skill rt-attack-chain-builder \
+  --phase "Reporting" \
+  --note "Attack chain CHAIN-01 built — 4 steps, pivot at F-002, terminal impact 800K records" \
+  --finding "F-001,F-002,F-005,F-007"
+```
+
+Log each chain separately. If you built three chains in one session, log three entries.
+
+---
+
+## 3. Integration with RTExit Scripts and Other Skills
+
+### finding_tracker.py
+
+Pull confirmed findings:
+```bash
+python3 _rtexit/scripts/finding_tracker.py list --status CONFIRMED
+python3 _rtexit/scripts/finding_tracker.py export --format csv
+```
+
+Update findings with chain membership (use the `notes` field to record chain participation):
+```bash
+python3 _rtexit/scripts/finding_tracker.py update F-002 --notes "CHAIN-01 step 2 (pivot), CHAIN-02 step 1"
+```
+
+Check that every finding included in a chain is confirmed — reject potential findings:
+```bash
+python3 _rtexit/scripts/finding_tracker.py list --status POTENTIAL
+```
+
+### autodoc_engine.py
+
+Log chain construction start:
+```bash
+python3 _rtexit/scripts/autodoc_engine.py log \
+  --skill rt-attack-chain-builder \
+  --phase "Reporting" \
+  --note "Starting attack chain analysis — reviewing all confirmed findings for dependencies"
+```
+
+Log each chain as completed:
+```bash
+python3 _rtexit/scripts/autodoc_engine.py log \
+  --skill rt-attack-chain-builder \
+  --phase "Reporting" \
+  --note "CHAIN-02 built — 4 steps, pivot at F-003 (Django Debug), terminal impact IDOR account takeover"
+```
+
+### Skill Dependencies and Sequencing
+
+| Skill | Relationship to rt-attack-chain-builder |
+|---|---|
+| `rt-finding-document` | Run first. All findings must be documented before chain analysis. |
+| `rt-mitre-map` | Run first. Chain diagrams reference MITRE technique IDs that rt-mitre-map assigns. |
+| `rt-evidence-chain` | Run in parallel. Evidence for each finding in a chain should be logged before chain is built. |
+| `rt-kill-chain-map` | Run after. The kill chain map consumes chains built by this skill to populate its phase table. |
+| `rt-technical-report` | Run after. The technical report's attack chain section pulls from the chain documents produced here. |
+| `rt-executive-report` | Run last. rt-attack-chain-builder output feeds the executive narrative via rt-kill-chain-map. |
+| `rt-remediation-roadmap` | Run after. Pivot point analysis from each chain directly informs remediation priority scoring. |
+
+### Passing Chain Output to rt-technical-report
+
+The technical report's attack chain section references chain documents by path:
+
+```
+_rtexit-output/docs/attack-chains/chain-01-jenkins-to-s3.md
+_rtexit-output/docs/attack-chains/chain-02-swagger-to-idor.md
+```
+
+When generating the technical report, include chain documents in context so the report skill can pull the chain table, Mermaid diagram, and narrative without reconstructing them.
+
+### Passing Chain Pivot Points to rt-remediation-roadmap
+
+The remediation roadmap uses pivot point analysis to produce a prioritized remediation list that differs from CVSS-only ordering. After building all chains, create a pivot summary:
+
+```
+CHAIN-01 PIVOT: F-002 (MEDIUM, CVSS 5.3) — breaks 4-step chain to 800K record exfiltration
+CHAIN-02 PIVOT: F-003 (LOW, CVSS 3.1) — breaks 4-step chain to account takeover via IDOR
+```
+
+This input causes the remediation roadmap to elevate F-002 and F-003 above higher-CVSS findings that are not chain pivots.
+
+---
+
+## 4. Example Outputs and Interactions
+
+### Example: Operator Invoking the Skill
+
+**Operator prompt:**
+> "Run rt-attack-chain-builder. I have 7 confirmed findings. Pull from the tracker and build chains."
+
+**Skill response flow:**
+1. Load all confirmed findings from `findings-master.csv`
+2. Display the finding list with IDs, titles, severities, and MITRE annotations
+3. Ask the operator to confirm which findings form chains or proceed with automated dependency analysis
+4. Identify 2 candidate chains from dependency analysis
+5. Build CHAIN-01 (4 steps) and CHAIN-02 (4 steps)
+6. Produce chain tables, pivot analysis, Mermaid diagrams, MITRE annotations, and narratives for both
+7. Save to `_rtexit-output/docs/attack-chains/`
+8. Log both chains to autodoc engine
+
+**Operator prompt (manual chain specification):**
+> "Build an attack chain from F-003 to F-006 to F-004. CHAIN-02. Label it IDOR-credential-chain."
+
+**Skill response flow:**
+1. Pull F-003, F-006, and F-004 from the tracker
+2. Verify all three are CONFIRMED
+3. Build the 3-step chain table with the operator-specified ordering
+4. Identify pivot (requires asking or inferring from the dependency logic)
+5. Generate diagram labeled `chain-02-idor-credential-chain`
+6. Save to `_rtexit-output/docs/attack-chains/chain-02-idor-credential-chain.md`
+
+### Example: Complete Chain Document Output
+
+```markdown
+# Attack Chain 01 — Jenkins to S3 Exfiltration
+**Engagement:** RT-2026-007
+**Date Completed:** 2026-05-15
+**Operator:** Ghost
+**Findings Covered:** F-001, F-002, F-005, F-007
+**Terminal Impact:** Exfiltration of 800,000 customer records from production S3 backup bucket
+
+---
+
+## Chain Step Table
+
+| Step | Finding | Technique | Gained | Enables |
+|------|---------|-----------|--------|---------|
+| 1 | F-001 INFO — Subdomain Enum | T1596.003 | 47 subdomains including dev-api | Reveals dev-api.acmecorp.com as target |
+| 2 | F-002 MEDIUM — Swagger UI Exposed ★PIVOT | T1592 | Full API schema, 23 endpoints | Identifies /api/v1/search as injection candidate |
+| 3 | F-005 CRITICAL — SQL Injection | T1190 | PostgreSQL access, full schema via sqlmap | Confirms customers table with 800K rows |
+| 4 | F-007 CRITICAL — DB Dump 800K Records | T1005 | Full customer PII exfiltrated | Terminal impact — chain complete |
+
+★ PIVOT: Removing F-002 collapses steps 3 and 4.
+
+---
+
+## Mermaid Chain Diagram
+
+[diagram as produced in Step 4]
+
+---
+
+## MITRE ATT&CK Annotations
+
+[per-step annotations as produced in Step 5]
+
+---
+
+## Chain Narrative
+
+[narrative as produced in Step 6]
+
+---
+
+## Remediation Sequencing
+
+1. F-002 (MEDIUM) — Disable Swagger UI on external-facing environments. CHAIN PIVOT.
+2. F-005 (CRITICAL) — Parameterize all database queries; implement WAF SQL injection rule.
+3. F-007 (CRITICAL) — Restrict S3 bucket access to VPC endpoint; enable CloudTrail alerting on bulk GetObject.
+4. F-001 (INFO) — No direct remediation; monitor CT logs for your own domains to detect attacker recon.
+```
+
+---
+
+## 5. Practical Usage Tips
+
+**Start with dependency analysis, not CVSS ordering.** Open the CSV sorted by `phase`, not `severity`. Chains form along temporal and technical dependencies, not severity scores. A LOW finding can be the pivot of a CRITICAL chain.
+
+**One Mermaid diagram per chain, not one diagram for all chains.** A single diagram with 7 findings and two crossing chains is unreadable. Produce one diagram per chain. If chains share a finding (e.g., a recon finding that enables two different chains), duplicate that node in each diagram with a note that it appears in both chains.
+
+**Pivot analysis changes the remediation conversation.** When a MEDIUM finding is identified as the pivot for a CRITICAL-impact chain, lead with that fact in the client debrief. It reframes the conversation from "you have CVSS 9.8 vulnerabilities" to "there is one MEDIUM-severity fix that collapses your most dangerous attack path entirely."
+
+**Verify MITRE technique IDs before logging.** ATT&CK is versioned. Technique IDs change between versions — sub-techniques are added, parent techniques are deprecated. Cross-reference every ID against ATT&CK v15 or the current version at attack.mitre.org before writing the chain document. An incorrect technique ID in a deliverable damages credibility.
+
+**Do not invent dependencies.** A chain step is only valid if the previous step demonstrably provided something the next step required. If two findings happened sequentially but were independently exploitable, they are parallel findings, not a chain. Document parallel findings as separate standalone issues. Overstating chain depth inflates perceived impact and can be challenged in client review.
+
+**Log chains to autodoc_engine.py before closing the terminal session.** The timeline in `engagement/timeline.md` is the primary audit record of when each chain was built. Chains documented retroactively — after the report is submitted — lose evidentiary standing. Log immediately after each chain is complete.
+
+**Cross-reference with rt-evidence-chain before finalizing.** Every finding in a chain must have its evidence logged with a SHA-256 hash in the custody log. A chain step with missing evidence is a chain step that cannot be demonstrated to the client. Run `rt-evidence-chain` for any findings not yet logged before finalizing the chain document.
+
+**When multiple chains share a pivot, escalate that finding's priority.** A finding that is the pivot for two or more chains represents extraordinary remediation leverage. Tag it explicitly in the remediation roadmap as a multi-chain pivot and assign it the highest possible remediation priority regardless of its standalone CVSS score.
+
+**Name output files descriptively.** `chain-01.md` is useless six months later. Use `chain-01-jenkins-default-creds-to-rce.md` or `chain-02-swagger-idor-credential-exfil.md`. The filename is the first thing a QA reviewer sees and the first thing a client's security team searches for.

package/packaged-assets/.agents/skills/rt-attack-chain-builder/workflow.md

@@ -0,0 +1,68 @@
+# Workflow - rt-attack-chain-builder
+
+## Purpose
+
+This workflow standardizes how $skill is executed inside RTExit. It is designed for authorized engagements, evidence-first documentation, and consistent handoff into reporting.
+
+## Authorization Gate
+
+Before execution, confirm:
+
+- SEAD exists and explicitly covers the target asset or activity.
+- Rules of Engagement define allowed techniques, rate limits, and stop conditions.
+- The operator knows the evidence handling rules.
+- Any active or sensitive validation has client approval.
+
+If any item is unclear, pause and invoke 
+
+## Required Inputs
+
+| Input | Source | Notes |
+|---|---|---|
+| Engagement reference | _rtexit/config.toml or SEAD | Used in output names. |
+| Target asset(s) | Scope document | Must be explicitly approved. |
+| Operator name | Config/user context | Used in timeline entries. |
+| Evidence directory | _rtexit-output/docs/evidence/ | Store logs, screenshots, and artifacts. |
+| Finding tracker | _rtexit-output/docs/findings/ | Create/update findings when confirmed. |
+
+## Execution Steps
+
+1. Load current engagement configuration.
+2. Read scope, exclusions, and current findings.
+3. Build a small test plan for this skill with target, expected control, and evidence type.
+4. Run the lowest-risk validation first.
+5. Capture baseline behavior before proof behavior.
+6. Record exact timestamp, account/role used, and affected asset.
+7. Stop when evidence is sufficient; avoid unnecessary data access.
+8. Create or update findings through the RTExit finding tracker.
+9. Map remediation owner and recommended timeline.
+10. Add a timeline entry and evidence chain entry.
+
+## Evidence Requirements
+
+| Evidence | Required? | Notes |
+|---|---|---|
+| Command or action summary | Yes | Redact secrets and tokens. |
+| Screenshot or transcript | If useful | Store under evidence folder. |
+| Request/response pair | For web/API | Redact cookies and bearer tokens. |
+| Config excerpt | For cloud/infra | Include only relevant lines. |
+| Business impact note | Yes | Explain why it matters. |
+
+## Autodoc Commands
+
+`ash
+python _rtexit/scripts/autodoc_engine.py log --skill rt-attack-chain-builder --phase auto --cmd "workflow execution" --output "summary"
+python _rtexit/scripts/finding_tracker.py list
+`
+
+## Completion Criteria
+
+- Scope and authorization are referenced.
+- Evidence is stored and redacted.
+- Findings are added or explicitly marked as not found.
+- Remediation guidance is actionable.
+- Timeline and chain of custody are updated where applicable.
+
+## Handoff
+
+Send confirmed findings to