# What Is scope-contract.md? Understanding the Pre-ACT Gate in the Reverse-Skill Framework

> Understand scope-contract.md, the pre-ACT gate in the Reverse-Skill framework. Learn how this policy document enforces authorization and risk mitigation before operations begin.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: deep-dive
- Published: 2026-08-06

---

**The [`scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope-contract.md) file is a canonical policy document that enforces authorization, scope boundaries, and risk-mitigation rules before any active operations (ACT) can begin.**

In the `zhaoxuya520/reverse-skill` repository, [`scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope-contract.md) lives at **[`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md)** and serves as the single source of truth for procedural compliance. This machine-readable contract ensures every security engagement—whether reverse engineering, penetration testing, or malware analysis—meets strict legal and ethical prerequisites before the framework transitions from routing to active execution.

## Core Purpose of scope-contract.md

The document operates as a **hard gate** with three architectural mandates that prevent unauthorized or unsafe operations.

### Authorization Gate

The contract mandates that every case creates a `work/<case>/scope.md` file complying with a prescribed markdown template. The framework explicitly **MUST NOT proceed** unless the `auth.status` field is set to **`granted`**. This check is enforced by the routing engine referenced in the "路由挂钩" (routing hook) block (lines 71‑79 of [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md)), which aborts any active scanning or exploitation attempts if authorization is missing.

### Standardized Scope Definition

Lines 15‑69 of the contract define a rigid template with eight standardized sections: *meta*, *auth*, *in_scope*, *out_of_scope*, *network_profile*, *deliverables*, *constraints*, and *signoff*. This uniformity enables automated validation scripts like `skills/scripts/case-init.ps1` to parse scope files without custom logic, guaranteeing consistent handling across all engagements regardless of the specific reverse-skill operator.

### Risk-Mitigation Policy Enforcement

By encoding explicit "must-not" conditions directly into the workflow—such as "MUST NOT use unrestricted against production without written auth"—the contract embeds legal safeguards into executable policy. The `constraints` and `out_of_scope` sections create immutable boundaries that the routing engine validates before unlocking the **ACT** phase in `skills/ops/PRIMARY SKILL.md`.

## How scope-contract.md Fits Into the Workflow

The contract functions as a **pre-ACT checklist** that couples procedural compliance with technical gating across three distinct phases.

### Case Initialization with case-init.ps1

When initializing a new engagement, operators run the PowerShell scaffolding script to generate a compliant scope file. The script automatically populates the `work/<case>/scope.md` path with the canonical template from [`scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope-contract.md).

```powershell

# Initialise a new case called "my-case"

powershell -NoProfile -ExecutionPolicy Bypass `
    -File skills\scripts\case-init.ps1 `
    -Hint "Analyze suspicious APK" `
    -CaseName "my-case"

```

This creates the directory structure and a [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file ready for authorization data entry.

### Routing and the Pre-ACT Checkpoint

The master routing logic in **[`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md)** interprets the contract via the "路由挂钩" rules. The router performs a strict validation: if `auth.status` is not `granted` or if `ready_for_act` is false, the framework stops at the checkpoint and refuses to load the primary skill. This prevents accidental activation of exploitation modules against unauthorized targets.

### Transition to the ACT Phase

Only when the `signoff.checklist` contains all `[x]` marks—confirming that scope assets are defined, network profiles are selected, and out-of-scope items are reviewed—does the framework set `ready_for_act: true`. At this point, the routing engine permits access to `skills/ops/PRIMARY SKILL.md` and the **ACT** phase begins.

## Anatomy of a Valid Scope File

A compliant [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file must follow the exact structure defined in [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md). The following example demonstrates the minimal valid configuration required to satisfy the pre-ACT gate:

```markdown

# Case Scope

## meta

- case_id: 20260806-01
- created: 2026-08-06T12:00:00Z
- operator: alice
- primary_skill: master-route
- lead_role: lead
- specialist_roles: []

## auth

- status: granted
- basis: written_contract
- evidence_of_auth: ticket/12345
- MUST NOT proceed if status != granted

## in_scope

- assets: ["10.0.0.5"]
- surfaces: ["web"]
- activities: ["recon", "reverse"]

## out_of_scope

- assets: []
- activities: ["DoS"]

## network_profile

- mode: authorized_target_only
- notes: |
    Only assets listed above may be contacted.

## deliverables

- report: true
- field_journal: true
- diagrams: true
- timeline: true

## constraints

- timebox: {}
- stealth: medium
- data_handling: anonymize

## signoff

- ready_for_act: true
- checklist:
  - [x] auth.status = granted
  - [x] in_scope.assets non-empty OR offline sample path set
  - [x] network_profile.mode chosen
  - [x] out_of_scope reviewed

```

## Validating the Contract Programmatically

Automated tooling can validate the scope file before attempting ACT. The following pseudo-code demonstrates the logic used by the routing engine to enforce the contract:

```python
def can_act(scope_path):
    scope = parse_markdown(scope_path)
    
    # Hard gate: authorization must be granted

    if scope['auth']['status'] != 'granted':
        return False
    
    # Hard gate: explicit signoff required

    if not scope['signoff']['ready_for_act']:
        return False
    
    # Verify all checklist items are completed

    return all(item.startswith('[x]') for item in scope['signoff']['checklist'])

# Usage

if can_act('work/my-case/scope.md'):
    enter_act_phase()
else:
    raise AuthorizationError("Scope contract not satisfied")

```

## Summary

- **[`scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope-contract.md)** is located at [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) and defines the universal policy for pre-ACT authorization.
- The contract requires a `work/<case>/scope.md` file with standardized sections including `auth`, `in_scope`, and `signoff`.
- **ACT cannot proceed** unless `auth.status` is explicitly set to `granted` and `ready_for_act` is true.
- The `skills/scripts/case-init.ps1` script scaffolds compliant scope files automatically.
- Routing logic in [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md) enforces the "路由挂钩" rules to block unauthorized operations.

## Frequently Asked Questions

### Where is scope-contract.md located in the reverse-skill repository?

The file resides at **[`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md)** in the `zhaoxuya520/reverse-skill` repository. This location is referenced by the master routing system and initialization scripts as the canonical template for all engagement scope definitions.

### What fields are required in a scope.md file before ACT?

The framework requires eight mandatory sections: **meta** (case identification), **auth** (authorization status), **in_scope** (target assets), **out_of_scope** (prohibited actions), **network_profile** (connection rules), **deliverables** (output requirements), **constraints** (operational limits), and **signoff** (readiness confirmation). The `auth.status` must be `granted` and `signoff.ready_for_act` must be `true`.

### How does the framework validate the scope contract before allowing ACT?

Validation occurs in the routing hook ("路由挂钩") defined in [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) (lines 71‑79). The engine parses `work/<case>/scope.md` and verifies that `auth.status` equals `granted`, that all checklist items in `signoff.checklist` are marked `[x]`, and that scope boundaries are explicitly defined. Any failure results in an immediate stop before loading `skills/ops/PRIMARY SKILL.md`.

### Can ACT proceed if auth.status is not set to granted?

No. The contract explicitly states **"MUST NOT proceed if status != granted"**. This is a non-negotiable hard gate. If the `auth` section lacks written authorization evidence or the status field contains any value other than `granted`, the framework will remain in the routing phase and block all active operations, including scanning, hooking, or exploitation.