operational-closure

name	operational-closure
description	Produce release-readiness, monitoring, rollback, and feedback artifacts that close the loop after implementation and verification - Brought to you by microsoft/hve-core

Operational Closure

Turn "implemented" into "safely absorbed by the running system". This skill creates the artifacts and decisions that close the loop after code review, CI, and runtime verification.

When to Use

Invoke when a feature, fix, or risky change is ready to hand off into merge, deployment, or post-deploy monitoring.

Inputs

• mode: (Required) One of pre-merge, post-merge, or post-deploy.
• context: (Required) PR, task, feature, or release context.
• verification_report: (Optional) Path to the runtime verification report.

Output

• Closure artifact at docs/closure/{YYYY-MM-DD}-{slug}-closure.md
• Explicit go/no-go or ready/blocked recommendation
• Follow-up tasks or compound-learnings triggers when needed

Required Protocol

When the agent-intercom capability pack is installed, follow .github/instructions/agent-intercom.instructions.md: broadcast closure readiness, blocked states, monitoring handoff details, and any rollback trigger that the operator should be aware of during the validation window.

When the browser-verification capability pack is installed, also follow .github/instructions/browser-verification.instructions.md: carry browser verification evidence, human-checkpoint outcomes, and browser-specific post-deploy checks into the closure artifact instead of treating them as side notes.

When the strict-safety capability pack is installed, also follow .github/instructions/strict-safety.instructions.md: carry the risky ProposedAction entries, their ActionRisk, approval path, and final ActionResult into closure artifacts when those details matter to rollout, monitoring, or rollback.

When the release-observability capability pack is installed, also follow .github/instructions/release-observability.instructions.md: integrate the monitoring plan (SLIs, dashboards, alert thresholds), pre-deploy audit results, post-deploy observation window (owner, duration), and rollback triggers into the closure artifact as structured sections rather than ad hoc notes.

Step 1: Gather Closure Context

Collect:

• Summary of the change
• CI status and unresolved review items
• Runtime verification report (required when runtime surfaces were changed) — including verdict (PASS / PASS WITH FOLLOW-UP / FAIL / BLOCKED), evidence, and follow-up recommendations. If verification was BLOCKED, record the blocked status and the missing prerequisite as a closure condition.
• Any risky actions that required approval, rollback planning, or explicit containment
• Affected runtime surfaces
• Deployment or release path, if applicable
• Invariants that must remain true after release
• Data, migration, or rollout-sensitive behavior that could require extra monitoring

Step 2: Build the Closure Checklist

The closure artifact MUST include:

• Invariants to preserve — the behaviors or guarantees that cannot regress
• Pre-deploy audits — migrations, flags, config, access, or rollout prerequisites that must be checked before release
• Deployment or rollout path — merge-only, deploy, canary, phased rollout, maintenance window, or handoff path
• Post-deploy checks — the first concrete observations or smoke checks to run after release
• Risky action record — the ProposedAction entries that materially affected rollout or rollback, their ActionRisk, and final ActionResult
• Source artifact cleanup — stash entries removed (ID + reason tag) and deliberation artifacts archived (ID + reason tag) during this closure; list source artifact IDs not found (already cleaned up or never created). Omit this section when no features in the shipment have source_stash_id or source_deliberation_id populated.
• Healthy signals — what success should look like
• Failure signals — what indicates rollback or intervention is needed
• Monitoring plan — logs, dashboards, alerts, or smoke checks to watch
• Rollback trigger — the condition that should halt or reverse the rollout
• Rollback procedure — the actual rollback or mitigation action to take when the trigger fires
• Validation window — how long the change should be watched
• Owner — who is responsible for observing or acting

Step 3: Record Readiness Status

Return one of:

• READY — merge/deploy can proceed with the recorded monitoring plan
• READY WITH CONDITIONS — proceed only if named conditions are satisfied
• BLOCKED — missing verification, unclear rollback path, or unresolved runtime risk

Step 4: Feed Back into the Harness

When the closure process reveals durable knowledge:

• Invoke compound for new runtime, deployment, or workflow learnings
• Update documentation if the release process or architecture knowledge changed
• Add tuning proposals if the harness lacked a needed safety mode, verification pattern, or reviewer

Why This Skill Exists

Operational closure is the compositional bridge from code production to safe absorption. It makes runtime verification actionable, keeps PRs honest about monitoring expectations, and turns release outcomes into future harness improvements.

Quality Criteria

• Closure artifacts include concrete release and monitoring signals, not generic advice
• Pre-deploy and post-deploy checks are explicit when the change has runtime or rollout risk
• Risky actions and their outcomes are visible when they affect release safety
• Rollback triggers and rollback procedures are explicit and actionable
• Ownership and validation windows are recorded
• Durable runtime learnings are fed back into the harness when appropriate

Model Routing

This skill operates at Tier 2 (Standard) — closure artifact assembly from defined inputs.

Generated by autoharness | Template: operational-closure/SKILL.md.tmpl