# How to Verify If a Case Is Ready to ACT in reverse-skill: Complete Checklist Guide

> Learn how to verify if a case is ready to ACT in reverse-skill. Check scope.md and ensure all five checklist items are satisfied for seamless progression.

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

---

**A case is ready to ACT when the [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file in the case directory contains `signoff.ready_for_act: true` and all five mandatory checklist items—including authorization status, asset definition, network profile selection, and out-of-scope review—are satisfied according to the Scope Contract.**

Before executing any active operations in the zhaoxuya520/reverse-skill framework, every security engagement must pass a hard gate defined in [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md). This article explains how to verify if a case is ready to ACT in reverse-skill by examining the validation rules, the routing hook logic, and practical verification scripts that enforce this critical safety mechanism.

## The Scope Contract and ACT Phase Gate

The framework enforces the ACT phase gate through three tightly-coupled mechanisms. First, **Master Routing** ([`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md)) selects the primary skill for the engagement. Second, **Case Initialization** creates a case folder at `work/<case>/` and generates a [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file via `skills/scripts/case-init.ps1` [[source]](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md#L9-L12). Third, the **Ops Contract** validates that [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) satisfies the ready-for-ACT checklist before the router opens the primary [`SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/SKILL.md) for execution [[source]](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md#L61-L68).

## The Ready-for-ACT Checklist Requirements

The `signoff.ready_for_act` boolean flag acts as the final gate, but it can only be set to `true` after five specific conditions are met. These checklist items are encoded in the Scope Contract and evaluated by the routing hook.

### Authorization Status Must Be Granted

The `auth.status` field must contain the value **`granted`**. This guarantees that legal or authorized permission to touch the target has been obtained and documented [[source]](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md#L27-L32). If authorization is missing, the router halts and permits only documentation updates or routing actions.

### Asset Definition Verification

Either `in_scope.assets` must be non-empty, or an `offline sample path` must be set. This ensures there is at least one defined asset or a static sample available for the engagement [[source]](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md#L33-L36). Without a defined target or sample, active operations cannot proceed.

### Network Profile Selection

The `network_profile.mode` must be explicitly chosen from the allowed values: `offline`, `lab_only`, `authorized_target_only`, or `unrestricted_lab`. This parameter determines the allowed network connectivity for the case [[source]](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md#L42-L48). The framework requires this selection to prevent accidental network leakage or unauthorized external connections.

### Out-of-Scope Review

The `out_of_scope` section must be reviewed and acknowledged. This checkpoint prevents accidental out-of-scope actions such as Denial-of-Service attacks or real-user phishing [[source]](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md#L38-L41). The presence of this review is validated before the ACT phase unlocks.

### Final Signoff Flag

The `signoff.ready_for_act` field must be set to **`true`**. This serves as the final gate that flips only after all previous items are satisfied [[source]](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md#L61-L66). When this flag is `false`, the primary skill file remains locked.

## Routing Hook Evaluation Logic

When the router evaluates a case, it follows the routing hook defined at the end of the Scope Contract. The logic proceeds through four steps:

1. Master-route selects the **PRIMARY** skill
2. Case initialization executes (via `case-init.ps1`) or manual [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) creation
3. If `auth` is not granted (`未 granted`), the process **STOPS** and only permits authorization material supplementation
4. If `ready_for_act` equals `true`, the framework opens `PRIMARY SKILL.md` and enters the **ACT** phase

If step 4 evaluates to false, the router halts execution. Only when the condition passes does the framework load the domain-specific skill file (e.g., [`skills/windows-ad/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/windows-ad/SKILL.md)) and allow execution of ACT commands.

## Practical Methods to Verify Case Readiness

You can verify case readiness programmatically using the following approaches, which reference the actual file paths and structures defined in the repository.

### PowerShell Inspection of scope.md

Use PowerShell 7+ to load the YAML-based [`scope.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope.md) file and evaluate the checklist programmatically:

```powershell

# Point to the case folder (replace MyCase with your case name)

$case = "work/MyCase"

# Load the scope file as a hashtable (requires PowerShell 7+)

$scope = Get-Content "$case/scope.md" -Raw |
         ConvertFrom-Yaml

# Evaluate the checklist

$authGranted      = $scope.auth.status -eq 'granted'
$hasAssets        = $scope.in_scope.assets.Count -gt 0 -or $scope.network_profile.mode -eq 'offline'
$profileChosen    = $scope.network_profile.mode -ne $null
$outScopeReviewed = $scope.out_of_scope.assets.Count -ge 0   # presence is enough

$readyForAct      = $scope.signoff.ready_for_act -eq $true

if ($authGranted -and $hasAssets -and $profileChosen -and $outScopeReviewed -and $readyForAct) {
    "✅ Case $case is ready to ACT."
} else {
    "⚠️ Case $case is NOT ready. Checklist status:"
    " • auth.status = $($scope.auth.status)"
    " • assets count = $($scope.in_scope.assets.Count)"
    " • network_profile = $($scope.network_profile.mode)"
    " • out_of_scope reviewed = $($outScopeReviewed)"
    " • ready_for_act = $($scope.signoff.ready_for_act)"
}

```

### Automated CI Verification with Bash and yq

For continuous integration pipelines, use the `yq` YAML processor to validate the checklist:

```bash
CASE_DIR="work/my-case"
SCOPE_FILE="${CASE_DIR}/scope.md"

# Extract fields using yq (YAML parser)

auth_status=$(yq e '.auth.status' "$SCOPE_FILE")
ready=$(yq e '.signoff.ready_for_act' "$SCOPE_FILE")
assets=$(yq e '.in_scope.assets | length' "$SCOPE_FILE")
profile=$(yq e '.network_profile.mode' "$SCOPE_FILE")

if [[ "$auth_status" == "granted" && "$ready" == "true" && "$assets" -gt 0 && -n "$profile" ]]; then
    echo "✅ Ready for ACT"
else
    echo "❌ Not ready – review checklist"
fi

```

### Using case-init.ps1 for Automated Validation

The `skills/scripts/case-init.ps1` script automatically writes `ready_for_act: false` and a template checklist during initialization. After manually editing `work/<case>/scope.md` to satisfy all conditions, update the flag automatically:

```powershell

# After editing work/MyCase/scope.md, run:

powershell -NoProfile -ExecutionPolicy Bypass -File skills\scripts\case-init.ps1 -UpdateReadyFlag "MyCase"

```

This script reads the checklist, validates the conditions against the Scope Contract requirements, and updates `ready_for_act` to `true` only when all criteria pass.

## Summary

- **The Scope Contract** ([`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md)) defines the mandatory gate before active operations.
- **Five checklist items** must be satisfied: authorization granted, assets defined, network profile selected, out-of-scope reviewed, and final signoff flagged.
- **The `ready_for_act` boolean** in `work/<case>/scope.md` serves as the final gate that permits entry into the ACT phase.
- **Verification methods** include PowerShell YAML parsing, Bash CI checks with `yq`, and the built-in `case-init.ps1` validation script.
- **Routing hook logic** explicitly halts execution if any checklist item is missing, preventing unauthorized active operations.

## Frequently Asked Questions

### What happens if I attempt to ACT before ready_for_act is true?

The Master Routing hook will halt execution and prevent the primary [`SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/SKILL.md) file from opening. According to the routing rules in [`skills/ops/scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md), the framework stops at step 3 or 4 of the evaluation chain and permits only documentation updates or authorization material supplementation, blocking all active commands.

### Can I manually set ready_for_act to true without completing the checklist?

While you can manually edit `work/<case>/scope.md` to set `signoff.ready_for_act: true`, the `skills/scripts/case-init.ps1` script provides an `-UpdateReadyFlag` parameter that validates conditions before flipping the flag. Manual bypass violates the framework's safety design and may result in out-of-scope operations or legal violations.

### Where is the scope.md file located for a specific case?

Each case stores its configuration in `work/<case>/scope.md`, where `<case>` is the unique case identifier created during initialization. This file is generated by `skills/scripts/case-init.ps1` and resides in the case-specific subdirectory under the `work/` folder.

### Which network_profile.mode values satisfy the ready-to-ACT requirement?

The `network_profile.mode` must be explicitly set to one of four values: `offline`, `lab_only`, `authorized_target_only`, or `unrestricted_lab`. The presence of any of these values—not null or empty—satisfies the checklist requirement, though each mode carries different connectivity restrictions defined in the Scope Contract.