Omh Workspace Audit

Workspace Audit

This is a Hermes-native workspace-audit workflow skill.

Why This Exists

workspace-audit gives OMH an ECC-inspired but OMH-native front door for understanding a large agent workspace before strengthening it, without turning inventory into hidden mutation or runtime proof.

Do Not Use When

• The user already named a concrete implementation task with files and acceptance criteria; use the coding handoff or delivery workflow.
• The request is local OMH installation health only; use doctor.
• The request is a source acquisition or current web lookup; use source-finder or research.

Examples

Good example:

• Prompt: workspace-audit OMH에 스킬/프롬프트/플러그인 표면이 어디 비어있는지 먼저 점검해줘.
• Expected behavior: Prepare workspace_audit_plan/v1, observed surface_inventory/v1, gap matrix, redacted config findings, and downstream workflow recommendation.
• Why: The user asks for repo/workspace capability strengthening based on observed local surfaces.

Bad example:

• Prompt: workspace-audit 발견한 config 파일을 바로 고치고 secret 값도 출력해줘.
• Expected behavior: Refuse secret disclosure, keep the audit read-only, and prepare a separate remediation handoff if needed.
• Why: Workspace audit is inventory and risk mapping, not unsafe config mutation or secret extraction.

Completion Checklist

• Confirm the workflow target, evidence boundary, and stop condition are named.
• Report which outputs are prepared, observed, blocked, or missing.
• Name the smallest next verification or handoff instead of claiming completion from narration.

Recovery Notes

• If required context is missing, ask one blocking question or route back to the narrower workflow.
• If runtime or wrapper evidence is unavailable, keep the status as not_observed and expose the next observable action.

Workflow Lane

• Current lane: Automation and status (achievements, workspace-audit, production-audit, live-incident-response, automation-blueprint, github-event-ops, github-issue-intake, buzz, +39 more) - schedules, status, health, and ops review.
• If intent belongs to another lane, hand back to oh-my-hermes or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: omh-routing/references/skill-common-rail.md.

Use When

Use when Hermes should inspect the local repo/workspace/operator surface and produce a safe inventory, risk map, and gap list before planning, routing, or feature strengthening.

Strong routing signals: `workspace-audit`, `workspace audit`, `repo surface audit`, `repository surface audit`, `workspace surface audit`, `repo inventory`, `surface inventory`, `skill inventory`, `prompt inventory`, `plugin inventory`, `mcp inventory`, `hook inventory`, `config audit`, `what are we missing`, `audit this repo`, `레포 감사`, `워크스페이스 감사`, `설정 감사`, `스킬 인벤토리`

Catalog Metadata

Category: operations Phase: workspace-audit Hermes role: operator Quality tier: workspace-audit-gated Reasoning demand: light

Quality bar:

• Name the audit scope, root, exclusions, and downstream decision before inspecting.
• Separate discovered surfaces, inferred relationships, missing evidence, risks, and candidate fixes.
• Rank gaps by user impact, operational risk, and reviewability rather than by file count.
• Route code changes, setup repair, security fixes, or skill updates into later explicit workflows.

Handoff policy:

Keep the audit as Hermes-retained local evidence gathering. Prepare executor handoff only for later code changes, and record file reads, tool availability, config checks, and runtime observations only when observed.

Required inputs:

• workspace or repo root
• audit scope: repo, skills, prompts, plugins, MCP/tools, hooks, config, docs, runtime artifacts
• known constraints such as no secrets, no network, or read-only mode
• desired downstream decision or strengthening goal

Expected outputs:

• workspace_audit_plan/v1
• surface_inventory/v1
• capability_gap_matrix/v1
• config_security_findings/v1
• downstream_workflow_recommendation/v1
• not-evidence boundary

Artifact expectations:

• workspace_audit_plan/v1 with target root, scopes, exclusions, and read-only boundary
• surface_inventory/v1 with repo, skill, prompt, plugin, MCP/tool, hook, config, docs, and runtime surfaces when observed
• capability_gap_matrix/v1 with missing, duplicate, stale, risky, and high-leverage strengthening candidates
• redacted config_security_findings/v1 when secrets, permissions, or external integrations are mentioned

Safety rules:

• Do not mutate repo files, installed skills, prompts, configs, plugins, MCP servers, hooks, secrets, or runtime state from the audit lane.
• Never print secret values; record only redacted key names, file paths, and risk categories.
• Do not claim a surface exists, is loaded, or is reachable unless file, CLI, wrapper, or supplied evidence was observed.
• Keep audit findings separate from implementation, setup repair, security remediation, or skill mutation.