omh-deploy-and-monitor

# Deploy And Monitor This is a Hermes-native `deploy-and-monitor` workflow skill. ## 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 - The request is casual chat, a status-only acknowledgement, or another workflow has stronger routing evidence. - The user needs implementation, review, CI, merge, or external publishing evidence that has not been delegated or observed. ## 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 ...