---
name: rt-autodoc
description: "Manual trigger for RTExit auto-documentation engine. Logs activities, commands, and findings to engagement timeline and evidence chain. Wraps autodoc_engine.py for skill-level integration. Use explicitly to log important activities not automatically captured. Creates SHA-256 hashed evidence entries."
---

# rt-autodoc Skill Guide

## 1. Purpose and When to Use

`rt-autodoc` is the manual documentation trigger for the RTExit auto-documentation engine. It ensures that significant activities, findings, commands, and decisions are captured in the engagement timeline and evidence chain even when automatic capture does not occur.

### Primary purposes

- Log discrete activities or findings that fall outside automated capture hooks
- Commit SHA-256 hashed evidence entries to the immutable evidence chain
- Maintain a coherent, auditable engagement timeline across all RTExit operations
- Bridge gap when other skills produce outputs that must be formally recorded

### When to invoke explicitly

- After running discovery scans or recon commands manually in a terminal
- When documenting analyst decisions or interpretation of ambiguous findings
- To record out-of-band communications or observations (e.g., client call notes)
- After importing external evidence files not produced by RTExit scripts
- When a prior skill execution produced findings but autodoc hooks did not fire
- To create checkpoint entries before and after high-risk or destructive actions
- Any time you need a tamper-evident record of a specific moment in the engagement

### When NOT to invoke

- Routine script executions that already trigger autodoc hooks automatically
- Duplicate logging of entries already present in the timeline
- Administrative bookkeeping unrelated to the active engagement

---

## 2. Step-by-Step Workflow

### Step 1 - Identify what to document

Determine the category of the entry:

- `activity` - general analyst action (e.g., started port scan)
- `command` - specific command or tool invocation with its output
- `finding` - discovered vulnerability, misconfiguration, or artifact
- `decision` - analyst judgment or scope change
- `evidence` - file, screenshot, or artifact to anchor in the chain

### Step 2 - Gather required fields

Collect the following before invoking:

| Field | Description | Required |
|---|---|---|
| `category` | Entry type (activity, command, finding, decision, evidence) | Yes |
| `title` | Short human-readable summary (max 120 chars) | Yes |
| `detail` | Full description, command text, or finding narrative | Yes |
| `severity` | info / low / medium / high / critical (findings only) | Conditional |
| `artifact_path` | Absolute path to associated file or output | Optional |
| `tags` | Comma-separated labels for later filtering | Optional |

### Step 3 - Invoke the skill

The skill wraps `autodoc_engine.py`. A typical invocation pattern:

```
rt-autodoc
category: finding
title: SMB signing disabled on 10.10.1.45
detail: nmap --script smb-security-mode output confirms message_signing: disabled. Host is susceptible to relay attacks.
severity: high
tags: smb, relay, lateral-movement
```

### Step 4 - Engine processing

`autodoc_engine.py` performs the following internally:

1. Reads the active engagement context from the RTExit session state
2. Stamps the entry with ISO-8601 UTC timestamp
3. Generates SHA-256 hash of (timestamp + category + title + detail)
4. Appends entry to `timeline.jsonl` in the engagement output directory
5. Appends hash to `evidence_chain.log` with back-reference to the previous hash (chain linkage)
6. Writes a human-readable summary line to `activity_log.txt`
7. Returns the entry ID and hash for confirmation

### Step 5 - Verify the entry

After the skill returns, confirm the entry was recorded:

```
cat <engagement_dir>/evidence_chain.log | tail -5
```

The last line should contain the new hash and entry ID.

---

## 3. Integration with RTExit Scripts and Other Skills

### autodoc_engine.py

`rt-autodoc` is a skill-level wrapper around `autodoc_engine.py`. The engine exposes a CLI interface:

```
python autodoc_engine.py \
  --category finding \
  --title "SMB signing disabled" \
  --detail "Full detail text here" \
  --severity high \
  --tags smb,relay
```

The skill handles argument marshalling, session context injection, and error reporting on top of this CLI.

### Engagement session state

The engine reads the active engagement from the RTExit session state file (typically `.rtexit_session.json` in the project root). This file must exist and contain a valid `engagement_id` before `rt-autodoc` can log entries. Use `rt-init` or `rt-session` to establish the session first.

### Integration with other skills

| Skill | Integration point |
|---|---|
| `rt-recon` | Call rt-autodoc after manual recon steps to capture findings not auto-logged |
| `rt-exploit` | Log pre-exploitation decision entries and post-exploitation artifacts |
| `rt-report` | Timeline and evidence chain produced by rt-autodoc feed directly into report generation |
| `rt-evidence` | rt-autodoc creates evidence chain anchors; rt-evidence manages associated files |
| `rt-session` | Provides session context that rt-autodoc reads to scope entries correctly |

### File outputs

| File | Purpose |
|---|---|
| `<engagement_dir>/timeline.jsonl` | Machine-readable JSONL timeline of all entries |
| `<engagement_dir>/evidence_chain.log` | Append-only SHA-256 hash chain for tamper detection |
| `<engagement_dir>/activity_log.txt` | Human-readable chronological activity summary |

