How to Configure and Use the Case Guard Script Before ACT Execution

The case-guard script validates four mandatory conditions in scope.md—authorization status, network profile, in-scope assets, and ready-for-act flag—exiting with code 2 if checks fail to prevent premature ACT execution.

The reverse-skill repository relies on a strict scope-contract pattern to ensure every penetration test or reverse-engineering task stays within legal and ethical boundaries. Learning how to configure and use the case guard script before ACT execution is essential for operators who need to validate that work/<case>/scope.md satisfies all preconditions defined in skills/ops/scope-contract.md. This lightweight PowerShell gate runs automatically (or manually) immediately before the primary skill launches, blocking execution until the checklist is complete.

What the Case Guard Script Validates

The script located at skills/scripts/case-guard.ps1 (see lines 30-73) performs four non-negotiable inspections using regular-expression matches against the case’s scope.md file:

• Authorization status – Must find status: granted (or - status: granted) to confirm legal/ethical approval is recorded.

• Network profile – Requires network_profile.mode to be explicitly set. If the mode is offline, a sample cue must be present to justify the lack of network access.

• In-scope assets – Verifies at least one non-empty entry exists under ## in_scope → - assets: to ensure concrete targets are defined.

• Ready-for-ACT flag – Checks for ready_for_act: true (or - ready_for_act: true) acting as the explicit “go” signal.

If any check fails, the script aggregates issues and exits with code 2 (not ready). A usage or internal error causes exit 1, while a clean validation returns exit 0. Supplying the -Force switch suppresses the failure and forces exit 0 with warnings only.

Configuring the Guard

1. Initialize the Case with case-init.ps1

Rather than manually creating scope.md, use the generator to populate required fields automatically:

powershell -File skills/scripts/case-init.ps1 `
    -Hint "web pentest" `
    -CaseName my-case `
    -AuthGranted `
    -TargetUrl "https://target.example" `
    -NetworkProfile authorized_target_only

This command creates work\my-case\ and a starter scope.md (see template generation in case-init.ps1 lines 61-110) containing the mandatory YAML sections prepopulated with your arguments.

2. Manual Edits and Indentation Sensitivity

If you need custom values, edit work\<case>\scope.md directly:

• Ensure auth → status: granted is present.

• Set network_profile → mode to offline, lab_only, or authorized_target_only as appropriate.

• List target assets under ## in_scope → - assets: with each entry prefixed by -.

• Add ready_for_act: true when your checklist is complete.

Critical: The script uses regex matching to locate keys, so the exact indentation and bullet syntax shown in the generated file must be preserved. Changing - assets: to assets: or altering YAML indentation will cause validation failures.

3. Optional Bypass for Testing

To proceed despite warnings (useful for dry-runs), append the -Force flag:

powershell -File skills/scripts/case-guard.ps1 -CaseRoot work\my-case -Force

Running the Guard Before ACT Execution

The standard operator workflow follows three phases:

1. Initialize (once per engagement): Run case-init.ps1 to scaffold the case directory.
2. Verify (repeat while editing): Run case-guard.ps1 to poll scope.md until it passes.
3. Execute ACT: Only when the guard returns exit 0 should you invoke the primary skill.

# Verify scope before ACT

powershell -File skills/scripts/case-guard.ps1 -CaseRoot work\my-case

If the guard returns exit 2, the console output lists specific blockers:

CASE-GUARD NOT READY: work\my-case
 - auth.status is not granted
 - in_scope.assets appears empty
 - ready_for_act is not true

Fix the listed items, then re-run until you see "CASE-GUARD OK" (exit 0).

Practical Code Examples

Example 1 – Successful Validation

PS> powershell -File skills/scripts/case-guard.ps1 -CaseRoot work\my-case
CASE-GUARD OK: work\my-case

Example 2 – Missing Assets and Readiness Flag

PS> powershell -File skills/scripts/case-guard.ps1 -CaseRoot work\my-case
CASE-GUARD NOT READY: work\my-case
 - in_scope.assets appears empty
 - ready_for_act is not true

Example 3 – Forced Execution Despite Warnings

PS> powershell -File skills/scripts/case-guard.ps1 -CaseRoot work\my-case -Force
CASE-GUARD: -Force set; continuing with warnings only.
CASE-GUARD OK: work\my-case

Key Files and Implementation Details

File	Role
skills/scripts/case-guard.ps1	The gate script that validates scope.md using regex matches (lines 30-73).
skills/scripts/case-init.ps1	Generates the case directory and default scope.md with required fields (lines 61-110).
work/<case>/scope.md	Human-editable contract file; source of truth for auth, assets, and network mode.
skills/ops/scope-contract.md	Formal specification defining the required sections and valid values.
skills/ops/role-map.md	Reference for role assignments used in the scope checklist.

Summary

• The case-guard script acts as a mandatory gatekeeper that inspects scope.md immediately before ACT execution.
• It enforces four conditions: granted authorization, valid network profile, non-empty asset list, and ready_for_act: true.
• Exit code 2 signals "not ready" and blocks the ACT; exit code 0 allows execution to proceed.
• Use case-init.ps1 to generate properly formatted scope.md files, preserving indentation required by the regex parser.
• Append -Force to bypass validation failures when testing or debugging workflows.

Frequently Asked Questions

What exit code indicates the case is not ready for ACT execution?

The script exits with code 2 when validation checks fail (e.g., missing authorization or empty asset list). Exit 0 indicates success, while exit 1 signals a usage or internal error.

Can I run the ACT if the guard reports warnings?

By default, no. The guard intentionally blocks ACT execution on any non-zero exit. However, you can supply the -Force switch to case-guard.ps1 to convert failures into warnings and return exit 0, allowing the workflow to continue for testing purposes.

Why must indentation be preserved when editing scope.md?

The validation logic in case-guard.ps1 (lines 30-73) uses regular-expression matches to locate keys like - assets: and ready_for_act. AlteringWhitespace or removing the hyphen prefix causes the regex to miss the entry, triggering false-negative validation failures.

Where is the formal contract defining these requirements documented?

The authoritative specification resides in skills/ops/scope-contract.md within the reverse-skill repository. This document defines the mandatory YAML structure, acceptable values for network_profile.mode, and the semantic meaning of each gate-check implemented by case-guard.ps1.

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