Reverse‑Skill Case Initialization Workflow and auth.status Requirement Explained

The reverse‑skill case initialization workflow requires auth.status: granted and a non‑offline network_profile before any target engagement can proceed.

The reverse‑skill framework enforces a strict, policy‑driven workflow for initiating cybersecurity investigations. This article breaks down the exact initialization process implemented in skills/scripts/case-init.ps1 and explains why the auth.status requirement acts as a mandatory safety gate.

Reverse‑Skill Case Initialization Workflow Overview

The entire workflow is orchestrated by the PowerShell script skills/scripts/case-init.ps1. When executed, this script creates a structured case directory under work/ and generates three core contract files that govern the investigation.

Core Contract Files Created

• scope.md — Case metadata, authentication status, in‑scope assets, and network profile
• timeline.md — Append‑only log of all actions taken on the case
• workitems.md — Kanban‑style task list for tracking investigation progress

Step‑by‑Step Initialization Process

The script follows nine distinct phases, each designed to enforce compliance before any active testing begins.

1. Determine the Case Name

If ‑CaseName is omitted, the script generates a slug from ‑Hint plus a timestamp (format: 20230814‑123456‑web‑pentest).

# Line 38-44 excerpt — name generation logic

if (-not $PSBoundParameters.ContainsKey('CaseName')) {
    $timestamp = (Get-Date -Format 'yyyyMMdd-HHmmss')
    $slug = ($Hint -replace '[^\w\s-]', '').ToLower().Trim() -replace '\s+', '-'
    $CaseName = "$timestamp-$slug"
}

2. Create the Case Directory Structure

The script builds work/<case>/ with three sub‑folders: evidence, notes, and report.

3. Resolve Authentication Status

The auth.status value is determined through a cascading resolution:

• Default: pending
• Override via ‑AuthGranted switch: forces granted
• Explicit via ‑AuthStatus <value>: validates against pending|granted|denied|unknown

# Line 70-81 excerpt — auth status resolution

$authStatusResolved = 'pending'
if ($AuthGranted) { $authStatusResolved = 'granted' }
if ($PSBoundParameters.ContainsKey('AuthStatus') -and -not [string]::IsNullOrWhiteSpace($AuthStatus)) {
    $candidate = $AuthStatus.Trim().ToLowerInvariant()
    $allowedAuth = @('pending','granted','denied','unknown')
    if ($allowedAuth -contains $candidate) { $authStatusResolved = $candidate }
}

4. Collect In‑Scope Assets

Sources assets from ‑TargetUrl, ‑InScopeAssets, or a fallback extracted from the hint URL.

5. Determine Network Profile

Uses ‑NetworkProfile or defaults to offline. When assets exist and auth is granted, the mode defaults to authorized_target_only. Common aliases (lab, auth, etc.) are normalized to canonical values.

6. Compute ready_for_act Flag

This is the critical enforcement point. The flag becomes true only when all three conditions are satisfied:

• auth.status = granted
• At least one asset is listed
• network_profile is not offline

# Line 124-139 excerpt — readiness check

$ready = $false
$netAllowsAct = ($networkMode -ne 'offline' -and -not [string]::IsNullOrWhiteSpace($networkMode))
if ($authStatusResolved -eq 'granted' -and $assets.Count -gt 0 -and $netAllowsAct) {
    $ready = $true
}

If any condition fails, the script emits warnings and maintains ready_for_act = false.

7. Optional Master Routing

If a primary skill is identified, master‑route.ps1 adjusts the primary skill reference in the scope.

8. Write Contract Files

All resolved values are persisted to scope.md, timeline.md, workitems.md, and a brief README.md. The ready_for_act flag appears in the scope.md checklist.

9. Print Summary

Final output displays case path, primary skill, auth.status, network_profile, and readiness status.

The auth.status Requirement: Hard Policy Enforcement

The auth.status requirement is not merely conventional—it is contractually binding across multiple governing documents.

Contractual Sources

Document	Governing Statement
scope.md template	"MUST NOT proceed if status != granted"
[RULES.md](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md) line 20	"MUST NOT ACT against targets until auth.status=granted and network_profile set"
[skills/ops/scope-contract.md](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md) line 65	Checklist requires auth.status = granted
[README_AI.md](https://github.com/zhaoxuya520/reverse-skill/blob/main/README_AI.md) line 42	"Set auth.status=granted + network_profile before any target ACT"

These documents create redundant enforcement: the framework physically prevents skill execution until the ready_for_act boolean evaluates to true, which cannot happen without explicit authorization.

Practical Example: Satisfying the Requirements

This invocation creates a fully authorized, ready‑for‑act case:

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

Omitting ‑AuthGranted or using ‑NetworkProfile offline would result in ready_for_act: false, blocking downstream skill execution.

Key Implementation Files

File	Role
skills/scripts/case-init.ps1	Core workflow: case creation, auth handling, contract generation
[skills/ops/scope-contract.md](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/ops/scope-contract.md)	Formal schema for required scope fields
[RULES.md](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md)	Repository‑wide policy enforcement
skills/scripts/master-route.ps1	Optional skill routing during initialization
[README_AI.md](https://github.com/zhaoxuya520/reverse-skill/blob/main/README_AI.md)	AI‑assisted usage guide

Summary

• The reverse‑skill case initialization workflow is implemented entirely in skills/scripts/case-init.ps1
• Three conditions must all be true for ready_for_act: auth.status = granted, assets defined, non‑offline network profile
• The auth.status requirement is enforced contractually across RULES.md, scope-contract.md, and README_AI.md
• Framework design physically blocks skill execution until authorization is explicitly granted
• Use ‑AuthGranted or ‑AuthStatus granted combined with a target‑accessible network profile to create actionable cases

Frequently Asked Questions

How does the reverse‑skill framework prevent unauthorized target engagement?

The framework computes a ready_for_act boolean during initialization. This flag remains false unless auth.status equals granted, at least one asset is defined, and the network profile permits external communication. Downstream skills check this flag before executing any offensive actions.

Can I override the auth.status requirement with a configuration file?

No. According to the source code in case-init.ps1 lines 70‑81, auth.status can only be set to pending, granted, denied, or unknown through explicit parameters. There is no configuration file bypass, and RULES.md line 20 explicitly prohibits acting without granted status.

What happens if I omit the network profile parameter?

The script defaults to offline at line 103. This automatically prevents ready_for_act from becoming true, since the readiness check at line 124 requires a non‑offline mode. You must explicitly specify authorized_target_only or another active profile.

Where is the authorization policy formally documented?

The auth.status requirement appears in four locations: the generated scope.md template, skills/ops/scope-contract.md line 65, RULES.md line 20, and README_AI.md line 42. This multi‑document approach ensures the policy is visible to human operators, AI assistants, and automated compliance checks.

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