sysop-kernel

ledzepp1109's avatarfrom ledzepp1109

Run the SYSopGPTWSL operator kernel (repeatable sysop pipeline + diffable report + learning ledger). Use when asked to run sysop checks, collect Windows/WSL snapshots, benchmark, or produce the operator report.

⭐0stars🔀0forks📁View on GitHub🕐Updated Jan 5, 2026
[IT Helpdesk and Runbooks]

When & Why to Use This Skill

The SYSopGPTWSL operator kernel is a specialized system administration tool designed for WSL2 and Windows environments. It automates essential sysop tasks including health checks, performance benchmarking, and security hardening through a repeatable pipeline. By generating diffable reports and maintaining a learning ledger, it enables users to track configuration drift, optimize Windows-WSL interoperability, and ensure system stability with auditable evidence.

Use Cases

  • Automated System Health Auditing: Running comprehensive preflight and health checks to ensure WSL2 and Windows environments are configured correctly.
  • Drift Detection and Baseline Verification: Identifying unauthorized or accidental changes in system configuration by comparing current snapshots against established baselines.
  • Performance Troubleshooting: Benchmarking WSL2 performance and diagnosing interop bottlenecks related to power plans, storage inventory, or UNC path issues.
  • Security Hardening and Compliance: Executing Windows-specific hardening signals and collecting evidence for system integrity via PowerShell-driven snapshots.
namesysop-kernel
description>-
SYSopGPTWSLrun a repeatable sysop pipeline (preflight, WSL healthcheck,
short-descriptionRun sysop operator kernel
version1.0.0
codex-version">=0.76.0"

SYSop Operator Kernel

Follow AGENTS.md (Plan-first; worktrees per task when parallel; verification required; auditable notes).

Plan mode (no writes yet)

  1. Read AGENTS.md, then sysop/README_INDEX.md (index-first).
  2. Restate the operator goal (health/drift/snapshot/bench/report).
  3. Define “done means…”:
    • fresh artifacts under sysop/out/ (at least sysop/out/report.md)
    • if ./sysop/run.sh is executed: a new entry appended to learn/LEDGER.md
  4. Hypotheses (when something fails):
    • Windows interop unavailable (for example powershell.exe/vsock errors)
    • UNC cwd issues (Windows commands must run from /mnt/c)
    • systemctl bus blocked in the Codex runner (expected)
  5. Minimal evidence (read-only) to gather as needed:
    • ./sysop/preflight.sh
    • ./sysop/healthcheck.sh
    • command -v powershell.exe || command -v pwsh.exe (if Windows snapshot is requested)
  6. Propose the exact ./sysop/run.sh ... command(s) and STOP for approval:
    • ./sysop/run.sh all (writes under sysop/out/ and appends to learn/LEDGER.md)
    • Optional (repo-scoped auto-fix + script generation): ./sysop/run.sh all --apply-fixes

Execution mode (after approval)

  • Run the approved ./sysop/run.sh ... command(s) from repo root.
  • Return results using the repo output format (see AGENTS.md), including:
    • report path: sysop/out/report.md
    • “Top bottlenecks” excerpt (if present)
    • latest learn/LEDGER.md excerpt (3–8 lines)

Safety

  • No destructive ops (rm -rf, git reset --hard, git clean -fdx).
  • No writes outside the repo or to /etc.
  • No internet fetches.

For details and rationale, see references/OPERATOR_KERNEL.md.