Deploy And Monitor

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

Why This Exists

deploy-and-monitor exists to keep monitoring work explicit, evidence-backed, and inside the Hermes/executor boundary instead of relying on ad hoc chat narration.

Do Not Use When

• An incident has already been declared and the work is commanding it -- severity, commander, running timeline, recovery verification -- rather than watching a release; use omh-live-incident-response.
• The ask is deciding a release before it ships -- what goes in, its version and tag, the canary stages, or which command rolls it back; use omh-release-cut, which writes the rollback trigger down before it is needed.
• The change is to declared infrastructure itself -- a Terraform plan, a Kubernetes manifest, a Helm chart -- and needs its drift, blast radius, and cost delta read before it is applied; use omh-iac-change.

Examples

Good example:

• Prompt: deploy-and-monitor: prepare the release monitor, rollback signals, health checks, and post-deploy status card.
• Expected behavior: Create release monitoring guidance with deployment, metric, rollback, and observation boundaries.
• Why: The request is about deploy readiness and monitoring rather than code review alone.

Bad example:

• Prompt: deploy-and-monitor: treat casual chat or unaccepted work as if this workflow already produced verified results.
• Expected behavior: Ask a clarification question or route to a narrower workflow instead of forcing deploy-and-monitor.
• Why: The request lacks the required inputs or would overclaim work that Hermes did not observe.

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.