What Information Is Stored in the scope.md File? The Reverse-Skill Authorization Contract

The scope.md file serves as the central authorization contract that defines legal boundaries, operational constraints, and readiness criteria for every security engagement in the zhaoxuya520/reverse-skill project.

In the zhaoxuya520/reverse-skill repository, the scope.md file acts as the mandatory gatekeeper for all penetration testing and reverse engineering activities. Located at work/<case>/scope.md and generated by the case-init script, this Markdown document establishes the single source of truth for what actions are authorized, when, and under what constraints.

scope.md File Location and Generation

The scope.md file must exist under work/<case>/scope.md before any ACT (Action) can be performed according to skills/ops/scope-contract.md. The case-init script generates this file from the template stored at skills/pentest-tools/templates/scope.md, ensuring consistent structure across all security cases. The fully populated example at examples/ctf-demo/scope.md demonstrates concrete implementation for CTF scenarios.

Core Sections Stored in the scope.md File

Meta (Case Identification)

The ## meta section stores basic identifiers including case_id, created timestamp, operator name, primary_skill reference (pointing to skill definitions like pentest-tools/SKILL.md), and assigned lead_role or specialist roles.

Auth (Authorization Status)

The ## auth section records the status (which must be explicitly set to granted), the basis for authorization (e.g., internal_security_team), and evidence_of_auth documenting who authorized the engagement. This section legally gates all downstream activities.

In-Scope Boundaries

The ## in_scope section defines permitted assets (specific IP addresses or domains), attack surfaces (such as ssh, http), and authorized activities (including enumeration or exploitation). This creates the positive authorization boundary for the engagement.

Out-of-Scope Prohibitions

Conversely, the ## out_of_scope section explicitly prohibits certain assets and activities such as phishing campaigns or access to internal_admin_portal systems. This negative boundary prevents scope creep and ensures legal compliance.

Network Profile Constraints

The ## network_profile section defines the permitted network mode from four strict options: offline, lab_only, authorized_target_only, or unrestricted_lab. The section includes notes requiring operators to switch modes only after explicit authorization updates, preventing accidental production exposure.

Deliverables and Constraints

The ## deliverables section specifies expected engagement outputs such as report, field journal, diagrams, and timeline. The ## constraints section operationalizes operational limits including timebox duration (e.g., {4h}), stealth levels, and data-handling requirements.

Signoff (Readiness Verification)

The ## signoff section contains the ready_for_act boolean flag and a mandatory checklist ensuring all prerequisites are satisfied. The checklist validates that auth.status = granted, in_scope.assets is non-empty, and network_profile.mode is explicitly chosen before any actions execute.

Ops Refs (Documentation Links)

The ## ops_refs section provides links to supporting documentation such as skills/ops/scope-contract.md, role-maps, and evidence-finding paths that provide deeper operational guidance for complex engagements.

How to Create a scope.md File from the Template

The template at skills/pentest-tools/templates/scope.md provides the structural skeleton. A minimal working scope.md requires populating all mandatory sections as shown below:

# 授权范围 (Scope)

## meta

- case_id: my-case
- created: 2026-09-01T12:00:00Z
- operator: alice
- primary_skill: pentest-tools/SKILL.md
- lead_role: lead

## auth

- status: granted
- basis: internal_security_team
- evidence_of_auth: signed authorization letter

## in_scope

- assets:
  - 10.0.0.5
- surfaces: [ssh, http]
- activities: [enumeration, exploitation]

## out_of_scope

- assets: [internal_admin_portal]
- activities: [phishing]

## network_profile

- mode: authorized_target_only
- notes: |
    offline | lab_only | authorized_target_only | unrestricted_lab

## deliverables

- report: true
- timeline: true

## constraints

- timebox: {4h}
- stealth: medium

## signoff

- ready_for_act: true
- checklist:
  - [x] auth.status = granted
  - [x] in_scope.assets non-empty
  - [x] network_profile.mode chosen

Summary

• The scope.md file in zhaoxuya520/reverse-skill serves as the legal and operational authorization contract for penetration testing and reverse engineering engagements.
• It stores nine critical sections: meta, auth, in_scope, out_of_scope, network_profile, deliverables, constraints, signoff, and ops_refs.
• The file must reside at work/<case>/scope.md and be generated via the case-init script before any ACT can proceed, as mandated by skills/ops/scope-contract.md.
• Key validation requires auth.status: granted, non-empty in-scope assets, and an explicit network mode selection in the signoff checklist.
• Reference implementations are available in skills/pentest-tools/templates/scope.md (template) and examples/ctf-demo/scope.md (example).

Frequently Asked Questions

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

The scope.md file must be created at work/<case>/scope.md for each specific engagement. The case-init script automatically generates this file from the template located at skills/pentest-tools/templates/scope.md when initializing a new case directory.

What authorization status is required in the scope.md auth section?

The ## auth section must contain status: granted along with a basis (such as internal_security_team) and evidence_of_auth documenting the authorization source. No ACT operations can proceed without this explicit granted status, making this section the primary legal gatekeeper.

Can you perform penetration testing without a scope.md file?

No. According to skills/ops/scope-contract.md, the physical presence of scope.md is mandatory before any ACT can be performed. The ## signoff section includes a ready_for_act boolean and checklist that validates all prerequisites, ensuring operational boundaries are legally established and verified.

What network modes are available in the scope.md network_profile section?

The ## network_profile supports four strict modes: offline, lab_only, authorized_target_only, and unrestricted_lab. These modes restrict network connectivity based on authorization levels, with explicit requirements that mode switching only occurs after authorization updates to prevent unauthorized network access.

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