---

## 4. Example Outputs and Interactions

### Example 1 - Logging a command and its output

**Input to skill:**

```
rt-autodoc
category: command
title: Ran nmap SYN scan against 10.10.1.0/24
detail: Command: nmap -sS -p 22,80,443,445,3389 10.10.1.0/24 -oN nmap_syn.txt
Result: 14 hosts up. Ports 445 and 3389 open on multiple hosts. Full output in nmap_syn.txt.
artifact_path: /engagements/ENG-2026-001/evidence/nmap_syn.txt
tags: nmap, portscan, smb, rdp
```

**Timeline entry written (timeline.jsonl):**

```json
{
  "entry_id": "ae7f3c1b",
  "timestamp": "2026-05-31T09:14:22Z",
  "category": "command",
  "title": "Ran nmap SYN scan against 10.10.1.0/24",
  "detail": "Command: nmap -sS -p 22,80,443,445,3389 10.10.1.0/24 ...",
  "artifact_path": "/engagements/ENG-2026-001/evidence/nmap_syn.txt",
  "tags": ["nmap", "portscan", "smb", "rdp"],
  "hash": "3a7f9bc2d4e1058fa6c3b7d92e4f1a0c8b5d3e7f9a2c4b6d8f0e2a4c6b8d0f2",
  "prev_hash": "1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c"
}
```

**Evidence chain append:**

```
2026-05-31T09:14:22Z | ae7f3c1b | 3a7f9bc2d4e1058fa6c3b7d92e4f1a0c8b5d3e7f9a2c4b6d8f0e2a4c6b8d0f2
```

### Example 2 - Logging a high-severity finding

**Input:**

```
rt-autodoc
category: finding
title: Kerberoastable service account discovered - svc_sql
detail: GetUserSPNs.py output identified svc_sql with SPN MSSQLSvc/db01.corp.local:1433. Account has no pre-auth requirement. Hash captured for offline cracking.
severity: high
tags: kerberoasting, active-directory, credential-access
artifact_path: /engagements/ENG-2026-001/evidence/kerberoast_hashes.txt
```

**Skill response:**

```
[rt-autodoc] Entry logged successfully.
  Entry ID : b3d9e2f1
  Category : finding
  Severity : high
  Timestamp: 2026-05-31T11:03:45Z
  Hash     : 8f2a1c3e5b7d9f1a3c5e7b9d1f3a5c7e9b1d3f5a7c9e1b3d5f7a9c1e3b5d7f9
  Chain pos: 47 (prev: 9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0)
```

### Example 3 - Logging an analyst decision

**Input:**

```
rt-autodoc
category: decision
title: Deferred exploitation of CVE-2024-1234 pending client approval
detail: Discovered RCE vector on 10.10.1.20 (CVE-2024-1234). Risk of service disruption is high. Decision made to pause exploitation and notify client via secure channel before proceeding. Awaiting written go-ahead.
tags: scope, client-communication, deferred
```

**Activity log line written:**

```
[2026-05-31 13:22:07 UTC] [decision] Deferred exploitation of CVE-2024-1234 pending client approval (entry: c1f4a8b2)
```

---

## 5. Practical Usage Tips

### Build a habit of pre/post entries for high-risk actions

Before any destructive or high-impact action, log a `decision` entry stating intent. After the action, log a `command` or `finding` entry with the result. This creates a clear before-and-after bracket in the evidence chain.

### Use tags consistently

Establish a tag taxonomy at engagement start and stick to it. Consistent tags allow timeline filtering during report generation. Suggested base tags: `discovery`, `credential-access`, `lateral-movement`, `exfiltration`, `persistence`, `scope-change`.

### Attach artifacts whenever possible

If a tool produced a file, pass the path via `artifact_path`. The engine will record the file's SHA-256 hash alongside the entry hash, creating a two-layer integrity check on the evidence.

### Chain entries for multi-step findings

For findings that unfold across multiple steps (initial discovery, exploitation, impact demonstration), log a `finding` entry at each stage and use the same root tag to group them. The timeline JSONL can later be filtered by tag to reconstruct the kill chain.

### Recovering from missed auto-capture

If you realize several steps were not logged (e.g., you ran commands in a separate terminal), log them retroactively using the `detail` field to include approximate timing. The engine stamps entries with the actual invocation time, so note any time offset explicitly in the detail text.

### Verify chain integrity periodically

Run the RTExit chain integrity checker against `evidence_chain.log` at the end of each session to confirm no entries were altered or dropped:

```
python autodoc_engine.py --verify-chain <engagement_dir>/evidence_chain.log
```

A clean chain returns: `Chain integrity: OK - N entries verified`.

### Do not edit timeline.jsonl or evidence_chain.log manually

Manual edits break the hash chain and will cause integrity verification to fail. If an entry contains an error, log a corrective `decision` entry referencing the original entry ID rather than modifying the existing record.
