Zurück zur Bibliothek

Change release record

Turns a proposed production change into a structured risk, test, approval, rollback, and verification record with traceable evidence. Use for change management, release readiness, deployment review, CAB preparation, rollback planning, and audit documentation.

von adlass TemplatesVersion 1Nutzt adlass-ToolsUniversell

Veröffentlicht 21. Aug. 2026 · Aktualisiert 26. Aug. 2026

Hilfreich · 0Rohes SKILL.md ansehen

Voraussetzungen

Add change, risk, approval, testing, and rollback policies. Define verification fields and release-note audience. Set required terminology and maintenance-window format.

Skill-Dokument

Das vollständige SKILL.md, das dein Agent liest und befolgt.

Change release record

Purpose

Assess whether a proposed production change is described well enough to understand risk, verify testing, identify required approvals, and recover if implementation fails. Produce a record that distinguishes evidence from planned work.

Scope

One change or release, its affected systems, test results, approval matrix, implementation plan, rollback plan, and post-change checks. Excluded: executing the change, granting approval, or notifying users.

Data basis

  • Change description, implementation steps, dependencies, and affected services.
  • Test results, risk policy, approval matrix, and rollback standard.
  • Release notes, incident history, and post-change observations when available.

Result

A change record, a structured log entry, and release notes containing risk, evidence, approvals required, recovery criteria, and verification status.

Quality criteria

  • Scope, impact, dependencies, and implementation window are explicit.
  • Test evidence names environment, result, date, and coverage.
  • Rollback triggers and verification checks are measurable.
  • Required approvals are derived from the supplied matrix, not assumed.

Instructions

Separate planned actions from completed evidence. Treat missing test or rollback details as gaps. Use the company risk classification; if absent, label the classification indicative. Never state that a change is approved because an approver is named. Preserve technical identifiers and version values exactly.

The review should make the population, calculation basis, and exception treatment understandable to a second operator. Preserve source identifiers in every working table, and state the effect of missing evidence on the decision. A reviewer must be able to reproduce each material result from the cited rows, clauses, dates, or policy rules. Where two sources disagree, show both values and explain which source was treated as authoritative.

Adapt before use

  • Add the change policy, risk matrix, approval matrix, and rollback standard.
  • Define required test evidence and post-change verification fields.
  • Set release-note audience, terminology, and maintenance-window format.

Verwandte Skills

  • Access provisioning checklist

    Converts employee roles and lifecycle events into a system-by-system provisioning or deprovisioning checklist with approvals, dependencies, and audit evidence fields. Use for joiner, mover, leaver, role-change, access-request, and identity-control preparation.

  • Audit evidence pack

    Organizes audit requests into evidence tests, evaluates supplied documents for coverage and period, and produces a traceable evidence tracker with control narratives and gaps. Use for SOC, ISO, internal control, customer audit, certification, and audit-readiness preparation.

  • Backup and recovery verification

    Checks backup coverage, retention, failures, and recovery-test evidence against system criticality and recovery objectives, then produces a verification report and remediation list. Use for backup audits, disaster-recovery readiness, RTO/RPO reviews, resilience checks, and recurring IT control evidence.

  • Incident postmortem

    Reconstructs a technical incident from timelines, tickets, chats, monitoring evidence, and impact data, then produces a blameless postmortem with causes, gaps, and owned corrective actions. Use for service outages, security incidents, production failures, incident reviews, and lessons-learned reports.