Verification (Definition Of Done)

Use this skill after implementing changes (or before marking a ticket “done”) to produce a clear, repeatable verification record.

This skill is cross-cutting: it applies regardless of whether the change was Terraform/Terragrunt, Helm, GitHub Actions, or a Kubernetes rollout.

Outcomes

• Prevent false “fixed” claims by requiring explicit, recorded evidence
• Make rollback readiness explicit
• Produce a skimmable verification section suitable for PR description and ticket updates

Where This Fits In The Flow

• Use after implementation work and before infra-kit.workflow.audit (or as part of the final readiness gate).
• Use to fill implementation-notes.md and to complete plan.md Verification with real outputs.

Output Rules

• Always write verification evidence to the repo (not only chat output).
• Prefer writing into the active work item:
• docs/infras-kit/work-items/<id>-<slug>/implementation-notes.md
• and/or add a short verification.md in the same folder when the evidence is large.
• List only commands that were actually run, and capture the observed outputs (or summaries with links/files).

Workflow

1. Confirm the “definition of done” inputs:

• acceptance criteria from ticket.md
• verification intent from plan.md

1. Build a verification matrix (AC -> check -> expected -> observed).
2. Run the strongest deterministic checks available for the change surface:

• IaC: terraform fmt/validate/plan or terragrunt validate/plan
• Helm: helm lint, helm template, schema validation (kubeconform), dry-run apply when safe
• GitHub Actions: actionlint when available; confirm permissions and triggers by inspection
• Kubernetes runtime: kubectl get/describe/logs evidence (read-only first)

1. Capture evidence:

• commands run
• key outputs (or file paths to captured outputs)
• what was not run and why (missing creds, missing tools, no cluster access)

1. Rollout and rollback readiness:

• what was rolled out (or not)
• rollback trigger and exact rollback steps

1. Close with remaining risks and follow-ups.

Verification Record Template

Write the following (at minimum) into implementation-notes.md or verification.md:

• Scope verified:
• Acceptance criteria verification matrix:
• Commands run:
• Observed evidence:
• Skipped checks (and why):
• Rollback readiness:
• Residual risks:

Guardrails

• Do not claim “verified” unless you can point to a command output, log excerpt, or explicit inspected file.
• If verification requires prod access, ask for approval and limit blast radius (read-only first).