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

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 — The mandatory contract template defining case metadata, authorization status, and scope boundaries
• 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 — 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) 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 -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 from the contract template.

Step 2: Complete the Authorization

Edit the generated scope.md to set auth.status to granted:

# 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 -File skills/scripts/case-guard.ps1 -CaseName "fw-2026-aug"

Expected output when documentation is complete:

✔ 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 permit skill execution.

Where the Enforcement Happens

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

• RULES.md (and RULES_zh.md): Explicitly prohibits "any target ACT until auth.status = granted and a valid network_profile is set"

• 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:

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) 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 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, 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 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?

Almost. 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}