Rhel Devops Auditor

RHEL DevOps Auditor

When to Use

• User says "audit this project", "check compliance", "run an audit"
• User asks "how does this project compare to standards"
• After scaffolding a project, to validate completeness
• User wants to identify gaps before submitting for review
• User asks "what's missing" or "what do I need to fix"
• User asks to verify project structure against best practices

Do NOT use this skill for:

• Refactoring AgnosticD configs directly — use agnosticd-refactor (this skill audits and recommends, that skill executes)
• Validating a live running deployment — use agnosticd-deploy-test or student-readiness (this skill can dispatch to those)
• Creating a new project from scratch — use ./install.sh scaffold first, then audit

Instructions

This skill defines a four-module audit process. Each module checks a specific domain against documented standards. Run all modules by default (full audit) or individual modules on request.

Key behaviors:

• Always produce a structured report with PASS/WARN/FAIL per check
• Always produce a prioritized remediation plan when failures exist
• Remediation actions must include executable commands, not just descriptions
• Reference specific file paths and line numbers in findings
• Distinguish between BLOCKING (must fix), HIGH (should fix), and MEDIUM (nice to fix)
• If a module cannot run (e.g. no cluster credentials for deployment audit), mark it SKIP with a reason

Gotchas

• The auditor dispatches to other skills — it does NOT perform deep checks itself. If agnosticd-refactor or student-readiness are not installed, those check categories will be skipped
• Audit results are point-in-time — a PASS can become a FAIL if the environment changes between audit and student access
• The --mode full default runs ALL check categories, which can take 10+ minutes on large deployments — use --mode quick for fast pre-flight checks
• WARN severity means "works but not ideal" — do NOT block a demo on WARNs unless the user explicitly asks for strict compliance
• Remediation commands in the report are generated, not tested — always review before executing, especially oc delete commands

Audit Modes

Ask the user which mode they want if not specified. Default to full.

Required Input

Module 1 — AgnosticD Config Audit

Standards source: agnosticd-refactor skill (Audit Areas 1-7)

Checks

How to check

• Scan ansible/configs/, ansible/roles/, and vars directories
• Verify file presence and YAML structure
• grep for hardcoded patterns: passwords, tokens, keys in plain text
• Validate variable naming conventions

Module 2 — Onboard Manifest Audit

Standards source: onboard skill's references/manifest-spec.md

Checks

How to check

• Parse onboard.yml with python3 + PyYAML
• Validate against schema fields
• Cross-reference .gitignore entries
• Check each prerequisite entry for completeness

Module 3 — Live Deployment Audit

Standards source: student-readiness + agnosticd-deploy-test skills

Checks

How to check

• Requires cluster credentials (kubeconfig path or API URL + token)
• Run oc / kubectl commands against target clusters
• Check route/ingress for Showroom accessibility
• Verify ConfigMaps/Secrets for credential injection
• If no credentials provided: mark entire module as SKIP

Module 4 — Project Structure Audit

Standards source: ./install.sh scaffold output (standard project pattern)

Checks

How to check

• File existence checks (test -f, test -x)
• grep Makefile for target names
• grep .gitignore for required entries
• grep deploy/teardown scripts for flag handling patterns
• Run shellcheck if available

Report Format

After running all applicable modules, produce this exact format:

=== RHEL DevOps Project Audit Report ===
Project: <name>     Date: <timestamp>
Type: <hub-student|demo|agnosticd-infra|unknown>
Mode: <full|config|manifest|deployment|structure>
Modules: <N>/4 run

Module 1: AgnosticD Config          <PASS|WARN|FAIL|SKIP> (<X>/<Y> checks)
Module 2: Onboard Manifest          <PASS|WARN|FAIL|SKIP> (<X>/<Y> checks)
Module 3: Live Deployment           <PASS|WARN|FAIL|SKIP> (<X>/<Y> checks)
Module 4: Project Structure         <PASS|WARN|FAIL|SKIP> (<X>/<Y> checks)

Overall: <READY|NEEDS ATTENTION> (<N> finding(s))
══════════════════════════════════════════════════════════════════

--- Findings ---

  [FAIL] <ID>: <description>
         File: <path>:<line> (if applicable)
  [WARN] <ID>: <description>
  ...

--- Remediation Plan (prioritized) ---

Priority 1 (BLOCKING):
  1. <finding description>
     Action: <exact command or edit to fix>

Priority 2 (HIGH):
  2. <finding description>
     Action: <exact command or edit to fix>

Priority 3 (MEDIUM):
  3. <finding description>
     Action: <exact command or edit to fix>

Scoring

• Module PASS: All checks in that module pass (0 failures, 0 warnings)
• Module WARN: All required checks pass but at least 1 warning
• Module FAIL: At least 1 required check failed
• Module SKIP: Module could not run (missing input data)
• Overall READY: All modules are PASS or WARN (no FAIL)
• Overall NEEDS ATTENTION: At least 1 module has FAIL

Remediation Plan Rules

1. Group by priority: BLOCKING first, then HIGH, then MEDIUM
2. Each item must have an Action field with one of:
   • An exact shell command to run
   • An exact file edit (show the content to add/change)
   • A reference to another skill to activate (e.g. "Activate agnosticd-refactor")
3. Order within priority: fix items that unblock other items first
4. If a scaffold would fix multiple items at once, recommend it: Action: ./install.sh scaffold --type <type> --output .
5. If the fix requires research: mark it as "(RESEARCH NEEDED)" and suggest activating the skill-researcher

Re-audit After Fixes

After the user applies fixes from the remediation plan, offer to re-run only the failed modules:

Re-running failed modules only:
  Module 2 (Onboard Manifest) — re-checking...
  Module 4 (Project Structure) — re-checking...

Skipping Module 1 (passed), Module 3 (skipped — no credentials).

Escalation

• AgnosticD config issues found → Recommend activating agnosticd-refactor to apply fixes
• Onboard manifest missing → Recommend ./install.sh scaffold --type <type> or manual creation per manifest-spec.md
• Deployment issues found → Recommend activating student-readiness or agnosticd-deploy-test
• Project structure gaps → Recommend ./install.sh scaffold --type <type> to generate missing files
• Research needed for a finding → Recommend activating skill-researcher