# Reverse-Skill Documentation Requirements: What You Need Before Interacting With a Target

> Understand reverse-skill documentation requirements. Learn what you need, including Scope Contract and authorization checklist, before interacting with a target.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: how-to-guide
- Published: 2026-08-10

---

**You must complete a mandatory Scope Contract and authorization checklist before any active target interaction is permitted in Reverse-Skill.**

Reverse-Skill enforces a strict documentation gate that blocks all offensive operations until specific contracts are in place. This article breaks down exactly what documentation is required before interacting with a target in reverse-skill, where to find the templates, and how to validate your setup.

## The Core Pre-Interaction Documentation

Reverse-Skill operates on a **"no docs, no action"** principle. The system will refuse to route skills to targets unless four critical documentation pieces are satisfied:

- **[`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md)** — The mandatory contract template defining case metadata, authorization status, and scope boundaries
- **[`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md)** — Global operational rules prohibiting any ACT until `auth.status = granted`
- **`work/<case>/scope.md`** — The case-specific instance created by running `case-init.ps1`
- **[`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md)** — The routing logic that enforces the gate before skill execution

These files work together to create an auditable, repeatable authorization workflow for every engagement.

## The Scope Contract: Your Authorization Gate

The **Scope Contract** ([`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md)) is the foundational document that must exist before any target interaction. According to the Reverse-Skill source code, this contract contains five mandatory sections:

| Section | Purpose | Required State |
|---------|---------|--------------|
| `meta` | Case identification (ID, operator, timestamps) | Must be populated |
| `auth` | Legal authorization status | **Must equal `granted`** |
| `in_scope` | Assets and activities permitted | Must be non-empty |
| `out_of_scope` | Explicit exclusions | Must be reviewed |
| `network_profile` | Network operating mode | Must be explicitly chosen |

The `network_profile` field is particularly critical. Valid modes include:
- `offline` — Air-gapped analysis only
- `lab_only` — Private test environments
- `authorized_target_only` — Specific pre-approved targets
- `unrestricted_lab` — Broader lab network access

## How to Generate Required Documentation

Rather than creating files manually, Reverse-Skill provides `skills/scripts/case-init.ps1` to bootstrap compliant documentation. This PowerShell script enforces the correct structure and populates required fields.

### Step 1: Initialize the Case

```powershell
powershell -NoProfile -ExecutionPolicy Bypass `
    -File skills/scripts/case-init.ps1 `
    -Hint "Analyze suspicious firmware binary" `
    -CaseName "fw-2026-aug"

```

This creates [`work/fw-2026-aug/scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/work/fw-2026-aug/scope.md) from the contract template.

### Step 2: Complete the Authorization

Edit the generated [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) to set `auth.status` to `granted`:

```markdown

# work/fw-2026-aug/scope.md

# -------------------------------------------------

## auth

- status: granted
- basis: vendor_bug_bounty
- evidence_of_auth: contract-2026-08-001-signed.pdf

## in_scope

- assets: [ "router-firmware-v2.3.bin", "192.168.1.0/24" ]
- activities: [ "static_analysis", "emulation", "report" ]

## network_profile

- mode: lab_only

# -------------------------------------------------

```

### Step 3: Validate Before Acting

Run the guard script to verify your documentation meets all requirements:

```powershell
powershell -File skills/scripts/case-guard.ps1 -CaseName "fw-2026-aug"

```

Expected output when documentation is complete:

```text
✔ auth.status = granted
✔ in_scope.assets non-empty
✔ network_profile.mode chosen
✔ out_of_scope reviewed
→ ready_for_act = true

```

Only after this validation will [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md) permit skill execution.

## Where the Enforcement Happens

The documentation requirement is hard-coded at multiple points in the Reverse-Skill codebase:

- **[`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md)** (and [`RULES_zh.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES_zh.md)): Explicitly prohibits "any target ACT until `auth.status = granted` **and** a valid `network_profile` is set"

- **[`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md)**: Step 3 of the routing logic checks for "case-init / scope.md" before proceeding to primary skills

- **`skills/scripts/case-guard.ps1`**: Runtime validation that the checklist is complete

If any check fails, the routing system emits an error and blocks execution:

```text
ERROR: Case 'fw-2026-aug' not initialized or not authorized.
Run: powershell -File skills/scripts/case-init.ps1 -CaseName "fw-2026-aug"

```

## Documentation Checklist Summary

Before interacting with any target in Reverse-Skill, confirm:

1. `case-init.ps1` executed successfully with your case name
2. `work/<case>/scope.md` exists with proper structure
3. `auth.status` explicitly set to `granted` (not `pending` or `denied`)
4. `network_profile.mode` selected from valid options
5. `case-guard.ps1` reports `ready_for_act = true`

Missing any of these will block operations at the routing layer.

## Summary

- **Primary gate**: The Scope Contract ([`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md)) instantiated as `work/<case>/scope.md`
- **Critical fields**: `auth.status = granted` and valid `network_profile`
- **Generation tool**: `skills/scripts/case-init.ps1` with `-CaseName` parameter
- **Validation tool**: `skills/scripts/case-guard.ps1` confirms readiness
- **Enforcement point**: [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md) blocks execution until documentation is complete

## Frequently Asked Questions

### What happens if I try to run a skill without completing the documentation?

The routing system will reject the operation. As implemented in [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md), the master router checks for the scope contract before dispatching to any primary skill. You'll receive an error directing you to run `case-init.ps1` and complete authorization.

### Can I use `pending` or `denied` status for testing?

No. The [`RULES.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md) explicitly require `auth.status = granted` for any target ACT. The `case-guard.ps1` validation script will fail checks and set `ready_for_act = false` unless the status matches exactly.

### Is the Scope Contract the same as [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md)?

Almost. [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) is the **template**; `work/<case>/scope.md` is your **instantiated contract** for a specific case. The `case-init.ps1` script copies and populates the template. Both follow identical structure, but only the case-specific file authorizes operations.

### How do I change network profiles mid-engagement?

Edit `work/<case>/scope.md` directly to modify the `network_profile.mode` value, then re-run `case-guard.ps1` to validate. The routing system reads the current state on each skill invocation, so changes take effect immediately upon validation.