Production Audit

This is an OMH production-audit workflow skill, projected for Agent Skills hosts (Claude Code, Codex, Cursor, opencode, OpenClaw, pi).

Why This Exists

production-audit gives OMH a preflight release surface so operators can see production risks before launch while OMH stays out of deploy and infrastructure execution.

Do Not Use When

• The user wants to implement a feature or fix; prepare a coding handoff first.
• The user wants incident/SLO analysis after production behavior; use reliability-review.
• The user wants a narrow code diff review; use code-review.

Examples

Good example:

• Prompt: production-audit 이 릴리즈가 운영에 나가도 되는지 테스트, CI, 롤백, 모니터링 기준으로 봐줘.
• Expected behavior: Prepare readiness_matrix/v1, release_gate_verdict/v1, rollback_and_monitoring_plan/v1, and missing-evidence list.
• Why: The request is release-readiness review, not implementation or deploy execution.

Bad example:

• Prompt: production-audit 지금 바로 prod 배포하고 정상이라고 말해줘.
• Expected behavior: Block deploy/health claims without observed operator evidence and route deploy to an explicit authorized workflow.
• Why: Production audit can assess readiness, but it cannot secretly deploy or observe live health.

Completion Checklist

• Findings or no-issue results are grounded in concrete file, artifact, command, or source evidence.
• Open questions, residual risk, and missing verification are named.
• Fixes or follow-up work are separate handoffs unless the user explicitly asked to implement them.

Recovery Notes

• If the reviewed target is missing, inspect the requested artifact or ask one target question.
• If independent verification is unavailable, report the gap and avoid an approval-style claim.

Use When

Use before launch, deploy, release, or public delivery when Hermes should check operational readiness and expose missing production evidence.

Strong routing signals: `production-audit`, `production audit`, `production readiness`, `prod audit`, `prod readiness`, `ready for production`, `ready to ship`, `ship readiness`, `release readiness`, `launch readiness`, `preflight audit`, `operational readiness`, `rollback readiness`, `프로덕션 준비`, `출시 준비`, `운영 준비`, `릴리즈 준비`, `롤백 준비`

Catalog Metadata

Category: review Phase: production-readiness Quality tier: production-readiness-gated Reasoning demand: standard

Quality bar:

• Name scope, environment, release channel, owners, and acceptable risk threshold.
• Check build/test/CI, security/privacy, performance, observability, rollback, docs/support, and release communication.
• Return GO, HOLD, or BLOCK only with evidence IDs and missing evidence.
• Convert remediation into explicit follow-up workflows instead of silently patching.

Required inputs:

• product, service, release, or artifact scope
• target environment and release channel
• known test, CI, deploy, observability, security, and support evidence
• rollback owner and acceptable risk threshold

Expected outputs:

• production_audit_plan/v1
• readiness_matrix/v1
• release_gate_verdict/v1
• rollback_and_monitoring_plan/v1
• risk_register/v1
• not-evidence boundary

Artifact expectations:

• readiness_matrix/v1 covering build, tests, CI, security/privacy, performance, observability, rollback, docs/support, and release communication
• release_gate_verdict/v1 with GO, HOLD, or BLOCK plus missing evidence
• rollback_and_monitoring_plan/v1 with health signals, owner, threshold, and recovery path

Artifact contracts:

This label denotes the machine-enforcement level, not a skill quality score and not an observed evidence state.

• contract_id: readiness_matrix/v1; enforcement_level: executable_validated; consumer_id: parse_readiness_matrix

Safety rules:

• Do not claim production deploy, security scan, live traffic, monitoring health, rollback readiness, or support readiness without observed evidence.
• Do not perform deploy, infra, credential, production, or external-platform actions from the audit lane.
• Keep readiness verdict separate from implementation, CI, incident closure, or merge evidence.

Runtime Evidence

Use the current host's own tools and subagent/task mechanism when available; otherwise run the same lanes sequentially or name the unavailable capability. A prepared plan, handoff, checklist, or skill installation is not execution, review, CI, merge-readiness, or merge evidence. Record actual tool results, or not_observed / not_available, in the record; never invent dispatch or host accounting. Treat supplied context as advisory, not proof of hidden memory reads or writes. State scope, constraints, verification, and the stop condition before work. Reply in the user's own words and the host's own voice: OMH's record terms (surface, lane, wrapper, handoff, evidence boundary, not_observed) stay in records and tool calls, never in the sentence the user reads unless they ask about one; and when a stop condition or a decision the user owns ends the turn, offer the next action as a question rather than declaring what will not be done. Supporting paths are relative to this skill directory; sibling skill paths are relative to its parent. Resolve them from the host-provided skill base directory ({baseDir} on hosts that provide it), never a hardcoded install location. A named workflow not installed here is unavailable, not permission to emulate its host-specific capabilities. Verify through the real surface before done.